From owner-ipsec@lists.tislabs.com Wed Aug 1 01:42:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f718gFs13805;
Wed, 1 Aug 2001 01:42:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25188
Wed, 1 Aug 2001 03:35:53 -0400 (EDT)
Message-Id: <3.0.3.32.20010801094510.007f3630@pop.wanadoo.fr>
X-Sender: jr.peulve@pop.wanadoo.fr
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Wed, 01 Aug 2001 09:45:10 +0200
To: Michael Choung Shieh <mshieh@netscreen.com>
From: Jean-Rene Peulve <jr.peulve@wanadoo.fr>
Subject: RE: IPSec performance statistics
Cc: "'Kopeikin, Roy A (Roy)'" <rkopeikin@lucent.com>,
Marc Solsona-Palomar <marc@iprg.nokia.com>,
Parijat Mishra <parijat@cwc.nus.edu.sg>, awank@future.futsoft.com,
ipsec@lists.tislabs.com
In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3607@NS-CA>
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 DAA25185
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Don't forget that IP tunneling + ESP adds around 52 bytes overhead. This is
almost 50% overhead on small packet. So wire speed is a dream.
At 10:18 31/07/01 -0700, Michael Choung Shieh wrote:
>
>The performance lost of ipsec processing depends on the architecture of the
>design and the size of packets. Some vendors can achieve wire-speed while
>the others only improve a little even with hardware acceleration. It's also
>easier to boost the performance for large size packets(1500bytes) than small
>size (64bytes).
>
>Hardware accelaration does reduce the difference of processing time between
>encryption algorithms. The differences between DES and 3DES processing may
>be less than 10%.
>
>I would say the performance really depends on the gateway you used. There
>are many reports and comparisons out there.
>
>--------------------------------------------
>Michael Shieh
>NetScreen Technologies, Inc
>350 Oakmead Parkway
>Sunnyvale, CA 94085
>TEL: (408)730-6060
>FAX: (408)730-6050
>Email: mshieh@netscreen.com
>--------------------------------------------
>
>-----Original Message-----
>From: Kopeikin, Roy A (Roy) [mailto:rkopeikin@lucent.com]
>Sent: Tuesday, July 31, 2001 9:26 AM
>To: Marc Solsona-Palomar
>Cc: Parijat Mishra; awank@future.futsoft.com; ipsec@lists.tislabs.com
>Subject: RE: IPSec performance statistics
>
>
>Marc,
>Do you think these cycles lost can bd quantified into performanc statistics?
>roy
>
>-----Original Message-----
>From: Marc Solsona-Palomar [mailto:marc@iprg.nokia.com]
>Sent: Tuesday, July 31, 2001 4:22 AM
>To: Kopeikin, Roy A (Roy)
>Cc: Parijat Mishra; awank@future.futsoft.com; ipsec@lists.tislabs.com
>Subject: Re: IPSec performance statistics
>
>
>IPsec processing implies an overhead. Even the fact to send the packet
>somewhere else (like to an accelerator card) means cycles lost. What an
>accelerator will provide is more unified results across different algorithms
>as the chips have been optimized for this type of processing.
>
>marc
>
>"Kopeikin, Roy A (Roy)" wrote:
>
>> Correct me if I'm wrong but I think this is a non-issue for corporate VPNs
>> since accelerator boards are typically integrated to handle the encryption
>> and decryption functions. It is unacceptable for VPNs to degrade
>> router/internework performance.
>> Roy
>>
>> -----Original Message-----
>> From: Parijat Mishra [mailto:mishrap@cwc.nus.edu.sg]
>> Sent: Monday, July 30, 2001 9:26 PM
>> To: awank@future.futsoft.com; ipsec@lists.tislabs.com
>> Subject: Re: IPSec performance statistics
>>
>> There will be lots of statistics, but they'll depend on the machines
>> used, and the packet size. However, my observation is that with
>> ESP-3DES, the time taken to process packets is almost doubled.
>>
>> It should be easy to run performance tests for your own setup.
>>
>> Parijat
>> ----- Original Message -----
>> From: "Awan Kumar" <awank@future.futsoft.com>
>> To: <ipsec@lists.tislabs.com>
>> Sent: Monday, July 30, 2001 12:26 PM
>> Subject: IPSec performance statistics
>>
>> | Hi,
>> | Can anybody provide some statistics on the percentage of change in
>> | performance (throughtput) due to the inclusion of IPsec in the IP
>> stack. Are
>> | there any statistics available which shows the reduction in
>> performance due
>> | to the use of DES or 3DES for ESP.
>> |
>> | Thanks in advance.
>> |
>> | Regards,
>> | Awan
>> |
>> | ----------------------------
>> | Awan Kumar Sharma
>> | Sr. Software Engg.,
>> | Future Software Ltd.,
>> | Chennai, India.
>> | Ph: 4330 550 Extn: 437
>> | (www.futsoft.com)
>> | ------------------------------
>> |
>> |
>
Jean-Rene Peulve
Les Tilleuls
Chemin de Vermillère
84.160 Cadenet
France
Tel: (33)4.90.68.36.86
Fax: (33)4.90.68.36.87
Email: jr.peulve@wanadoo.fr
From owner-ipsec@lists.tislabs.com Wed Aug 1 10:34:37 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f71HYbs11904;
Wed, 1 Aug 2001 10:34:37 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26432
Wed, 1 Aug 2001 12:16:36 -0400 (EDT)
Message-Id: <3.0.3.32.20010801092204.00ecec30@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Wed, 01 Aug 2001 09:22:04 -0700
To: Mike Fratto <mfratto@nwc.syr.edu>,
"Kopeikin, Roy A (Roy)" <rkopeikin@lucent.com>,
Parijat Mishra <parijat@cwc.nus.edu.sg>, awank@future.futsoft.com,
ipsec@lists.tislabs.com
From: Alex Alten <Alten@home.com>
Subject: RE: IPSec performance statistics
In-Reply-To: <5.0.2.1.2.20010731124944.04073690@128.230.92.5>
References: <80B684C5E29FD211AA8000A0C9CDD91908FCE8DB@il0015exch005u.ih .lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Could you provide specific URLs?
Thanks,
- Alex
At 01:01 PM 7/31/2001 -0400, Mike Fratto wrote:
>There have been several performance reviews published over the last several
>years. For more detailed information, read the test bed scenario and if you
>have specific questions about the testing, contact the author for details.
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Wed Aug 1 19:37:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f722bAs25617;
Wed, 1 Aug 2001 19:37:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27520
Wed, 1 Aug 2001 21:16:29 -0400 (EDT)
Date: Thu, 2 Aug 2001 03:22:32 +0200
From: Marco Ender <marco.ender@dungeonmaster.at>
X-Mailer: The Bat! (v1.53bis) Educational
Reply-To: Marco Ender <marco.ender@dungeonmaster.at>
X-Priority: 3 (Normal)
Message-ID: <1750576405.20010802032232@dungeonmaster.at>
To: ipsec@lists.tislabs.com
Subject: SPD Selector (Newbie) Question
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello,
i am writing on my diploma thesis about VPNs (not in english as you
may guess ;)) and have a question which may someone of you can answer.
If this is not the place to ask such questions i am sorry, but i
couldn´t find a newsgroup for IPSec, if there is another newsgroup or
list that fits better please tell me and i will no longer bother you
=)
In RFC2401 (Security Architecture for the Internet Protocoll) on page
17 it is mentioned that in the SPD there can be used IP-Adresses (and
adress ranges) or Identifiers like names. Now my question: Suppose i
want to use names, how does a security gateway match incoming
IP-packets from the local subnet (which should be sent secured over
the internet to somewhere else) to those names? The hosts will not
send identifiers along with every IP-packet i guess, so how does it
work? If every SPD-entry has to have ip-adresses in addition to the
name, what is the name good for?
hope you can help me
Marco
From owner-ipsec@lists.tislabs.com Wed Aug 1 20:19:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f723JHs26621;
Wed, 1 Aug 2001 20:19:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA27618
Wed, 1 Aug 2001 22:28:23 -0400 (EDT)
From: "David Carman" <dcarman@hw.midatlanticexpress.com>
To: <ipsec@lists.tislabs.com>
Cc: <David_Carman@nai.com>
Subject: RE: IPSec performance statistics
Date: Wed, 1 Aug 2001 22:35:10 -0400
Message-ID: <000001c11afb$c1a6eba0$6501a8c0@na.nai.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <000001c118af$d0d44440$0702060a@future.futsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Awan,
A data point that has a finite chance at usefulness for a Pentium II 400
MHz, FreeS/WAN (Linux), ESP, authentication only, is located at:
http://www.pgp.com/research/nailabs/cryptographic/adaptive-cryptographic.asp
Check out Figure 3 in our final report at:
http://download.nai.com/products/media/pgp/pdf/acsa_final_report.pdf
Regards - Dave Carman
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
David W. Carman, Principal Cryptographic Engineer
NAI Labs, The Security Research Division of Network Associates, Inc.
email: David_Carman@nai.com
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Awan Kumar
> Sent: Monday, July 30, 2001 12:27 AM
> To: ipsec@lists.tislabs.com
> Subject: IPSec performance statistics
>
>
> Hi,
> Can anybody provide some statistics on the percentage of change in
> performance (throughtput) due to the inclusion of IPsec in
> the IP stack. Are
> there any statistics available which shows the reduction in
> performance due
> to the use of DES or 3DES for ESP.
>
> Thanks in advance.
>
> Regards,
> Awan
>
> ----------------------------
> Awan Kumar Sharma
> Sr. Software Engg.,
> Future Software Ltd.,
> Chennai, India.
> Ph: 4330 550 Extn: 437
> (www.futsoft.com)
> ------------------------------
>
From owner-ipsec@lists.tislabs.com Thu Aug 2 05:24:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f72CO2s07708;
Thu, 2 Aug 2001 05:24:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28526
Thu, 2 Aug 2001 07:02:16 -0400 (EDT)
Message-Id: <3.0.5.32.20010802093146.050a29d0@smtp.datafellows.com>
X-Sender: joern@smtp.datafellows.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 02 Aug 2001 09:31:46 +0200
To: ipsec@lists.tislabs.com
From: Joern Sierwald <joern.sierwald@F-Secure.com>
Subject: Re: SPD Selector (Newbie) Question
In-Reply-To: <1750576405.20010802032232@dungeonmaster.at>
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 DAA28167
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 03:22 02.08.01 +0200, you wrote:
>Hello,
>
>i am writing on my diploma thesis about VPNs (not in english as you
>may guess ;)) and have a question which may someone of you can answer.
>If this is not the place to ask such questions i am sorry, but i
>couldn¥t find a newsgroup for IPSec, if there is another newsgroup or
>list that fits better please tell me and i will no longer bother you
>=)
>
Don't worry, you found the correct list.
>In RFC2401 (Security Architecture for the Internet Protocoll) on page
>17 it is mentioned that in the SPD there can be used IP-Adresses (and
>adress ranges) or Identifiers like names. Now my question: Suppose i
>want to use names, how does a security gateway match incoming
>IP-packets from the local subnet (which should be sent secured over
>the internet to somewhere else) to those names? The hosts will not
>send identifiers along with every IP-packet i guess, so how does it
>work? If every SPD-entry has to have ip-adresses in addition to the
>name, what is the name good for?
>
>hope you can help me
>
>Marco
"names" in the SPD are only used for the Phase 1, the authentication part.
The most natural ID for a computer is it's IP address. So you normally
put that into the certificate and send an ID payload containing the IP
address.
But there are situations where this won't work. Most common is
a client using dialup. Now this client has to use more other ID.
In this case the client might send the full distiguished name of
his certificate, not containing any IP address. In order to accept that,
the SPD might contain that distinguished name.
The same works for email addresses, which can be used as IKE ID payloads.
The client sends it, and the GW looks up his SPD for it.
>work? If every SPD-entry has to have ip-adresses in addition to the
>name, what is the name good for?
Well, this SPD-entry for the client will _not_ have an ip address in it.
In Phase 2, only IP addresses, ranges and subnets are used for ID payloads.
J–rn Sierwald, www.f-secure.com
From owner-ipsec@lists.tislabs.com Thu Aug 2 13:11:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f72KB8s27341;
Thu, 2 Aug 2001 13:11:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29794
Thu, 2 Aug 2001 15:01:11 -0400 (EDT)
Message-Id: <3.0.3.32.20010802120638.00e22c70@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Thu, 02 Aug 2001 12:06:38 -0700
To: "David Carman" <dcarman@hw.midatlanticexpress.com>,
<ipsec@lists.tislabs.com>
From: Alex Alten <Alten@home.com>
Subject: RE: IPSec performance statistics
Cc: <David_Carman@nai.com>
In-Reply-To: <000001c11afb$c1a6eba0$6501a8c0@na.nai.com>
References: <000001c118af$d0d44440$0702060a@future.futsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Based on your figure 3 and using the 3DES costs from Antoon
Bosselaers URL at http://www.esat.kuleuven.ac.be/~bosselae/fast.html,
I get the following per byte cycle costs on a Pentium.
IP-Only about 5 cycles/byte
IPSec w/o crypto about +6 cycles/byte
HMAC-SHA-1-96 about +13 cycles/byte
3DES about +14 to +15 cycles/byte (from Bosselaers url)
--------------------------------------
Total IPSEC w/SHA1 & 3DES is about 38 to 39 cycles/byte.
So I should see almost an order of magnitude (about 1/8) slow down
when IPSec is used between two hosts versus when just ordinary IP
is running. Does this correlate with what people are seeing in
actual IPSec deployments? Or is everyone only using hardware to
get around this problem (but introducing other problems like extra
cost and deployment issues).
Does anyone have metrics for SA setup costs, with and without IKE?
I've seen claims of about 1 setup (w/out IKE?) per second in hardware.
Any metrics for Pentium class PC's?
- Alex
At 10:35 PM 8/1/2001 -0400, David Carman wrote:
>Awan,
>
>A data point that has a finite chance at usefulness for a Pentium II 400
>MHz, FreeS/WAN (Linux), ESP, authentication only, is located at:
>
>http://www.pgp.com/research/nailabs/cryptographic/adaptive-cryptographic.asp
>
>Check out Figure 3 in our final report at:
>
>http://download.nai.com/products/media/pgp/pdf/acsa_final_report.pdf
>
>Regards - Dave Carman
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>David W. Carman, Principal Cryptographic Engineer
>NAI Labs, The Security Research Division of Network Associates, Inc.
>email: David_Carman@nai.com
>
>> -----Original Message-----
>> From: owner-ipsec@lists.tislabs.com
>> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Awan Kumar
>> Sent: Monday, July 30, 2001 12:27 AM
>> To: ipsec@lists.tislabs.com
>> Subject: IPSec performance statistics
>>
>>
>> Hi,
>> Can anybody provide some statistics on the percentage of change in
>> performance (throughtput) due to the inclusion of IPsec in
>> the IP stack. Are
>> there any statistics available which shows the reduction in
>> performance due
>> to the use of DES or 3DES for ESP.
>>
>> Thanks in advance.
>>
>> Regards,
>> Awan
>>
>> ----------------------------
>> Awan Kumar Sharma
>> Sr. Software Engg.,
>> Future Software Ltd.,
>> Chennai, India.
>> Ph: 4330 550 Extn: 437
>> (www.futsoft.com)
>> ------------------------------
>>
>
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Thu Aug 2 13:41:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f72Kfks28222;
Thu, 2 Aug 2001 13:41:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29980
Thu, 2 Aug 2001 16:03:28 -0400 (EDT)
Message-Id: <200108022009.f72K9hJ06140@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: Alex Alten <Alten@home.com>
cc: "David Carman" <dcarman@hw.midatlanticexpress.com>,
ipsec@lists.tislabs.com, David_Carman@nai.com
Subject: Re: IPSec performance statistics
In-reply-to: Your message of "Thu, 02 Aug 2001 12:06:38 PDT."
<3.0.3.32.20010802120638.00e22c70@mail>
Reply-to: sommerfeld@East.Sun.COM
Date: Thu, 02 Aug 2001 16:09:42 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Does anyone have metrics for SA setup costs, with and without IKE?
> I've seen claims of about 1 setup (w/out IKE?) per second in
> hardware.
That's really kind of pessimistic.
I'm reluctant to quote exact numbers on a product not yet shipping,
but the IPsec/IKE product I'm currently working on, running without
any specialized hardware, does considerably better than that when the
peers are "close" as the packet flies..
I can readily believe 1 second setup time *including* the IKE exchange
when the round trip time between peers is in the 100-200ms range.
Main mode + quick mode + first-user-traffic winds up being about 5
round trips, so network latency winds up being a dominant factor in
how long it takes to get things flowing..
- Bill
From owner-ipsec@lists.tislabs.com Thu Aug 2 19:28:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f732S2s05160;
Thu, 2 Aug 2001 19:28:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA00986
Thu, 2 Aug 2001 21:24:01 -0400 (EDT)
Message-ID: <3B69FF7B.85CF61@nortelnetworks.com>
Date: Thu, 02 Aug 2001 21:33:47 -0400
From: "Marcus Leech" <mleech@nortelnetworks.com>
Organization: Nortel Networks: Information Systems
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org,
ipsec@lists.tislabs.com
Subject: Position statement on IKE development
Content-Type: multipart/mixed; boundary="------------700C1CE7C41A16595853A0C3"
X-Orig: <mleech@nortelnetworks.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
--------------700C1CE7C41A16595853A0C3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm sending the attached ASCII TEXT document on behalf of myself, Jeff
Schiller, and
Steve Bellovin, to clarify our position with respect to IKE
development. It is our hope
that it will clarify, to some extent, some fuzziness in this area that
has evolved over
the last year or so.
--------------700C1CE7C41A16595853A0C3
Content-Type: text/plain; charset=us-ascii;
name="statement.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="statement.txt"
In the several years since the standardization of the IPSEC protocols
(ESP, AH, and ISAKMP/IKE), there have come to light several security
problems with the protocols, most notably the key-agreement protocol,
IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
Simpson, have shown that the security problems in IKE stem directly
from its complexity. It seems only a matter of time before more
analyses show more serious security issues in the protocol design that
stem directly from its complexity. It seems also, only a matter of
time, before serious *implementation* problems become apparent, again
due to the complex nature of the protocol, and the complex
implementation that must surely follow.
Despite the obviously complex nature of IKE, several proposals have
been put forward to extend ISAKMP/IKE in various ways, for various
purposes. Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and
others do nothing to improve the complexity situation with regard to
IKE as a whole. While many of these proposals are, individually,
based on sound engineering and reasonably prudent practice, when cast
in the larger context of IKE, it seems clear that they can do nothing
to improve the complexity picture.
It is with that in mind that the Security Area directors in the IETF,
with the consultation of appropriate people on the IESG and IAB, hereby
place a temporary moratorium on the addition of new features to IKE.
It is fairly clear that work on IKE should focus on fixing identified
weaknesses in the protocol, rather than adding features that detract
from the goal of simplicity and correctness.
We are concerned that trying to reuse too much of the IKE
code base in new protocols -- PIC and GDOI come to mind --
will lead to more complex (and hence vulnerable) implementations.
We suggest that implementors resist this temptation, with the
obvious exception of common library functions that perform
functions such as large modular exponentiations. Attempts
to share state or to optimize message exchanges are likely to
lead to disaster.
The Security Area Directors have asked the IPSEC working group to come
up with a replacement for IKE. This work is underway and is known in
the community as "Son of IKE". This effort is at serious risk of
suffering the "second system effect", where all the features that were
left out of the first version, end up in the second. For this to
happen would be a spectacular disaster, and very much detract from the
goal: to produce a more secure, simpler, and more robust version of IKE.
Arriving at this point has been exceedingly difficult and harrowing.
Understandably, egos have been bruised, and the "change not the IKE,
for it is subtle and quick to anger" position has been taken as a
personal afront by some members of the IPSEC community. Nothing could
be further from the intent of either of the Security Area directors.
If IKE is vulnerable, we must all share a burden of responsibility for
allowing it to get to the state it is in and we must all work together
to correct the problems.
The IPSEC community must act prudently in moving forward with a
replacement for IKE. The IPSEC auxillary groups (IPSRA, MSEC, IPSP)
must act with good judgment (chairs and members alike) in designing
protocols that don't interfere with the goal of security and
simplifying our IPSEC key-agreement protocol.
Marcus Leech (IESG)
Jeff Schiller (IESG)
Steve Bellovin (IAB)
--------------700C1CE7C41A16595853A0C3--
From owner-ipsec@lists.tislabs.com Thu Aug 2 19:43:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f732hus05565;
Thu, 2 Aug 2001 19:43:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01029
Thu, 2 Aug 2001 22:03:32 -0400 (EDT)
Message-Id: <200107271107.HAA06703@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt
Date: Fri, 27 Jul 2001 07:07:56 -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 : Responder Lifetime Notify Message for IKE
Author(s) : S. Fanning
Filename : draft-ietf-ipsec-ike-lifetime-00.txt
Pages : 5
Date : 26-Jul-01
This document describes how the RESPONDER-LIFETIME notify message,
used within the ISAKMP DOI can be used to facilitate lifetime
negotiation and rekeying.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-ike-lifetime-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-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: <20010726170632.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ike-lifetime-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010726170632.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Thu Aug 2 22:48:37 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f735mas08670;
Thu, 2 Aug 2001 22:48:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA01378
Fri, 3 Aug 2001 00:59:34 -0400 (EDT)
Message-Id: <3.0.3.32.20010802220454.00fc0530@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Thu, 02 Aug 2001 22:04:54 -0700
To: "Marcus Leech" <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
From: Alex Alten <Alten@home.com>
Subject: Re: Position statement on IKE development
In-Reply-To: <3B69FF7B.85CF61@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dear Marcus, Jeff and Steve,
May I make a suggestion given the seriousness of this?
Let's hold an international design competition to select a key
management protocol for IPSec in a manner similar to how NIST did
the AES selection (although I hope it takes less than 5 years).
Once we get to a final 5, then let's cryptanalyze them and select
the best one. In this manner hopefully we can avoid a 2nd debacle.
Sincerely,
- Alex Alten
At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote:
>I'm sending the attached ASCII TEXT document on behalf of myself, Jeff
>Schiller, and
> Steve Bellovin, to clarify our position with respect to IKE
>development. It is our hope
> that it will clarify, to some extent, some fuzziness in this area that
>has evolved over
> the last year or so.In the several years since the standardization of
the IPSEC protocols
>(ESP, AH, and ISAKMP/IKE), there have come to light several security
>problems with the protocols, most notably the key-agreement protocol,
>IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
>Simpson, have shown that the security problems in IKE stem directly
>from its complexity. It seems only a matter of time before more
>analyses show more serious security issues in the protocol design that
>stem directly from its complexity. It seems also, only a matter of
>time, before serious *implementation* problems become apparent, again
>due to the complex nature of the protocol, and the complex
>implementation that must surely follow.
...
>
>
>Marcus Leech (IESG)
>Jeff Schiller (IESG)
>Steve Bellovin (IAB)
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Thu Aug 2 23:29:54 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f736Trs15894;
Thu, 2 Aug 2001 23:29:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA01453
Fri, 3 Aug 2001 01:35:42 -0400 (EDT)
Message-ID: <002901c11bdf$9d1f0f80$ae0510ac@roc.com>
Reply-To: "lokesh" <lokeshnb@intotoinc.com>
From: "lokesh" <lokeshnb@intotoinc.com>
To: <ipsec@lists.tislabs.com>
Subject: problem with HMAC precomputes.
Date: Fri, 3 Aug 2001 11:16:12 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0024_01C11C0D.B3F64BA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0024_01C11C0D.B3F64BA0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hello all,
I'm doing a project on Ipsecurity and have come across a=20
problem. I'm sure some of you can help me with an answer
Many Crypto Accelerator Chips expect Ipsec application to=20
supply inner and outer digests of HMAC Authentication only once when Key =
is formed or a New SA is created, and they use those digests to =
Authenticate or to calculate ICV of packet using HMAC. Again Application =
need to supply inner and outer digests only if keys is changed or New SA =
is formed.=20
RFC 2104 on HMAC Keyed Hashing tells that packet processing using =
authentication mechanism of HMAC computation using MD5 or SHA can be =
enhanced by having precomputed inner and outer digests of
(K XOR ipad and K XOR opad , where K is Authentication Key, ipad 0x36 =
and opad is 0x5c as defined in RFC2104)
K_ipad and K_opad zero padded strings.
So that we need to to precompute these values only once when keys are =
created and can be used directly when there is a packet to process thus =
avoiding two hashes on Kipad and Kopad for every packet. however RFC =
does not tell about exact method of precomputing inner and outer digests =
of HMAC computation only once and using them untill key is changed.
In my case Authentication is failing because I'm not able to precompute =
the inner and outer digests correctly :( .
because, I dont have clear Idea on this aspect.
Can you tell me how it can be done ? I mean what is the Exact method to =
do this?
How Precomputed hashes on Kipad and Kopad are used=20
for Authenticating packet?
Thank You=20
Lokesh
------=_NextPart_000_0024_01C11C0D.B3F64BA0
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello all,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm doing a project on Ipsecurity and =
have come=20
across a </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>problem. I'm sure some of you can help =
me with an=20
answer</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Many Crypto Accelerator Chips expect =
Ipsec=20
application to </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>supply inner and outer digests of HMAC=20
Authentication only once when Key is formed or a New SA is created, and =
they use=20
those digests to Authenticate or to calculate ICV of packet using HMAC. =
Again=20
Application need to supply inner and outer digests only if keys is =
changed=20
or New SA is formed. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>RFC 2104 on HMAC Keyed Hashing =
tells that=20
packet processing using authentication mechanism of HMAC =
computation=20
using MD5 or SHA can be enhanced by having precomputed inner and =
outer=20
digests of</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> (K XOR ipad and </FONT><FONT =
face=3DArial=20
size=3D2>K XOR opad , where K is Authentication Key, ipad 0x36 and opad =
is 0x5c as=20
defined in RFC2104)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> K_ipad and K_opad zero padded=20
strings.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So that we need to to precompute =
these values=20
only once when keys are created and can be used directly when =
there=20
is a packet to process thus avoiding two hashes on Kipad and Kopad for =
every=20
packet. however RFC does not tell about exact method of precomputing =
inner and=20
outer digests of HMAC computation only once and using them untill =
key is=20
changed.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>In my case Authentication is failing =
because I'm=20
not able to precompute the inner and outer digests correctly :( =
.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>because, </FONT><FONT face=3DArial =
size=3D2>I dont have=20
clear Idea on this aspect.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Can you tell me how it can be done ? I =
mean what is=20
the Exact method to do this?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>How Precomputed hashes on Kipad and =
Kopad are used=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>for Authenticating packet?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Thank You </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Lokesh</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0024_01C11C0D.B3F64BA0--
From owner-ipsec@lists.tislabs.com Fri Aug 3 00:40:31 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f737eUs26906;
Fri, 3 Aug 2001 00:40:30 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01613
Fri, 3 Aug 2001 02:44:19 -0400 (EDT)
Message-Id: <3.0.3.32.20010802234951.00e4eb00@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Thu, 02 Aug 2001 23:49:51 -0700
To: "Marcus Leech" <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
From: Alex Alten <Alten@home.com>
Subject: Re: Position statement on IKE development
In-Reply-To: <3.0.3.32.20010802220454.00fc0530@mail>
References: <3B69FF7B.85CF61@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
After just reading the papers by Meadows, Schneier/Ferguson and
Simpson, I now have serious doubts that IPsec delivers the security
required by the Internet community.
This is a very serious issue.
To make a mistake of this caliber when so many firms have committed
large amounts of resources for software, board, ASIC and chip designs,
implementations and manufactures is a terrible thing.
I agree with Schneier & Ferguson. A security protocol/system cannot be
designed by a large committee, unlike many other successful insecure
protocols. Their suggestion to use a process like NIST's for selecting
the AES standard is an excellent one. It's a pity they did not suggest
it a decade ago. However it should be considered seriously not only
for the replacement of IKE, but possibly also for the modification or
simplification of the entire IPsec protocol suite. (I hesitate to say
the replacement of IPSEC given the tremendous repercussions of doing
so.)
- Alex
At 10:04 PM 8/2/2001 -0700, Alex Alten wrote:
>
>Dear Marcus, Jeff and Steve,
>
>May I make a suggestion given the seriousness of this?
>
>Let's hold an international design competition to select a key
>management protocol for IPSec in a manner similar to how NIST did
>the AES selection (although I hope it takes less than 5 years).
>Once we get to a final 5, then let's cryptanalyze them and select
>the best one. In this manner hopefully we can avoid a 2nd debacle.
>
>Sincerely,
>
>- Alex Alten
>
>
>At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote:
>>I'm sending the attached ASCII TEXT document on behalf of myself, Jeff
>>Schiller, and
>> Steve Bellovin, to clarify our position with respect to IKE
>>development. It is our hope
>> that it will clarify, to some extent, some fuzziness in this area that
>>has evolved over
>> the last year or so.In the several years since the standardization of
>the IPSEC protocols
>>(ESP, AH, and ISAKMP/IKE), there have come to light several security
>>problems with the protocols, most notably the key-agreement protocol,
>>IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
>>Simpson, have shown that the security problems in IKE stem directly
>>from its complexity. It seems only a matter of time before more
>>analyses show more serious security issues in the protocol design that
>>stem directly from its complexity. It seems also, only a matter of
>>time, before serious *implementation* problems become apparent, again
>>due to the complex nature of the protocol, and the complex
>>implementation that must surely follow.
>
>...
>
>>
>>
>>Marcus Leech (IESG)
>>Jeff Schiller (IESG)
>>Steve Bellovin (IAB)
>>
>--
>
>Alex Alten
>
>Alten@Home.Com
>
>
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Fri Aug 3 02:44:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f739i2s07765;
Fri, 3 Aug 2001 02:44:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA01941
Fri, 3 Aug 2001 04:48:14 -0400 (EDT)
Message-Id: <200107271107.HAA06703@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt
Date: Fri, 27 Jul 2001 07:07:56 -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 : Responder Lifetime Notify Message for IKE
Author(s) : S. Fanning
Filename : draft-ietf-ipsec-ike-lifetime-00.txt
Pages : 5
Date : 26-Jul-01
This document describes how the RESPONDER-LIFETIME notify message,
used within the ISAKMP DOI can be used to facilitate lifetime
negotiation and rekeying.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-ike-lifetime-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-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: <20010726170632.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ike-lifetime-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010726170632.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Fri Aug 3 07:21:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73ELvs16426;
Fri, 3 Aug 2001 07:21:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02507
Fri, 3 Aug 2001 09:28:17 -0400 (EDT)
Message-ID: <3B6AA869.73844050@storm.ca>
Date: Fri, 03 Aug 2001 09:34:33 -0400
From: Sandy Harris <sandy@storm.ca>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: msec@securemulticast.org
CC: ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
References: <3B69FF7B.85CF61@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Marcus Leech wrote:
> In the several years since the standardization of the IPSEC protocols
> (ESP, AH, and ISAKMP/IKE), there have come to light several security
> problems with the protocols, most notably the key-agreement protocol,
> IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
> Simpson, have shown that the security problems in IKE stem directly
> from its complexity. ...
For anyone who has not seen those papers, there are links to them at:
http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/web.html#analysis
From owner-ipsec@lists.tislabs.com Fri Aug 3 07:21:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73ELvs16427;
Fri, 3 Aug 2001 07:21:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02423
Fri, 3 Aug 2001 09:02:15 -0400 (EDT)
Message-ID: <490717515EE6D41187A60003470D713629D3DF@kanatamail.kanata.unispherenetworks.ca>
From: "Lordello, Claudio" <CLordello@unispherenetworks.com>
To: "'lokesh'" <lokeshnb@intotoinc.com>, ipsec@lists.tislabs.com
Subject: RE: problem with HMAC precomputes.
Date: Fri, 3 Aug 2001 09:08:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C11C1D.6B455620"
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_01C11C1D.6B455620
Content-Type: text/plain;
charset="windows-1252"
Just do a partial H transform to (K xor ipad) to get the inner digest and
another partial transform to (K xor opad) to get the outer digest. By
partial transform I mean apply the actual MD5/SHA1 transforms to the (K xor
*pad) block without the final padding (that will be done later when
computing the icv). The MD5 transform is described in RFC 1321 and SHA in
FIPS PUB 180-1.
Claudio.
-----Original Message-----
From: lokesh [mailto:lokeshnb@intotoinc.com]
Sent: Friday, August 03, 2001 1:46 AM
To: ipsec@lists.tislabs.com
Subject: problem with HMAC precomputes.
Hello all,
I'm doing a project on Ipsecurity and have come across a
problem. I'm sure some of you can help me with an answer
Many Crypto Accelerator Chips expect Ipsec application to
supply inner and outer digests of HMAC Authentication only once when Key is
formed or a New SA is created, and they use those digests to Authenticate or
to calculate ICV of packet using HMAC. Again Application need to supply
inner and outer digests only if keys is changed or New SA is formed.
RFC 2104 on HMAC Keyed Hashing tells that packet processing using
authentication mechanism of HMAC computation using MD5 or SHA can be
enhanced by having precomputed inner and outer digests of
(K XOR ipad and K XOR opad , where K is Authentication Key, ipad 0x36 and
opad is 0x5c as defined in RFC2104)
K_ipad and K_opad zero padded strings.
So that we need to to precompute these values only once when keys are
created and can be used directly when there is a packet to process thus
avoiding two hashes on Kipad and Kopad for every packet. however RFC does
not tell about exact method of precomputing inner and outer digests of HMAC
computation only once and using them untill key is changed.
In my case Authentication is failing because I'm not able to precompute the
inner and outer digests correctly :( .
because, I dont have clear Idea on this aspect.
Can you tell me how it can be done ? I mean what is the Exact method to do
this?
How Precomputed hashes on Kipad and Kopad are used
for Authenticating packet?
Thank You
Lokesh
------_=_NextPart_001_01C11C1D.6B455620
Content-Type: text/html;
charset="windows-1252"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META content="MSHTML 5.00.2919.6307" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=988355212-03082001>Just
do a partial H transform to (K xor ipad) to get the inner digest and another
partial transform to (K xor opad) to get the outer digest. By partial transform
I mean apply the actual MD5/SHA1 transforms to the (K xor *pad) block without
the final padding (that will be done later when computing the icv). The MD5
transform is described in RFC 1321 and SHA in FIPS PUB
180-1.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=988355212-03082001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=988355212-03082001>Claudio.</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> lokesh
[mailto:lokeshnb@intotoinc.com]<BR><B>Sent:</B> Friday, August 03, 2001 1:46
AM<BR><B>To:</B> ipsec@lists.tislabs.com<BR><B>Subject:</B> problem with HMAC
precomputes.<BR><BR></DIV></FONT>
<DIV><FONT face=Arial size=2>Hello all,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>I'm doing a project on Ipsecurity and have come
across a </FONT></DIV>
<DIV><FONT face=Arial size=2>problem. I'm sure some of you can help me with an
answer</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Many Crypto Accelerator Chips expect Ipsec
application to </FONT></DIV>
<DIV><FONT face=Arial size=2>supply inner and outer digests of HMAC
Authentication only once when Key is formed or a New SA is created, and they
use those digests to Authenticate or to calculate ICV of packet using HMAC.
Again Application need to supply inner and outer digests only if keys is
changed or New SA is formed. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>RFC 2104 on HMAC Keyed Hashing tells that
packet processing using authentication mechanism of HMAC
computation using MD5 or SHA can be enhanced by having precomputed inner
and outer digests of</FONT></DIV>
<DIV><FONT face=Arial size=2> (K XOR ipad and </FONT><FONT face=Arial
size=2>K XOR opad , where K is Authentication Key, ipad 0x36 and opad is 0x5c
as defined in RFC2104)</FONT></DIV>
<DIV><FONT face=Arial size=2> K_ipad and K_opad zero padded
strings.</FONT></DIV>
<DIV><FONT face=Arial size=2>So that we need to to precompute these
values only once when keys are created and can be used directly
when there is a packet to process thus avoiding two hashes on Kipad and Kopad
for every packet. however RFC does not tell about exact method of precomputing
inner and outer digests of HMAC computation only once and using them
untill key is changed.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>In my case Authentication is failing because I'm
not able to precompute the inner and outer digests correctly :( .</FONT></DIV>
<DIV><FONT face=Arial size=2>because, </FONT><FONT face=Arial size=2>I dont
have clear Idea on this aspect.</FONT></DIV>
<DIV><FONT face=Arial size=2>Can you tell me how it can be done ? I mean what
is the Exact method to do this?</FONT></DIV>
<DIV><FONT face=Arial size=2>How Precomputed hashes on Kipad and Kopad are
used </FONT></DIV>
<DIV><FONT face=Arial size=2>for Authenticating packet?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Thank You </FONT></DIV>
<DIV><FONT face=Arial size=2>Lokesh</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C11C1D.6B455620--
From owner-ipsec@lists.tislabs.com Fri Aug 3 07:31:45 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73EVjs16684;
Fri, 3 Aug 2001 07:31:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02603
Fri, 3 Aug 2001 09:39:10 -0400 (EDT)
Reply-To: <jeevas@future.futsoft.com>
From: "JEEVA" <jeevas@future.futsoft.com>
To: <ipsec@lists.tislabs.com>
Subject: ipsec design related questions.
Date: Fri, 3 Aug 2001 13:55:41 +0530
Message-Id: <000001c11bf6$fb099ae0$2a05080a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Disposition-Notification-To: "JEEVA" <jeevas@future.futsoft.com>
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi,
i just had a doubt - where is IPSec placed in the network stack?
conceptually, IPSec should be placed like this (please comment if wrong):
Design -1
+--------------------------------+
Tcp/udp
+--------------------------------+
IP other functions (Like routing etc.)
+--------------------------------+
IPSec
+--------------------------------+
low -level layer fuctions
+--------------------------------+
Design - 2 :
+--------------------------------+
tcp/udp
+--------------------------------+
IPsec
+-------------------------------+
IP other fuctions.
+------------------------------+
low-level layer functions
+-------------------------------+
Design -3 :
+-------------------------------+
tcp/udp
+-------------------------------+
IP/ IPsec
+------------------------------+
low -level layer functions.
+-----------------------------+
Design - 4:
+---------------------------------+
applications
+---------------------------------+
----------------------------------
some intermediate layer for making ipsec independent. (e.g to implement
socket layer )
-----------------------------------
---------------------------------
IPsec
-------------------------------
thnaks.
regards,
jeeva.
From owner-ipsec@lists.tislabs.com Fri Aug 3 07:33:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73EXks16734;
Fri, 3 Aug 2001 07:33:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02542
Fri, 3 Aug 2001 09:36:07 -0400 (EDT)
Message-Id: <200108022331.f72NVWB13759@marajade.sandelman.ottawa.on.ca>
To: sommerfeld@East.Sun.COM
cc: ipsec@lists.tislabs.com
Subject: Re: IPSec performance statistics
In-reply-to: Your message of "Thu, 02 Aug 2001 16:09:42 EDT."
<200108022009.f72K9hJ06140@thunk.east.sun.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 02 Aug 2001 19:30:28 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Bill" == Bill Sommerfeld <sommerfeld@East.Sun.COM> writes:
Bill> Main mode + quick mode + first-user-traffic winds up being about 5
Bill> round trips, so network latency winds up being a dominant factor in
Bill> how long it takes to get things flowing..
so long as there is enough CPU leftover, of course.
I'd be interested to know how long it takes before 1000 road warriors are
able to function again after rebooting the gateway :-)
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
From owner-ipsec@lists.tislabs.com Fri Aug 3 08:06:56 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73F6ts19313;
Fri, 3 Aug 2001 08:06:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02753
Fri, 3 Aug 2001 10:16:54 -0400 (EDT)
Date: Fri, 3 Aug 2001 10:23:20 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: JEEVA <jeevas@future.futsoft.com>
cc: ipsec@lists.tislabs.com
Subject: Re: ipsec design related questions.
In-Reply-To: <000001c11bf6$fb099ae0$2a05080a@future.futsoft.com>
Message-ID: <Pine.BSI.3.91.1010803102255.12632B-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, 3 Aug 2001, JEEVA wrote:
> i just had a doubt - where is IPSec placed in the network stack?
Please read RFC 2401, specifically section 3.3.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Fri Aug 3 08:12:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73FCvs19546;
Fri, 3 Aug 2001 08:12:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02741
Fri, 3 Aug 2001 10:15:29 -0400 (EDT)
Date: Fri, 3 Aug 2001 10:21:49 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Alex Alten <Alten@home.com>
cc: Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
In-Reply-To: <3.0.3.32.20010802234951.00e4eb00@mail>
Message-ID: <Pine.BSI.3.91.1010803100851.12632A-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 2 Aug 2001, Alex Alten wrote:
> ...Their suggestion to use a process like NIST's for selecting
> the AES standard is an excellent one. It's a pity they did not suggest
> it a decade ago. However it should be considered seriously not only
> for the replacement of IKE, but possibly also for the modification or
> simplification of the entire IPsec protocol suite...
I think this is throwing the baby out with the bathwater.
While the packet-level parts (ESP etc.) do have some flaws, most of those
can be fixed simply by taking a big black pen and crossing out superfluous
parts of the existing specs (e.g., all of RFC 2402). While there is room
for some debate about exactly which parts should be crossed out (e.g.,
there are people who still think AH is useful), I think there would be
little or no support for redesigning the surviving parts. So a design
competition does not seem very useful in this area. Moreover, *this* is
the area where there is massive investment in silicon, solder traces, etc.
Just deleting features does not, by and large, invalidate that investment.
IKE is the disaster area. The rest of IPsec could use some judicious
featurectomies, but is not badly broken.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Fri Aug 3 12:32:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73JWps28192;
Fri, 3 Aug 2001 12:32:51 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03847
Fri, 3 Aug 2001 14:18:36 -0400 (EDT)
Message-Id: <3.0.3.32.20010803112414.00eadaa0@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Fri, 03 Aug 2001 11:24:14 -0700
To: Henry Spencer <henry@spsystems.net>
From: Alex Alten <Alten@home.com>
Subject: Re: Position statement on IKE development
Cc: Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
In-Reply-To: <Pine.BSI.3.91.1010803100851.12632A-100000@spsystems.net>
References: <3.0.3.32.20010802234951.00e4eb00@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Several people have asked me for the urls of the paper's analyzing
IPsec and IKE. These are the ones I found searching the web last
night.
A Cryptographic Evaluation of IPsec
by Niels Ferguson and Bruce Schneier
http://www.counterpane.com/ipsec.pdf
Analysis of the Internet Key Exchange Protocol Using the NRL Protocol Analyzer
by Catherine Meadows
http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/1999/1999meadows-IEE
E99.ps
IKE/ISAKMP Considered Dangerous
by William Simpson
draft-simpson-danger-isakmp-01.txt
http://www.alternic.org/drafts/drafts-s-t/draft-simpson-danger-isakmp-01.html
BTW Henry,
The issue is not that parts of IPsec are superfluous.
The question is if IKE is broken then is IPsec also broken?
- Alex
At 10:21 AM 8/3/2001 -0400, Henry Spencer wrote:
>On Thu, 2 Aug 2001, Alex Alten wrote:
>> ...Their suggestion to use a process like NIST's for selecting
>> the AES standard is an excellent one. It's a pity they did not suggest
>> it a decade ago. However it should be considered seriously not only
>> for the replacement of IKE, but possibly also for the modification or
>> simplification of the entire IPsec protocol suite...
>
>I think this is throwing the baby out with the bathwater.
>
>While the packet-level parts (ESP etc.) do have some flaws, most of those
>can be fixed simply by taking a big black pen and crossing out superfluous
>parts of the existing specs (e.g., all of RFC 2402). While there is room
>for some debate about exactly which parts should be crossed out (e.g.,
>there are people who still think AH is useful), I think there would be
>little or no support for redesigning the surviving parts. So a design
>competition does not seem very useful in this area. Moreover, *this* is
>the area where there is massive investment in silicon, solder traces, etc.
>Just deleting features does not, by and large, invalidate that investment.
>
>IKE is the disaster area. The rest of IPsec could use some judicious
>featurectomies, but is not badly broken.
>
> Henry Spencer
> henry@spsystems.net
>
>
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Fri Aug 3 12:32:52 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73JWqs28200;
Fri, 3 Aug 2001 12:32:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03919
Fri, 3 Aug 2001 14:40:22 -0400 (EDT)
Message-Id: <200108031847.OAA06613@bcn.East.Sun.COM>
Date: Fri, 3 Aug 2001 14:47:15 -0400 (EDT)
From: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Subject: Another paper analyzing IKE
To: henry@spsystems.net, Alten@home.com
Cc: mleech@nortelnetworks.com, msec@securemulticast.org, ietf-ipsra@vpnc.org,
ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 7C6ZlrC1Nr0L0ACd3hyYAA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Analysis of the IPsec Key Exchange Standard, by
Radia Perlman and Charlie Kaufman
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf
(It's also summarized in an internet draft "code-preserving simplifications
and improvements to IKE" which is pointed to from the IPsec web page).
Radia
From owner-ipsec@lists.tislabs.com Fri Aug 3 12:32:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73JWvs28219;
Fri, 3 Aug 2001 12:32:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03839
Fri, 3 Aug 2001 14:14:31 -0400 (EDT)
Message-ID: <23051C9F9BABD411A7850002B30847992587BA@delta.allegrosys.com>
From: Bora Akyol <akyol@allegrosys.com>
To: "'Henry Spencer'" <henry@spsystems.net>
Cc: ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: RE: Position statement on IKE development
Date: Fri, 3 Aug 2001 10:48:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
As a newcomer to IPSec field (but not to the IETF) one of the things that
continues the amaze me is the deliberate effort that has been made to create
a wall between IKE and IPSEC. IKE is written such that it is a general
protocol
that can negotiate SAs for protocols other than IP such as AppleTalk, IPX,
...
Yet the primary (and possibly only use) of IKE is for negotiating IPSEC SAs
(in addition to the IKE SA). The IPSEC DOI (unfortunately) is also written
in
a pretty generic manner and does very little to aid a developer writing IKE
software from scratch. For example, what exactly IKE can negotiate with
respect to
IP selector fields and ranges is pretty much left to the interpretation of
the
developers.
IMHO, IPSEC SA negotiation also is the biggest cause of headaches in
interoperability problems between different implementations. Which I believe
was what
Henry was alluding to below.
Therefore, I would suggest that any effort in replacing IKE also consider
replacing/rewriting portions of IPSEC DOI such that:
1) Text is clear and one could write easily working code from it.
2) The IPSEC SA negotiation within IKE is well-defined and not open to
interpretation.
3) All error cases are documented and handling is clearly specified.
4) Some references added to the text to at least outline what to do when
negotiating behind a
NAT/firewall and refer to relevant RFCs/drafts.
As far as I am concerned, IKE is the moral equivalent of a signaling
protocol that
establishes connections (IPSEC SAs in IKE case) and should be specified in
enough
detail as such.
I have seen similar problems while developing MPLS code with the MPLS specs
but as we were writing software while the drafts were still drafts, most of
the complaints did get addressed
before they became RFCS.
Also note that I am making these suggestions with a constructive desire.
Regards,
Bora
ps. I would be willing to volunteer in such an effort as I described above.
|-----Original Message-----
|From: Henry Spencer [mailto:henry@spsystems.net]
|Sent: Friday, August 03, 2001 7:22 AM
|To: Alex Alten
|Cc: Marcus Leech; msec@securemulticast.org; ietf-ipsra@vpnc.org;
|ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
|Subject: Re: Position statement on IKE development
|
|
|On Thu, 2 Aug 2001, Alex Alten wrote:
|> ...Their suggestion to use a process like NIST's for selecting
|> the AES standard is an excellent one. It's a pity they did
|not suggest
|> it a decade ago. However it should be considered seriously not only
|> for the replacement of IKE, but possibly also for the modification or
|> simplification of the entire IPsec protocol suite...
|
|I think this is throwing the baby out with the bathwater.
|
|While the packet-level parts (ESP etc.) do have some flaws,
|most of those
|can be fixed simply by taking a big black pen and crossing out
|superfluous
|parts of the existing specs (e.g., all of RFC 2402). While
|there is room
|for some debate about exactly which parts should be crossed out (e.g.,
|there are people who still think AH is useful), I think there would be
|little or no support for redesigning the surviving parts. So a design
|competition does not seem very useful in this area. Moreover,
|*this* is
|the area where there is massive investment in silicon, solder
|traces, etc.
|Just deleting features does not, by and large, invalidate that
|investment.
|
|IKE is the disaster area. The rest of IPsec could use some judicious
|featurectomies, but is not badly broken.
|
| Henry Spencer
|
|henry@spsystems.net
|
|
From owner-ipsec@lists.tislabs.com Fri Aug 3 12:37:55 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73Jbts28329;
Fri, 3 Aug 2001 12:37:55 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04276
Fri, 3 Aug 2001 14:51:57 -0400 (EDT)
Message-Id: <200108031857.f73IviJ20038@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: Bora Akyol <akyol@allegrosys.com>
cc: "'Henry Spencer'" <henry@spsystems.net>, ietf-ipsra@vpnc.org,
ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
In-reply-to: Your message of "Fri, 03 Aug 2001 10:48:58 PDT."
<23051C9F9BABD411A7850002B30847992587BA@delta.allegrosys.com>
Reply-to: sommerfeld@East.Sun.COM
Date: Fri, 03 Aug 2001 14:57:44 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> As a newcomer to IPSec field (but not to the IETF) one of the things that
> continues the amaze me is the deliberate effort that has been made to create
> a wall between IKE and IPSEC.
Well, this is a good thing -- it means that if you get IKE wrong, it
can be replaced without having to toss the rest of the architecture.
The solaris implementation is structured specifically to allow for
this; we're extending PF_KEY and adding a PF_POLICY to allow for a
strong separation of concerns between packet protection policy, packet
protection mechanisms, and key management.
This is one of the reasons why we (me and my fellow implementors here)
don't want any ipsra authentication/cert provisioning protocols
running on port 500..
> Therefore, I would suggest that any effort in replacing IKE also consider
> replacing/rewriting portions of IPSEC DOI ...
Last I heard, the son-of-ike plan was to merge the DOI into the key
mgmt document.
I think we also need a better-defined interface between 2401 and the
KM protocol...
- Bill
From owner-ipsec@lists.tislabs.com Fri Aug 3 13:15:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73KFbs01803;
Fri, 3 Aug 2001 13:15:37 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04466
Fri, 3 Aug 2001 15:35:33 -0400 (EDT)
Date: Fri, 3 Aug 2001 15:41:57 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Alex Alten <Alten@home.com>
cc: Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
In-Reply-To: <3.0.3.32.20010803112414.00eadaa0@mail>
Message-ID: <Pine.BSI.3.91.1010803153453.15136D-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, 3 Aug 2001, Alex Alten wrote:
> BTW Henry,
> The issue is not that parts of IPsec are superfluous.
> The question is if IKE is broken then is IPsec also broken?
That depends somewhat on exactly what you mean by "IPsec", which is why I
specifically referred to "the packet-level parts". I don't think there is
much wrong with the packet-level stuff except for a few too many useless
options and alternatives. The key-management ugliness doesn't seem to me
to have spilled over into the packet level (at least partly because the
packet-level work was nearly finished before key management came to the
fore).
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Fri Aug 3 13:24:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73KODs02512;
Fri, 3 Aug 2001 13:24:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04450
Fri, 3 Aug 2001 15:22:44 -0400 (EDT)
Date: Fri, 3 Aug 2001 15:29:09 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: IP Security List <ipsec@lists.tislabs.com>
cc: ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org
Subject: Re: Position statement on IKE development
In-Reply-To: <200108031857.f73IviJ20038@thunk.east.sun.com>
Message-ID: <Pine.BSI.3.91.1010803152724.15136C-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, 3 Aug 2001, Bill Sommerfeld wrote:
> > Therefore, I would suggest that any effort in replacing IKE also consider
> > replacing/rewriting portions of IPSEC DOI ...
>
> Last I heard, the son-of-ike plan was to merge the DOI into the key
> mgmt document.
Realistically, there's no meaningful distinction between IKE and the DOI.
In fact, the separation between the two documents is a real nuisance when
one is looking for obscure details. They need to be considered as a unit.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Fri Aug 3 14:12:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73LC1s03897;
Fri, 3 Aug 2001 14:12:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04501
Fri, 3 Aug 2001 16:14:52 -0400 (EDT)
Message-Id: <3.0.3.32.20010803132027.00eae6b0@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Fri, 03 Aug 2001 13:20:27 -0700
To: Henry Spencer <henry@spsystems.net>
From: Alex Alten <Alten@home.com>
Subject: Re: Position statement on IKE development
Cc: Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
In-Reply-To: <Pine.BSI.3.91.1010803153453.15136D-100000@spsystems.net>
References: <3.0.3.32.20010803112414.00eadaa0@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Unfortunately what you and I think probably doesn't matter. What matters
is that end user customers will hear that IPsec's IKE is broken, and they
will then ask themselves the question, is all of IPsec also broken? It's
anyone's guess as to how this will play out in the VPN markets, etc.
My own personal question is why the IPsec working group did not have a
thorough cryptanalysis done by professionals, say by an outfit like ISSI,
before the standards were issued?
- Alex
At 03:41 PM 8/3/2001 -0400, Henry Spencer wrote:
>On Fri, 3 Aug 2001, Alex Alten wrote:
>> BTW Henry,
>> The issue is not that parts of IPsec are superfluous.
>> The question is if IKE is broken then is IPsec also broken?
>
>That depends somewhat on exactly what you mean by "IPsec", which is why I
>specifically referred to "the packet-level parts". I don't think there is
>much wrong with the packet-level stuff except for a few too many useless
>options and alternatives. The key-management ugliness doesn't seem to me
>to have spilled over into the packet level (at least partly because the
>packet-level work was nearly finished before key management came to the
>fore).
>
> Henry Spencer
> henry@spsystems.net
>
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Fri Aug 3 14:28:45 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73LSjs04231;
Fri, 3 Aug 2001 14:28:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04516
Fri, 3 Aug 2001 16:30:34 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA41@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Marcus Leech'" <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: RE: Position statement on IKE development
Date: Fri, 3 Aug 2001 13:37:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C11C5C.14D9EDC0"
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_000_01C11C5C.14D9EDC0
Content-Type: text/plain;
charset="iso-8859-1"
I have a different set of concerns, IPSEC is not being used in cases where
it should have been the answer.
In particular the IEEE 802.11b WEP fiasco could have been averted if the
designers had not been discouraged by the complexity of IPSEC.
Another issue is why can't I buy a printer that is IPSEC enabled?
I believe that the biggest problem with IPSEC is that the search for a
certain view of perfect security has lead to a standard that many have
bypassed altogether as too demanding.
Perfect Forward Secrecy is great, but I would rather have a secure means of
connecting to my printer than the possibility of a perfectly secure means in
ten years time.
End to end security is a good thing, but in many applications the overhead
of negotiating trust relationships end to end is just too high. How am I
expected to configure the end to end security on an embedded device with no
console. Oh I use a web browser to connect to it, yes very end to end.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Marcus Leech [mailto:mleech@nortelnetworks.com]
> Sent: Thursday, August 02, 2001 9:34 PM
> To: msec@securemulticast.org; ietf-ipsra@vpnc.org;
> ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> Subject: Position statement on IKE development
>
>
> I'm sending the attached ASCII TEXT document on behalf of myself, Jeff
> Schiller, and
> Steve Bellovin, to clarify our position with respect to IKE
> development. It is our hope
> that it will clarify, to some extent, some fuzziness in
> this area that
> has evolved over
> the last year or so.
>
------_=_NextPart_000_01C11C5C.14D9EDC0
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C11C5C.14D9EDC0--
From owner-ipsec@lists.tislabs.com Fri Aug 3 15:05:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73M5ps05879;
Fri, 3 Aug 2001 15:05:51 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04585
Fri, 3 Aug 2001 17:11:46 -0400 (EDT)
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Cc: "'Marcus Leech'" <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
References: <2F3EC696EAEED311BB2D009027C3F4F40154CA41@vhqpostal.verisign.com>
From: Derek Atkins <warlord@mit.edu>
Date: 03 Aug 2001 17:18:11 -0400
In-Reply-To: "Hallam-Baker, Phillip"'s message of "Fri, 3 Aug 2001 13:37:15 -0700"
Message-ID: <sjmitg4zvu4.fsf@rcn.ihtfp.org>
Lines: 88
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I think certificate management (and distribution) within IKE is the
biggest problem of all. I want to talk to the host/printer/network
device at address 1.2.3.4. How do I get it's public key, and why do I
want to trust it?
PFS is _EASY_ compared to that. An ephemeral DH exchange solves PFS.
But how do I authenticate? Better, how do I authenticate on a GLOBAL
scale? Now _THAT_ is the hard problem (IMHO).
-derek
"Hallam-Baker, Phillip" <pbaker@verisign.com> writes:
> I have a different set of concerns, IPSEC is not being used in cases where
> it should have been the answer.
>
> In particular the IEEE 802.11b WEP fiasco could have been averted if the
> designers had not been discouraged by the complexity of IPSEC.
>
> Another issue is why can't I buy a printer that is IPSEC enabled?
>
> I believe that the biggest problem with IPSEC is that the search for a
> certain view of perfect security has lead to a standard that many have
> bypassed altogether as too demanding.
>
> Perfect Forward Secrecy is great, but I would rather have a secure means of
> connecting to my printer than the possibility of a perfectly secure means in
> ten years time.
>
> End to end security is a good thing, but in many applications the overhead
> of negotiating trust relationships end to end is just too high. How am I
> expected to configure the end to end security on an embedded device with no
> console. Oh I use a web browser to connect to it, yes very end to end.
>
> Phill
>
>
>
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
>
>
> > -----Original Message-----
> > From: Marcus Leech [mailto:mleech@nortelnetworks.com]
> > Sent: Thursday, August 02, 2001 9:34 PM
> > To: msec@securemulticast.org; ietf-ipsra@vpnc.org;
> > ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> > Subject: Position statement on IKE development
> >
> >
> > I'm sending the attached ASCII TEXT document on behalf of myself, Jeff
> > Schiller, and
> > Steve Bellovin, to clarify our position with respect to IKE
> > development. It is our hope
> > that it will clarify, to some extent, some fuzziness in
> > this area that
> > has evolved over
> > the last year or so.
> >
>
>
> ------_=_NextPart_000_01C11C5C.14D9EDC0
> Content-Type: application/octet-stream;
> name="Phillip Hallam-Baker (E-mail).vcf"
> Content-Disposition: attachment;
> filename="Phillip Hallam-Baker (E-mail).vcf"
>
> BEGIN:VCARD
> VERSION:2.1
> N:Hallam-Baker;Phillip
> FN:Phillip Hallam-Baker (E-mail)
> ORG:VeriSign
> TITLE:Principal Consultant
> TEL;WORK;VOICE:(781) 245-6996 x227
> EMAIL;PREF;INTERNET:hallam@verisign.com
> REV:20010214T163732Z
> END:VCARD
>
> ------_=_NextPart_000_01C11C5C.14D9EDC0--
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Fri Aug 3 15:34:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73MYas06489;
Fri, 3 Aug 2001 15:34:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04610
Fri, 3 Aug 2001 17:38:55 -0400 (EDT)
Message-Id: <200108032145.f73Lj5J21336@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: Alex Alten <Alten@home.com>
cc: "Marcus Leech" <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
In-reply-to: Your message of "Thu, 02 Aug 2001 22:04:54 PDT."
<3.0.3.32.20010802220454.00fc0530@mail>
Reply-to: sommerfeld@East.Sun.COM
Date: Fri, 03 Aug 2001 17:45:05 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Let's hold an international design competition to select a key
> management protocol for IPSec in a manner similar to how NIST did
> the AES selection (although I hope it takes less than 5 years).
> Once we get to a final 5, then let's cryptanalyze them and select
> the best one. In this manner hopefully we can avoid a 2nd debacle.
the worst of IKE's problems are not in the cryptography.
Besides the general complexity of encoding, there's also the matter of
robustness in the face of retransmissions, as well as loss of peer
state. Not to mention flash crowds and flooding attacks..
From owner-ipsec@lists.tislabs.com Fri Aug 3 15:40:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73MePs06744;
Fri, 3 Aug 2001 15:40:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04640
Fri, 3 Aug 2001 17:54:57 -0400 (EDT)
Message-Id: <200108032159.f73Lwxd01332@dharkins@lounge.orgatty.lounge.org>
To: Alex Alten <Alten@home.com>
Cc: Henry Spencer <henry@spsystems.net>,
Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
In-Reply-To: Your message of "Fri, 03 Aug 2001 11:24:14 PDT."
<3.0.3.32.20010803112414.00eadaa0@mail>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1329.996875939.1@lounge.org>
Date: Fri, 03 Aug 2001 14:58:59 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, 03 Aug 2001 11:24:14 PDT you wrote
>
> BTW Henry,
>
> The issue is not that parts of IPsec are superfluous.
>
> The question is if IKE is broken then is IPsec also broken?
>
> - Alex
No, of course not.
And you are assuming that IKE is broken. What has been noted by all the
analysis mentiond so far is that IKE is too complex to know whether it
is broken or not. The effort is to make it less complex, get rid of
unnecessary and unused options, get rid of the inconsistent and sometimes
contradictory verbage between the 3 RFCs, and make it a specification of
a key management protocol for IPsec and IPsec only instead of the current
instantiation (RFC2407) of a protocol framework (RFC2409) of a generic
language (RFC2408).
Dan.
From owner-ipsec@lists.tislabs.com Fri Aug 3 15:44:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73Mids06809;
Fri, 3 Aug 2001 15:44:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04647
Fri, 3 Aug 2001 17:55:21 -0400 (EDT)
Message-Id: <4.3.2.7.0.20010803164227.01c2fab0@STPNTMX03.sctc.com>
X-Sender: smith@STPNTMX03.sctc.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 03 Aug 2001 16:58:09 -0500
To: Alex Alten <Alten@home.com>
From: Rick Smith at Secure Computing <rick_smith@securecomputing.com>
Subject: Re: Position statement on IKE development
Cc: Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
In-Reply-To: <3.0.3.32.20010803132027.00eae6b0@mail>
References: <Pine.BSI.3.91.1010803153453.15136D-100000@spsystems.net>
<3.0.3.32.20010803112414.00eadaa0@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 03:20 PM 8/3/2001, Alex Alten wrote:
>Unfortunately what you and I think probably doesn't matter. What matters
>is that end user customers will hear that IPsec's IKE is broken, and they
>will then ask themselves the question, is all of IPsec also broken? It's
>anyone's guess as to how this will play out in the VPN markets, etc.
It's not as if VPN customers have a well-recognized alternative with a less
tarnished reputation. If anything, this simply illustrates how much
pioneering work has gone into IKE.
>My own personal question is why the IPsec working group did not have a
>thorough cryptanalysis done by professionals, say by an outfit like ISSI,
>before the standards were issued?
Some weaknesses emerge only after you've actually built and deployed a
protocol. Such flaws may be in the implementation, but some may be faulty
assumptions about how the protocol will work in a practical deployment.
It's especially hard to predict problems when the protocol is the
foundation of a fairly new class of products, like VPN gateways, since
there's not enough well-known prior art to base the analytical models on.
Rick.
smith@securecomputing.com
From owner-ipsec@lists.tislabs.com Fri Aug 3 15:57:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73Mv5s06977;
Fri, 3 Aug 2001 15:57:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04685
Fri, 3 Aug 2001 18:11:56 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Subject: RE: IPSec performance statistics
Date: Fri, 3 Aug 2001 15:20:03 -0700
Message-ID: <4EBB5C35607E7F48B4AE162D956666EF339147@guam.corp.axcelerant.com>
Thread-Topic: IPSec performance statistics
Thread-Index: AcEcN9hqgG0w6q6MQ22IAhzbgs6SewAMjruw
From: "Christopher Gripp" <cgripp@axcelerant.com>
To: "Michael Richardson" <mcr@sandelman.ottawa.on.ca>,
<sommerfeld@East.Sun.COM>
Cc: <ipsec@lists.tislabs.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA04682
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Well, I have seen 300+ simultaneous connections renegotiatiate within 30
seconds after a reboot with only 10-20 dropped packets. This was on a
RedCreek 7150 terminating Personal Ravlin II's.
Christopher S. Gripp
Systems Engineer
Axcelerant
-----Original Message-----
From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca]
Sent: Thursday, August 02, 2001 4:30 PM
To: sommerfeld@East.Sun.COM
Cc: ipsec@lists.tislabs.com
Subject: Re: IPSec performance statistics
>>>>> "Bill" == Bill Sommerfeld <sommerfeld@East.Sun.COM> writes:
Bill> Main mode + quick mode + first-user-traffic winds up being
about 5
Bill> round trips, so network latency winds up being a dominant
factor in
Bill> how long it takes to get things flowing..
so long as there is enough CPU leftover, of course.
I'd be interested to know how long it takes before 1000 road warriors
are
able to function again after rebooting the gateway :-)
] ON HUMILITY: to err is human. To moo, bovine. |
firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net
architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security
guy"); [
From owner-ipsec@lists.tislabs.com Fri Aug 3 16:15:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73NFQs07505;
Fri, 3 Aug 2001 16:15:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04731
Fri, 3 Aug 2001 18:23:48 -0400 (EDT)
Message-Id: <3.0.3.32.20010803152924.00ed6b10@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Fri, 03 Aug 2001 15:29:24 -0700
To: Dan Harkins <dharkins@lounge.org>
From: Alex Alten <Alten@home.com>
Subject: Re: Position statement on IKE development
Cc: Henry Spencer <henry@spsystems.net>,
Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
In-Reply-To: <200108032159.f73Lwxd01332@dharkins@lounge.orgatty.lounge.o
rg>
References: <Your message of "Fri, 03 Aug 2001 11:24:14 PDT." <3.0.3.32.20010803112414.00eadaa0@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Quoting Marcus, Jeff and Steve:
"The Security Area Directors have asked the IPSEC working group to come
up with a replacement for IKE. This work is underway and is known in
the community as "Son of IKE". "
"If IKE is vulnerable, we must all share a burden of responsibility for
allowing it to get to the state it is in and we must all work together
to correct the problems."
OK. IKE is not technically broken. But it sure sounds like someone
is worried. Otherwise why bother with a replacement for IKE?
It's rather ironic that the 802.11 wireless key management was broken
just recently as well.
- Alex
At 02:58 PM 8/3/2001 -0700, Dan Harkins wrote:
>On Fri, 03 Aug 2001 11:24:14 PDT you wrote
>>
>> BTW Henry,
>>
>> The issue is not that parts of IPsec are superfluous.
>>
>> The question is if IKE is broken then is IPsec also broken?
>>
>> - Alex
>
>No, of course not.
>
>And you are assuming that IKE is broken. What has been noted by all the
>analysis mentiond so far is that IKE is too complex to know whether it
>is broken or not. The effort is to make it less complex, get rid of
>unnecessary and unused options, get rid of the inconsistent and sometimes
>contradictory verbage between the 3 RFCs, and make it a specification of
>a key management protocol for IPsec and IPsec only instead of the current
>instantiation (RFC2407) of a protocol framework (RFC2409) of a generic
>language (RFC2408).
>
> Dan.
>
>
>
>
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Fri Aug 3 16:15:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73NFvs07519;
Fri, 3 Aug 2001 16:15:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04751
Fri, 3 Aug 2001 18:30:15 -0400 (EDT)
Message-Id: <200108032235.f73MZDd01426@dharkins@lounge.orgatty.lounge.org>
To: Henry Spencer <henry@spsystems.net>
Cc: IP Security List <ipsec@lists.tislabs.com>, ietf-ipsra@vpnc.org,
ipsec-policy@vpnc.org
Subject: Re: Position statement on IKE development
In-Reply-To: Your message of "Fri, 03 Aug 2001 15:29:09 EDT."
<Pine.BSI.3.91.1010803152724.15136C-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1423.996878113.1@lounge.org>
Date: Fri, 03 Aug 2001 15:35:13 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I discussed this in Minneapolis. The plan is to combine ISAKMP, IKE,
and the IPsec DOI into a single draft describing a key management
protocol for IPsec.
The intent, as well-meaning as it was, was to have a generic language
(ISAKMP) in which to describe a key management protocol and there could
be many key management protocols with IKE as just one of them. IKE, then,
was supposed to be a generic key exchange protocol which could create
"SAs" for multiple services, of which IPsec (specified in the DOI) was
just one. But IKE is the only thing that used ISAKMP and the other two
DOI documents-- OSPF and RIP-- died a quiet death.
The benefit of having this artificial layering is nil and the cost
(the nuisance factor you mention, the conflicting verbage, the unnecessary
repetition of things, the incredible complexity it causes) is high so
it is being done away with. There should be only one thing that listens
on UDP port 500 and that is a key management protocol for IPsec which
should be described in a (relatively) short and concise draft. I'm
working on it.
Dan.
On Fri, 03 Aug 2001 15:29:09 EDT Henry Spencer wrote
> On Fri, 3 Aug 2001, Bill Sommerfeld wrote:
> > > Therefore, I would suggest that any effort in replacing IKE also consider
> > > replacing/rewriting portions of IPSEC DOI ...
> >
> > Last I heard, the son-of-ike plan was to merge the DOI into the key
> > mgmt document.
>
> Realistically, there's no meaningful distinction between IKE and the DOI.
> In fact, the separation between the two documents is a real nuisance when
> one is looking for obscure details. They need to be considered as a unit.
>
> Henry Spencer
> henry@spsystems.net
From owner-ipsec@lists.tislabs.com Fri Aug 3 16:44:06 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73Ni6s07813;
Fri, 3 Aug 2001 16:44:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04812
Fri, 3 Aug 2001 18:52:29 -0400 (EDT)
Message-Id: <200108032257.f73MvCd01488@dharkins@lounge.orgatty.lounge.org>
To: alten@tristrata.com
Cc: ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
In-Reply-To: Your message of "Fri, 03 Aug 2001 15:29:24 PDT."
<3.0.3.32.20010803152924.00ed6b10@mail>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1485.996879432.1@lounge.org>
Date: Fri, 03 Aug 2001 15:57:12 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Nothing like what happened to 802.11 has happened to IKE so don't
say "as well". It's unfortunate that this position statement gives an
opportunity for vendors which sell non-IPsec network security products
to spread FUD.
We should all be worried about IKE because, as I said, it is complex.
There is way too much complexity to just establish IPsec SAs and that
complexity naturally makes people worried. That issue is being addressed.
Dan.
On Fri, 03 Aug 2001 15:29:24 PDT you wrote
>
> Quoting Marcus, Jeff and Steve:
>
> "The Security Area Directors have asked the IPSEC working group to come
> up with a replacement for IKE. This work is underway and is known in
> the community as "Son of IKE". "
>
> "If IKE is vulnerable, we must all share a burden of responsibility for
> allowing it to get to the state it is in and we must all work together
> to correct the problems."
>
> OK. IKE is not technically broken. But it sure sounds like someone
> is worried. Otherwise why bother with a replacement for IKE?
>
> It's rather ironic that the 802.11 wireless key management was broken
> just recently as well.
>
> - Alex
>
> At 02:58 PM 8/3/2001 -0700, Dan Harkins wrote:
> >On Fri, 03 Aug 2001 11:24:14 PDT you wrote
> >>
> >> BTW Henry,
> >>
> >> The issue is not that parts of IPsec are superfluous.
> >>
> >> The question is if IKE is broken then is IPsec also broken?
> >>
> >> - Alex
> >
> >No, of course not.
> >
> >And you are assuming that IKE is broken. What has been noted by all the
> >analysis mentiond so far is that IKE is too complex to know whether it
> >is broken or not. The effort is to make it less complex, get rid of
> >unnecessary and unused options, get rid of the inconsistent and sometimes
> >contradictory verbage between the 3 RFCs, and make it a specification of
> >a key management protocol for IPsec and IPsec only instead of the current
> >instantiation (RFC2407) of a protocol framework (RFC2409) of a generic
> >language (RFC2408).
> >
> > Dan.
> >
> >
> >
> >
> >
> --
>
> Alex Alten
>
> Alten@Home.Com
>
>
From owner-ipsec@lists.tislabs.com Fri Aug 3 16:44:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f73NiFs07826;
Fri, 3 Aug 2001 16:44:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04782
Fri, 3 Aug 2001 18:50:27 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010803155109.04464d58@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 03 Aug 2001 15:56:02 -0700
To: Alex Alten <Alten@home.com>
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: Position statement on IKE development
Cc: msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org,
ipsec@lists.tislabs.com
In-Reply-To: <3.0.3.32.20010802220454.00fc0530@mail>
References: <3B69FF7B.85CF61@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ferguson and Schneier suggested the same thing as an alternative to
design-by-committee, which they suggested was the source of problems with
IPsec and IKE. When I read this, I did not think it was a viable solution
because the IPsec and IKE requirements were so much more complex than AES.
I don't think their criticisms of IKE were ever addressed on this list
though the points about AH and ESP were as I recall.
Mark
At 10:04 PM 8/2/2001 -0700, Alex Alten wrote:
>Dear Marcus, Jeff and Steve,
>
>May I make a suggestion given the seriousness of this?
>
>Let's hold an international design competition to select a key
>management protocol for IPSec in a manner similar to how NIST did
>the AES selection (although I hope it takes less than 5 years).
>Once we get to a final 5, then let's cryptanalyze them and select
>the best one. In this manner hopefully we can avoid a 2nd debacle.
>
>Sincerely,
>
>- Alex Alten
>
>
>At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote:
> >I'm sending the attached ASCII TEXT document on behalf of myself, Jeff
> >Schiller, and
> > Steve Bellovin, to clarify our position with respect to IKE
> >development. It is our hope
> > that it will clarify, to some extent, some fuzziness in this area that
> >has evolved over
> > the last year or so.In the several years since the standardization of
>the IPSEC protocols
> >(ESP, AH, and ISAKMP/IKE), there have come to light several security
> >problems with the protocols, most notably the key-agreement protocol,
> >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
> >Simpson, have shown that the security problems in IKE stem directly
> >from its complexity. It seems only a matter of time before more
> >analyses show more serious security issues in the protocol design that
> >stem directly from its complexity. It seems also, only a matter of
> >time, before serious *implementation* problems become apparent, again
> >due to the complex nature of the protocol, and the complex
> >implementation that must surely follow.
>
>...
>
> >
> >
> >Marcus Leech (IESG)
> >Jeff Schiller (IESG)
> >Steve Bellovin (IAB)
> >
>--
>
>Alex Alten
>
>Alten@Home.Com
From owner-ipsec@lists.tislabs.com Fri Aug 3 18:52:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f741qds09393;
Fri, 3 Aug 2001 18:52:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04964
Fri, 3 Aug 2001 20:57:57 -0400 (EDT)
To: Alex Alten <Alten@home.com>
Cc: msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org,
ipsec@lists.tislabs.com
In-reply-to: Alten's message of Fri, 03 Aug 2001 15:29:24 MST.
<3.0.3.32.20010803152924.00ed6b10@mail>
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: Position statement on IKE development
From: itojun@iijlab.net
Date: Sat, 04 Aug 2001 10:03:20 +0900
Message-ID: <6530.996887000@itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
(stripped off some of the explicit cc:s)
just checking: does "ongoing work on Son of IKE" mean this draft,
or something else?
draft-ietf-ipsec-improveike-00.txt
itojun
From owner-ipsec@lists.tislabs.com Sat Aug 4 00:36:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f747als29105;
Sat, 4 Aug 2001 00:36:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA05245
Sat, 4 Aug 2001 02:08:42 -0400 (EDT)
Date: Fri, 3 Aug 2001 23:01:44 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Bill Sommerfeld <sommerfeld@East.Sun.COM>
cc: Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
In-Reply-To: <200108032145.f73Lj5J21336@thunk.east.sun.com>
Message-ID: <Pine.BSF.4.21.0108032242540.95634-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Let's hold an international design competition to select a key
> management protocol for IPSec in a manner similar to how NIST did
> the AES selection (although I hope it takes less than 5 years).
> Once we get to a final 5, then let's cryptanalyze them and select
> the best one. In this manner hopefully we can avoid a 2nd debacle.
>
In practice, such a competition is being held every day in the offices of
customers. The problem is that the contenders are proprietary versions of
IKE (IKE's evil sisters), that there is no cryptanalysis available, and
that the decision criteria and selection are not openly discussed.
I can state from experience that the "Cinderella IKE" that we now seek to
shelter rarely wins these private beauty contests against the evil
sisters. This is in part, because it is not a good match to customer
requirements such as the need for NAT friendliness and a viable
shared-secret authentication mode.
It seems to me that unless we can find a "glass slipper" for Cinderella
IKE, that it will languish as the evil sisters grow stronger and more
popular. While we might not like this outcome, or feel that it is "right",
the evidence is to strong to ignore. Cinderella IKE just isn't being
invited to the ball.
From owner-ipsec@lists.tislabs.com Sat Aug 4 07:13:43 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f74EDgs16458;
Sat, 4 Aug 2001 07:13:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05487
Sat, 4 Aug 2001 09:07:05 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: Henry Spencer <henry@spsystems.net>
Cc: Alex Alten <Alten@home.com>, Marcus Leech <mleech@nortelnetworks.com>,
msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org,
ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 04 Aug 2001 09:12:51 -0400
Message-Id: <20010804131251.B07AF7B5B@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <Pine.BSI.3.91.1010803100851.12632A-100000@spsystems.net>, Henry Spe
ncer writes:
>
>On Thu, 2 Aug 2001, Alex Alten wrote:
>> ...Their suggestion to use a process like NIST's for selecting
>> the AES standard is an excellent one. It's a pity they did not suggest
>> it a decade ago. However it should be considered seriously not only
>> for the replacement of IKE, but possibly also for the modification or
>> simplification of the entire IPsec protocol suite...
>
>I think this is throwing the baby out with the bathwater.
>
>While the packet-level parts (ESP etc.) do have some flaws, most of those
>can be fixed simply by taking a big black pen and crossing out superfluous
>parts of the existing specs (e.g., all of RFC 2402). While there is room
>for some debate about exactly which parts should be crossed out (e.g.,
>there are people who still think AH is useful), I think there would be
>little or no support for redesigning the surviving parts. So a design
>competition does not seem very useful in this area. Moreover, *this* is
>the area where there is massive investment in silicon, solder traces, etc.
>Just deleting features does not, by and large, invalidate that investment.
>
>IKE is the disaster area. The rest of IPsec could use some judicious
>featurectomies, but is not badly broken.
Agreed. And large parts of the Schneier/Ferguson analysis of the
packet-level parts are just plain wrong.
--Steve Bellovin, http://www.research.att.com/~smb
From owner-ipsec@lists.tislabs.com Sat Aug 4 15:42:30 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f74MgTs28450;
Sat, 4 Aug 2001 15:42:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05893
Sat, 4 Aug 2001 17:36:46 -0400 (EDT)
Message-Id: <3.0.3.32.20010804144227.00ebdb30@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Sat, 04 Aug 2001 14:42:27 -0700
To: "Steven M. Bellovin" <smb@research.att.com>,
Henry Spencer <henry@spsystems.net>
From: Alex Alten <Alten@home.com>
Subject: Re: Position statement on IKE development
Cc: Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
In-Reply-To: <20010804131251.B07AF7B5B@berkshire.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 09:12 AM 8/4/2001 -0400, Steven M. Bellovin wrote:
>In message <Pine.BSI.3.91.1010803100851.12632A-100000@spsystems.net>,
Henry Spe
>ncer writes:
>>
>>On Thu, 2 Aug 2001, Alex Alten wrote:
>>> ...Their suggestion to use a process like NIST's for selecting
>>> the AES standard is an excellent one. It's a pity they did not suggest
>>> it a decade ago. However it should be considered seriously not only
>>> for the replacement of IKE, but possibly also for the modification or
>>> simplification of the entire IPsec protocol suite...
>>
>>I think this is throwing the baby out with the bathwater.
>>
>>While the packet-level parts (ESP etc.) do have some flaws, most of those
>>can be fixed simply by taking a big black pen and crossing out superfluous
>>parts of the existing specs (e.g., all of RFC 2402). While there is room
>>for some debate about exactly which parts should be crossed out (e.g.,
>>there are people who still think AH is useful), I think there would be
>>little or no support for redesigning the surviving parts. So a design
>>competition does not seem very useful in this area. Moreover, *this* is
>>the area where there is massive investment in silicon, solder traces, etc.
>>Just deleting features does not, by and large, invalidate that investment.
>>
>>IKE is the disaster area. The rest of IPsec could use some judicious
>>featurectomies, but is not badly broken.
>
>Agreed. And large parts of the Schneier/Ferguson analysis of the
>packet-level parts are just plain wrong.
>
Steve, with all due respect, you, Jeff and Marcus stated the following.
"In the several years since the standardization of the IPSEC protocols
(ESP, AH, and ISAKMP/IKE), there have come to light several security
problems with the protocols, most notably the key-agreement protocol,
IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
Simpson, have shown that the security problems in IKE stem directly
from its complexity."
If IKE is no longer considered viable because of it's complexity, then
I am concerned that the other protocols of IPsec are also at risk. This
is not my concern alone, others have expressed it to me as well.
At this point, to restore confidence in the security of the design I
would hope that the IETF will retain the services of a quality
cryptanalysis consulting firm and publish the results. To do otherwise
will be to risk the discrediting of the entire IPsec standard.
Sincerely,
- Alex
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Sat Aug 4 16:38:04 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f74Nc4s29077;
Sat, 4 Aug 2001 16:38:04 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05941
Sat, 4 Aug 2001 18:55:30 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: Alex Alten <Alten@home.com>
Cc: Henry Spencer <henry@spsystems.net>,
Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 05 Aug 2001 00:00:25 +0100
Message-Id: <20010804230025.A59117B5B@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <3.0.3.32.20010804144227.00ebdb30@mail>, Alex Alten writes:
>>
>>Agreed. And large parts of the Schneier/Ferguson analysis of the
>>packet-level parts are just plain wrong.
>>
>
>
>Steve, with all due respect, you, Jeff and Marcus stated the following.
>
>"In the several years since the standardization of the IPSEC protocols
>(ESP, AH, and ISAKMP/IKE), there have come to light several security
>problems with the protocols, most notably the key-agreement protocol,
>IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
>Simpson, have shown that the security problems in IKE stem directly
>from its complexity."
>
>If IKE is no longer considered viable because of it's complexity, then
>I am concerned that the other protocols of IPsec are also at risk. This
>is not my concern alone, others have expressed it to me as well.
>
>At this point, to restore confidence in the security of the design I
>would hope that the IETF will retain the services of a quality
>cryptanalysis consulting firm and publish the results. To do otherwise
>will be to risk the discrediting of the entire IPsec standard.
Frankly, a lot of very competent folks did look at the cryptography.
WIth all due modesty, I published two papers on the subject myself, and
I wasn't the only one. In fact, that's one of the reasons why IPsec
took so long -- the result of those analyses is why RFCs 1825-29 were
replaced by 2401 et al. -- because we found and fixed a fair number of
problems. The flaws in the Schneier/Ferguson analysis are
because they don't understand the networking context. I sent Bruce a
long, detailed note about that before he ever published the analysis.
You say "retain the services of a quality cryptanalysis consulting firm".
Apart from the point that there aren't that many -- and I and others
know most of the likely players in the field -- the question is whether
or not they understand the networking context. I have no particular
reason to think that the results would be any better than what we have
now.
Is IPsec perfect? No, of course not. I'd like to get rid of AH, for
example, not because it doesn't work -- it does -- but because it adds
complexity to implementations without (to me) doing anything useful.
There are a few other minor things I'd have done differently. But I
have a great deal of confidence in the correctness of the packet-level
transforms.
--Steve Bellovin, http://www.research.att.com/~smb
From owner-ipsec@lists.tislabs.com Sat Aug 4 16:59:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f74NxBs29298;
Sat, 4 Aug 2001 16:59:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05926
Sat, 4 Aug 2001 18:48:10 -0400 (EDT)
X-Envelope-To: ipsec@lists.tislabs.com
To: ipsec@lists.tislabs.com
Path: not-for-mail
From: daw@mozart.cs.berkeley.edu (David Wagner)
Newsgroups: isaac.lists.ipsec
Subject: Re: Position statement on IKE development
Date: 4 Aug 2001 22:52:02 GMT
Organization: University of California, Berkeley
Lines: 18
Distribution: isaac
Message-ID: <9khuai$1hi$1@abraham.cs.berkeley.edu>
References: <20010804131251.B07AF7B5B@berkshire.research.att.com> <3.0.3.32.20010804144227.00ebdb30@mail>
NNTP-Posting-Host: mozart.cs.berkeley.edu
X-Trace: abraham.cs.berkeley.edu 996965522 1586 128.32.45.153 (4 Aug 2001 22:52:02 GMT)
X-Complaints-To: news@abraham.cs.berkeley.edu
NNTP-Posting-Date: 4 Aug 2001 22:52:02 GMT
X-Newsreader: trn 4.0-test74 (May 26, 2000)
Originator: daw@mozart.cs.berkeley.edu (David Wagner)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Alex Alten wrote:
>If IKE is no longer considered viable because of it's complexity, then
>I am concerned that the other protocols of IPsec are also at risk.
Why? The packet-level parts of IPsec are much less complex
(and, partially as a result, have received more scrutiny, as
far as I can tell).
>At this point, to restore confidence in the security of the design I
>would hope that the IETF will retain the services of a quality
>cryptanalysis consulting firm and publish the results. To do otherwise
>will be to risk the discrediting of the entire IPsec standard.
I think this is probably unnecessary. The main thing that deters
analysis from the academics (from the anecdotes I've heard) is the
complexity of IKE. If this improves, my guess is that you're likely
to receive better cryptanalysis from the community as a whole than
you'd get from a consulting firm.
From owner-ipsec@lists.tislabs.com Sat Aug 4 23:45:19 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f756jJs12334;
Sat, 4 Aug 2001 23:45:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06156
Sun, 5 Aug 2001 01:43:07 -0400 (EDT)
To: Barbara Fraser <byfraser@cisco.com>, "Theodore Ts'o" <tytso@mit.edu>
Cc: ipsec@lists.tislabs.com
Subject: ipsec mailing list archive
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Sun, 05 Aug 2001 14:49:36 +0900
Message-Id: <20010805054937.EDB8E7BB@starfruit.itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
there are two email archives listed on ipsec wg webpage:
http://www.ietf.org/html.charters/ipsec-charter.html
unfortunately, both of those do not work. could you please find
another one and list it onto the webpage?
ftp://ftp.tis.com/pub/lists/ipsec - no ftp.tis.com any more?
ftp.ans.net/pub/archive/ipsec - the archive is ancient
with google, i found a couple of these. i dunno which is better than
the others.
http://www.vpnc.org/ietf-ipsec/
http://www.sandelman.ottawa.on.ca/ipsec/
http://www.cs.arizona.edu/xkernel/www/ipsec/
itojun
From owner-ipsec@lists.tislabs.com Sun Aug 5 05:40:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f75Ce7s06237;
Sun, 5 Aug 2001 05:40:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06311
Sun, 5 Aug 2001 07:43:30 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15213.12991.222510.889533@thomasm-u1.cisco.com>
Date: Sun, 5 Aug 2001 04:49:19 -0700 (PDT)
To: Dan Harkins <dharkins@lounge.org>
Cc: Henry Spencer <henry@spsystems.net>,
IP Security List <ipsec@lists.tislabs.com>, ietf-ipsra@vpnc.org,
ipsec-policy@vpnc.org
Subject: Re: Position statement on IKE development
In-Reply-To: <200108032235.f73MZDd01426@dharkins@lounge.orgatty.lounge.org>
References: <Pine.BSI.3.91.1010803152724.15136C-100000@spsystems.net>
<200108032235.f73MZDd01426@dharkins@lounge.orgatty.lounge.org>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dan Harkins writes:
> I discussed this in Minneapolis. The plan is to combine ISAKMP, IKE,
> and the IPsec DOI into a single draft describing a key management
> protocol for IPsec.
>
> The intent, as well-meaning as it was, was to have a generic language
> (ISAKMP) in which to describe a key management protocol and there could
> be many key management protocols with IKE as just one of them. IKE, then,
> was supposed to be a generic key exchange protocol which could create
> "SAs" for multiple services, of which IPsec (specified in the DOI) was
> just one. But IKE is the only thing that used ISAKMP and the other two
> DOI documents-- OSPF and RIP-- died a quiet death.
Not entirely correct. KINK is using ISAKMP payloads
(sa, id, nonce, ke, notify, delete, ie quick mode).
IMO, the logical split here is between authentication
and IPsec SA establishment. The former is *always*
a far harder problem than the latter.
Mike
From owner-ipsec@lists.tislabs.com Sun Aug 5 05:40:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f75Ce8s06249;
Sun, 5 Aug 2001 05:40:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06295
Sun, 5 Aug 2001 07:34:07 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15213.12426.278709.314071@thomasm-u1.cisco.com>
Date: Sun, 5 Aug 2001 04:39:54 -0700 (PDT)
To: Henry Spencer <henry@spsystems.net>
Cc: IP Security List <ipsec@lists.tislabs.com>, ietf-ipsra@vpnc.org,
ipsec-policy@vpnc.org
Subject: Re: Position statement on IKE development
In-Reply-To: <Pine.BSI.3.91.1010803152724.15136C-100000@spsystems.net>
References: <200108031857.f73IviJ20038@thunk.east.sun.com>
<Pine.BSI.3.91.1010803152724.15136C-100000@spsystems.net>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Speaking as an implementor of KINK, it would be nice
if there were a split of anything to make a clean
split between main mode and quick mode. As far as I
can tell, quick mode is far less broken and far more
reusable by any number of key distribution protocols
than main mode.
Mike
Henry Spencer writes:
> On Fri, 3 Aug 2001, Bill Sommerfeld wrote:
> > > Therefore, I would suggest that any effort in replacing IKE also consider
> > > replacing/rewriting portions of IPSEC DOI ...
> >
> > Last I heard, the son-of-ike plan was to merge the DOI into the key
> > mgmt document.
>
> Realistically, there's no meaningful distinction between IKE and the DOI.
> In fact, the separation between the two documents is a real nuisance when
> one is looking for obscure details. They need to be considered as a unit.
>
> Henry Spencer
> henry@spsystems.net
>
From owner-ipsec@lists.tislabs.com Sun Aug 5 12:54:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f75JsVs16330;
Sun, 5 Aug 2001 12:54:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06666
Sun, 5 Aug 2001 14:54:35 -0400 (EDT)
Message-Id: <3.0.3.32.20010805120024.01051bf0@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Sun, 05 Aug 2001 12:00:24 -0700
To: "Steven M. Bellovin" <smb@research.att.com>
From: Alex Alten <Alten@home.com>
Subject: Re: Position statement on IKE development
Cc: Henry Spencer <henry@spsystems.net>,
Marcus Leech <mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
In-Reply-To: <20010804230025.A59117B5B@berkshire.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 12:00 AM 8/5/2001 +0100, Steven M. Bellovin wrote:
>In message <3.0.3.32.20010804144227.00ebdb30@mail>, Alex Alten writes:
>
>
>>>
>>>Agreed. And large parts of the Schneier/Ferguson analysis of the
>>>packet-level parts are just plain wrong.
>>>
>>
>>
>>Steve, with all due respect, you, Jeff and Marcus stated the following.
>>
>>"In the several years since the standardization of the IPSEC protocols
>>(ESP, AH, and ISAKMP/IKE), there have come to light several security
>>problems with the protocols, most notably the key-agreement protocol,
>>IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
>>Simpson, have shown that the security problems in IKE stem directly
>>from its complexity."
>>
>>If IKE is no longer considered viable because of it's complexity, then
>>I am concerned that the other protocols of IPsec are also at risk. This
>>is not my concern alone, others have expressed it to me as well.
>>
>>At this point, to restore confidence in the security of the design I
>>would hope that the IETF will retain the services of a quality
>>cryptanalysis consulting firm and publish the results. To do otherwise
>>will be to risk the discrediting of the entire IPsec standard.
>
>Frankly, a lot of very competent folks did look at the cryptography.
>WIth all due modesty, I published two papers on the subject myself, and
>I wasn't the only one. In fact, that's one of the reasons why IPsec
>took so long -- the result of those analyses is why RFCs 1825-29 were
>replaced by 2401 et al. -- because we found and fixed a fair number of
>problems. The flaws in the Schneier/Ferguson analysis are
>because they don't understand the networking context. I sent Bruce a
>long, detailed note about that before he ever published the analysis.
>
>You say "retain the services of a quality cryptanalysis consulting firm".
>Apart from the point that there aren't that many -- and I and others
>know most of the likely players in the field -- the question is whether
>or not they understand the networking context. I have no particular
>reason to think that the results would be any better than what we have
>now.
>
>Is IPsec perfect? No, of course not. I'd like to get rid of AH, for
>example, not because it doesn't work -- it does -- but because it adds
>complexity to implementations without (to me) doing anything useful.
>There are a few other minor things I'd have done differently. But I
>have a great deal of confidence in the correctness of the packet-level
>transforms.
>
Dr. Steven Bellovin,
I have the greatest respect for your design and analysis capabilities
in both networking and cryptography. However at this point in time,
besides the Ferguson & Schneier analysis, and in a sense older papers
by yourself, Dr. Rogaway and possibly others, I have yet to come across
a comprehensive, thorough analysis of the 2401 set of RFCs. I don't
think that this is something that can be done properly through academia,
at least not as a free, unfocused effort. It really requires a focused
effort, with clear, practical analysis objectives laid out. That is why
I suggest using a good consulting firm, preferably one that does similar
type of work on a regular basis.
I appreciate your personal assurances that it is a sound design. However
I think it is critical that an unbiased, reputable third party report
on the core suite of protocols. I understand your concern that they
might not understand the underlying network context. But I would expect
that you and others would be appropriate guides for the analysis. As you
should well know, unbiased peer review is critical in the design of any
security system. We, as designers, tend to be blind to our own mistakes.
It is a rather humbling profession for any security system designer.
Therefore I ask the IAB/IETF to strongly consider sponsering a thorough
analysis of the 2401 set of RFC's. As a member of the Internet Society
I feel it is our responsibility and duty to the Internet community to
ensure, as best as we can, the integrity and soundness of the design.
At the same time, I would hope that the IAB/IETF will come up with a
criteria for selecting the replacement for IKE, rather than trying to
do it all in-house again. While understanding the misgivings others
have expressed, I still feel that a competition along the same lines
that NIST used for AES selection, would be the best approach. The
internal workings of a block cipher are probably just as complex as
the external workings of a key management protocol. Arguements
against a NIST-like selection approach using complexity as a reason
seem to be fallacious to me.
Sincerely,
Alex Alten
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Sun Aug 5 13:03:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f75K3ms16455;
Sun, 5 Aug 2001 13:03:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06697
Sun, 5 Aug 2001 15:22:51 -0400 (EDT)
X-Sender: mundy@217.33.140.133 (Unverified)
Message-Id: <v03130300b7934ba6b341@[217.33.140.133]>
In-Reply-To: <20010805054937.EDB8E7BB@starfruit.itojun.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 5 Aug 2001 20:29:16 +0100
To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
From: Russ Mundy <mundy@tislabs.com>
Subject: Re: ipsec mailing list archive
Cc: Barbara Fraser <byfraser@cisco.com>, "Theodore Ts'o" <tytso@mit.edu>,
ipsec@lists.tislabs.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
We had a domain name change/transition a couple of years ago from tis.com
to tislabs.com. It was announced on all the ietf lists we support at the
time but I never check the full set of working group web sites to see if
they all picked up the name change. I just checked the old zone name and,
I agree, that it doesn't work (at least from the London IETF site). The
current name for the site with ALL of the archives is:
ftp://ftp.tislabs.com/pub/lists/ipsec
I'll see if I can find out whether or not the 'old' name should still be
functioning.
Russ
NAI Labs
(aka, owner/operator of tislabs.com)
At 2:49 PM +0900 8/5/01, Jun-ichiro itojun Hagino wrote:
> there are two email archives listed on ipsec wg webpage:
> http://www.ietf.org/html.charters/ipsec-charter.html
>
> unfortunately, both of those do not work. could you please find
> another one and list it onto the webpage?
> ftp://ftp.tis.com/pub/lists/ipsec - no ftp.tis.com any more?
> ftp.ans.net/pub/archive/ipsec - the archive is ancient
>
> with google, i found a couple of these. i dunno which is better than
> the others.
> http://www.vpnc.org/ietf-ipsec/
> http://www.sandelman.ottawa.on.ca/ipsec/
> http://www.cs.arizona.edu/xkernel/www/ipsec/
>
>itojun
From owner-ipsec@lists.tislabs.com Sun Aug 5 20:25:45 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f763Pjs21155;
Sun, 5 Aug 2001 20:25:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06924
Sun, 5 Aug 2001 22:06:06 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Alex Alten'" <Alten@home.com>,
"'Marcus Leech'" <mleech@nortelnetworks.com>, <ipsec@lists.tislabs.com>
Subject: RE: Position statement on IKE development
Date: Sun, 5 Aug 2001 21:59:56 -0400
Message-Id: <000001c11e1c$313810c0$0b9321d9@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <3.0.3.32.20010802234951.00e4eb00@mail>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Okay, the first thing to do is **DON'T PANIC**.
The opinion in this document is not new. In fact, this moratorium on IKE
development has been in place for more than a year already, as I
specifically remember Ted talking about it at the Adelaide meeting. The fact
that the opinion of the ADs has suddenly been put in writing and posted to
the mailing list is no reason to get excited.
What does concern me is the effect that this moratorium has had on the WG.
Instead of encouraging work on simplifying IKE, it has merely stifled the
ongoing work on features that we simply must have. NAT traversal is clearly
not an optional feature. Development of a NAT traversal protocol will
continue with or without the IESG's blessing, as will user authentication
and dead peer detection.
If all development must stop until IKE is simplified, then how are we to add
these essential new features? Must there be an IKEv3 a year from now to add
all the features that have already been developed? I would also like to ask
why, if the enclosed opinion is in fact shared by all 3 authors, then how is
it that one of them recently co-authored a draft for adding SCTP support to
IKE?
---
In technical circles, just as in politics, the pendulum swings one way and
then it swings back again. No matter which way it is travelling, it
inevitably swings too far.
In our zeal to criticize IKE/Isakmp for its generic approach, we have
assumed there is some kind of magic pixie dust that we can sprinkle on IKE
to make it simpler. Rewriting the documents may make IKE easier to
understand, but it won't change the bits on the wire or the underlying
protocol. Designing related protocols to not share any code may reduce the
complexity of either protocol taken alone, but it will probably increase the
complexity of the system as a whole.
I agree with Mike that the separation of Main Mode from Quick Mode was a
good design decision for IKE. I also feel that the separation of ISAKMP from
IKE was a good decision. I would much rather see a rewritten IKE document
and a separate, simplified ISAKMP document (which only defines the payload
formats and such) than a new, fully merged IKE spec.
Counterintuitively, "simplicity" is a difficult concept to apply and
understand. A shorter RFC does not necessarily make a simpler protocol.
Simplicity can come from adding things as well as removing them. In
particular, adding restrictions can greatly simplify a protocol.
I am worried that if we try to make Son of IKE too terse then the lack of
restrictions will make the protocol vague. It has been my observation that
the single biggest problem area for IKEv1 has been rekeying. The IKE RFC
remains curiously silent on this topic, except to state the SAs are
"uncorrelated". The lack of sufficient rules for how to use the Certificate
Request payload has also been a source of trouble.
---
If you want to consider some real, bits-on-the-wire type simplifications to
IKE then take a look at our draft-improveike document. Also look at the
revised hash document and the IKE anti-replay document. These last two are
ideas for simplifying IKE by taking security properties which were formerly
solved individually for each mode, and defining a solution which solves the
problem for all modes, a simplification.
Not all of the things we suggest are simplifications; some of them are
merely suggestions to improve the protocol. But then again, not all of the
papers that Marcus cites are really commenting on complexity of IKE. The
paper by Simpson doesn't talk about the complexity of IKE at all. In fact,
all it says is that IKE is succeptible to a certain kind of DoS attack.
The paper by Ferguson/Schneier certainly talks about complexity, but I think
that many people are too star-struck by who the co-author is to consider
that he obviously isn't very familiar with the intimate details of IKE. In
fact, some of his comments are rather schitzophrenic, in the sense that he
interlaces suggestions for simplifying Main Mode with suggestions for
reducing the length of the exchange, a short-sighted idea which would almost
certainly introduce some new DoS attacks.
If we are going to redesign IKE then let us do so, but it would help if the
charter was defined so that people actually had an incentive to implement
the new, simplified IKE. Many of the proposed suggestions have been wild,
unsupported assertions such as: (A) let's have a contest and redesign
everything from scratch (clearly not from an implementer), (B) related
protocols X and Y shouldn't share code (great as long as you don't have to
implement both X and Y), (C) Merging all the documents together will somehow
automagically fix IKE (only if we agree on conventions for things like
rekeying).
I also wonder why IKE gets all the blame when the PKI-related protocols we
use with IKE are easily as complex, if not more complex.
My apologies for not replying earlier, but I have been on vacation until
today.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten
> Sent: Friday, August 03, 2001 2:50 AM
> To: Marcus Leech; msec@securemulticast.org; ietf-ipsra@vpnc.org;
> ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> Subject: Re: Position statement on IKE development
>
>
>
> After just reading the papers by Meadows, Schneier/Ferguson and
> Simpson, I now have serious doubts that IPsec delivers the security
> required by the Internet community.
>
> This is a very serious issue.
>
> To make a mistake of this caliber when so many firms have committed
> large amounts of resources for software, board, ASIC and chip designs,
> implementations and manufactures is a terrible thing.
>
> I agree with Schneier & Ferguson. A security protocol/system cannot be
> designed by a large committee, unlike many other successful insecure
> protocols. Their suggestion to use a process like NIST's for selecting
> the AES standard is an excellent one. It's a pity they did not suggest
> it a decade ago. However it should be considered seriously not only
> for the replacement of IKE, but possibly also for the modification or
> simplification of the entire IPsec protocol suite. (I hesitate to say
> the replacement of IPSEC given the tremendous repercussions of doing
> so.)
>
> - Alex
>
>
> At 10:04 PM 8/2/2001 -0700, Alex Alten wrote:
> >
> >Dear Marcus, Jeff and Steve,
> >
> >May I make a suggestion given the seriousness of this?
> >
> >Let's hold an international design competition to select a key
> >management protocol for IPSec in a manner similar to how NIST did
> >the AES selection (although I hope it takes less than 5 years).
> >Once we get to a final 5, then let's cryptanalyze them and select
> >the best one. In this manner hopefully we can avoid a 2nd debacle.
> >
> >Sincerely,
> >
> >- Alex Alten
> >
> >
> >At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote:
> >>I'm sending the attached ASCII TEXT document on behalf of
> myself, Jeff
> >>Schiller, and
> >> Steve Bellovin, to clarify our position with respect to IKE
> >>development. It is our hope
> >> that it will clarify, to some extent, some fuzziness in
> this area that
> >>has evolved over
> >> the last year or so.In the several years since the
> standardization of
> >the IPSEC protocols
> >>(ESP, AH, and ISAKMP/IKE), there have come to light several security
> >>problems with the protocols, most notably the key-agreement
> protocol,
> >>IKE. Formal and semi-formal analyses by Meadows, Schneier
> et al, and
> >>Simpson, have shown that the security problems in IKE stem directly
> >>from its complexity. It seems only a matter of time before more
> >>analyses show more serious security issues in the protocol
> design that
> >>stem directly from its complexity. It seems also, only a matter of
> >>time, before serious *implementation* problems become
> apparent, again
> >>due to the complex nature of the protocol, and the complex
> >>implementation that must surely follow.
> >
> >...
> >
> >>
> >>
> >>Marcus Leech (IESG)
> >>Jeff Schiller (IESG)
> >>Steve Bellovin (IAB)
> >>
> >--
> >
> >Alex Alten
> >
> >Alten@Home.Com
> >
> >
> >
> --
>
> Alex Alten
>
> Alten@Home.Com
>
>
>
From owner-ipsec@lists.tislabs.com Mon Aug 6 01:08:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7688qs14525;
Mon, 6 Aug 2001 01:08:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA07419
Mon, 6 Aug 2001 02:46:04 -0400 (EDT)
To: akshay.singh@analog.com
Cc: snap-users@kame.net, ipsec@lists.tislabs.com
Subject: Re: (KAME-snap 5215) ESP Encryption Key
In-Reply-To: Your message of "Sat, 4 Aug 2001 15:55:32 -0700"
<001901c11d38$92593b20$c78b4789@pctest1>
References: <001901c11d38$92593b20$c78b4789@pctest1>
X-Mailer: Cue version 0.6 (010413-1707/sakane)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Message-Id: <20010806155248Q.sakane@kame.net>
Date: Mon, 06 Aug 2001 15:52:48 +0900
From: Shoichi Sakane <sakane@kame.net>
X-Dispatcher: imput version 20000228(IM140)
Lines: 17
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> I have a question related to esp encryption key ,
> I am using 3des so I set my keys as
> case 1:
> { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
> 0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,
> 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03}
> Here problem is this If I use the keys as
> case 2:
> { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
> 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
> 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01}
> the encrypted results are same in case 1 and case 2. Can any one tell why it is
> same even I am using different keys ?
i'm not sure what the platform you are using.
at least, these key cannot be installed into the kernel based kame stack.
kame stack says "esp_cbc_mature 3des-cbc: weak key was passed",
From owner-ipsec@lists.tislabs.com Mon Aug 6 01:22:06 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f768M5s15225;
Mon, 6 Aug 2001 01:22:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA07523
Mon, 6 Aug 2001 03:20:34 -0400 (EDT)
Message-Id: <200108060726.f767Qas00663@dharkins@lounge.orgatty.lounge.org>
To: Michael Thomas <mat@cisco.com>
Cc: IP Security List <ipsec@lists.tislabs.com>, ietf-ipsra@vpnc.org,
ipsec-policy@vpnc.org
Subject: Re: Position statement on IKE development
In-Reply-To: Your message of "Sun, 05 Aug 2001 04:49:19 PDT."
<15213.12991.222510.889533@thomasm-u1.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <660.997082796.1@lounge.org>
Date: Mon, 06 Aug 2001 00:26:36 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I stand corrected... well sort of.
KINK doesn't really re-use quick mode since certain things were
dropped like PFS and the whole commit bit stuff. So it's really
quick-mode-lite. And it doesn't use UDP port 500 so it's not really
ISAKMP after all. And I don't even think it uses the ISAKMP header.
It also defines as many (if not more) new payloads as it uses
from ISAKMP.
So all in all, KINK is not really doing quick mode nor is it
using ISAKMP.
Why don't you just define your protocol in full? I don't believe you'll
be sued for cutting-and-pasting payloads from RFC2408.
Dan.
On Sun, 05 Aug 2001 04:49:19 PDT you wrote
> Dan Harkins writes:
> > I discussed this in Minneapolis. The plan is to combine ISAKMP, IKE,
> > and the IPsec DOI into a single draft describing a key management
> > protocol for IPsec.
> >
> > The intent, as well-meaning as it was, was to have a generic language
> > (ISAKMP) in which to describe a key management protocol and there could
> > be many key management protocols with IKE as just one of them. IKE, then,
> > was supposed to be a generic key exchange protocol which could create
> > "SAs" for multiple services, of which IPsec (specified in the DOI) was
> > just one. But IKE is the only thing that used ISAKMP and the other two
> > DOI documents-- OSPF and RIP-- died a quiet death.
>
> Not entirely correct. KINK is using ISAKMP payloads
> (sa, id, nonce, ke, notify, delete, ie quick mode).
> IMO, the logical split here is between authentication
> and IPsec SA establishment. The former is *always*
> a far harder problem than the latter.
>
> Mike
>
From owner-ipsec@lists.tislabs.com Mon Aug 6 02:44:52 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f769ipN21969;
Mon, 6 Aug 2001 02:44:51 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA07581
Mon, 6 Aug 2001 04:35:05 -0400 (EDT)
Date: Mon, 6 Aug 2001 04:41:27 -0400
From: Theodore Tso <tytso@mit.edu>
To: Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>
Cc: "'Alex Alten'" <Alten@home.com>,
"'Marcus Leech'" <mleech@nortelnetworks.com>, ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
Message-ID: <20010806044127.B577@thunk.org>
References: <3.0.3.32.20010802234951.00e4eb00@mail> <000001c11e1c$313810c0$0b9321d9@andrewk3.ca.newbridge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <000001c11e1c$313810c0$0b9321d9@andrewk3.ca.newbridge.com>; from andrew.krywaniuk@alcatel.com on Sun, Aug 05, 2001 at 09:59:56PM -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Sun, Aug 05, 2001 at 09:59:56PM -0400, Andrew Krywaniuk wrote:
> Okay, the first thing to do is **DON'T PANIC**.
>
> The opinion in this document is not new. In fact, this moratorium on IKE
> development has been in place for more than a year already, as I
> specifically remember Ted talking about it at the Adelaide meeting. The fact
> that the opinion of the ADs has suddenly been put in writing and posted to
> the mailing list is no reason to get excited.
Indeed. Nothing really has changed here. My understanding is that
the note from the IESG/IAB this is more of a reminder more than
anything else. It was explaining the reasons for the moratorium,
Specifically, we do have permission to go ahead with making interim
modifications to IKE, which need badly fixing in the short term:
specifically in the NAT/Firewall traversal and support for SCTP. But
all other changes are to be shunted to "son of IKE", and even there
the focus is on making the protocol work, and be simpler and easier to
understand/analyze, and not add the kitchen sink in terms of feature.
As far as user authentication and dead peer detection, part of the
problem with those items is that there has *not* been consensus, and
in fact there's been a fair amount of controversy, about what's the
best way to handle these items. People have sketched out solutions
for user authentication that don't require changes to IKE, and that
work is properly scoped to the IPSRA working group (and not "son of
ike").
Dead peer recovery probably will be within in the scope of "son of
ike", but here again there has been controversy about how is the best
way of solving the problem. One advantage about "son of ike" allowing
protocol changes (but likely requiring that the changes be
"implementation preserving"), is that there may be more latitude to
solve this particular proble right, instead of kludging around things.
I will note that there have been many different proposed solutions to
solving this particular problem, including polling/heartbeat
mechanisms, authenticated birth/death certificates, etc.
- Ted
From owner-ipsec@lists.tislabs.com Mon Aug 6 02:46:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f769kmN22019;
Mon, 6 Aug 2001 02:46:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA07612
Mon, 6 Aug 2001 04:50:07 -0400 (EDT)
Date: Mon, 6 Aug 2001 06:01:07 -0400
From: Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>
To: Shoichi Sakane <sakane@kame.net>
Cc: akshay.singh@analog.com, snap-users@kame.net, ipsec@lists.tislabs.com
Subject: Re: (KAME-snap 5215) ESP Encryption Key
Message-ID: <20010806060107.A30359@grendel.conscoop.ottawa.on.ca>
References: <001901c11d38$92593b20$c78b4789@pctest1> <20010806155248Q.sakane@kame.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010806155248Q.sakane@kame.net>; from sakane@kame.net on Mon, Aug 06, 2001 at 03:52:48PM +0900
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Mon, Aug 06, 2001 at 03:52:48PM +0900, Shoichi Sakane wrote:
> > I have a question related to esp encryption key ,
> > I am using 3des so I set my keys as
> > case 1:
> > { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
> > 0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,
> > 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03}
> > Here problem is this If I use the keys as
> > case 2:
> > { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
> > 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
> > 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01}
> > the encrypted results are same in case 1 and case 2. Can any one tell why it is
> > same even I am using different keys ?
I found a bug and provided a fix, in OpenBSD, at least two years ago,
which looked exactly like this. The problem was in the userspace manual
keying utility. I assume it was fixed long ago.
> i'm not sure what the platform you are using.
> at least, these key cannot be installed into the kernel based kame stack.
> kame stack says "esp_cbc_mature 3des-cbc: weak key was passed",
slainte mhath, RGB
...just back from the American Solar Challenge <formulasun.org/asc>, a
cross-continental solar vehicle competition on historic Route 66. Now
in Europe for 3 weeks..., presently at IETF.
--
Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada
<www.conscoop.ottawa.on.ca/rgb/> <www.flora.org/afo/>
Prevent Internet Wiretapping! -- FreeS/WAN:<www.freeswan.org>
Thanks for voting Green! -- <green.ca> Marillion:<www.marillion.co.uk>
From owner-ipsec@lists.tislabs.com Mon Aug 6 04:45:55 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76BjtN00153;
Mon, 6 Aug 2001 04:45:55 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07817
Mon, 6 Aug 2001 06:47:58 -0400 (EDT)
Message-ID: <003001c11e66$ba4b9ea0$ae0510ac@roc.com>
Reply-To: "lokesh" <lokeshnb@intotoinc.com>
From: "lokesh" <lokeshnb@intotoinc.com>
To: <ipsec@lists.tislabs.com>
Subject: Information needed on AND and OR SB's
Date: Mon, 6 Aug 2001 16:28:21 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_002D_01C11E94.CED76420"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_002D_01C11E94.CED76420
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi all,
I need Information on "AND SB" (AND Security Bundle)
and "OR SB" (OR Security Bundles).
which are used in multiple levels of security Bundle Applications. Can =
any one tell me where I can get Documents on these subjects?
Thanks In Advance,
Lokesh.
------=_NextPart_000_002D_01C11E94.CED76420
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I need Information on "AND SB" (AND =
Security=20
Bundle)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>and "OR SB" (OR Security =
Bundles).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>which are used in multiple levels of =
security=20
Bundle Applications. Can any one tell me where I can get Documents on =
these=20
subjects?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks In Advance,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Lokesh.</FONT></DIV></BODY></HTML>
------=_NextPart_000_002D_01C11E94.CED76420--
From owner-ipsec@lists.tislabs.com Mon Aug 6 05:17:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76CHkN00577;
Mon, 6 Aug 2001 05:17:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07876
Mon, 6 Aug 2001 07:29:06 -0400 (EDT)
Reply-To: <jh@hsworldwide.com>
From: "Judah Hauser" <jh@hsworldwide.com>
To: <ipsec@lists.tislabs.com>
Date: Sat, 4 Aug 2001 01:02:36 +0200
Message-ID: <NFBBIFMKMLINDBDNBEFHCENACBAA.jh@hsworldwide.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dear Sir,
I have a linksys BEFSR81 Router all hooked up but have a mjor issue im
hoping you can help me with. I dial into my adsl provider using VPN+PPTP.
I am able to connect with no problems, but only on the main computer thats
dialing. I can actually dial on any of the computers, but only on at a time.
I heard this is a known bug because of some ipsec issue.
are you familiar with this problem?
Basically what I need to know is if their is some fix for this or do I need
to buy a different brand?
Do you expect support for - Unlimited PPTP & IPsec client passthru
sessions?
Thanks,
Judah Hauser
HS Worldwide Enterprises Inc
Email: jh@hsworldwide.com
jhauser@tlite.co.il
WWW.HSWORLDWIDE.COM
From owner-ipsec@lists.tislabs.com Mon Aug 6 05:27:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76CR1N00761;
Mon, 6 Aug 2001 05:27:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07891
Mon, 6 Aug 2001 07:41:38 -0400 (EDT)
To: ipsec@lists.tislabs.com
Subject: isakmp cookies field
X-Mailer: Cue version 0.6 (010413-1707/sakane)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Message-Id: <20010806204824B.sakane@kame.net>
Date: Mon, 06 Aug 2001 20:48:24 +0900
From: Shoichi Sakane <sakane@kame.net>
X-Dispatcher: imput version 20000228(IM140)
Lines: 3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
could anybody tell me what the benefit of the isakmp cookie field is ?
i think the cookie indicates just isakmp spi. does it have any function
to prevent from dos attack ?
From owner-ipsec@lists.tislabs.com Mon Aug 6 05:51:19 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76CpJN01382;
Mon, 6 Aug 2001 05:51:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07836
Mon, 6 Aug 2001 07:01:17 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15214.31358.903185.187715@thomasm-u1.cisco.com>
Date: Mon, 6 Aug 2001 04:07:42 -0700 (PDT)
To: Dan Harkins <dharkins@lounge.org>
Cc: Michael Thomas <mat@cisco.com>, IP Security List <ipsec@lists.tislabs.com>,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org
Subject: Re: Position statement on IKE development
In-Reply-To: <200108060726.f767Qas00663@dharkins@lounge.orgatty.lounge.org>
References: <15213.12991.222510.889533@thomasm-u1.cisco.com>
<200108060726.f767Qas00663@dharkins@lounge.orgatty.lounge.org>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dan Harkins writes:
> I stand corrected... well sort of.
>
> KINK doesn't really re-use quick mode since certain things were
> dropped like PFS and the whole commit bit stuff. So it's really
> quick-mode-lite. And it doesn't use UDP port 500 so it's not really
> ISAKMP after all. And I don't even think it uses the ISAKMP header.
> It also defines as many (if not more) new payloads as it uses
> from ISAKMP.
>
> So all in all, KINK is not really doing quick mode nor is it
> using ISAKMP.
Actually, PFS was added back in. I guess it depends
on what is meant by "using" and "really". It's I'd
say about 90% code preserving which was really the
main desire.
> Why don't you just define your protocol in full? I don't believe you'll
> be sued for cutting-and-pasting payloads from RFC2408.
It was a possibility, but the consensus was to just
reference quick mode in 2409. I think it will be
interesting to see if the profile we did is sufficiently
clear. If not, cut and paste may be the reasonable
course of action.
Mike
From owner-ipsec@lists.tislabs.com Mon Aug 6 06:17:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76DH9N01982;
Mon, 6 Aug 2001 06:17:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07927
Mon, 6 Aug 2001 08:08:08 -0400 (EDT)
Message-Id: <200108050240.f752eaw06850@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
In-reply-to: Your message of "04 Aug 2001 22:52:02 GMT."
<9khuai$1hi$1@abraham.cs.berkeley.edu>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Sat, 04 Aug 2001 22:40:35 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "David" == David Wagner <daw@mozart.cs.berkeley.edu> writes:
David> I think this is probably unnecessary. The main thing that deters
David> analysis from the academics (from the anecdotes I've heard) is the
David> complexity of IKE. If this improves, my guess is that you're
David> likely to receive better cryptanalysis from the community as a
David> whole than you'd get from a consulting firm.
Is IKE really that complex?
Or rather, could be be much simpler and still get the job done?
This is really a different question from: is IKE poorly documented?
I think that we all agree that the document could be a lot better.
I still think that this is really the first step. Clean up the document(s),
and doing nothing to the specification, and then decide what to chop.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
From owner-ipsec@lists.tislabs.com Mon Aug 6 06:31:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76DVcN02232;
Mon, 6 Aug 2001 06:31:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08113
Mon, 6 Aug 2001 08:43:10 -0400 (EDT)
To: Shoichi Sakane <sakane@kame.net>
Cc: ipsec@lists.tislabs.com
Subject: Re: isakmp cookies field
References: <20010806204824B.sakane@kame.net>
From: Derek Atkins <warlord@mit.edu>
Date: 06 Aug 2001 08:50:05 -0400
In-Reply-To: Shoichi Sakane's message of "Mon, 06 Aug 2001 20:48:24 +0900"
Message-ID: <sjmzo9dxshu.fsf@rcn.ihtfp.org>
Lines: 15
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It provides ISAKMP session identification and peer reachability.
-derek
Shoichi Sakane <sakane@kame.net> writes:
> could anybody tell me what the benefit of the isakmp cookie field is ?
> i think the cookie indicates just isakmp spi. does it have any function
> to prevent from dos attack ?
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Mon Aug 6 07:08:43 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76E8gN03729;
Mon, 6 Aug 2001 07:08:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07918
Mon, 6 Aug 2001 08:07:08 -0400 (EDT)
Message-ID: <001901c11d38$92593b20$c78b4789@pctest1>
Reply-To: "akshay" <akshay.singh@analog.com>
From: "akshay" <akshay.singh@analog.com>
To: <snap-users@kame.net>, <ipsec@lists.tislabs.com>
Subject: ESP Encryption Key
Date: Sat, 4 Aug 2001 15:55:32 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0016_01C11CFD.E4209A10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0016_01C11CFD.E4209A10
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi ,
I have a question related to esp encryption key ,
I am using 3des so I set my keys as=20
case 1:
{ 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,
0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03}
Here problem is this If I use the keys as=20
case 2:
{ 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01}
the encrypted results are same in case 1 and case 2. Can any one tell =
why it is same even I am using different keys ?
Further when I call des_key_sched function with first key i.e =
{0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01}
the value of my des_key_schedule variable is all 0 , why so ? cannt I =
select key like this .
Cheers!!
akshay
=20
------=_NextPart_000_0016_01C11CFD.E4209A10
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Hi ,
I have a question related to esp = encryption key=20 ,
I am using 3des so I set my keys as =
case 1:
{=20 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
=20 0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,
=20 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03}
Here problem is this If I use the keys = as=20
case 2:
{=20 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01}
the encrypted results are same in case 1 and case 2. Can any one = tell why=20 it is same even I am using different keys ?
Further when I call des_key_sched function with first key i.e=20 {0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01}
the value of my des_key_schedule variable is all 0 , why so ? = cannt I=20 select key like this .
Cheers!!
akshay
------=_NextPart_000_0016_01C11CFD.E4209A10--
From owner-ipsec@lists.tislabs.com Mon Aug 6 07:57:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76EvGN06935;
Mon, 6 Aug 2001 07:57:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08262
Mon, 6 Aug 2001 09:54:38 -0400 (EDT)
Message-ID: <005001c11e80$c6984680$ae0510ac@roc.com>
Reply-To: "lokesh" <lokeshnb@intotoinc.com>
From: "lokesh" <lokeshnb@intotoinc.com>
To: "Shoichi Sakane" <sakane@kame.net>
Cc: <ipsec@lists.tislabs.com>
References: <20010806204824B.sakane@kame.net>
Subject: Re: isakmp cookies field
Date: Mon, 6 Aug 2001 19:34:51 +0530
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> could anybody tell me what the benefit of the isakmp cookie field is ?
> i think the cookie indicates just isakmp spi. does it have any function
> to prevent from dos attack ?
using cookies is the feature of Oakley algorithm(used by ISAKMP)
these cookies are used to thwart clogging attacks.
in this attack, the opponent forges the src address of a legitimate user and
sends a public DH key to victim,
the victim then performs the modular exponentiation to compute secret key,
Repeated messages of this type can clog the victims system with useless
work, thus exhausting cpu resource to perform modular exponentiation.
The technique of cookie exchange requires that each side send a
pseudo-random number , the cookie , in the initial message, which other side
acknowledges
This acknowledgement must be repeated in the first message of DH key
exchange. If src address is forged , the opponent gets no answer, thus an
opponent can only force user to generate acknowledgements and not to perform
the DH modular exponentiation.
ISAKMP mandates that cookie generation must satisfy three basic
requirements.
1. The cookie must depend on specific parties.
2. It must not be possible for anyone otherthan issueing entity to generate
cookies that will be accepted by that entity, that is, cookie generation
should be based on some local secret.
3. cookie generation and verification methods must be fast to thwart attacks
intended to sabotage the processor resources..
From owner-ipsec@lists.tislabs.com Mon Aug 6 08:01:59 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76F1wN07061;
Mon, 6 Aug 2001 08:01:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08279
Mon, 6 Aug 2001 10:03:18 -0400 (EDT)
Message-ID: <8B204D152222D51182B70001028841372024CC@postmaster.cryptek.com>
From: "Aronson, David" <daronson@cryptek.com>
To: "'Shoichi Sakane'" <sakane@kame.net>
Cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: RE: isakmp cookies field
Date: Mon, 6 Aug 2001 10:34:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> could anybody tell me what the benefit of the isakmp cookie
> field is ?
> i think the cookie indicates just isakmp spi. does it have
> any function
> to prevent from dos attack ?
Yes, exactly. See RFC 2048 (ISAKMP), section 2.5.3 (Anti-Clogging Token
("Cookie") Creation), on pages 20-21.
--
Dave Aronson, Sysop of free public Fidonet BBS Air 'n Sun, +1-703-319-0714.
Opinions all MINE, not by Cryptek/NRA/SCA/Mensa/HWG/LPUSA/CAUCE/FedGov/God!
See my web site, at http://listen.to/davearonson (last updated 2001-06-27).
Device-driver proggers: see http://www.cryptek.com and send me your resume!
From owner-ipsec@lists.tislabs.com Mon Aug 6 08:33:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76FX7N08222;
Mon, 6 Aug 2001 08:33:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08357
Mon, 6 Aug 2001 10:42:11 -0400 (EDT)
To: ipsec@lists.tislabs.com
Subject: RE: isakmp cookies field
In-Reply-To: Your message of "Mon, 6 Aug 2001 10:34:44 -0400 "
<8B204D152222D51182B70001028841372024CC@postmaster.cryptek.com>
References: <8B204D152222D51182B70001028841372024CC@postmaster.cryptek.com>
X-Mailer: Cue version 0.6 (010413-1707/sakane)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Message-Id: <20010806234819O.sakane@kame.net>
Date: Mon, 06 Aug 2001 23:48:19 +0900
From: Shoichi Sakane <sakane@kame.net>
X-Dispatcher: imput version 20000228(IM140)
Lines: 16
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> > could anybody tell me what the benefit of the isakmp cookie
> > field is ?
> > i think the cookie indicates just isakmp spi. does it have
> > any function
> > to prevent from dos attack ?
> Yes, exactly. See RFC 2048 (ISAKMP), section 2.5.3 (Anti-Clogging Token
> ("Cookie") Creation), on pages 20-21.
of course, i've read this document. but i think this cookie creation
couldn't prevent from dos or mitm attack.
if nodes which would start to communicate knew the local secret information,
yes, the cookie function could prevent from the attack. but the local
secret information is known by the entity that creates a cookie.
Or does nodes have to share any local secret information before the
isakmp negotiation is started.
From owner-ipsec@lists.tislabs.com Mon Aug 6 08:45:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76FjPN10253;
Mon, 6 Aug 2001 08:45:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08435
Mon, 6 Aug 2001 11:06:06 -0400 (EDT)
Date: Mon, 6 Aug 2001 18:07:31 +0300 (EET DST)
From: Markus Stenberg <mstenber@ssh.com>
X-X-Sender: <mstenber@torni.hel.fi.ssh.com>
To: <ipsec@lists.tislabs.com>
Subject: NAT-T drafts in 51st IETF
Message-ID: <Pine.OSF.4.33.0108061803220.25159-100000@torni.hel.fi.ssh.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At the WG chairs' request, I'm posting this note also here:
The NAT-T drafts are, as far as the authors are concerned, mostly done.
Nobody in the WG disagreed. But the part that really needs noting is this:
- the AH portion won't work quite (as described in the UDP encapsulation
draft)
- the WG was polled about whether or not we really need AH support
- ~two dozen+ people had read the draft
- NOBODY wanted to retain AH support (and by my informal polls, nobody
was going to bother to implement support anyway because it was defined as
'MAY' be supported)
- therefore, unless there is some urgent argument for retaining of the AH
support in the drafts, the AH support'll disappear and the drafts may
enter last call if no arguments against it are raised here.
-Markus
From owner-ipsec@lists.tislabs.com Mon Aug 6 08:58:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76FwnN12494;
Mon, 6 Aug 2001 08:58:49 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08449
Mon, 6 Aug 2001 11:07:51 -0400 (EDT)
To: Shoichi Sakane <sakane@kame.net>
Cc: ipsec@lists.tislabs.com
Subject: Re: isakmp cookies field
References: <8B204D152222D51182B70001028841372024CC@postmaster.cryptek.com> <20010806234819O.sakane@kame.net>
From: Derek Atkins <warlord@mit.edu>
Date: 06 Aug 2001 11:14:44 -0400
In-Reply-To: Shoichi Sakane's message of "Mon, 06 Aug 2001 23:48:19 +0900"
Message-ID: <sjmvgk1xlsr.fsf@rcn.ihtfp.org>
Lines: 27
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Cookies provide you reachability, which implies that the initiator is
actually interested in an IKE exchange, and is actually at the
specified IP address (or at least somewhere along the route to that
peer address). This prevents a DoS attack where the attacker sends
out a forged IP Address, because the responder does no real work until
message 3 (and the attacker wont receive message 2 which contains the
server cookie).
Cookies do not prevent an attacker from attempting DoS from their own
IP Address.. However, then you at least have the IP address of the
host causing problems, and you can just block it or rate-limit it.
-derek
Shoichi Sakane <sakane@kame.net> writes:
> if nodes which would start to communicate knew the local secret information,
> yes, the cookie function could prevent from the attack. but the local
> secret information is known by the entity that creates a cookie.
> Or does nodes have to share any local secret information before the
> isakmp negotiation is started.
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Mon Aug 6 08:58:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76FwrN12517;
Mon, 6 Aug 2001 08:58:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08410
Mon, 6 Aug 2001 11:01:04 -0400 (EDT)
Message-Id: <200108061450.f76EofM05322@road.xisp.net>
To: design@lists-freeswan.org
cc: wes@hardakers.net, ipsec@lists.tislabs.com
Subject: Wes Hardaker: opportunistic encryption deployment problems
Date: Mon, 06 Aug 2001 15:50:41 +0100
From: Hugh Daniel <hugh@road.xisp.net>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
I just spoke about the FreeS/WAN's teams Opportunistic Encryption
design using IKE/IPsec at IETF and am already getting email on the
subject.
The conversation will now be split between our list and the IETF
ipsec list (look at the headers below). Such is life.
To answer Mr. Hardaker, we understand the problem with requiring the
data be in the reverse DNS space and considering a forward space
solution, but there are many folks who have no control over even their
forward space.
At some point one has to just give up and tell folks to get it
together and control there own resources.
On the subject of NAT: If your NAT on the net your NOT on the net.
That's what I personally say at least.
||ugh Daniel
hugh@freeswan.org
Systems Testing & Project mis-Management
The Linux FreeS/WAN Project
http://www.freeswan.org
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.
iQCVAwUBO26usVZpdJR7FBQRAQF6QgP7BhFHok49P/UZcsw61EEUEeITH74DArkM
FyaNWCbCGtySAK2SRiV6k/8weXairJuLb5xTT62Siq/+JTWAlxGPmsa9AuKnAJvY
98nVKG066UcqyRu7/rS2fhP8lRpFHtY3a3TgkLevICPg4rl9vM2Hburs28DMx+rw
7gxta46ZRFI=
=6D6I
-----END PGP SIGNATURE-----
------- Forwarded Message
Return-Path: wes@hardakers.net
Delivery-Date: Mon Aug 6 07:33:39 2001
Return-Path: <wes@hardakers.net>
Received: from wanderer.hardakers.net (root@host217-33-137-141.ietf.ignite.net [217.33.137.141])
by ecotone.toad.com (8.8.7/8.8.7) with ESMTP id HAA04408
for <hugh@road.xisp.net>; Mon, 6 Aug 2001 07:33:38 -0700
Received: (from hardaker@localhost)
by wanderer.hardakers.net (8.11.2/8.11.2) id f76EYs108296;
Mon, 6 Aug 2001 07:34:54 -0700
X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f
To: Hugh Daniel <hugh@road.xisp.net>
Cc: ipsec@lists.tislabs.com
Subject: opportunistic encryption deployment problems
From: Wes Hardaker <wes@hardakers.net>
X-URL: http://dcas.ucdavis.edu/~hardaker
Organization: Network Associates - NAI Labs
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Date: Mon, 06 Aug 2001 07:34:54 -0700
Message-ID: <sd4rrlb6k1.fsf@wanderer.hardakers.net>
Lines: 24
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.2 (Terspichore)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
3 problems I see with the deployment of opportunistic encryption:
1) your method of obtaining information is by reverse DNS lookup,
which will provide problems with people who can't control their
reverse DNS bindings. As an example, I don't have control over the
subnet mapped to my house and can not insert information into the
controlling DNS server (and can not convince them to redirect to
me).
2) your method of obtaining information is by reverse DNS lookup,
which will provide problems with people behind NATs. Until IPv6 is
(if) widely deployed, this will continue to be a growing problem.
Sure, if you can convince your NAT provider to do encryption to and
from both sides of the NAT, you may be able to get around this but
it certainly would take an effort to get this done.
3) The wider and wider spread use of things like web and other proxies
will provide similar problems seen in #2.
- --
Wes Hardaker
NAI Labs
Network Associates
------- End of Forwarded Message
From owner-ipsec@lists.tislabs.com Mon Aug 6 09:16:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76GGkN13049;
Mon, 6 Aug 2001 09:16:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08331
Mon, 6 Aug 2001 10:30:01 -0400 (EDT)
X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f
To: Hugh Daniel <hugh@road.xisp.net>
Cc: ipsec@lists.tislabs.com
Subject: opportunistic encryption deployment problems
From: Wes Hardaker <wes@hardakers.net>
X-URL: http://dcas.ucdavis.edu/~hardaker
Organization: Network Associates - NAI Labs
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Date: Mon, 06 Aug 2001 07:34:54 -0700
Message-ID: <sd4rrlb6k1.fsf@wanderer.hardakers.net>
Lines: 24
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.2 (Terspichore)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
3 problems I see with the deployment of opportunistic encryption:
1) your method of obtaining information is by reverse DNS lookup,
which will provide problems with people who can't control their
reverse DNS bindings. As an example, I don't have control over the
subnet mapped to my house and can not insert information into the
controlling DNS server (and can not convince them to redirect to
me).
2) your method of obtaining information is by reverse DNS lookup,
which will provide problems with people behind NATs. Until IPv6 is
(if) widely deployed, this will continue to be a growing problem.
Sure, if you can convince your NAT provider to do encryption to and
from both sides of the NAT, you may be able to get around this but
it certainly would take an effort to get this done.
3) The wider and wider spread use of things like web and other proxies
will provide similar problems seen in #2.
--
Wes Hardaker
NAI Labs
Network Associates
From owner-ipsec@lists.tislabs.com Mon Aug 6 09:16:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76GGrN13061;
Mon, 6 Aug 2001 09:16:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08528
Mon, 6 Aug 2001 11:26:31 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA42@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Derek Atkins'" <warlord@mit.edu>,
"Hallam-Baker, Phillip"
<pbaker@verisign.com>
Cc: "'Marcus Leech'" <mleech@nortelnetworks.com>, ietf-ipsra@vpnc.org,
ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: RE: Position statement on IKE development
Date: Mon, 6 Aug 2001 08:32:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C11E8D.12D55F40"
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_000_01C11E8D.12D55F40
Content-Type: text/plain;
charset="iso-8859-1"
Derek,
My point is not that PFS is bad, but that the imposition of a
particular set of design priorities led to the very important properties of
usability and deployability to be left out.
The problem is as you say the means by which the keys are ultimately
authenticated. It is not the cryptography. This is a complex task which is
expensive to manage if the semantics of the trust network are complex and
management takes place in devices at the periphery of the network.
One solution is the SSL solution where the trust semantics are made
very simple. Unfortunately people don't seem to like that solution, even
though it is the only large scale open PKI that we have people using every
day for real business.
If people want to have a complex set of trust semantics than the
only way to deploy the system is to provide a mechanism that allows the
trust path processing to be delegated to a trust service - see XKMS
[www.xmltrustcenter.org].
I would also like to be able to delegate the process of key
agreement. This is because key agreement is an expensive operation that
expensive database engines and routers have no business doing and because
high end crypto hardware is expensive.
That said there are a set of simplifications to IKE that could be
achieved immediately:
1) Just decide what type of public key encryption you are going to use,
encryption or signature. There is certainly an ongoing need for algorithm
replacement, but allowing each party to chose from encryption/signature
simply quadruples the work with zero added security.
At this point we have two public key signature algorithms in general
use and one encryption. So I would pick the signature, all things being
equal.
2) Separate the credential download. In most cases Alice has Bob's
certificate cached from a previous interaction. If Alice is trying to talk
to Bob and does not have a credential then she should either (1) make a
credential request of Bob or (2) receive the credential in an error message
from Bob.
3) Get rid of the negotiation assumption generally. At this point we
have 1 working digest function, 2 acceptable symmetric ciphers, 1 key
agreement and 2 public key algorithms. Alice should start with the
assumption that Bob is going to accept what she sends (after all she
probably has the information cached). If that is a false assumption then Bob
can send her an error message saying (I don't do X).
4) If you want to have the documents reviewed by the cryptography field
generally PRESENT THEM TYPESET. This is the 3rd millenium, we don't use
teletypes any more. Trying to read a crypto protocol with subscripts is bad
enough. Reading K_X, K_AB_X etc is a turn off for anyone. I don't know of a
single cryptographer who can't afford a bit mapped screen.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Derek Atkins [mailto:warlord@MIT.EDU]
> Sent: Friday, August 03, 2001 5:18 PM
> To: Hallam-Baker, Phillip
> Cc: 'Marcus Leech'; msec@securemulticast.org; ietf-ipsra@vpnc.org;
> ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> Subject: Re: Position statement on IKE development
>
>
> I think certificate management (and distribution) within IKE is the
> biggest problem of all. I want to talk to the host/printer/network
> device at address 1.2.3.4. How do I get it's public key, and why do I
> want to trust it?
>
> PFS is _EASY_ compared to that. An ephemeral DH exchange solves PFS.
> But how do I authenticate? Better, how do I authenticate on a GLOBAL
> scale? Now _THAT_ is the hard problem (IMHO).
>
> -derek
>
> "Hallam-Baker, Phillip" <pbaker@verisign.com> writes:
>
> > I have a different set of concerns, IPSEC is not being used
> in cases where
> > it should have been the answer.
> >
> > In particular the IEEE 802.11b WEP fiasco could have been
> averted if the
> > designers had not been discouraged by the complexity of IPSEC.
> >
> > Another issue is why can't I buy a printer that is IPSEC enabled?
> >
> > I believe that the biggest problem with IPSEC is that the
> search for a
> > certain view of perfect security has lead to a standard
> that many have
> > bypassed altogether as too demanding.
> >
> > Perfect Forward Secrecy is great, but I would rather have a
> secure means of
> > connecting to my printer than the possibility of a
> perfectly secure means in
> > ten years time.
> >
> > End to end security is a good thing, but in many
> applications the overhead
> > of negotiating trust relationships end to end is just too
> high. How am I
> > expected to configure the end to end security on an
> embedded device with no
> > console. Oh I use a web browser to connect to it, yes very
> end to end.
> >
> > Phill
> >
> >
> >
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> >
> >
> > > -----Original Message-----
> > > From: Marcus Leech [mailto:mleech@nortelnetworks.com]
> > > Sent: Thursday, August 02, 2001 9:34 PM
> > > To: msec@securemulticast.org; ietf-ipsra@vpnc.org;
> > > ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> > > Subject: Position statement on IKE development
> > >
> > >
> > > I'm sending the attached ASCII TEXT document on behalf of
> myself, Jeff
> > > Schiller, and
> > > Steve Bellovin, to clarify our position with respect to IKE
> > > development. It is our hope
> > > that it will clarify, to some extent, some fuzziness in
> > > this area that
> > > has evolved over
> > > the last year or so.
> > >
> >
> >
> > ------_=_NextPart_000_01C11C5C.14D9EDC0
> > Content-Type: application/octet-stream;
> > name="Phillip Hallam-Baker (E-mail).vcf"
> > Content-Disposition: attachment;
> > filename="Phillip Hallam-Baker (E-mail).vcf"
> >
> > BEGIN:VCARD
> > VERSION:2.1
> > N:Hallam-Baker;Phillip
> > FN:Phillip Hallam-Baker (E-mail)
> > ORG:VeriSign
> > TITLE:Principal Consultant
> > TEL;WORK;VOICE:(781) 245-6996 x227
> > EMAIL;PREF;INTERNET:hallam@verisign.com
> > REV:20010214T163732Z
> > END:VCARD
> >
> > ------_=_NextPart_000_01C11C5C.14D9EDC0--
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
>
<<Phillip Hallam-Baker (E-mail).vcf>>
------_=_NextPart_000_01C11E8D.12D55F40
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C11E8D.12D55F40--
From owner-ipsec@lists.tislabs.com Mon Aug 6 09:29:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76GTQN13247;
Mon, 6 Aug 2001 09:29:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08566
Mon, 6 Aug 2001 11:41:13 -0400 (EDT)
Message-Id: <200108061520.f76FKRK11964@nyarlathotep.keromytis.org>
X-Mailer: exmh version 2.0.2 2/24/98
To: ipsec@lists.tislabs.com
Subject: Phase 1 IDs ("son of IKE")
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 06 Aug 2001 11:20:27 -0400
From: "Angelos D. Keromytis" <angelos@coredump.cis.upenn.edu>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ted suggested I bring this up to the list:
Currently, the Responder in a Phase 1 (Main Mode) exchange picks the identity
to use based on the Initiator's IP address or Phase 1 ID, or uses some default
value (like the address of the interface the Phase 1 exchange occurs).
What I'd like to suggest is that the Initiator be allowed to send a Responder
Phase 1 ID payload, which the Responder will use as a hint as to what ID to
use itself; the Responder can ignore this hint, at the risk of the exchange
not being completed. The extra code to support this is fairly small (in the
order of 50 lines, in OpenBSD isakmpd).
This change allows for per-user authentication on IKE, and makes much simpler
Phase 1 negotiations where a) the Initiator and Responder roles change over
time (because of unbalanced Phase 1 SA expirations), *and* b) the Phase 1 ID
used by the Initiator is not the same as that used when it acts as a Responder.
Anyway, I'll say the same thing tomorrow at the WG meeting --- just wanted to
give some warning :-)
-Angelos
From owner-ipsec@lists.tislabs.com Mon Aug 6 11:21:27 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76ILRN15229;
Mon, 6 Aug 2001 11:21:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08777
Mon, 6 Aug 2001 13:33:52 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA47@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Steven M. Bellovin'" <smb@research.att.com>,
Alex Alten
<Alten@home.com>
Cc: Henry Spencer <henry@spsystems.net>,
Marcus Leech
<mleech@nortelnetworks.com>, msec@securemulticast.org,
ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: RE: Position statement on IKE development
Date: Mon, 6 Aug 2001 10:39:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C11E9E.C9E18270"
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_000_01C11E9E.C9E18270
Content-Type: text/plain;
charset="iso-8859-1"
A couple of points:
1) You state that Bruce and co had failled to understand the network
context. This is one of my concerns as people present IKE as a general
purpose solution to all key agreement problems - including the key agreement
for XML based Web services I have been working on.
The argument keeps being thrown up 'use what exists and is tested', yet the
protocol is of necessity tied to its context. It is not possible to pick up
ISAKMP/IKE and apply it to another appliction, I have tried. Yet others are
going to insist upon doing so.
I believe that the current multilayered, 'everything is negotiable'
negotiating mechanism is a liability even for its stated goal. It encourages
people to try to use ISAKMP for purposes which it just does not support.
2) The current problems with NAT occur because IPSEC is being used in a
network context it was never designed for. The IPSEC authentication
mechanisms are designed to bind a key to an IP address. In the case of a
user behind a NAT box that fails for obvious reasons.
The question to be asked then is does this shift in the networking context
affect the underlying security assumptions?
The meta-question is, do we have a framework that allows questions such as
these to be addressed?
This is the problem that really bit the 802.11b team, their scheme is broken
for two reasons, first the person who analysed the security appears to have
assumed a block cipher would be used and not a stream cipher, second the
design goals are fundamentally incomplete. The problem is not PRIVACY, but
authenticating the user to stop the sacked employee in the car park surfing
the ex-employer's intranet. Also any conception of privacy that includes
Louis Freeh having to be able to read all my packets if he is granted access
to the same network as me is somewhat strange to say the least... It may be
a feature of ethernet, in a wireless network with an encryption layer it is
a bug.
3) At this point we do not have a engineering approach to security protocol
analysis. The nearest I have seen to an analytical approach is the work Phil
Rogaway and Mihi Belhare have been doing on algorithms.
Putting out a tender for security protocol analysis would be pointless if
all we got as a result was a further set of experts reviewing the specs in
the same ad hoc 'can we see holes' fashion.
In the early days of bridge building the 'build it, see if it will fall
down' algorithm was employed. Today most people (makers of wobbly bridges in
London appart) believe in the 'use design principles that prevent failure'
approach. Unfortunately we don't have the design principles (yet).
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Steven M. Bellovin [mailto:smb@research.att.com]
> Sent: Saturday, August 04, 2001 7:00 PM
> To: Alex Alten
> Cc: Henry Spencer; Marcus Leech; msec@securemulticast.org;
> ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> Subject: Re: Position statement on IKE development
>
>
> In message <3.0.3.32.20010804144227.00ebdb30@mail>, Alex Alten writes:
>
>
> >>
> >>Agreed. And large parts of the Schneier/Ferguson analysis of the
> >>packet-level parts are just plain wrong.
> >>
> >
> >
> >Steve, with all due respect, you, Jeff and Marcus stated the
> following.
> >
> >"In the several years since the standardization of the IPSEC
> protocols
> >(ESP, AH, and ISAKMP/IKE), there have come to light several security
> >problems with the protocols, most notably the key-agreement protocol,
> >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
> >Simpson, have shown that the security problems in IKE stem directly
> >from its complexity."
> >
> >If IKE is no longer considered viable because of it's
> complexity, then
> >I am concerned that the other protocols of IPsec are also at
> risk. This
> >is not my concern alone, others have expressed it to me as well.
> >
> >At this point, to restore confidence in the security of the design I
> >would hope that the IETF will retain the services of a quality
> >cryptanalysis consulting firm and publish the results. To
> do otherwise
> >will be to risk the discrediting of the entire IPsec standard.
>
> Frankly, a lot of very competent folks did look at the cryptography.
> WIth all due modesty, I published two papers on the subject
> myself, and
> I wasn't the only one. In fact, that's one of the reasons why IPsec
> took so long -- the result of those analyses is why RFCs 1825-29 were
> replaced by 2401 et al. -- because we found and fixed a fair
> number of
> problems. The flaws in the Schneier/Ferguson analysis are
> because they don't understand the networking context. I sent Bruce a
> long, detailed note about that before he ever published the analysis.
>
> You say "retain the services of a quality cryptanalysis
> consulting firm".
> Apart from the point that there aren't that many -- and I and others
> know most of the likely players in the field -- the question
> is whether
> or not they understand the networking context. I have no particular
> reason to think that the results would be any better than
> what we have
> now.
>
> Is IPsec perfect? No, of course not. I'd like to get rid of AH, for
> example, not because it doesn't work -- it does -- but
> because it adds
> complexity to implementations without (to me) doing anything useful.
> There are a few other minor things I'd have done differently. But I
> have a great deal of confidence in the correctness of the
> packet-level
> transforms.
>
> --Steve Bellovin, http://www.research.att.com/~smb
>
>
------_=_NextPart_000_01C11E9E.C9E18270
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C11E9E.C9E18270--
From owner-ipsec@lists.tislabs.com Mon Aug 6 11:21:34 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76ILXN15251;
Mon, 6 Aug 2001 11:21:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08794
Mon, 6 Aug 2001 13:36:57 -0400 (EDT)
Message-ID: <8B204D152222D51182B70001028841372024CD@postmaster.cryptek.com>
From: "Aronson, David" <daronson@cryptek.com>
To: "'Shoichi Sakane'" <sakane@kame.net>
Cc: ipsec@lists.tislabs.com
Subject: RE: isakmp cookies field
Date: Mon, 6 Aug 2001 14:08:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Shoichi Sakane [mailto:sakane@kame.net] writes:
> of course, i've read this document. but i think this cookie creation
> couldn't prevent from dos or mitm attack.
I dunno, you may be right, I'm rather new to IKE/ISAKMP/etc., was just
quoting the RFC, and haven't the time right now to devote to a fuller
analysis. Can you trace out a situation in which a DoS or MitM attack would
succeed despite the cookies? (Even assuming that they are generated
according to the RFC's recommendation, or any later that may have superseded
it.) If you're wrong, I'm sure someone will speak up about how the cookies
would prevent it....
--
Dave Aronson, Sysop of free public Fidonet BBS Air 'n Sun, +1-703-319-0714.
Opinions all MINE, not by Cryptek/NRA/SCA/Mensa/HWG/LPUSA/CAUCE/FedGov/God!
See my web site, at http://listen.to/davearonson (last updated 2001-06-27).
Device-driver proggers: see http://www.cryptek.com and send me your resume!
From owner-ipsec@lists.tislabs.com Mon Aug 6 11:21:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76ILZN15266;
Mon, 6 Aug 2001 11:21:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08755
Mon, 6 Aug 2001 13:24:28 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA46@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Hugh Daniel'" <hugh@road.xisp.net>, design@lists-freeswan.org
Cc: wes@hardakers.net, ipsec@lists.tislabs.com
Subject: RE: Wes Hardaker: opportunistic encryption deployment problems
Date: Mon, 6 Aug 2001 10:30:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C11E9D.8BC4BDF0"
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_000_01C11E9D.8BC4BDF0
Content-Type: text/plain;
charset="iso-8859-1"
> At some point one has to just give up and tell folks to get it
> together and control there own resources.
OK, in my town high speed Internet is only available from one monopoly
supplier, AT&T broadband. Absent an act of Congress to force AT&T to
run their net the way you think they should, my only option is to start
digging up the city streets myself with a back hoe.
My situation is not unusual, it is the norm and will continue to be
the norm unless someone works out how to make DSL work in practice.
The Web grew because it adapted to the network configuration as it
was and not how the designers thought it should be. If you can't cope
with reality then that is your design problem and NOT someone else's
deployment problem.
> On the subject of NAT: If your NAT on the net your NOT on the net.
> That's what I personally say at least.
Without NAT the Internet would be dead of IP address exhaustion. To start
making pejorative comments about a scheme that is the main means of
conserving a scarce resource is unhelpful to say the least.
Equally there are many good reasons to conceal an IP address for security
purposes. I use NAT at my house, I don't want the structure of the internal
net to be revealled to the outside world. I want to know that there the only
servers in the network are the ones that I have set aside for that purpose
and maintain accordingly. I don't want to be spending my time applying the
latest inane patches to every machine.
Schemes that can't cope with NAT should be outlawed until IPv6 is deployable
and deployed.
Somehow the 'let them eat cake' attitude of the net-affluent reminds me of
a guy down in Washington.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
------_=_NextPart_000_01C11E9D.8BC4BDF0
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C11E9D.8BC4BDF0--
From owner-ipsec@lists.tislabs.com Mon Aug 6 12:41:24 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76JfNN16828;
Mon, 6 Aug 2001 12:41:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08876
Mon, 6 Aug 2001 14:34:14 -0400 (EDT)
Message-Id: <200108061717.f76HH5p25519@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: ipsec mailing list archive
In-reply-to: Your message of "Sun, 05 Aug 2001 14:49:36 +0900."
<20010805054937.EDB8E7BB@starfruit.itojun.org>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 06 Aug 2001 13:17:05 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Jun-ichiro" == Jun-ichiro itojun Hagino <itojun@iijlab.net> writes:
Jun-ichiro> unfortunately, both of those do not work. could you please
Jun-ichiro> find another one and list it onto the webpage?
Jun-ichiro> ftp://ftp.tis.com/pub/lists/ipsec - no ftp.tis.com any more?
Should be tislabs.com now.
Jun-ichiro> with google, i found a couple of these. i dunno which is
Jun-ichiro> better than the others. http://www.vpnc.org/ietf-ipsec/
Jun-ichiro> http://www.sandelman.ottawa.on.ca/ipsec/
I think that both Paul and my archives are current. Mine tends to
be 1/2 month out at times since I pull the archives from ftp.tislabs.com
instead of having an address subscribed.
I recommend Paul's archives, since he probably has better connectivity
than I.
Jun-ichiro> http://www.cs.arizona.edu/xkernel/www/ipsec/
I can't speak for this one.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
From owner-ipsec@lists.tislabs.com Mon Aug 6 12:41:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76JfcN16855;
Mon, 6 Aug 2001 12:41:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08897
Mon, 6 Aug 2001 14:45:49 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA49@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
Cc: ipsec@lists.tislabs.com
Subject: Cookies only make you fat
Date: Mon, 6 Aug 2001 11:50:33 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C11EA8.ABEE1350"
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_000_01C11EA8.ABEE1350
Content-Type: text/plain;
charset="iso-8859-1"
I just read Radia and Charlie's paper on IPSEC. I agree with the points they
make there against the IPSEC cookies. I now believe that cookies do nothing
but make the clients fat.
First consider the reason for having the cookies, to avoid the need to
maintain state in the server during the negotiation. But the negotiation
only takes multiple round trips because it overloads the protocol with
multiple functions (credential exchange) and attempts to conceal the
identities of the participants (poorly as it happens).
If the key agreement was a single round trip we would not require cookies.
Mutual agreement of a key is possible in one round trip.
Key agreement is not mutual authentication. It is slightly less. The
criteria for a mutual key agreement is that at the end of the protocol the
two parties have knowledge of the same shared token bound to the same
context data if and only if they are the parties that authenticated
themselves with the specified credentials. In mutual authentication there is
the additional requirement that the two parties know the status of the
other. But that is not our requirement here, all that is required is that
Alice only gets the correct token if and only if she is Alice.
In XKASS we use a single round trip, I hope to get the paper out by the end
of the week.
The other reason the key agreement is so long is because there is a half
baked attempt at concealling the identity of the principals. I use the term
'half-baked' in the technical sense, the scheme conceals some but not all of
the characteristics of the parties. Some observations:
1) True anonymous/anonymous contact in which neither party has any knowledge
of the other in advance is impossible (unless someone implements randomcast
routing in which your packets are sent off to a randomly chosen Internet
address). One party is going to have to be listening on a specific port of a
specific IP address somewhere.
2) If we assume that it is the responder whose credentials are 'known' in
some sense then the people who really, really want to have unobservable
communications can achieve them by simply issuing the clients with books of
disposable, one time use credentials [note that OnSite is sold on a 'per
seat basis' not 'per certificacte' any more so please don't ascribe unfair
reasons to the suggestion].
3) Alternatively assume that when Alice reauthenticates that she uses her
old expired SA (or similar data thrown up for the purpose during the
exchange) to encrypt the exchange. That would limit the identity leakage gap
to the first contact. I strongly suspect that is sufficient for many
purposes, or at least enough to serve.
4) The same information leaks out in the IP address in any case, so unless
we are going across a true Chaumian network or we are using the Starbucks
coffee house 802.11b alternative...
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
------_=_NextPart_000_01C11EA8.ABEE1350
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C11EA8.ABEE1350--
From owner-ipsec@lists.tislabs.com Mon Aug 6 13:20:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76KKRN17450;
Mon, 6 Aug 2001 13:20:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09036
Mon, 6 Aug 2001 15:25:50 -0400 (EDT)
Message-ID: <8894CA1F87A5D411BD24009027EE7838128231@ROC-76-204.nai.com>
From: "Mason, David" <David_Mason@nai.com>
To: "'Marcus Leech'" <mleech@nortelnetworks.com>, ietf-ipsra@vpnc.org,
ipsec@lists.tislabs.com
Cc: "'jis@mit.edu'" <jis@mit.edu>
Subject: RE: Position statement on IKE development
Date: Mon, 6 Aug 2001 12:28:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Is it true that the NAT traversal IKE and IPsec changes have been exempted
from the moratorium?
-dave
From owner-ipsec@lists.tislabs.com Mon Aug 6 13:24:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76KOqN17512;
Mon, 6 Aug 2001 13:24:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09048
Mon, 6 Aug 2001 15:26:25 -0400 (EDT)
Message-Id: <200108061932.f76JW4u66072@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Hugh Daniel <hugh@road.xisp.net>
cc: design@lists-freeswan.org, wes@hardakers.net, ipsec@lists.tislabs.com
Subject: Re: Wes Hardaker: opportunistic encryption deployment problems
In-reply-to: Your message of Mon, 06 Aug 2001 15:50:41 BST.
<200108061450.f76EofM05322@road.xisp.net>
Date: Mon, 06 Aug 2001 21:32:04 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
To answer Mr. Hardaker, we understand the problem with requiring the
data be in the reverse DNS space and considering a forward space
solution, but there are many folks who have no control over even their
forward space.
Wes Hardaker's orginal (partial) message:
3 problems I see with the deployment of opportunistic encryption:
1) your method of obtaining information is by reverse DNS lookup,
which will provide problems with people who can't control their
reverse DNS bindings. As an example, I don't have control over the
subnet mapped to my house and can not insert information into the
controlling DNS server (and can not convince them to redirect to
me).
=> first you should complain at your provider provider. I don't know
the rules for ARIN but in Europe RIPE rules are clear: someone can get
some address space only if it manages the reverse map and delegates
it with parts of its address space. Of course RFC 2317 is not easy
so even this kind of rules doesn't provide always a solution...
Second point, when DNSSEC will be deployed it should be available
for reverse maps first because today reverse maps are broken , nobody
shall rely on them so they are free for experiments or an "all or
nothing" use (DNSSEC should become a part of the "all" in this view).
Don't forget direct maps are for NICs/RIRs clients and reverse maps
are for operators/ISPs which should have the technical skill and
a very different relationship with NICs/RIRs.
Concretly, there are some deployment efforts from various NICs/RIRs
and we can expect some results one day.
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Mon Aug 6 14:44:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76Li3N18700;
Mon, 6 Aug 2001 14:44:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09307
Mon, 6 Aug 2001 16:49:01 -0400 (EDT)
From: mcnelson@mindspring.com
Date: Mon, 06 Aug 2001 16:56:02 -0400
To: pbaker@verisign.com
Cc: ipsec@lists.tislabs.com
Subject: Re: RE: Position statement on IKE development
Message-ID: <Springmail.105.997131362.0.50129600@www.springmail.com>
X-Originating-IP: 208.37.68.36
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Unfortunately the notion that IPsec should simply \"bind
a key to an IP address\" was rejected repeatedly throughout
the history of the IPsec WG. There are alternative
protocols that have been built that demonstrate that one
can provide a useful and appropriate encryption service
in the IP layer and that such a system can be keyed and
managed in a simple scalable way.
Trying to key and manage all kinds of relationships many
of which are conceptually challenging when viewed from
the IP layer, is felt by many to be at the core of IPsec\'s
complexity.
As far as testing is concerned, it would be interesting
to see an IPsec protected network set up as a challenge
to the general networking public with a sizable cash
price offered for the first 10 breakins.
Mitch Nelson
\"Hallam-Baker, Phillip\" <pbaker@verisign.com> wrote:
> A couple of points:
1) You state that Bruce and co had failled to understand the network
context. This is one of my concerns as people present IKE as a general
purpose solution to all key agreement problems - including the key agreement
for XML based Web services I have been working on.
The argument keeps being thrown up \'use what exists and is tested\', yet the
protocol is of necessity tied to its context. It is not possible to pick up
ISAKMP/IKE and apply it to another appliction, I have tried. Yet others are
going to insist upon doing so.
I believe that the current multilayered, \'everything is negotiable\'
negotiating mechanism is a liability even for its stated goal. It encourages
people to try to use ISAKMP for purposes which it just does not support.
2) The current problems with NAT occur because IPSEC is being used in a
network context it was never designed for. The IPSEC authentication
mechanisms are designed to bind a key to an IP address. In the case of a
user behind a NAT box that fails for obvious reasons.
The question to be asked then is does this shift in the networking context
affect the underlying security assumptions?
The meta-question is, do we have a framework that allows questions such as
these to be addressed?
This is the problem that really bit the 802.11b team, their scheme is broken
for two reasons, first the person who analysed the security appears to have
assumed a block cipher would be used and not a stream cipher, second the
design goals are fundamentally incomplete. The problem is not PRIVACY, but
authenticating the user to stop the sacked employee in the car park surfing
the ex-employer\'s intranet. Also any conception of privacy that includes
Louis Freeh having to be able to read all my packets if he is granted access
to the same network as me is somewhat strange to say the least... It may be
a feature of ethernet, in a wireless network with an encryption layer it is
a bug.
3) At this point we do not have a engineering approach to security protocol
analysis. The nearest I have seen to an analytical approach is the work Phil
Rogaway and Mihi Belhare have been doing on algorithms.
Putting out a tender for security protocol analysis would be pointless if
all we got as a result was a further set of experts reviewing the specs in
the same ad hoc \'can we see holes\' fashion.
In the early days of bridge building the \'build it, see if it will fall
down\' algorithm was employed. Today most people (makers of wobbly bridges in
London appart) believe in the \'use design principles that prevent failure\'
approach. Unfortunately we don\'t have the design principles (yet).
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Steven M. Bellovin [mailto:smb@research.att.com]
> Sent: Saturday, August 04, 2001 7:00 PM
> To: Alex Alten
> Cc: Henry Spencer; Marcus Leech; msec@securemulticast.org;
> ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> Subject: Re: Position statement on IKE development
>
>
> In message , Alex Alten writes:
>
>
> >>
> >>Agreed. And large parts of the Schneier/Ferguson analysis of the
> >>packet-level parts are just plain wrong.
> >>
> >
> >
> >Steve, with all due respect, you, Jeff and Marcus stated the
> following.
> >
> >\"In the several years since the standardization of the IPSEC
> protocols
> >(ESP, AH, and ISAKMP/IKE), there have come to light several security
> >problems with the protocols, most notably the key-agreement protocol,
> >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
> >Simpson, have shown that the security problems in IKE stem directly
> >from its complexity.\"
> >
> >If IKE is no longer considered viable because of it\'s
> complexity, then
> >I am concerned that the other protocols of IPsec are also at
> risk. This
> >is not my concern alone, others have expressed it to me as well.
> >
> >At this point, to restore confidence in the security of the design I
> >would hope that the IETF will retain the services of a quality
> >cryptanalysis consulting firm and publish the results. To
> do otherwise
> >will be to risk the discrediting of the entire IPsec standard.
>
> Frankly, a lot of very competent folks did look at the cryptography.
> WIth all due modesty, I published two papers on the subject
> myself, and
> I wasn\'t the only one. In fact, that\'s one of the reasons why IPsec
> took so long -- the result of those analyses is why RFCs 1825-29 were
> replaced by 2401 et al. -- because we found and fixed a fair
> number of
> problems. The flaws in the Schneier/Ferguson analysis are
> because they don\'t understand the networking context. I sent Bruce a
> long, detailed note about that before he ever published the analysis.
>
> You say \"retain the services of a quality cryptanalysis
> consulting firm\".
> Apart from the point that there aren\'t that many -- and I and others
> know most of the likely players in the field -- the question
> is whether
> or not they understand the networking context. I have no particular
> reason to think that the results would be any better than
> what we have
> now.
>
> Is IPsec perfect? No, of course not. I\'d like to get rid of AH, for
> example, not because it doesn\'t work -- it does -- but
> because it adds
> complexity to implementations without (to me) doing anything useful.
> There are a few other minor things I\'d have done differently. But I
> have a great deal of confidence in the correctness of the
> packet-level
> transforms.
>
> --Steve Bellovin, http://www.research.att.com/~smb
>
>
From owner-ipsec@lists.tislabs.com Mon Aug 6 14:44:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76Li8N18712;
Mon, 6 Aug 2001 14:44:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09335
Mon, 6 Aug 2001 17:04:06 -0400 (EDT)
Message-ID: <3B6F07DC.F3A37A39@storm.ca>
Date: Mon, 06 Aug 2001 17:10:52 -0400
From: Sandy Harris <sandy@storm.ca>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Re: opportunistic encryption deployment problems
References: <sd4rrlb6k1.fsf@wanderer.hardakers.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Wes Hardaker wrote:
>
> 3 problems I see with the deployment of opportunistic encryption:
>
> 1) your method of obtaining information is by reverse DNS lookup,
> which will provide problems with people who can't control their
> reverse DNS bindings. As an example, I don't have control over the
> subnet mapped to my house and can not insert information into the
> controlling DNS server (and can not convince them to redirect to
> me).
Yes, but what alternatives are there, short of giving up on DNS and
mandating that anyone wanting to do opportunistic encryption must
have a particular type of PKI infrastructure in place?
What is really wanted is support in the DNS for inverse queries, as
Henry says in a document that preceeded the ID:
http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/opportunism.spec
> Inverse queries, an obscure DNS feature from the distant past,
> in theory can be used to ask a DNS server to reverse that
> lookup, giving the name that produced the address.
> This is not the same as a reverse lookup, and the difference can
> matter a great deal in cases where a host does not control
> its reverse map (e.g., when the host's IP address is dynamically
> assigned). Unfortunately, inverse queries were never widely
> implemented and are now considered obsolete.
I suppose we could be trying to convince DNS implementors to support
them, but it seems unlikely we could do that. Even if we succeeded,
we'd still need a fallback mechanism for the situations where such
support wasn't in place.
Putting keys in the forward maps has some nice consequences, but
also some serious problems.
It goes a long way toward solving the problem for people with
dynamic addresses. All we need to do is persuade the providers of
dynamic DNS services to include keys. Well, not quite all. We
have to work out how they can do that securely, and persuade
them to implement secure DNS, and get things signed and ...
It may also make connection setup faster. In the current design,
the sequence is often:
client does forward lookup to get IP address
client builds and sends packet
gateway interecepts packet
gateway does reverse lookup to get key
gateway starts negotiation
If we could change it to:
client does forward lookup to get IP address
gateway gets key as a byproduct
gateway starts negotiation
that would involve less delay.
However, short of requiring that every IPsec gateway run a DNS daemon,
that clients all use that as their DNS server, and that the daemon be
modified for some extra functionality (roughly equivalent to inverse
queries), this does not work.
Even if the responding DNS delivers key information from a forward map
in response to client queries, the gateway has no way to get that info.
All it sees is a packet with an IP address. It can get key info from a
reverse map in one lookup. If the info is in a forward map, it needs
two lookups and there can be complications with multiple names.
Just taking the overhead hit and telling it do the two lookups doesn't
work. In the situation you mention -- dynamic address and no control
over the reverse map -- the reverse does not point to the name we
want used in the subsequent forward lookup.
Even in cases where it does give the right answer, the extra overhead
of two lookups is a problem. Opportunistic must be fast; there are user
packets waiting for the connection to be set up or declared unavailable.
If we do specify a DNS daemon on the gateway and arrange for it, on
doing a lookup for a client, to get a key if possible and pass it
(how?) to IPsec, we still have problems. Clients will sometimes use
addresses without first looking up the names, so we need another
mechanism for that case.
Also, it is by no means clear that requiring a DNS server on the
gateway will fit into local security policies.
From owner-ipsec@lists.tislabs.com Mon Aug 6 14:49:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76LnSN18765;
Mon, 6 Aug 2001 14:49:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09341
Mon, 6 Aug 2001 17:04:20 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA4B@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Francis Dupont'" <Francis.Dupont@enst-bretagne.fr>,
Hugh Daniel
<hugh@road.xisp.net>
Cc: wes@hardakers.net, ipsec@lists.tislabs.com
Subject: RE: Wes Hardaker: opportunistic encryption deployment problems
Date: Mon, 6 Aug 2001 14:07:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C11EBB.BD0518B0"
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_000_01C11EBB.BD0518B0
Content-Type: text/plain;
charset="iso-8859-1"
> => first you should complain at your provider provider. I don't know
> the rules for ARIN but in Europe RIPE rules are clear: someone can get
> some address space only if it manages the reverse map and delegates
> it with parts of its address space. Of course RFC 2317 is not easy
> so even this kind of rules doesn't provide always a solution...
Support for reverse DNS lookup for current purposes (limited debugging)
should not be conflated into support for a dependable service with
arbitrary extensions added in to support specific applications.
In particular reverse DNS is not much use when the target does not
have a DNS address. This is the case for the vast majority of DCHP
hosted home Internet hookups.
I *like* my 10Mb/s cable modem into my house, particularly since I
am the only person on my loop. If you want people to use your technology
best design it arround their constraints.
> Second point, when DNSSEC will be deployed it should be available
> for reverse maps first because today reverse maps are broken , nobody
> shall rely on them so they are free for experiments or an "all or
> nothing" use (DNSSEC should become a part of the "all" in this view).
> Don't forget direct maps are for NICs/RIRs clients and reverse maps
> are for operators/ISPs which should have the technical skill and
> a very different relationship with NICs/RIRs.
> Concretly, there are some deployment efforts from various NICs/RIRs
> and we can expect some results one day.
I would not rely on any outcome being achieved as a byproduct of
DNSSEC. DNSSEC has too many deployment obstacles of its own making
to overcome without being given the task of putting other parts of
the world to right on the way.
Persuading people to use a new DNS system that requires more public
key operations than SET to validate a single domain name is challenging
enough without making its use dependent on reverse DNS being deployed.
Phill
------_=_NextPart_000_01C11EBB.BD0518B0
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C11EBB.BD0518B0--
From owner-ipsec@lists.tislabs.com Mon Aug 6 15:35:34 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76MZXN19298;
Mon, 6 Aug 2001 15:35:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09510
Mon, 6 Aug 2001 17:55:16 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA4C@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'mcnelson@mindspring.com'" <mcnelson@mindspring.com>,
"Hallam-Baker, Phillip" <pbaker@verisign.com>
Cc: ipsec@lists.tislabs.com
Subject: IKE must have no Heirs
Date: Mon, 6 Aug 2001 15:02:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C11EC3.70947CC0"
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_000_01C11EC3.70947CC0
Content-Type: text/plain;
charset="iso-8859-1"
> Unfortunately the notion that IPsec should simply \"bind
> a key to an IP address\" was rejected repeatedly throughout
> the history of the IPsec WG.
This is why I think we have to stop talking about 'son of IKE'
as if the problem was in the 7 years and 9 months of trying to
implement the requirements and not the 3 months of requirements
capture.
If a WG takes 8 years to come up with a solution it indicates
a broken set of requirements. In the time that we have been waiting
for IPSEC and DNSSEC to deploy we have deployed one generation of
PKIX/X509.v3 based PKI and have started deployment of a second
generation architecture to replace it. We can move quickly when
there is clarity in the requirements.
The first people to complain about the complexity of IKE were
told 'we have been working on this for a year, it is too late
to start again'.
The next lot were told 'we have been working on this for two
years, we can't wait another two'.
The 'we have spent so long digging the well here we will not
try digging elsewhere, even though others have struck water there'
argument is self re-inforcing but does nothing but perpetuate
the original broken assumptions. If the argument for the
status quo is strong today 'it would take 8 years to replace IKE',
just think how strong it will be in 2009 - 'it has taken 16
years to get this far, we will all be retired before your
redesign is complete'.
The DNSSEC group have been making a similar argument for years
concerning the specious 'requirement' for non-repudiable
responses. Despite the fact that non-repudiation is worthless
without infrastructure to archive the messages no client will
ever implement, the DNSSEC spec makes a fetish of it to the
extent that each field in each message has its own signature.
The combination of the non-repudiation requirement and the
backwards compatibility requirement cannot be met except at
unacceptable cost.
The problem is not the demand for additional features, the problem
is that they have to be addressed as 'additional'. IKE/ISAKMP
spent their entire complexity budget on a negotiation framework
for variation in features that are not core, not essential while
ignoring real world problems such as NAT that are core.
>From here there are two routes forward. We could specify a reduced
IKE, eliminating all but 2 of the current 8 modes, simplifying the
negotiation, knife AH... to result in a simpler draft that we can be
confident would get a broad review. I think that would have been an
excellent idea three years ago, I think that it is too late after
the interop tests have been performed. All that would come out
is a description of a profile of the current spec that resulted
in one configuration that was secure. But implementations would
still be constrained by the existing legacy base which would
drag deployments back into the mire of unexamined code paths and
unanticipated interactions.
The second is to burn the current drafts and start from scratch
with a fresh port number. If any change is made that breaks
backwards compatibility then this might as well be what you do.
In short the phrase 'Son of IKE' is part of the problem, not
the solution. IKE must have no heirs, it is time for a new dynasty
to take the throne.
Phill
------_=_NextPart_000_01C11EC3.70947CC0
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C11EC3.70947CC0--
From owner-ipsec@lists.tislabs.com Mon Aug 6 16:26:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f76NQPN20162;
Mon, 6 Aug 2001 16:26:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09624
Mon, 6 Aug 2001 18:43:52 -0400 (EDT)
Message-ID: <3B6F1F2F.A28C6371@hns.com>
Date: Mon, 06 Aug 2001 18:50:23 -0400
From: borderlt <border@hns.com>
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Re draft-kaufman-ipsec-improveike-00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Re getting rid of aggressive mode... Sigh! I can see the reasoning
behind wanting to simplify down to only one mode. But, not offering the
option for fewer messages will affect deployment of IPsec for links with high
latency. We are starting to see a lot demand for the use of IPsec over
satellite links with the usual corresponding optimization questions. And,
identity hiding is not important for the cases where this has come up...
John
From owner-ipsec@lists.tislabs.com Mon Aug 6 17:06:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7706BN20699;
Mon, 6 Aug 2001 17:06:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09746
Mon, 6 Aug 2001 19:22:40 -0400 (EDT)
Date: Mon, 6 Aug 2001 16:29:03 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: borderlt <border@hns.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Re draft-kaufman-ipsec-improveike-00.txt
In-Reply-To: <3B6F1F2F.A28C6371@hns.com>
Message-ID: <Pine.LNX.4.21.0108061622570.1153-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I see this argument a lot, and I've also used it in the past. My current
thinking is: There's several routing protocols, not just one. They are sort
of tailored to an certain network-topology, and one routing-protocol doesn't
necessarily work in all topologies. We should look at a keying protocol in
the same way.
I suggest we work on more than one keying mechanism. Each one should be
simple and should be tailored to one type of environment (the VPN space is
afterall very different from the core-network environment). Different people
will have different requirements, too. The answer to 'which keying protocol
should I use' is no longer simple then, and requires one to think about the
situation we're using it in, and what we want from it. So be it. It's not
like users have to think about this stuff: It's what network admins do. They
already have to deal with 'which routing protocol should I use'.
We can then generate more than one rather simple keying mechanisms, that may
or may not overlap slightly, but have strengths in different areas.
Flames to /dev/null, constructive criticism encouraged. I am, of course, not
a network admin, so those that have this job may well tell me this is a
non-starter.
Of course you should realize that we are already doing this: KINK is a keying
protocol tailored to certain requirements. It doesn't try to be everything to
all people. We probably need only one or two more to cover the other current
requirements people have of a keying protocol.
jan
On Mon, 6 Aug 2001, borderlt wrote:
>
> Re getting rid of aggressive mode... Sigh! I can see the reasoning
> behind wanting to simplify down to only one mode. But, not offering the
> option for fewer messages will affect deployment of IPsec for links with high
> latency. We are starting to see a lot demand for the use of IPsec over
> satellite links with the usual corresponding optimization questions. And,
> identity hiding is not important for the cases where this has come up...
>
>
> John
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Mon Aug 6 18:01:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77119N21526;
Mon, 6 Aug 2001 18:01:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09870
Mon, 6 Aug 2001 20:10:37 -0400 (EDT)
Date: Mon, 6 Aug 2001 16:15:05 -0700 (PDT)
Message-Id: <200108062315.QAA09683@potomac.incog.com>
From: ford@apollo.incog.com (Mike "Ford" Ditto)
To: angelos@coredump.cis.upenn.edu
CC: ipsec@lists.tislabs.com@potomac.incog.com
In-reply-to: <200108061520.f76FKRK11964@nyarlathotep.keromytis.org>
(angelos@coredump.cis.upenn.edu)
Subject: Re: Phase 1 IDs ("son of IKE")
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: "Angelos D. Keromytis" <angelos@coredump.cis.upenn.edu>
>
> Currently, the Responder in a Phase 1 (Main Mode) exchange picks the identity
> to use based on the Initiator's IP address or Phase 1 ID, or uses some default
> value (like the address of the interface the Phase 1 exchange occurs).
The responder could conceivably use any information available, such as
the proposed Phase I protection suite or the time of day.
> What I'd like to suggest is that the Initiator be allowed to send a Responder
> Phase 1 ID payload, which the Responder will use as a hint as to what ID to
> use itself; the Responder can ignore this hint, at the risk of the exchange
> not being completed. The extra code to support this is fairly small (in the
> order of 50 lines, in OpenBSD isakmpd).
This is an interesting suggestion. The current IKE scheme is the
equivalent of calling a telephone number and saying "Hi, this is Mike,
may I please speak to someone there?" and when the responder says "This
is Joe," hanging up because you really wanted to talk to Bob. If you
had just asked for Bob in the first place, the responder could have
handed the phone to Bob.
One problem is that the initiator's policy may not express the
desired/allowed remote identity in a simple form that can be conveyed to
the responder. For example, the initiator's policy may allow a
connection with any remote identity that has a certificate signed by a
particular CA, or with any of a long list of remote identities, or with
a particular value of O= and OU= name components, but any CN= name
component. The possibilities vary depending on the flexibility of the
initiator's policy language. Even in the case of a single intended
remote identity, it's possible that the initiator might use an alternate
name for that identity that is not recognized by the responder, but
still be able to recognize and accept the name that the responder would
use in the absence of any "hint".
But if the identity hint was used as an abstract name, rather than the
exact identity that the responder is expected to use, it could be used
as a kind of generic "scope" or "role" identifier. For example, if the
initiator sends a hint of "internal-vpn.my.org", then a responder with
many local identities could be configured to choose the identity that is
appropriate for use as a gateway to the internal VPN when it sees that
particular hint; for other hints it could be configured to use a more
public identity.
-=] Ford [=-
From owner-ipsec@lists.tislabs.com Mon Aug 6 18:16:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f771GoN21884;
Mon, 6 Aug 2001 18:16:51 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09961
Mon, 6 Aug 2001 20:38:39 -0400 (EDT)
Message-Id: <200108070041.f770f1J23253@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: "Horn, Mike" <mhorn@virtela.net>
cc: "'Theodore Tso'" <tytso@mit.edu>,
Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>,
"'Alex Alten'" <Alten@home.com>,
"'Marcus Leech'" <mleech@nortelnetworks.com>, ipsec@lists.tislabs.com,
ietf-ipsra@vpnc.org
Subject: Re: Position statement on IKE development
In-reply-to: Your message of "Mon, 06 Aug 2001 18:03:08 MDT."
<CCFF88268143CC4181A758DCC0ECDC13DE773D@posthaus.virtela.cc>
Reply-to: sommerfeld@East.Sun.COM
Date: Mon, 06 Aug 2001 20:41:01 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> One of the reasons various user authentication schemes have not been
> considered (CRACK for instance) is the moratorium on changes to IKE.
> Unfortunately the IPSRA WG is very dependent on IKE.
The IPSRA WG is not at all dependant on IKE; it's really all about
protocols to turn legacy authentication into certificates..
- Bill
From owner-ipsec@lists.tislabs.com Tue Aug 7 00:07:27 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7777RN08247;
Tue, 7 Aug 2001 00:07:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA10480
Tue, 7 Aug 2001 02:01:05 -0400 (EDT)
Date: Mon, 6 Aug 2001 23:07:06 -0700 (PDT)
From: Kory Hamzeh <kory@avatar.com>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
cc: "'mcnelson@mindspring.com'" <mcnelson@mindspring.com>,
ipsec@lists.tislabs.com
Subject: Re: IKE must have no Heirs
In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40154CA4C@vhqpostal.verisign.com>
Message-ID: <Pine.BSF.3.96.1010806230331.19308B-100000@ns1.avatar.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Well said. I agree with you 100%. Throw is out and let's start from
scratch with something more reasonable and realistic.
Kory
On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote:
>
> > Unfortunately the notion that IPsec should simply \"bind
> > a key to an IP address\" was rejected repeatedly throughout
> > the history of the IPsec WG.
>
> This is why I think we have to stop talking about 'son of IKE'
> as if the problem was in the 7 years and 9 months of trying to
> implement the requirements and not the 3 months of requirements
> capture.
>
> [ ..... ]
>
> From here there are two routes forward. We could specify a reduced
> IKE, eliminating all but 2 of the current 8 modes, simplifying the
> negotiation, knife AH... to result in a simpler draft that we can be
> confident would get a broad review. I think that would have been an
> excellent idea three years ago, I think that it is too late after
> the interop tests have been performed. All that would come out
> is a description of a profile of the current spec that resulted
> in one configuration that was secure. But implementations would
> still be constrained by the existing legacy base which would
> drag deployments back into the mire of unexamined code paths and
> unanticipated interactions.
>
> The second is to burn the current drafts and start from scratch
> with a fresh port number. If any change is made that breaks
> backwards compatibility then this might as well be what you do.
>
> In short the phrase 'Son of IKE' is part of the problem, not
> the solution. IKE must have no heirs, it is time for a new dynasty
> to take the throne.
>
>
> Phill
>
>
From owner-ipsec@lists.tislabs.com Tue Aug 7 01:14:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f778E9N15741;
Tue, 7 Aug 2001 01:14:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA10645
Tue, 7 Aug 2001 03:22:20 -0400 (EDT)
Message-Id: <3.0.3.32.20010807002820.010a77f8@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Tue, 07 Aug 2001 00:28:20 -0700
To: Kory Hamzeh <kory@avatar.com>,
"Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Alex Alten <Alten@home.com>
Subject: Re: IKE must have no Heirs
Cc: "'mcnelson@mindspring.com'" <mcnelson@mindspring.com>,
ipsec@lists.tislabs.com
In-Reply-To: <Pine.BSF.3.96.1010806230331.19308B-100000@ns1.avatar.com>
References: <2F3EC696EAEED311BB2D009027C3F4F40154CA4C@vhqpostal.verisign.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I second the motion. And also propose no port number (i.e. do the new
one over raw IP).
- Alex
At 11:07 PM 8/6/2001 -0700, Kory Hamzeh wrote:
>
>Well said. I agree with you 100%. Throw is out and let's start from
>scratch with something more reasonable and realistic.
>
>Kory
>
>
>On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote:
>
>>
>> > Unfortunately the notion that IPsec should simply \"bind
>> > a key to an IP address\" was rejected repeatedly throughout
>> > the history of the IPsec WG.
>>
>> This is why I think we have to stop talking about 'son of IKE'
>> as if the problem was in the 7 years and 9 months of trying to
>> implement the requirements and not the 3 months of requirements
>> capture.
>>
>> [ ..... ]
>>
>> From here there are two routes forward. We could specify a reduced
>> IKE, eliminating all but 2 of the current 8 modes, simplifying the
>> negotiation, knife AH... to result in a simpler draft that we can be
>> confident would get a broad review. I think that would have been an
>> excellent idea three years ago, I think that it is too late after
>> the interop tests have been performed. All that would come out
>> is a description of a profile of the current spec that resulted
>> in one configuration that was secure. But implementations would
>> still be constrained by the existing legacy base which would
>> drag deployments back into the mire of unexamined code paths and
>> unanticipated interactions.
>>
>> The second is to burn the current drafts and start from scratch
>> with a fresh port number. If any change is made that breaks
>> backwards compatibility then this might as well be what you do.
>>
>> In short the phrase 'Son of IKE' is part of the problem, not
>> the solution. IKE must have no heirs, it is time for a new dynasty
>> to take the throne.
>>
>>
>> Phill
>>
>>
>
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Tue Aug 7 02:01:46 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7791kN21486;
Tue, 7 Aug 2001 02:01:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10834
Tue, 7 Aug 2001 04:07:49 -0400 (EDT)
Message-Id: <200108070812.f778Cfu67935@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
cc: Hugh Daniel <hugh@road.xisp.net>, wes@hardakers.net,
ipsec@lists.tislabs.com
Subject: Re: Wes Hardaker: opportunistic encryption deployment problems
In-reply-to: Your message of Mon, 06 Aug 2001 14:07:02 PDT.
<2F3EC696EAEED311BB2D009027C3F4F40154CA4B@vhqpostal.verisign.com>
Date: Tue, 07 Aug 2001 10:12:41 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
> => first you should complain at your provider provider. I don't know
> the rules for ARIN but in Europe RIPE rules are clear: someone can get
> some address space only if it manages the reverse map and delegates
> it with parts of its address space. Of course RFC 2317 is not easy
> so even this kind of rules doesn't provide always a solution...
Support for reverse DNS lookup for current purposes (limited debugging)
should not be conflated into support for a dependable service with
arbitrary extensions added in to support specific applications.
In particular reverse DNS is not much use when the target does not
have a DNS address.
=> DNS name.
This is the case for the vast majority of DCHP hosted home Internet
hookups.
=> my answer was about a fixed subnet, not a dynamic single address.
I *like* my 10Mb/s cable modem into my house, particularly since I
am the only person on my loop. If you want people to use your technology
best design it arround their constraints.
=> you don't use the Internet itself, you use an online service connected
to the Internet. Or explain how you can run a server at home...
Obviously you are out of the topics.
(PS: I know you are not responsible of this situation, the shame is
for your monopolistic ISP :-).
> Second point, when DNSSEC will be deployed it should be available
> for reverse maps first because today reverse maps are broken , nobody
> shall rely on them so they are free for experiments or an "all or
> nothing" use (DNSSEC should become a part of the "all" in this view).
> Don't forget direct maps are for NICs/RIRs clients and reverse maps
> are for operators/ISPs which should have the technical skill and
> a very different relationship with NICs/RIRs.
> Concretly, there are some deployment efforts from various NICs/RIRs
> and we can expect some results one day.
I would not rely on any outcome being achieved as a byproduct of
DNSSEC.
=> you can believe in DNSSEC or not, or would like to believe in it
in the future (my case). I've just said that DNSSEC deployment efforts
should be for reverse maps...
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Tue Aug 7 02:15:31 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f779FUN22373;
Tue, 7 Aug 2001 02:15:30 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10859
Tue, 7 Aug 2001 04:19:04 -0400 (EDT)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B8028A14@hhdata3.cdsemea.baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: Alex Alten <Alten@home.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
Date: Tue, 7 Aug 2001 09:22:47 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: Alex Alten [mailto:Alten@home.com]
> Sent: 07 August 2001 08:28
> To: Kory Hamzeh; Hallam-Baker, Phillip
> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> Subject: Re: IKE must have no Heirs
>
>
>
> I second the motion. And also propose no port number (i.e. do the new
> one over raw IP).
>
> - Alex
What would that achieve? (communicating over raw IP)
Chris
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
From owner-ipsec@lists.tislabs.com Tue Aug 7 03:10:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77AASN24716;
Tue, 7 Aug 2001 03:10:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10978
Tue, 7 Aug 2001 04:59:54 -0400 (EDT)
Message-Id: <3.0.3.32.20010807020559.00d89980@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Tue, 07 Aug 2001 02:05:59 -0700
To: Chris Trobridge <CTrobridge@baltimore.com>
From: Alex Alten <Alten@home.com>
Subject: RE: IKE must have no Heirs
Cc: ipsec@lists.tislabs.com
In-Reply-To: <F86F34FDF1F9D411B7A40008C74C27B8028A14@hhdata3.cdsemea.bal
timore.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Think about it. Do you do OSPF over IP and then BGP over UDP?
The same applies to IPSEC and key management.
- Alex
At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
>
>
>> -----Original Message-----
>> From: Alex Alten [mailto:Alten@home.com]
>> Sent: 07 August 2001 08:28
>> To: Kory Hamzeh; Hallam-Baker, Phillip
>> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
>> Subject: Re: IKE must have no Heirs
>>
>>
>>
>> I second the motion. And also propose no port number (i.e. do the new
>> one over raw IP).
>>
>> - Alex
>
>What would that achieve? (communicating over raw IP)
>
>Chris
>
>
>---------------------------------------------------------------------------
--------------------------------------
>The information contained in this message is confidential and is intended
>for the addressee(s) only. If you have received this message in error or
>there are any problems please notify the originator immediately. The
>unauthorized use, disclosure, copying or alteration of this message is
>strictly forbidden. Baltimore Technologies plc will not be liable for
direct,
>special, indirect or consequential damages arising from alteration of the
>contents of this message by a third party or as a result of any virus being
>passed on.
>
>In addition, certain Marketing collateral may be added from time to time to
>promote Baltimore Technologies products, services, Global e-Security or
>appearance at trade shows and conferences.
>
>This footnote confirms that this email message has been swept by
>Baltimore MIMEsweeper for Content Security threats, including
>computer viruses.
>
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Tue Aug 7 05:30:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77CUmN01331;
Tue, 7 Aug 2001 05:30:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11374
Tue, 7 Aug 2001 07:17:44 -0400 (EDT)
Subject: Re: isakmp cookies field
To: Shoichi Sakane <sakane@kame.net>
Cc: ipsec@lists.tislabs.com
From: Niels Provos <provos@citi.umich.edu>
In-Reply-To: Shoichi Sakane, Mon, 06 Aug 2001 20:48:24 +0900
Date: Tue, 07 Aug 2001 07:24:48 -0400
Message-Id: <20010807112448.6FB72207C1@citi.umich.edu>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <20010806204824B.sakane@kame.net>, Shoichi Sakane writes:
>could anybody tell me what the benefit of the isakmp cookie field is ?
>i think the cookie indicates just isakmp spi. does it have any function
>to prevent from dos attack ?
It does not prevent simple resource starvation attacks. You might
want to read Bill Simpson's "IKE/ISAKMP considered harmful" about that.
You can find the article at
http://www.usenix.org/publications/login/1999-12/features/harmful.html
Greetings,
Niels.
From owner-ipsec@lists.tislabs.com Tue Aug 7 06:06:23 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77D6NN02020;
Tue, 7 Aug 2001 06:06:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11500
Tue, 7 Aug 2001 08:12:54 -0400 (EDT)
Message-ID: <3B6EF26D.E8A2C7D0@pgp.com>
Date: Mon, 06 Aug 2001 12:39:25 -0700
From: Will Price <wprice@pgp.com>
Reply-To: wprice@pgp.com
X-Mailer: Mozilla 4.75 (Macintosh; U; PPC)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: "Mason, David" <David_Mason@nai.com>
CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com,
"'jis@mit.edu'" <jis@mit.edu>
Subject: Re: Position statement on IKE development
References: <8894CA1F87A5D411BD24009027EE7838128231@ROC-76-204.nai.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Yes. See Ted's message from yesterday.
"Mason, David" wrote:
>
> Is it true that the NAT traversal IKE and IPsec changes have been exempted
> from the moratorium?
> -dave
--
From owner-ipsec@lists.tislabs.com Tue Aug 7 06:37:31 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DbUN02695;
Tue, 7 Aug 2001 06:37:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11539
Tue, 7 Aug 2001 08:31:55 -0400 (EDT)
Message-ID: <001501c11f3e$58ade7b0$4e8d21d9@sfanninglaptop>
From: "Scott Fanning" <sfanning@cisco.com>
To: "Chris Trobridge" <CTrobridge@baltimore.com>,
"Alex Alten" <Alten@home.com>
Cc: <ipsec@lists.tislabs.com>
References: <3.0.3.32.20010807020559.00d89980@mail>
Subject: Re: IKE must have no Heirs
Date: Tue, 7 Aug 2001 05:41:55 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
So, what do we propose to those that are using IKE right now (like
customers). Oops, sorry, its too complex. Maybe next time?
I suggest that we look at the documents that describe the improvements, and
ask the implementors (the ones confused by the complexity) how the standards
body can work to make their job easier (A clearly defined state machine
would be nice, with less SHOULDs' and more MUSTs).
Also, any changes should keep in mind an easy transition to "Son of Ike" so
that deploying the less complex version of IKE, does not create more
complexity.
Scott
----- Original Message -----
From: "Alex Alten" <Alten@home.com>
To: "Chris Trobridge" <CTrobridge@baltimore.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Tuesday, August 07, 2001 2:05 AM
Subject: RE: IKE must have no Heirs
> Think about it. Do you do OSPF over IP and then BGP over UDP?
> The same applies to IPSEC and key management.
>
> - Alex
>
> At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> >
> >
> >> -----Original Message-----
> >> From: Alex Alten [mailto:Alten@home.com]
> >> Sent: 07 August 2001 08:28
> >> To: Kory Hamzeh; Hallam-Baker, Phillip
> >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> >> Subject: Re: IKE must have no Heirs
> >>
> >>
> >>
> >> I second the motion. And also propose no port number (i.e. do the new
> >> one over raw IP).
> >>
> >> - Alex
> >
> >What would that achieve? (communicating over raw IP)
> >
> >Chris
> >
> >
>
>---------------------------------------------------------------------------
> --------------------------------------
> >The information contained in this message is confidential and is intended
> >for the addressee(s) only. If you have received this message in error or
> >there are any problems please notify the originator immediately. The
> >unauthorized use, disclosure, copying or alteration of this message is
> >strictly forbidden. Baltimore Technologies plc will not be liable for
> direct,
> >special, indirect or consequential damages arising from alteration of the
> >contents of this message by a third party or as a result of any virus
being
> >passed on.
> >
> >In addition, certain Marketing collateral may be added from time to time
to
> >promote Baltimore Technologies products, services, Global e-Security or
> >appearance at trade shows and conferences.
> >
> >This footnote confirms that this email message has been swept by
> >Baltimore MIMEsweeper for Content Security threats, including
> >computer viruses.
> >
> >
> --
>
> Alex Alten
>
> Alten@Home.Com
>
>
From owner-ipsec@lists.tislabs.com Tue Aug 7 06:41:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77Df6N02747;
Tue, 7 Aug 2001 06:41:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11651
Tue, 7 Aug 2001 09:03:04 -0400 (EDT)
Message-Id: <200108061957.f76JvkH01351@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: Phase 1 IDs ("son of IKE")
In-reply-to: Your message of "Mon, 06 Aug 2001 11:20:27 EDT."
<200108061520.f76FKRK11964@nyarlathotep.keromytis.org>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 06 Aug 2001 15:57:46 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Angelos" == Angelos D Keromytis <angelos@coredump.cis.upenn.edu> writes:
Angelos> What I'd like to suggest is that the Initiator be allowed to
Angelos> send a Responder Phase 1 ID payload, which the Responder will
Angelos> use as a hint as to what ID to use itself; the Responder can
Angelos> ignore this hint, at the risk of the exchange not being
Angelos> completed. The extra code to support this is fairly small (in
Angelos> the order of 50 lines, in OpenBSD isakmpd).
A la Host: header in HTTP?
I.e. "this is the ID which *I* thought I was contacting"
Angelos> This change allows for per-user authentication on IKE, and makes
I'm not sure that I follow this completely. You mean, individual users
can "respond" (via PF_* stuff...)
Angelos> much simpler Phase 1 negotiations where a) the Initiator and
Angelos> Responder roles change over time (because of unbalanced Phase 1
Angelos> SA expirations), *and* b) the Phase 1 ID used by the Initiator
Angelos> is not the same as that used when it acts as a Responder.
It seems to make sense to me.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO272uYqHRg3pndX9AQH21AP8CWerhFalJXFRgGmQutZ7PXWsCm3ncxRm
831gKb0XB6H9DXQfM6hF+aJvAyhed5QrDZBFgmoM+zvKGcVS2awC3vbNU/oxI9Ed
/MOyRIdECgcNklXRLru3cXZOT5+qp4HTbMn9OgT7Ei2gkqADh4tQpWdknOKKTtfX
eV1lf1lGZBw=
=A+66
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Tue Aug 7 06:52:33 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DqXN02975;
Tue, 7 Aug 2001 06:52:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11692
Tue, 7 Aug 2001 09:09:06 -0400 (EDT)
Message-ID: <3B6FAE9C.4010606@piuha.net>
Date: Tue, 07 Aug 2001 12:02:20 +0300
From: Jari Arkko <jari.arkko@piuha.net>
Reply-To: jari.arkko@piuha.net
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Vilhuber <vilhuber@cisco.com>
Cc: borderlt <border@hns.com>, ipsec@lists.tislabs.com
Subject: Re: Re draft-kaufman-ipsec-improveike-00.txt
References: <Pine.LNX.4.21.0108061622570.1153-100000@janpc-home.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Jan Vilhuber wrote:
>
> I suggest we work on more than one keying mechanism. Each one should be
> simple and should be tailored to one type of environment (the VPN space is
> afterall very different from the core-network environment). Different people
> will have different requirements, too.
I support this idea. A particular example comes to my mind: cellular systems
for instance typically have long delay times and propably want to make
the tradeoff of less roundtrips against e.g. PFS/identity
protection/some DoS
holes. In some environments, some of the lost features would be your
most important ones. Conflicts like this will lead to an incredible shouting
contest when Son-of-IKE is being designed. It is important to understand
that there are conflicting requirements.
(On the other hand, I'm not fully convinced that completely separate
protocols
are needed. Starting from scratch, it might be possible to have a cleaner
design that separates various protocol functionalities better. For instance,
servers that are under a DoS attack might respond to all key management
requests that "no, you have to run the
DoS-preventing-puzzle-solving-protocol
first".)
Jari
From owner-ipsec@lists.tislabs.com Tue Aug 7 06:53:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DrKN02997;
Tue, 7 Aug 2001 06:53:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11660
Tue, 7 Aug 2001 09:04:04 -0400 (EDT)
Message-ID: <3B6F0D5D.9F4990F4@datatekcorp.com>
Date: Mon, 06 Aug 2001 17:34:22 -0400
From: "Dr. Mitchell C. Nelson" <mcnelson@datatekcorp.com>
Reply-To: mcnelson@datatekcorp.com
Organization: Datatek Applications, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pbaker@verisign.com, ipsec@lists.tislabs.com
Subject: [Fwd: Position statement on IKE development]
Content-Type: multipart/mixed;
boundary="------------12200DC44185399836774F4F"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
--------------12200DC44185399836774F4F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Regarding design principles and communications security,
I think that indeed we do have the principles or at least the
taxonomy and an approach, as embodied in x.800. But there
seem to be very few in the network security industry who have
read it and appreciate it.
mcnelson@mindspring.com wrote:
> Unfortunately the notion that IPsec should simply \"bind
> a key to an IP address\" was rejected repeatedly throughout
> the history of the IPsec WG. There are alternative
> protocols that have been built that demonstrate that one
> can provide a useful and appropriate encryption service
> in the IP layer and that such a system can be keyed and
> managed in a simple scalable way.
>
> Trying to key and manage all kinds of relationships many
> of which are conceptually challenging when viewed from
> the IP layer, is felt by many to be at the core of IPsec\'s
> complexity.
>
> As far as testing is concerned, it would be interesting
> to see an IPsec protected network set up as a challenge
> to the general networking public with a sizable cash
> price offered for the first 10 breakins.
>
> Mitch Nelson
>
> \"Hallam-Baker, Phillip\" <pbaker@verisign.com> wrote:
> > A couple of points:
> 1) You state that Bruce and co had failled to understand the network
> context. This is one of my concerns as people present IKE as a general
> purpose solution to all key agreement problems - including the key agreement
> for XML based Web services I have been working on.
>
> The argument keeps being thrown up \'use what exists and is tested\', yet the
> protocol is of necessity tied to its context. It is not possible to pick up
> ISAKMP/IKE and apply it to another appliction, I have tried. Yet others are
> going to insist upon doing so.
>
> I believe that the current multilayered, \'everything is negotiable\'
> negotiating mechanism is a liability even for its stated goal. It encourages
> people to try to use ISAKMP for purposes which it just does not support.
>
> 2) The current problems with NAT occur because IPSEC is being used in a
> network context it was never designed for. The IPSEC authentication
> mechanisms are designed to bind a key to an IP address. In the case of a
> user behind a NAT box that fails for obvious reasons.
>
> The question to be asked then is does this shift in the networking context
> affect the underlying security assumptions?
>
> The meta-question is, do we have a framework that allows questions such as
> these to be addressed?
>
> This is the problem that really bit the 802.11b team, their scheme is broken
> for two reasons, first the person who analysed the security appears to have
> assumed a block cipher would be used and not a stream cipher, second the
> design goals are fundamentally incomplete. The problem is not PRIVACY, but
> authenticating the user to stop the sacked employee in the car park surfing
> the ex-employer\'s intranet. Also any conception of privacy that includes
> Louis Freeh having to be able to read all my packets if he is granted access
> to the same network as me is somewhat strange to say the least... It may be
> a feature of ethernet, in a wireless network with an encryption layer it is
> a bug.
>
> 3) At this point we do not have a engineering approach to security protocol
> analysis. The nearest I have seen to an analytical approach is the work Phil
> Rogaway and Mihi Belhare have been doing on algorithms.
>
> Putting out a tender for security protocol analysis would be pointless if
> all we got as a result was a further set of experts reviewing the specs in
> the same ad hoc \'can we see holes\' fashion.
>
> In the early days of bridge building the \'build it, see if it will fall
> down\' algorithm was employed. Today most people (makers of wobbly bridges in
> London appart) believe in the \'use design principles that prevent failure\'
> approach. Unfortunately we don\'t have the design principles (yet).
>
> Phill
>
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
>
> > -----Original Message-----
> > From: Steven M. Bellovin [mailto:smb@research.att.com]
> > Sent: Saturday, August 04, 2001 7:00 PM
> > To: Alex Alten
> > Cc: Henry Spencer; Marcus Leech; msec@securemulticast.org;
> > ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> > Subject: Re: Position statement on IKE development
> >
> >
> > In message , Alex Alten writes:
> >
> >
> > >>
> > >>Agreed. And large parts of the Schneier/Ferguson analysis of the
> > >>packet-level parts are just plain wrong.
> > >>
> > >
> > >
> > >Steve, with all due respect, you, Jeff and Marcus stated the
> > following.
> > >
> > >\"In the several years since the standardization of the IPSEC
> > protocols
> > >(ESP, AH, and ISAKMP/IKE), there have come to light several security
> > >problems with the protocols, most notably the key-agreement protocol,
> > >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
> > >Simpson, have shown that the security problems in IKE stem directly
> > >from its complexity.\"
> > >
> > >If IKE is no longer considered viable because of it\'s
> > complexity, then
> > >I am concerned that the other protocols of IPsec are also at
> > risk. This
> > >is not my concern alone, others have expressed it to me as well.
> > >
> > >At this point, to restore confidence in the security of the design I
> > >would hope that the IETF will retain the services of a quality
> > >cryptanalysis consulting firm and publish the results. To
> > do otherwise
> > >will be to risk the discrediting of the entire IPsec standard.
> >
> > Frankly, a lot of very competent folks did look at the cryptography.
> > WIth all due modesty, I published two papers on the subject
> > myself, and
> > I wasn\'t the only one. In fact, that\'s one of the reasons why IPsec
> > took so long -- the result of those analyses is why RFCs 1825-29 were
> > replaced by 2401 et al. -- because we found and fixed a fair
> > number of
> > problems. The flaws in the Schneier/Ferguson analysis are
> > because they don\'t understand the networking context. I sent Bruce a
> > long, detailed note about that before he ever published the analysis.
> >
> > You say \"retain the services of a quality cryptanalysis
> > consulting firm\".
> > Apart from the point that there aren\'t that many -- and I and others
> > know most of the likely players in the field -- the question
> > is whether
> > or not they understand the networking context. I have no particular
> > reason to think that the results would be any better than
> > what we have
> > now.
> >
> > Is IPsec perfect? No, of course not. I\'d like to get rid of AH, for
> > example, not because it doesn\'t work -- it does -- but
> > because it adds
> > complexity to implementations without (to me) doing anything useful.
> > There are a few other minor things I\'d have done differently. But I
> > have a great deal of confidence in the correctness of the
> > packet-level
> > transforms.
> >
> > --Steve Bellovin, http://www.research.att.com/~smb
> >
> >
--------------12200DC44185399836774F4F
Content-Type: message/rfc822
Content-Disposition: inline
Received: HReceived: from micro4.icsnet.net (micro4.icsnet.net [205.136.35.54])
by busmail3.icsnet.net (ics mailserver) with ESMTP id QAA25925
for <mcnelson@datatekcorp.com>; Mon, 6 Aug 2001 16:54:45 -0400 (EDT)
From: mcnelson@mindspring.com
Received: HReceived: from micro4.icsnet.net (localhost [127.0.0.1])
by micro4.icsnet.net (ics mailserver) with ESMTP id QAA10529
for <mcnelson@datatekcorp.com>; Mon, 6 Aug 2001 16:56:04 -0400 (EDT)
Received: HReceived: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243])
by micro4.icsnet.net (ics mailserver) with ESMTP id QAA10519
for <mcnelson@datatekcorp.com>; Mon, 6 Aug 2001 16:56:03 -0400 (EDT)
Received: from smui05.slb.mindspring.net (smui05.slb.mindspring.net [199.174.114.91])
by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA21677;
Mon, 6 Aug 2001 16:56:02 -0400 (EDT)
Received: by smui05.slb.mindspring.net id QAA0000024627; Mon, 6 Aug 2001 16:56:02 -0400 (EDT)
Date: Mon, 06 Aug 2001 16:56:02 -0400
To: pbaker@verisign.com
Cc: ipsec@lists.tislabs.com
Subject: Re: RE: Position statement on IKE development
Sender: mcnelson@mindspring.com
Message-ID: <Springmail.105.997131362.0.50129600@www.springmail.com>
X-Originating-IP: 208.37.68.36
Content-Type: text
X-Mozilla-Status2: 00000000
MIME-Version: 1.0
Unfortunately the notion that IPsec should simply \"bind
a key to an IP address\" was rejected repeatedly throughout
the history of the IPsec WG. There are alternative
protocols that have been built that demonstrate that one
can provide a useful and appropriate encryption service
in the IP layer and that such a system can be keyed and
managed in a simple scalable way.
Trying to key and manage all kinds of relationships many
of which are conceptually challenging when viewed from
the IP layer, is felt by many to be at the core of IPsec\'s
complexity.
As far as testing is concerned, it would be interesting
to see an IPsec protected network set up as a challenge
to the general networking public with a sizable cash
price offered for the first 10 breakins.
Mitch Nelson
\"Hallam-Baker, Phillip\" <pbaker@verisign.com> wrote:
> A couple of points:
1) You state that Bruce and co had failled to understand the network
context. This is one of my concerns as people present IKE as a general
purpose solution to all key agreement problems - including the key agreement
for XML based Web services I have been working on.
The argument keeps being thrown up \'use what exists and is tested\', yet the
protocol is of necessity tied to its context. It is not possible to pick up
ISAKMP/IKE and apply it to another appliction, I have tried. Yet others are
going to insist upon doing so.
I believe that the current multilayered, \'everything is negotiable\'
negotiating mechanism is a liability even for its stated goal. It encourages
people to try to use ISAKMP for purposes which it just does not support.
2) The current problems with NAT occur because IPSEC is being used in a
network context it was never designed for. The IPSEC authentication
mechanisms are designed to bind a key to an IP address. In the case of a
user behind a NAT box that fails for obvious reasons.
The question to be asked then is does this shift in the networking context
affect the underlying security assumptions?
The meta-question is, do we have a framework that allows questions such as
these to be addressed?
This is the problem that really bit the 802.11b team, their scheme is broken
for two reasons, first the person who analysed the security appears to have
assumed a block cipher would be used and not a stream cipher, second the
design goals are fundamentally incomplete. The problem is not PRIVACY, but
authenticating the user to stop the sacked employee in the car park surfing
the ex-employer\'s intranet. Also any conception of privacy that includes
Louis Freeh having to be able to read all my packets if he is granted access
to the same network as me is somewhat strange to say the least... It may be
a feature of ethernet, in a wireless network with an encryption layer it is
a bug.
3) At this point we do not have a engineering approach to security protocol
analysis. The nearest I have seen to an analytical approach is the work Phil
Rogaway and Mihi Belhare have been doing on algorithms.
Putting out a tender for security protocol analysis would be pointless if
all we got as a result was a further set of experts reviewing the specs in
the same ad hoc \'can we see holes\' fashion.
In the early days of bridge building the \'build it, see if it will fall
down\' algorithm was employed. Today most people (makers of wobbly bridges in
London appart) believe in the \'use design principles that prevent failure\'
approach. Unfortunately we don\'t have the design principles (yet).
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Steven M. Bellovin [mailto:smb@research.att.com]
> Sent: Saturday, August 04, 2001 7:00 PM
> To: Alex Alten
> Cc: Henry Spencer; Marcus Leech; msec@securemulticast.org;
> ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org; ipsec@lists.tislabs.com
> Subject: Re: Position statement on IKE development
>
>
> In message , Alex Alten writes:
>
>
> >>
> >>Agreed. And large parts of the Schneier/Ferguson analysis of the
> >>packet-level parts are just plain wrong.
> >>
> >
> >
> >Steve, with all due respect, you, Jeff and Marcus stated the
> following.
> >
> >\"In the several years since the standardization of the IPSEC
> protocols
> >(ESP, AH, and ISAKMP/IKE), there have come to light several security
> >problems with the protocols, most notably the key-agreement protocol,
> >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and
> >Simpson, have shown that the security problems in IKE stem directly
> >from its complexity.\"
> >
> >If IKE is no longer considered viable because of it\'s
> complexity, then
> >I am concerned that the other protocols of IPsec are also at
> risk. This
> >is not my concern alone, others have expressed it to me as well.
> >
> >At this point, to restore confidence in the security of the design I
> >would hope that the IETF will retain the services of a quality
> >cryptanalysis consulting firm and publish the results. To
> do otherwise
> >will be to risk the discrediting of the entire IPsec standard.
>
> Frankly, a lot of very competent folks did look at the cryptography.
> WIth all due modesty, I published two papers on the subject
> myself, and
> I wasn\'t the only one. In fact, that\'s one of the reasons why IPsec
> took so long -- the result of those analyses is why RFCs 1825-29 were
> replaced by 2401 et al. -- because we found and fixed a fair
> number of
> problems. The flaws in the Schneier/Ferguson analysis are
> because they don\'t understand the networking context. I sent Bruce a
> long, detailed note about that before he ever published the analysis.
>
> You say \"retain the services of a quality cryptanalysis
> consulting firm\".
> Apart from the point that there aren\'t that many -- and I and others
> know most of the likely players in the field -- the question
> is whether
> or not they understand the networking context. I have no particular
> reason to think that the results would be any better than
> what we have
> now.
>
> Is IPsec perfect? No, of course not. I\'d like to get rid of AH, for
> example, not because it doesn\'t work -- it does -- but
> because it adds
> complexity to implementations without (to me) doing anything useful.
> There are a few other minor things I\'d have done differently. But I
> have a great deal of confidence in the correctness of the
> packet-level
> transforms.
>
> --Steve Bellovin, http://www.research.att.com/~smb
>
>
--------------12200DC44185399836774F4F--
From owner-ipsec@lists.tislabs.com Tue Aug 7 06:54:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77Ds4N03024;
Tue, 7 Aug 2001 06:54:04 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11716
Tue, 7 Aug 2001 09:12:06 -0400 (EDT)
Date: 7 Aug 2001 09:11:34 -0000
Message-ID: <20010807091134.24970.qmail@mailweb29.rediffmail.com>
MIME-Version: 1.0
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: problems in manual keying
From: "tsbalaji1993@rediffmail.com" <tsbalaji1993@rediffmail.com>
Content-ID: <Tue_Aug__7_14_41_34_IST_2001_0@mailweb29.rediffmail.com>
Content-type: text/plain
Content-Description: Body
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi all
while working in openbsd,
we enabled ah and esp by
sysctl -w net.inet.esp.enable =1
sysctl -w net.inet.ah.enable =1
then we setup SA as follows
on host 192.168.7.151
ipsecadm new esp -spi 1000 -src 192.168.7.151 -dst 192.168.7.152 -forcetunnel -enc 3des -auth sha1 -key 5555555555555555555555555555555555555555 -authkey 7777777777777777777777777777777777777777
ipsecadm new esp -spi 1001 -src 192.168.7.152 -dst 192.168.7.151 -forcetunnel -enc 3des -auth sha1 -key 5555555555555555555555555555555555555555 -authkey 7777777777777777777777777777777777777777
On host 192.168.7.152
ipsecadm new esp -spi 1001 -src 192.168.7.152 -dst 192.168.7.151 -forcetunnel -enc 3des -auth sha1 -key 5555555555555555555555555555555555555555 -authkey 7777777777777777777777777777777777777777
ipsecadm new esp -spi 1000 -src 192.168.7.151 -dst 192.168.7.152 -forcetunnel -enc 3des -auth sha1 -key 5555555555555555555555555555555555555555 -authkey 7777777777777777777777777777777777777777
for flow we tried
On host 192.168.7.151
ipsecadm flow -proto esp -dst 192.168.7.152 -spi 1000 -addr 192.168.7.151 255.255.255.255 192.168.7.152 255.255.255.255
on host 192.168.7.152
ipsecadm flow -proto esp -dst 192.168.7.151 -spi 1001 -addr 192.168.7.152 255.255.255.255 192.168.7.151 255.255.255.255
but since "-spi depreciated" error came we tried
on host 192.168.7.151
ipsecadm flow -proto esp -dst 192.168.7.152 -addr 192.168.7.151 255.255.255.255 192.168.7.152 255.255.255.255 - out -require
on host 192.168.7.152
ipsecadm flow -proto esp -dst 192.168.7.151 -addr 192.168.7.152 255.255.255.255 192.168.7.151 255.255.255.255 -in -require
but after this PING is tried and Tcpdump is used to capture the packets. but only " echo request" packets are coming but not "echo reply " packets. how to rectify the error.
what is wrong.??
with love
balaji
_________________________________________________________
For Rs. 2,000,000 worth of Aptech scholarships click below
http://clients.rediff.com/clients/aptechsch/index.htm
From owner-ipsec@lists.tislabs.com Tue Aug 7 06:54:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DsAN03047;
Tue, 7 Aug 2001 06:54:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11681
Tue, 7 Aug 2001 09:07:06 -0400 (EDT)
Message-Id: <200108070821.f778LRR18797@nyarlathotep.keromytis.org>
X-Mailer: exmh version 2.0.2 2/24/98
To: ford@apollo.incog.com (Mike "Ford" Ditto)
Cc: ipsec@lists.tislabs.com
Subject: Re: Phase 1 IDs ("son of IKE")
In-reply-to: Your message of "Mon, 06 Aug 2001 16:15:05 PDT."
<200108062315.QAA09683@potomac.incog.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 07 Aug 2001 04:21:27 -0400
From: "Angelos D. Keromytis" <angelos@coredump.cis.upenn.edu>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <200108062315.QAA09683@potomac.incog.com>, Mike "Ford" Ditto writes:
>
>The responder could conceivably use any information available, such as
>the proposed Phase I protection suite or the time of day.
What I meant was that the Responder cannot know what the Initiator had
in mind.
>One problem is that the initiator's policy may not express the
>desired/allowed remote identity in a simple form that can be conveyed to
>the responder. For example, the initiator's policy may allow a
>connection with any remote identity that has a certificate signed by a
>particular CA,
This particular case is possible by sending the appropriate CERTREQ message.
>But if the identity hint was used as an abstract name, rather than the
>exact identity that the responder is expected to use, it could be used
>as a kind of generic "scope" or "role" identifier. For example, if the
>initiator sends a hint of "internal-vpn.my.org", then a responder with
>many local identities could be configured to choose the identity that is
>appropriate for use as a gateway to the internal VPN when it sees that
>particular hint; for other hints it could be configured to use a more
>public identity.
My concern with this is that it's more complicated than the simple case of
"here's what I'd like you to use", both in terms of semantics, effort that
has to go in specs, and code.
In any case, as I said the Responder is free to ignore the hint and use some
other Phase 1 ID (which the Initiator may or may not like). Furthermore, the
Responder, given the hint and the Initiator's ID, has enough information to
in fact reverse the roles and act as an Initiator with the appropriate Phase 1
ID for itself.
Finally, the "pick the right role" can, at least partly, be done by examining
just the Initiator's Phase 1 ID. What I suggest is really useful for per-user
keying, less so for host/user-to-host.
-Angelos
From owner-ipsec@lists.tislabs.com Tue Aug 7 07:16:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77EGhN03632;
Tue, 7 Aug 2001 07:16:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11515
Tue, 7 Aug 2001 08:18:12 -0400 (EDT)
To: "Mason, David" <David_Mason@nai.com>
Cc: "'Marcus Leech'" <mleech@nortelnetworks.com>, ietf-ipsra@vpnc.org,
ipsec@lists.tislabs.com, "'jis@mit.edu'" <jis@mit.edu>
Subject: Re: Position statement on IKE development
References: <8894CA1F87A5D411BD24009027EE7838128231@ROC-76-204.nai.com>
From: Derek Atkins <warlord@mit.edu>
Date: 07 Aug 2001 08:25:03 -0400
In-Reply-To: "Mason, David"'s message of "Mon, 6 Aug 2001 12:28:04 -0700"
Message-ID: <sjmvgk0dpls.fsf@rcn.ihtfp.org>
Lines: 15
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
They never were included in the moratorium.
-derek
"Mason, David" <David_Mason@nai.com> writes:
> Is it true that the NAT traversal IKE and IPsec changes have been exempted
> from the moratorium?
> -dave
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Tue Aug 7 08:38:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77Fc9N22835;
Tue, 7 Aug 2001 08:38:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12005
Tue, 7 Aug 2001 10:18:56 -0400 (EDT)
From: Bill Manning <bmanning@ISI.EDU>
Message-Id: <200108071425.f77EPrl19554@zed.isi.edu>
Subject: Re: Wes Hardaker: opportunistic encryption deployment problems
To: Francis.Dupont@enst-bretagne.fr (Francis Dupont)
Date: Tue, 7 Aug 2001 07:25:53 -0700 (PDT)
Cc: pbaker@verisign.com (Hallam-Baker Phillip),
hugh@road.xisp.net (Hugh Daniel), wes@hardakers.net,
ipsec@lists.tislabs.com
In-Reply-To: <200108070812.f778Cfu67935@givry.rennes.enst-bretagne.fr> from "Francis Dupont" at Aug 07, 2001 10:12:41 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
One point. Instead of TXT records for stuffing bits into, there is the CERT record
which was designed for just such stuff.
Well, two points. If folks want to kick the tyres on such a beast, I've a couple
of servers w/ signed in-addr.arpa zones.
--
--bill
From owner-ipsec@lists.tislabs.com Tue Aug 7 08:38:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77FcCN22908;
Tue, 7 Aug 2001 08:38:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11988
Tue, 7 Aug 2001 10:17:28 -0400 (EDT)
Message-Id: <200108071423.f77ENEg00553@dharkins@lounge.orgatty.lounge.org>
To: Alex Alten <Alten@home.com>
Cc: Kory Hamzeh <kory@avatar.com>,
"Hallam-Baker, Phillip" <pbaker@verisign.com>,
"'mcnelson@mindspring.com'" <mcnelson@mindspring.com>,
ipsec@lists.tislabs.com
Subject: Re: IKE must have no Heirs
In-Reply-To: Your message of "Tue, 07 Aug 2001 00:28:20 PDT."
<3.0.3.32.20010807002820.010a77f8@mail>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <550.997194194.1@lounge.org>
Date: Tue, 07 Aug 2001 07:23:14 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It was called SKIP. I suggest you guys familiarize yourselves with
this WG.
Dan.
On Tue, 07 Aug 2001 00:28:20 PDT you wrote
>
> I second the motion. And also propose no port number (i.e. do the new
> one over raw IP).
>
> - Alex
>
> At 11:07 PM 8/6/2001 -0700, Kory Hamzeh wrote:
> >
> >Well said. I agree with you 100%. Throw is out and let's start from
> >scratch with something more reasonable and realistic.
> >
> >Kory
> >
> >
> >On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote:
> >
> >>
> >> > Unfortunately the notion that IPsec should simply \"bind
> >> > a key to an IP address\" was rejected repeatedly throughout
> >> > the history of the IPsec WG.
> >>
> >> This is why I think we have to stop talking about 'son of IKE'
> >> as if the problem was in the 7 years and 9 months of trying to
> >> implement the requirements and not the 3 months of requirements
> >> capture.
> >>
> >> [ ..... ]
> >>
> >> From here there are two routes forward. We could specify a reduced
> >> IKE, eliminating all but 2 of the current 8 modes, simplifying the
> >> negotiation, knife AH... to result in a simpler draft that we can be
> >> confident would get a broad review. I think that would have been an
> >> excellent idea three years ago, I think that it is too late after
> >> the interop tests have been performed. All that would come out
> >> is a description of a profile of the current spec that resulted
> >> in one configuration that was secure. But implementations would
> >> still be constrained by the existing legacy base which would
> >> drag deployments back into the mire of unexamined code paths and
> >> unanticipated interactions.
> >>
> >> The second is to burn the current drafts and start from scratch
> >> with a fresh port number. If any change is made that breaks
> >> backwards compatibility then this might as well be what you do.
> >>
> >> In short the phrase 'Son of IKE' is part of the problem, not
> >> the solution. IKE must have no heirs, it is time for a new dynasty
> >> to take the throne.
> >>
> >>
> >> Phill
> >>
> >>
> >
> >
> --
>
> Alex Alten
>
> Alten@Home.Com
>
>
From owner-ipsec@lists.tislabs.com Tue Aug 7 08:57:23 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77FvNN03449;
Tue, 7 Aug 2001 08:57:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12154
Tue, 7 Aug 2001 11:13:19 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15215.65528.400728.281853@thomasm-u1.cisco.com>
Date: Tue, 7 Aug 2001 07:49:28 -0700 (PDT)
To: Alex Alten <Alten@home.com>
Cc: Chris Trobridge <CTrobridge@baltimore.com>, ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
In-Reply-To: <3.0.3.32.20010807020559.00d89980@mail>
References: <F86F34FDF1F9D411B7A40008C74C27B8028A14@hhdata3.cdsemea.bal
timore.com>
<3.0.3.32.20010807020559.00d89980@mail>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Alex Alten writes:
> Think about it. Do you do OSPF over IP and then BGP over UDP?
> The same applies to IPSEC and key management.
OK, I thought about it. I still don't get it.
Mike
>
> - Alex
>
> At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> >
> >
> >> -----Original Message-----
> >> From: Alex Alten [mailto:Alten@home.com]
> >> Sent: 07 August 2001 08:28
> >> To: Kory Hamzeh; Hallam-Baker, Phillip
> >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> >> Subject: Re: IKE must have no Heirs
> >>
> >>
> >>
> >> I second the motion. And also propose no port number (i.e. do the new
> >> one over raw IP).
> >>
> >> - Alex
> >
> >What would that achieve? (communicating over raw IP)
> >
> >Chris
> >
> >
> >---------------------------------------------------------------------------
> --------------------------------------
> >The information contained in this message is confidential and is intended
> >for the addressee(s) only. If you have received this message in error or
> >there are any problems please notify the originator immediately. The
> >unauthorized use, disclosure, copying or alteration of this message is
> >strictly forbidden. Baltimore Technologies plc will not be liable for
> direct,
> >special, indirect or consequential damages arising from alteration of the
> >contents of this message by a third party or as a result of any virus being
> >passed on.
> >
> >In addition, certain Marketing collateral may be added from time to time to
> >promote Baltimore Technologies products, services, Global e-Security or
> >appearance at trade shows and conferences.
> >
> >This footnote confirms that this email message has been swept by
> >Baltimore MIMEsweeper for Content Security threats, including
> >computer viruses.
> >
> >
> --
>
> Alex Alten
>
> Alten@Home.Com
>
>
From owner-ipsec@lists.tislabs.com Tue Aug 7 09:57:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77GvLN04920;
Tue, 7 Aug 2001 09:57:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12327
Tue, 7 Aug 2001 11:51:06 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA51@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Dan Harkins'" <dharkins@lounge.org>, Alex Alten <Alten@home.com>
Cc: Kory Hamzeh <kory@avatar.com>,
"Hallam-Baker, Phillip"
<pbaker@verisign.com>,
"'mcnelson@mindspring.com'"
<mcnelson@mindspring.com>,
ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
Date: Tue, 7 Aug 2001 08:56:53 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C11F59.93D58940"
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_000_01C11F59.93D58940
Content-Type: text/plain;
charset="iso-8859-1"
Dan,
It has been somewhat difficult for anyone in the IETF security area in the
past dacade not to become familliar with the internal machinations of the
IPSEC group.
I would like something no more complex than SKIP that used RSA or DSA.
In 1995 SKIP would have been the right move. At this point to go forward
there has to at least be compatibility with the keying material that is
already distributed.
I would also like to see a more analytical approach to demonstrating the
correctness and security of the protocol. Something that was at least simple
enough to be the subject of a proof.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Tuesday, August 07, 2001 10:23 AM
> To: Alex Alten
> Cc: Kory Hamzeh; Hallam-Baker, Phillip; 'mcnelson@mindspring.com';
> ipsec@lists.tislabs.com
> Subject: Re: IKE must have no Heirs
>
>
> It was called SKIP. I suggest you guys familiarize yourselves with
> this WG.
>
> Dan.
>
> On Tue, 07 Aug 2001 00:28:20 PDT you wrote
> >
> > I second the motion. And also propose no port number (i.e.
> do the new
> > one over raw IP).
> >
> > - Alex
> >
> > At 11:07 PM 8/6/2001 -0700, Kory Hamzeh wrote:
> > >
> > >Well said. I agree with you 100%. Throw is out and let's start from
> > >scratch with something more reasonable and realistic.
> > >
> > >Kory
> > >
> > >
> > >On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote:
> > >
> > >>
> > >> > Unfortunately the notion that IPsec should simply \"bind
> > >> > a key to an IP address\" was rejected repeatedly throughout
> > >> > the history of the IPsec WG.
> > >>
> > >> This is why I think we have to stop talking about 'son of IKE'
> > >> as if the problem was in the 7 years and 9 months of trying to
> > >> implement the requirements and not the 3 months of requirements
> > >> capture.
> > >>
> > >> [ ..... ]
> > >>
> > >> From here there are two routes forward. We could specify
> a reduced
> > >> IKE, eliminating all but 2 of the current 8 modes,
> simplifying the
> > >> negotiation, knife AH... to result in a simpler draft
> that we can be
> > >> confident would get a broad review. I think that would
> have been an
> > >> excellent idea three years ago, I think that it is too late after
> > >> the interop tests have been performed. All that would come out
> > >> is a description of a profile of the current spec that resulted
> > >> in one configuration that was secure. But implementations would
> > >> still be constrained by the existing legacy base which would
> > >> drag deployments back into the mire of unexamined code paths and
> > >> unanticipated interactions.
> > >>
> > >> The second is to burn the current drafts and start from scratch
> > >> with a fresh port number. If any change is made that breaks
> > >> backwards compatibility then this might as well be what you do.
> > >>
> > >> In short the phrase 'Son of IKE' is part of the problem, not
> > >> the solution. IKE must have no heirs, it is time for a
> new dynasty
> > >> to take the throne.
> > >>
> > >>
> > >> Phill
> > >>
> > >>
> > >
> > >
> > --
> >
> > Alex Alten
> >
> > Alten@Home.Com
> >
> >
>
------_=_NextPart_000_01C11F59.93D58940
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C11F59.93D58940--
From owner-ipsec@lists.tislabs.com Tue Aug 7 10:17:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77HH6N05536;
Tue, 7 Aug 2001 10:17:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12442
Tue, 7 Aug 2001 12:21:39 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15216.5899.191140.121446@thomasm-u1.cisco.com>
Date: Tue, 7 Aug 2001 09:27:55 -0700 (PDT)
To: Bill Manning <bmanning@ISI.EDU>
Cc: Francis.Dupont@enst-bretagne.fr (Francis Dupont),
pbaker@verisign.com (Hallam-Baker Phillip),
hugh@road.xisp.net (Hugh Daniel), wes@hardakers.net,
ipsec@lists.tislabs.com
Subject: Re: Wes Hardaker: opportunistic encryption deployment problems
In-Reply-To: <200108071425.f77EPrl19554@zed.isi.edu>
References: <200108070812.f778Cfu67935@givry.rennes.enst-bretagne.fr>
<200108071425.f77EPrl19554@zed.isi.edu>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I guess I have to ask a really dumb question. Given the
likelihood of DNSSEC any time soon, why don't we just
ignore any pretense of authentication with opportunistic
encryption and just accept the MITM attack inherent with
ephemeral DH exchanges? Also: it seems to me that expecting
a secure DNS isn't actually opportunistic at all: it's
trying to assert a different source of (sometimes strong)
identity, which obviously runs afoul of the mythical
global PKI, which leads back to point one. I think there's
some utility to crypto which accepts MITM as better than
nothing at all which is the current reality.
Mike
Bill Manning writes:
>
> One point. Instead of TXT records for stuffing bits into, there is the CERT record
> which was designed for just such stuff.
> Well, two points. If folks want to kick the tyres on such a beast, I've a couple
> of servers w/ signed in-addr.arpa zones.
>
>
> --
> --bill
From owner-ipsec@lists.tislabs.com Tue Aug 7 10:23:18 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77HNIN05649;
Tue, 7 Aug 2001 10:23:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12459
Tue, 7 Aug 2001 12:30:34 -0400 (EDT)
Date: Tue, 7 Aug 2001 09:36:31 -0700 (PDT)
From: Kory Hamzeh <kory@avatar.com>
To: Dan Harkins <dharkins@lounge.org>
cc: Alex Alten <Alten@home.com>,
"Hallam-Baker, Phillip" <pbaker@verisign.com>,
"'mcnelson@mindspring.com'" <mcnelson@mindspring.com>,
ipsec@lists.tislabs.com
Subject: Re: IKE must have no Heirs
In-Reply-To: <200108071423.f77ENEg00553@dharkins@lounge.orgatty.lounge.org>
Message-ID: <Pine.BSF.3.96.1010807092949.20739A-100000@ns1.avatar.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This will be my second (and last) e-mail on this thread because their are
too many egos involved here. As an implementor of IPSEC & IKE, I can
testify that IKE is confusion, convoluted, overly complicated,, and has
security holes. There are papers written on this subject by people much
more intelligent than myself who have come to the same conclusion.
Kory
On Tue, 7 Aug 2001, Dan Harkins wrote:
> It was called SKIP. I suggest you guys familiarize yourselves with
> this WG.
>
> Dan.
>
> On Tue, 07 Aug 2001 00:28:20 PDT you wrote
> >
> > I second the motion. And also propose no port number (i.e. do the new
> > one over raw IP).
> >
> > - Alex
> >
> > At 11:07 PM 8/6/2001 -0700, Kory Hamzeh wrote:
> > >
> > >Well said. I agree with you 100%. Throw is out and let's start from
> > >scratch with something more reasonable and realistic.
> > >
> > >Kory
> > >
> > >
> > >On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote:
> > >
> > >>
> > >> > Unfortunately the notion that IPsec should simply \"bind
> > >> > a key to an IP address\" was rejected repeatedly throughout
> > >> > the history of the IPsec WG.
> > >>
> > >> This is why I think we have to stop talking about 'son of IKE'
> > >> as if the problem was in the 7 years and 9 months of trying to
> > >> implement the requirements and not the 3 months of requirements
> > >> capture.
> > >>
> > >> [ ..... ]
> > >>
> > >> From here there are two routes forward. We could specify a reduced
> > >> IKE, eliminating all but 2 of the current 8 modes, simplifying the
> > >> negotiation, knife AH... to result in a simpler draft that we can be
> > >> confident would get a broad review. I think that would have been an
> > >> excellent idea three years ago, I think that it is too late after
> > >> the interop tests have been performed. All that would come out
> > >> is a description of a profile of the current spec that resulted
> > >> in one configuration that was secure. But implementations would
> > >> still be constrained by the existing legacy base which would
> > >> drag deployments back into the mire of unexamined code paths and
> > >> unanticipated interactions.
> > >>
> > >> The second is to burn the current drafts and start from scratch
> > >> with a fresh port number. If any change is made that breaks
> > >> backwards compatibility then this might as well be what you do.
> > >>
> > >> In short the phrase 'Son of IKE' is part of the problem, not
> > >> the solution. IKE must have no heirs, it is time for a new dynasty
> > >> to take the throne.
From owner-ipsec@lists.tislabs.com Tue Aug 7 11:32:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77IWBN07164;
Tue, 7 Aug 2001 11:32:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12696
Tue, 7 Aug 2001 13:39:23 -0400 (EDT)
Message-ID: <CCFF88268143CC4181A758DCC0ECDC13DE7749@posthaus.virtela.cc>
From: "Horn, Mike" <mhorn@virtela.net>
To: "'Alex Alten'" <Alten@home.com>,
Chris Trobridge
<CTrobridge@baltimore.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
Date: Tue, 7 Aug 2001 10:38:08 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Actually that is a poor example, there is no built-in protocol dependency
for BGP to use OSPF. And BGP does use TCP (port 179) for communication vs.
OSPF using a protocol number (89). IPsec currently has a strong dependency
on IKE. I do agree that from a network administration and debugging
standpoint it would be nice if both IPsec and IKE shared a common protocol
number. This would help to simplify firewall configurations, etc.
Mike Horn
> -----Original Message-----
> From: Alex Alten [mailto:Alten@home.com]
> Sent: Tuesday, August 07, 2001 3:06 AM
> To: Chris Trobridge
> Cc: ipsec@lists.tislabs.com
> Subject: RE: IKE must have no Heirs
>
>
> Think about it. Do you do OSPF over IP and then BGP over UDP?
> The same applies to IPSEC and key management.
>
> - Alex
>
> At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> >
> >
> >> -----Original Message-----
> >> From: Alex Alten [mailto:Alten@home.com]
> >> Sent: 07 August 2001 08:28
> >> To: Kory Hamzeh; Hallam-Baker, Phillip
> >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> >> Subject: Re: IKE must have no Heirs
> >>
> >>
> >>
> >> I second the motion. And also propose no port number (i.e.
> do the new
> >> one over raw IP).
> >>
> >> - Alex
> >
> >What would that achieve? (communicating over raw IP)
> >
> >Chris
> >
> >
> >-------------------------------------------------------------
> --------------
> --------------------------------------
> >The information contained in this message is confidential
> and is intended
> >for the addressee(s) only. If you have received this
> message in error or
> >there are any problems please notify the originator
> immediately. The
> >unauthorized use, disclosure, copying or alteration of this
> message is
> >strictly forbidden. Baltimore Technologies plc will not be liable for
> direct,
> >special, indirect or consequential damages arising from
> alteration of the
> >contents of this message by a third party or as a result of
> any virus being
> >passed on.
> >
> >In addition, certain Marketing collateral may be added from
> time to time to
> >promote Baltimore Technologies products, services, Global
> e-Security or
> >appearance at trade shows and conferences.
> >
> >This footnote confirms that this email message has been swept by
> >Baltimore MIMEsweeper for Content Security threats, including
> >computer viruses.
> >
> >
> --
>
> Alex Alten
>
> Alten@Home.Com
>
>
From owner-ipsec@lists.tislabs.com Tue Aug 7 11:35:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77IZVN07208;
Tue, 7 Aug 2001 11:35:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12712
Tue, 7 Aug 2001 13:40:24 -0400 (EDT)
Message-ID: <CCFF88268143CC4181A758DCC0ECDC13DE774B@posthaus.virtela.cc>
From: "Horn, Mike" <mhorn@virtela.net>
To: "'Scott Fanning'" <sfanning@cisco.com>,
Chris Trobridge
<CTrobridge@baltimore.com>, Alex Alten <Alten@home.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
Date: Tue, 7 Aug 2001 10:54:33 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>
> So, what do we propose to those that are using IKE right now (like
> customers). Oops, sorry, its too complex. Maybe next time?
>
This is precisely why many vendors will probably not move to a simplified
IKE implementation that adds no new features. Once the vendors have been
through the pain of getting the interoperability issues resolved, why would
they attempt to cut out major sections of working code? IMHO, the only
group that a simplified IKE implementation helps is vendors looking to
deploy their first implementation of IKE. If the simplified IKE also added
some critical new features which many vendors have already deployed
proprietary solutions for (NAT traversal, user authentication, keepalives,
etc.) then vendors might have some motivation to re-code existing
implemenations with a new standardized version.
> I suggest that we look at the documents that describe the
> improvements, and
> ask the implementors (the ones confused by the complexity)
> how the standards
> body can work to make their job easier (A clearly defined
> state machine
> would be nice, with less SHOULDs' and more MUSTs).
>
> Also, any changes should keep in mind an easy transition to
> "Son of Ike" so
> that deploying the less complex version of IKE, does not create more
> complexity.
>
I think users will only deploy Son of IKE if it solves all the open
requirements, not if it just simplifies IKE and adds a single feature like
NAT traversal. There seems to be a big rift between what the IPSEC and
IPSRA WGs are doing, and what the vendors are doing on their own.
Mike Horn
> Scott
> ----- Original Message -----
> From: "Alex Alten" <Alten@home.com>
> To: "Chris Trobridge" <CTrobridge@baltimore.com>
> Cc: <ipsec@lists.tislabs.com>
> Sent: Tuesday, August 07, 2001 2:05 AM
> Subject: RE: IKE must have no Heirs
>
>
> > Think about it. Do you do OSPF over IP and then BGP over UDP?
> > The same applies to IPSEC and key management.
> >
> > - Alex
> >
> > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Alex Alten [mailto:Alten@home.com]
> > >> Sent: 07 August 2001 08:28
> > >> To: Kory Hamzeh; Hallam-Baker, Phillip
> > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> > >> Subject: Re: IKE must have no Heirs
> > >>
> > >>
> > >>
> > >> I second the motion. And also propose no port number
> (i.e. do the new
> > >> one over raw IP).
> > >>
> > >> - Alex
> > >
> > >What would that achieve? (communicating over raw IP)
> > >
> > >Chris
> > >
> > >
> >
> >-------------------------------------------------------------
> --------------
> > --------------------------------------
> > >The information contained in this message is confidential
> and is intended
> > >for the addressee(s) only. If you have received this
> message in error or
> > >there are any problems please notify the originator
> immediately. The
> > >unauthorized use, disclosure, copying or alteration of
> this message is
> > >strictly forbidden. Baltimore Technologies plc will not be
> liable for
> > direct,
> > >special, indirect or consequential damages arising from
> alteration of the
> > >contents of this message by a third party or as a result
> of any virus
> being
> > >passed on.
> > >
> > >In addition, certain Marketing collateral may be added
> from time to time
> to
> > >promote Baltimore Technologies products, services, Global
> e-Security or
> > >appearance at trade shows and conferences.
> > >
> > >This footnote confirms that this email message has been swept by
> > >Baltimore MIMEsweeper for Content Security threats, including
> > >computer viruses.
> > >
> > >
> > --
> >
> > Alex Alten
> >
> > Alten@Home.Com
> >
> >
>
From owner-ipsec@lists.tislabs.com Tue Aug 7 11:45:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77IjoN07388;
Tue, 7 Aug 2001 11:45:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12697
Tue, 7 Aug 2001 13:39:29 -0400 (EDT)
Message-ID: <CCFF88268143CC4181A758DCC0ECDC13DE7745@posthaus.virtela.cc>
From: "Horn, Mike" <mhorn@virtela.net>
To: "'sommerfeld@east.sun.com'" <sommerfeld@East.Sun.COM>
Cc: "'Theodore Tso'" <tytso@mit.edu>,
Andrew Krywaniuk
<andrew.krywaniuk@alcatel.com>,
"'Alex Alten'" <Alten@home.com>,
"'Marcus Leech'" <mleech@nortelnetworks.com>, ipsec@lists.tislabs.com,
ietf-ipsra@vpnc.org
Subject: RE: Position statement on IKE development
Date: Tue, 7 Aug 2001 10:06:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Having everyone eventually migrate to certificates would be nice from a
theoretical viewpoint, but the reality is that there are VPN customers who
will _never_ move to a certificate based infrastructure. As a VPN service
provider, we see plenty of small customers who simply want their VPN
authentication proxied to their existing RADIUS/NT/etc server(s). This is
why it's critical to have a long term user authentication mechanism for
IPsec.
Mike Horn
> -----Original Message-----
> From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com]
> Sent: Monday, August 06, 2001 6:41 PM
> To: Horn, Mike
> Cc: 'Theodore Tso'; Andrew Krywaniuk; 'Alex Alten'; 'Marcus Leech';
> ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org
> Subject: Re: Position statement on IKE development
>
>
> > One of the reasons various user authentication schemes have not been
> > considered (CRACK for instance) is the moratorium on changes to IKE.
> > Unfortunately the IPSRA WG is very dependent on IKE.
>
> The IPSRA WG is not at all dependant on IKE; it's really all about
> protocols to turn legacy authentication into certificates..
>
> - Bill
>
From owner-ipsec@lists.tislabs.com Tue Aug 7 12:15:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77JFfN08016;
Tue, 7 Aug 2001 12:15:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12900
Tue, 7 Aug 2001 14:32:15 -0400 (EDT)
Date: Tue, 7 Aug 2001 12:49:05 -0600
From: Shane Amante <shane@amante.org>
To: "Horn, Mike" <mhorn@virtela.net>
Cc: "'Theodore Tso'" <tytso@mit.edu>,
Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>,
"'Alex Alten'" <Alten@home.com>,
"'Marcus Leech'" <mleech@nortelnetworks.com>, ipsec@lists.tislabs.com,
ietf-ipsra@vpnc.org
Subject: Re: Position statement on IKE development
Message-ID: <20010807124904.A3681@traveller.amante.org>
Mail-Followup-To: "Horn, Mike" <mhorn@virtela.net>,
'Theodore Tso' <tytso@mit.edu>,
Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>,
'Alex Alten' <Alten@home.com>,
'Marcus Leech' <mleech@nortelnetworks.com>, ipsec@lists.tislabs.com,
ietf-ipsra@vpnc.org
References: <CCFF88268143CC4181A758DCC0ECDC13DE773D@posthaus.virtela.cc>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <CCFF88268143CC4181A758DCC0ECDC13DE773D@posthaus.virtela.cc>; from mhorn@virtela.net on Mon, Aug 06, 2001 at 06:03:08PM -0600
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Mon, Aug 06, 2001 at 06:03:08PM -0600, Horn, Mike wrote:
[-- snip --]
> Perhaps a new requirements draft needs to be started, so that Son of IKE
> does not suffer the same fate as IKE. IMHO, I think trying to make Son of
> IKE "implementation preserving" is going to take Son of IKE down a very
> familiar and ugly path. Starting out with a new port assignment, and
> building from the ground up might be the only answer. There are obviously a
> lot of lessons that have been learned the hard way which should serve to
> greatly improve both the security and reduce the complexity of a next
> generation key exchange protocol designed specifically for IPsec.
Speaking from an operator's viewpoint, I have to agree with Mike and
other posters in support of jumping over 'son-of-IKE' and, instead,
launching a new initiative for a 'next-generation' IKE that is based
on a clearly defined set of *requirements* from the operator and
implementor community. In fact, starting with *requirements draft*
BEFORE 'son-of-IKE' would be immensely helpful in gathering consensus
on whether it is even worth it to do 'son-of-IKE' or just jump over it
and start from scratch. As a good friend and colleague says: "You've
got to define a target before you can aim at it; otherwise, you'll
never hit anything." Right now, I have a hard time seeing how
painting some broad strokes of: a) simplify IKE; and, b) possibly add
these other arbitrary "enhancements" will lead to anything but
delaying the inevitable opening up the can-of-worms that is re-vamping
IKE from the ground up so it has extensibility and future-proofing.
The bottom-line is the current proposals on the table really only
addresses two thirds of the problems I see in the real-world today.
Specifically, 1) simplification of IKE; and, 2) NAT-traversal. What
it doesn't address is: 3) remote-access/legacy-authentication issues,
which in all fairness, has been stated "will be worked on later" while
IPSRA is also valiantly attempting to come up with a solution today.
Ultimately, it boils down to the fact that, as an operator, I'd much
rather see a comprehensive solution developed that addresses all three
concerns than have to deploy 'son-of-IKE' and then, some time later,
either 'son-of-IKE++' or 'next-gen-IKE' that finally captures all of
my customer's needs.
Anyway, just my $0.02 ...
-shane
From owner-ipsec@lists.tislabs.com Tue Aug 7 12:39:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77JdVN08421;
Tue, 7 Aug 2001 12:39:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13049
Tue, 7 Aug 2001 14:57:55 -0400 (EDT)
Date: Tue, 7 Aug 2001 15:04:12 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Wes Hardaker <wes@hardakers.net>
cc: Hugh Daniel <hugh@road.xisp.net>, ipsec@lists.tislabs.com
Subject: Re: opportunistic encryption deployment problems
In-Reply-To: <sd4rrlb6k1.fsf@wanderer.hardakers.net>
Message-ID: <Pine.BSI.3.91.1010807142311.24224C-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Mon, 6 Aug 2001, Wes Hardaker wrote:
> 3 problems I see with the deployment of opportunistic encryption:
> 1) your method of obtaining information is by reverse DNS lookup,
> which will provide problems with people who can't control their
> reverse DNS bindings...
Agreed. We have some ideas on handling that, but the feedback we're
getting is that it's an even bigger problem than we thought. Sigh.
The central difficulty is that at the time we need to figure out who to
negotiate with and how to authenticate them, we have *no* information
other than the IP address of the ultimate destination. It's hard to avoid
starting with a reverse lookup in that situation.
Trying to finesse this by setting up a new tree parallel to the current
inet-addr.arpa reverse tree doesn't seem to really solve anything, alas --
if you follow through all the implications (e.g., how do you decide who is
allowed to update parts of that tree?), you find you have just re-invented
inet-addr.arpa, duplicating all its overheads without actually solving any
of its problems. At least, that's the way it looked when I analyzed this
option a while back.
The one possible way out of this is that 99.9% of the time, that IP
address was itself obtained by a very recent DNS lookup of a name, and so
it would be workable to associate the information with that name instead.
Trouble is, there's no way to ask a DNS server for that! We need to be
able to ask "what name did you recently map into address a.b.c.d, and what
else did you learn in that lookup?" (since DNSSEC-aware name servers try
to return KEY records along with A records). There sort of is a way to do
that -- inverse queries -- but it is excessively general, and as a result
nobody implements it and it's increasingly considered obsolete.
> 2) your method of obtaining information is by reverse DNS lookup,
> which will provide problems with people behind NATs.
Indeed so... but those people are going to have some difficulty using
IPsec anyway, since IPsec does not get along well with NAT. Also, NAT
is just plain evil, "a botch and a blemish".
That aside, we do have some notions about how to handle this, although
I don't think they made it into the -01 draft (which was done in great
haste). It's somewhat the same situation as a Road Warrior, which can be
using an IP address it does not "own". The answer is that (a) it must
originate the call, since there is no way to call in to it, (b) it must
supply enough information via ID payloads to point the other end to DNS
entries for it, and (c) the NAT machinery has to be sufficiently aware of
the situation to NAT things properly. (Given (c), it is basically the
same as Road Warrior.)
This is not ideal, but with an atrocity like NAT obstructing your network
access, there is inherently no graceful way.
> 3) The wider and wider spread use of things like web and other proxies
> will provide similar problems seen in #2.
Such "stupid packet tricks" do indeed interfere with your use of the
Internet. Fortunately, encryption prevents most of them anyway, so
widespread opportunistic encryption will make them obsolete. (The proxy
may intercept your HTTP packets if they go out as plaintext, but there's
not much it can do when they're hidden inside encrypted ESP packets.)
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue Aug 7 12:40:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77JeKN08453;
Tue, 7 Aug 2001 12:40:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12961
Tue, 7 Aug 2001 14:46:08 -0400 (EDT)
Message-Id: <4.3.2.7.0.20010807132741.00b8d318@STPNTMX03.sctc.com>
X-Sender: smith@STPNTMX03.sctc.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 07 Aug 2001 13:49:00 -0500
To: Alex Alten <Alten@home.com>, Kory Hamzeh <kory@avatar.com>,
"Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Rick Smith at Secure Computing <rick_smith@securecomputing.com>
Subject: Re: IKE must have no Heirs
Cc: "'mcnelson@mindspring.com'" <mcnelson@mindspring.com>,
ipsec@lists.tislabs.com
In-Reply-To: <3.0.3.32.20010807002820.010a77f8@mail>
References: <Pine.BSF.3.96.1010806230331.19308B-100000@ns1.avatar.com>
<2F3EC696EAEED311BB2D009027C3F4F40154CA4C@vhqpostal.verisign.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 02:28 AM 8/7/2001, Alex Alten wrote:
>I second the motion. And also propose no port number (i.e. do the new
>one over raw IP).
There is a benefit to this approach if, in some future universe, we ever
try to implement a protocol stack using least privilege to maximize
security assurance. It gives us an easy way of putting all parts of IPsec
within the same trust boundary and of keeping it better separated from
other protocol processing.
Otherwise you are stuck with a uniform level of trust for all of the
software in the protocol stack, crypto and non-crypto, including the
mechanism that binds ports to processes. I know, this isn't a problem today
because protocol stacks run in kernel mode and therefore we (have no other
choice but to) "trust" the entire protocol stack.
It is, of course, feasible to ignore the issues of incremental trust and/or
build additional mechanisms to bring together what is built asunder. But it
seems cleaner, design-wise, to keep the key management close to the code
that actually uses the resulting keys.
Rick.
smith@securecomputing.com
From owner-ipsec@lists.tislabs.com Tue Aug 7 13:23:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77KNZN09111;
Tue, 7 Aug 2001 13:23:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13224
Tue, 7 Aug 2001 15:33:32 -0400 (EDT)
Date: Tue, 7 Aug 2001 13:51:17 -0600
From: Shane Amante <shane@amante.org>
To: "Horn, Mike" <mhorn@virtela.net>
Cc: "'Shane Amante'" <shane@amante.org>, "'Theodore Tso'" <tytso@mit.edu>,
Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>,
"'Alex Alten'" <Alten@home.com>,
"'Marcus Leech'" <mleech@nortelnetworks.com>, ipsec@lists.tislabs.com,
ietf-ipsra@vpnc.org
Subject: Re: Position statement on IKE development
Message-ID: <20010807135117.A3844@traveller.amante.org>
Mail-Followup-To: "Horn, Mike" <mhorn@virtela.net>,
'Shane Amante' <shane@amante.org>, 'Theodore Tso' <tytso@mit.edu>,
Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>,
'Alex Alten' <Alten@home.com>,
'Marcus Leech' <mleech@nortelnetworks.com>, ipsec@lists.tislabs.com,
ietf-ipsra@vpnc.org
References: <CCFF88268143CC4181A758DCC0ECDC13DE774E@posthaus.virtela.cc>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <CCFF88268143CC4181A758DCC0ECDC13DE774E@posthaus.virtela.cc>; from mhorn@virtela.net on Tue, Aug 07, 2001 at 01:01:34PM -0600
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On the one hand, I agree with Paul that these aren't part of the base
IKE spec (as it stands today) and, unfortunately, there's nothing
IPSRA will be able to do to address them. So, are we to assume that
the IPSEC WG is responsible for these things?
Judging from the "IKE Position Statement" and follow-up e-mails, it
sounds as if item #1 are to be addressed immediately, while #3 is to
be addressed, possibly, later in 'son-of-IKE'. However, that leaves
item #2, which I agree with you, should be standardized in IPSec and IS
NOT only "an application issue".
So, I have to ask: who is keeping track of these, and other
requirements, at what point they will be addressed and where is it all
documented? It seems to me to be good common, and engineering, sense
to put in a draft all the requirements for what we want out of a
'son-of-IKE' and 'next-gen-IKE'. Then, we can compare the two
requirements docs side-by-side and judge which proposal meets the
needs of the community best.
-shane
On Tue, Aug 07, 2001 at 01:01:34PM -0600, Horn, Mike wrote:
> <snipped>
>
> > Speaking from an operator's viewpoint, I have to agree with Mike and
> > other posters in support of jumping over 'son-of-IKE' and, instead,
> > launching a new initiative for a 'next-generation' IKE that is based
> > on a clearly defined set of *requirements* from the operator and
> > implementor community. In fact, starting with *requirements draft*
> > BEFORE 'son-of-IKE' would be immensely helpful in gathering consensus
> > on whether it is even worth it to do 'son-of-IKE' or just jump over it
> > and start from scratch.
>
> I tried to get additional requirements added to the IPSRA requirements
> document, but I was told things like keepalives were out of scope due to the
> "no changes to IKE" requirements. These are some of the replies I got from
> Paul Hoffman when I suggested additions to the requirements draft.
>
> Mike Horn: 1) The IRAS and IRAC SHOULD support NAT traversal.
> Paul Hoffman: We don't yet have a standard for that.
> Mike Horn: 2) The IRAC SHOULD support redundant gateways.
> Paul Hoffman: This is an application issue, not a protocol issue.
> Mike Horn: 3) The IRAS and IRAC SHOULD support a keepalive or make dead
> mechanism.
> Paul Hoffman: We don't yet have a standard for that.
>
> I thought the point of a requirements draft was to clearly define the things
> that need solutions, not how to use existing solutions.
>
> Mike Horn
From owner-ipsec@lists.tislabs.com Tue Aug 7 13:34:18 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77KYIN10539;
Tue, 7 Aug 2001 13:34:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13298
Tue, 7 Aug 2001 15:52:23 -0400 (EDT)
Message-ID: <CCFF88268143CC4181A758DCC0ECDC13DE774E@posthaus.virtela.cc>
From: "Horn, Mike" <mhorn@virtela.net>
To: "'Shane Amante'" <shane@amante.org>
Cc: "'Theodore Tso'" <tytso@mit.edu>,
Andrew Krywaniuk
<andrew.krywaniuk@alcatel.com>,
"'Alex Alten'" <Alten@home.com>,
"'Marcus Leech'" <mleech@nortelnetworks.com>, ipsec@lists.tislabs.com,
ietf-ipsra@vpnc.org
Subject: RE: Position statement on IKE development
Date: Tue, 7 Aug 2001 13:01:34 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
<snipped>
> Speaking from an operator's viewpoint, I have to agree with Mike and
> other posters in support of jumping over 'son-of-IKE' and, instead,
> launching a new initiative for a 'next-generation' IKE that is based
> on a clearly defined set of *requirements* from the operator and
> implementor community. In fact, starting with *requirements draft*
> BEFORE 'son-of-IKE' would be immensely helpful in gathering consensus
> on whether it is even worth it to do 'son-of-IKE' or just jump over it
> and start from scratch.
I tried to get additional requirements added to the IPSRA requirements
document, but I was told things like keepalives were out of scope due to the
"no changes to IKE" requirements. These are some of the replies I got from
Paul Hoffman when I suggested additions to the requirements draft.
Mike Horn: 1) The IRAS and IRAC SHOULD support NAT traversal.
Paul Hoffman: We don't yet have a standard for that.
Mike Horn: 2) The IRAC SHOULD support redundant gateways.
Paul Hoffman: This is an application issue, not a protocol issue.
Mike Horn: 3) The IRAS and IRAC SHOULD support a keepalive or make dead
mechanism.
Paul Hoffman: We don't yet have a standard for that.
I thought the point of a requirements draft was to clearly define the things
that need solutions, not how to use existing solutions.
Mike Horn
From owner-ipsec@lists.tislabs.com Tue Aug 7 13:39:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77KdKN10587;
Tue, 7 Aug 2001 13:39:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13331
Tue, 7 Aug 2001 16:02:13 -0400 (EDT)
Date: Tue, 7 Aug 2001 16:08:03 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
cc: Hugh Daniel <hugh@road.xisp.net>, ipsec@lists.tislabs.com
Subject: RE: Wes Hardaker: opportunistic encryption deployment problems
In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40154CA4B@vhqpostal.verisign.com>
Message-ID: <Pine.BSI.3.91.1010807160125.25170C-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote:
> In particular reverse DNS is not much use when the target does not
> have a DNS address. This is the case for the vast majority of DCHP
> hosted home Internet hookups.
Remember that with continuous connectivity, your provider gains nothing
by not assigning you a permanent address -- there is no longer any
possibility of sharing a small pool of addresses among a large number of
users. Not all providers have figured this out yet, but it's coming.
(Most of Toronto's ADSL providers will give you a static IP address for a
small extra fee.) Getting stuff into the reverse map is more challenging,
admittedly, especially if you're dealing with a big stupid provider.
> I would not rely on any outcome being achieved as a byproduct of
> DNSSEC...
In other words, we can't ever rely on DNS being secure? Come now.
Admittedly, there are obstacles between here and there, but it is still
the right solution for a number of problems. Solving its remaining
difficulties is a better investment of time than inventing half-baked
alternatives.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue Aug 7 13:44:23 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77KiNN10661;
Tue, 7 Aug 2001 13:44:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13350
Tue, 7 Aug 2001 16:06:22 -0400 (EDT)
Date: Tue, 7 Aug 2001 16:12:28 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Bill Manning <bmanning@ISI.EDU>
cc: Hugh Daniel <hugh@road.xisp.net>, ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: Wes Hardaker: opportunistic encryption deployment problems
In-Reply-To: <200108071425.f77EPrl19554@zed.isi.edu>
Message-ID: <Pine.BSI.3.91.1010807160811.25170D-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 7 Aug 2001, Bill Manning wrote:
> One point. Instead of TXT records for stuffing bits into, there is
> the CERT record which was designed for just such stuff.
Well, for small values of "designed". :-) CERT itself is fine; the problem
is that the stuff inside it is X.509, which we have been resisting getting
involved with.
We chose TXT because we simply wanted to convey a gateway address and a
key, and we wanted to parse it with 10 lines of code, not 10,000.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue Aug 7 13:53:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77Kr2N10785;
Tue, 7 Aug 2001 13:53:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13414
Tue, 7 Aug 2001 16:14:10 -0400 (EDT)
Date: Tue, 7 Aug 2001 16:20:21 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Michael Thomas <mat@cisco.com>
cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: Wes Hardaker: opportunistic encryption deployment problems
In-Reply-To: <15216.5899.191140.121446@thomasm-u1.cisco.com>
Message-ID: <Pine.BSI.3.91.1010807161306.25170E-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 7 Aug 2001, Michael Thomas wrote:
> I guess I have to ask a really dumb question. Given the
> likelihood of DNSSEC any time soon, why don't we just
> ignore any pretense of authentication with opportunistic
> encryption and just accept the MITM attack inherent with
> ephemeral DH exchanges?
We thought about that, but decided that some authentication was better
than none, especially since it would upgrade transparently to full
authentication. It's one thing to accept security loopholes as a
temporary measure, and another to define a protocol that will always have
security loopholes.
> Also: it seems to me that expecting
> a secure DNS isn't actually opportunistic at all: it's
> trying to assert a different source of (sometimes strong) identity...
This basically boils down to what you think "opportunistic" means. We
don't see it as meaning "will talk to anybody, no setup necessary" but
rather "will talk to anybody who's set up for it". Some amount of setup
is clearly necessary anyway; we'd have liked to be able to talk to an
IPsec-capable host that's unaware of opportunistic encryption, but it
isn't possible.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue Aug 7 14:57:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77LveN11754;
Tue, 7 Aug 2001 14:57:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13557
Tue, 7 Aug 2001 17:00:19 -0400 (EDT)
Date: Tue, 7 Aug 2001 14:07:37 -0700 (PDT)
Message-Id: <200108072107.OAA10431@potomac.incog.com>
From: Mike Ditto <ford@apollo.incog.com>
To: angelos@coredump.cis.upenn.edu
CC: ipsec@lists.tislabs.com
In-reply-to: <200108070821.f778LRR18797@nyarlathotep.keromytis.org>
(angelos@coredump.cis.upenn.edu)
Subject: Re: Phase 1 IDs ("son of IKE")
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: "Angelos D. Keromytis" <angelos@coredump.cis.upenn.edu>
>
> >But if the identity hint was used as an abstract name, rather than the
> >exact identity that the responder is expected to use, it could be used
> >as a kind of generic "scope" or "role" identifier.
>
> My concern with this is that it's more complicated than the simple case of
> "here's what I'd like you to use", both in terms of semantics, effort that
> has to go in specs, and code.
I don't think it's more complicated. Instead of saying "the responder
must ignore the hint or use it as the value of the subsequent IDir
payload," you say "the responder may use the hint in an
implementation-defined way to influence its selection of its own
identity."
It would be important that the initiator have two distinct policy
parameters: one to specify what remote identities will be accepted from
the responder (regardless of whether it chooses to use the hint) and
another to specify the hint to be sent. This is because, as I said, the
initiator's policy language for specifying acceptable remote identities
may not have a simple representation as an ISAKMP identification
payload.
-=] Mike [=-
From owner-ipsec@lists.tislabs.com Tue Aug 7 15:00:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77M07N11803;
Tue, 7 Aug 2001 15:00:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13614
Tue, 7 Aug 2001 17:23:55 -0400 (EDT)
To: "Horn, Mike" <mhorn@virtela.net>
Cc: "'Alex Alten'" <Alten@home.com>,
Chris Trobridge <CTrobridge@baltimore.com>, ipsec@lists.tislabs.com
Subject: Re: IKE must have no Heirs
References: <CCFF88268143CC4181A758DCC0ECDC13DE7749@posthaus.virtela.cc>
From: Derek Atkins <warlord@mit.edu>
Date: 07 Aug 2001 17:30:13 -0400
In-Reply-To: "Horn, Mike"'s message of "Tue, 7 Aug 2001 10:38:08 -0600"
Message-ID: <sjmg0b3d0d6.fsf@rcn.ihtfp.org>
Lines: 101
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
There is no IPsec (ESP/AH) dependency on IKE. You can key manually
(which does not use IKE). There is the KINK work, is different than
IKE.
There is no reason to turn IKE into it's own IP Protocol. Using
UDP/500 works just fine, and making it's own protocol wont accomplish
anything.
-derek
"Horn, Mike" <mhorn@virtela.net> writes:
> Actually that is a poor example, there is no built-in protocol dependency
> for BGP to use OSPF. And BGP does use TCP (port 179) for communication vs.
> OSPF using a protocol number (89). IPsec currently has a strong dependency
> on IKE. I do agree that from a network administration and debugging
> standpoint it would be nice if both IPsec and IKE shared a common protocol
> number. This would help to simplify firewall configurations, etc.
>
> Mike Horn
>
> > -----Original Message-----
> > From: Alex Alten [mailto:Alten@home.com]
> > Sent: Tuesday, August 07, 2001 3:06 AM
> > To: Chris Trobridge
> > Cc: ipsec@lists.tislabs.com
> > Subject: RE: IKE must have no Heirs
> >
> >
> > Think about it. Do you do OSPF over IP and then BGP over UDP?
> > The same applies to IPSEC and key management.
> >
> > - Alex
> >
> > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Alex Alten [mailto:Alten@home.com]
> > >> Sent: 07 August 2001 08:28
> > >> To: Kory Hamzeh; Hallam-Baker, Phillip
> > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> > >> Subject: Re: IKE must have no Heirs
> > >>
> > >>
> > >>
> > >> I second the motion. And also propose no port number (i.e.
> > do the new
> > >> one over raw IP).
> > >>
> > >> - Alex
> > >
> > >What would that achieve? (communicating over raw IP)
> > >
> > >Chris
> > >
> > >
> > >-------------------------------------------------------------
> > --------------
> > --------------------------------------
> > >The information contained in this message is confidential
> > and is intended
> > >for the addressee(s) only. If you have received this
> > message in error or
> > >there are any problems please notify the originator
> > immediately. The
> > >unauthorized use, disclosure, copying or alteration of this
> > message is
> > >strictly forbidden. Baltimore Technologies plc will not be liable for
> > direct,
> > >special, indirect or consequential damages arising from
> > alteration of the
> > >contents of this message by a third party or as a result of
> > any virus being
> > >passed on.
> > >
> > >In addition, certain Marketing collateral may be added from
> > time to time to
> > >promote Baltimore Technologies products, services, Global
> > e-Security or
> > >appearance at trade shows and conferences.
> > >
> > >This footnote confirms that this email message has been swept by
> > >Baltimore MIMEsweeper for Content Security threats, including
> > >computer viruses.
> > >
> > >
> > --
> >
> > Alex Alten
> >
> > Alten@Home.Com
> >
> >
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Tue Aug 7 15:01:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77M18N11830;
Tue, 7 Aug 2001 15:01:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13622
Tue, 7 Aug 2001 17:26:37 -0400 (EDT)
Message-ID: <3B705EAF.211B0942@storm.ca>
Date: Tue, 07 Aug 2001 17:33:35 -0400
From: Sandy Harris <sandy@storm.ca>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Re: Position statement on IKE development
References: <3B69FF7B.85CF61@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I suspect if I knew more of the history, I wouldn't have to ask, but I seem
to see a contradiction below.
Marcus Leech wrote:
> ... Formal and semi-formal analyses by Meadows, Schneier et al, and
> Simpson, have shown that the security problems in IKE stem directly
> from its complexity. ...
>
> We are concerned that trying to reuse too much of the IKE
> code base in new protocols ...
> will lead to more complex (and hence vulnerable) implementations.
> We suggest that implementors resist this temptation, ...
This makes sense.
> The Security Area Directors have asked the IPSEC working group to come
> up with a replacement for IKE. This work is underway and is known in
> the community as "Son of IKE". ...
So why are we working on "Son of IKE", which is presumably a new protocol
and presumably re-uses much of IKE?
Presumably there are good reasons we don't just say IKE was a mistake
and switch to Simpson et al's simpler Photuris protocol. What are they?
From owner-ipsec@lists.tislabs.com Tue Aug 7 15:45:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77MjkN12746;
Tue, 7 Aug 2001 15:45:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13881
Tue, 7 Aug 2001 18:07:06 -0400 (EDT)
Date: Tue, 7 Aug 2001 15:13:02 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: "Horn, Mike" <mhorn@virtela.net>
cc: "'Alex Alten'" <Alten@home.com>,
Chris Trobridge <CTrobridge@baltimore.com>, ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
In-Reply-To: <CCFF88268143CC4181A758DCC0ECDC13DE7749@posthaus.virtela.cc>
Message-ID: <Pine.LNX.4.21.0108071511080.820-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 7 Aug 2001, Horn, Mike wrote:
> Actually that is a poor example, there is no built-in protocol dependency
> for BGP to use OSPF. And BGP does use TCP (port 179) for communication vs.
> OSPF using a protocol number (89). IPsec currently has a strong dependency
> on IKE.
I'm not sure I agree at all. IPSec wants keys. Where it gets these from, it
doesn't really care. There's KINK and manual keying for example. Different
keying protocols can be used (assuming they exist) and different keying
protocols can have different features and security definitions (one's more
secure against DOS/DDOS, another has less messages, another provides Identity
protection at the expense of more messages, etc). I'm not proposing 10 new
protocols, but I DO propose 2-3, as required by the non-overlapping
requirements that have gotten us IKE.
IPSec couldn't care less where it got the keys from.
jan
> I do agree that from a network administration and debugging
> standpoint it would be nice if both IPsec and IKE shared a common protocol
> number. This would help to simplify firewall configurations, etc.
>
> Mike Horn
>
> > -----Original Message-----
> > From: Alex Alten [mailto:Alten@home.com]
> > Sent: Tuesday, August 07, 2001 3:06 AM
> > To: Chris Trobridge
> > Cc: ipsec@lists.tislabs.com
> > Subject: RE: IKE must have no Heirs
> >
> >
> > Think about it. Do you do OSPF over IP and then BGP over UDP?
> > The same applies to IPSEC and key management.
> >
> > - Alex
> >
> > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Alex Alten [mailto:Alten@home.com]
> > >> Sent: 07 August 2001 08:28
> > >> To: Kory Hamzeh; Hallam-Baker, Phillip
> > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> > >> Subject: Re: IKE must have no Heirs
> > >>
> > >>
> > >>
> > >> I second the motion. And also propose no port number (i.e.
> > do the new
> > >> one over raw IP).
> > >>
> > >> - Alex
> > >
> > >What would that achieve? (communicating over raw IP)
> > >
> > >Chris
> > >
> > >
> > >-------------------------------------------------------------
> > --------------
> > --------------------------------------
> > >The information contained in this message is confidential
> > and is intended
> > >for the addressee(s) only. If you have received this
> > message in error or
> > >there are any problems please notify the originator
> > immediately. The
> > >unauthorized use, disclosure, copying or alteration of this
> > message is
> > >strictly forbidden. Baltimore Technologies plc will not be liable for
> > direct,
> > >special, indirect or consequential damages arising from
> > alteration of the
> > >contents of this message by a third party or as a result of
> > any virus being
> > >passed on.
> > >
> > >In addition, certain Marketing collateral may be added from
> > time to time to
> > >promote Baltimore Technologies products, services, Global
> > e-Security or
> > >appearance at trade shows and conferences.
> > >
> > >This footnote confirms that this email message has been swept by
> > >Baltimore MIMEsweeper for Content Security threats, including
> > >computer viruses.
> > >
> > >
> > --
> >
> > Alex Alten
> >
> > Alten@Home.Com
> >
> >
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Tue Aug 7 16:09:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77N93N13478;
Tue, 7 Aug 2001 16:09:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13915
Tue, 7 Aug 2001 18:23:54 -0400 (EDT)
To: "Horn, Mike" <mhorn@virtela.net>
Cc: ipsec@lists.tislabs.com
Subject: Re: IKE must have no Heirs
References: <CCFF88268143CC4181A758DCC0ECDC13DE7764@posthaus.virtela.cc>
From: Derek Atkins <warlord@mit.edu>
Date: 07 Aug 2001 18:30:53 -0400
In-Reply-To: "Horn, Mike"'s message of "Tue, 7 Aug 2001 15:42:48 -0600"
Message-ID: <sjmbslrcxk2.fsf@rcn.ihtfp.org>
Lines: 141
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Note the 'ipsec' has TWO protocol numbers... One for ESP and one for
AH. What do _YOU_ mean?
-derek
"Horn, Mike" <mhorn@virtela.net> writes:
> Again speaking from service provider experience, manual keys are not a
> scalable option. Some sort of key exchange protocol is definitely required,
> right now that means IKE. As for using a single IP protocol number for both
> IKE and IPsec, I was merely stating this would reduce the number of
> ports/protocols I have to request firewall administrators to allow. From an
> operational perspective, dealing with IPsec devices behind firewalls can be
> very painful. I will let this thread die, since the IPSEC and IPSRA working
> groups face much bigger challenges then determining if IKE and IPsec should
> share a protocol number.
>
> Mike Horn
>
> > -----Original Message-----
> > From: Derek Atkins [mailto:warlord@MIT.EDU]
> > Sent: Tuesday, August 07, 2001 3:30 PM
> > To: Horn, Mike
> > Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com
> > Subject: Re: IKE must have no Heirs
> >
> >
> > There is no IPsec (ESP/AH) dependency on IKE. You can key manually
> > (which does not use IKE). There is the KINK work, is different than
> > IKE.
> >
> > There is no reason to turn IKE into it's own IP Protocol. Using
> > UDP/500 works just fine, and making it's own protocol wont accomplish
> > anything.
> >
> > -derek
> >
> > "Horn, Mike" <mhorn@virtela.net> writes:
> >
> > > Actually that is a poor example, there is no built-in
> > protocol dependency
> > > for BGP to use OSPF. And BGP does use TCP (port 179) for
> > communication vs.
> > > OSPF using a protocol number (89). IPsec currently has a
> > strong dependency
> > > on IKE. I do agree that from a network administration and debugging
> > > standpoint it would be nice if both IPsec and IKE shared a
> > common protocol
> > > number. This would help to simplify firewall configurations, etc.
> > >
> > > Mike Horn
> > >
> > > > -----Original Message-----
> > > > From: Alex Alten [mailto:Alten@home.com]
> > > > Sent: Tuesday, August 07, 2001 3:06 AM
> > > > To: Chris Trobridge
> > > > Cc: ipsec@lists.tislabs.com
> > > > Subject: RE: IKE must have no Heirs
> > > >
> > > >
> > > > Think about it. Do you do OSPF over IP and then BGP over UDP?
> > > > The same applies to IPSEC and key management.
> > > >
> > > > - Alex
> > > >
> > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Alex Alten [mailto:Alten@home.com]
> > > > >> Sent: 07 August 2001 08:28
> > > > >> To: Kory Hamzeh; Hallam-Baker, Phillip
> > > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> > > > >> Subject: Re: IKE must have no Heirs
> > > > >>
> > > > >>
> > > > >>
> > > > >> I second the motion. And also propose no port number (i.e.
> > > > do the new
> > > > >> one over raw IP).
> > > > >>
> > > > >> - Alex
> > > > >
> > > > >What would that achieve? (communicating over raw IP)
> > > > >
> > > > >Chris
> > > > >
> > > > >
> > > > >-------------------------------------------------------------
> > > > --------------
> > > > --------------------------------------
> > > > >The information contained in this message is confidential
> > > > and is intended
> > > > >for the addressee(s) only. If you have received this
> > > > message in error or
> > > > >there are any problems please notify the originator
> > > > immediately. The
> > > > >unauthorized use, disclosure, copying or alteration of this
> > > > message is
> > > > >strictly forbidden. Baltimore Technologies plc will not
> > be liable for
> > > > direct,
> > > > >special, indirect or consequential damages arising from
> > > > alteration of the
> > > > >contents of this message by a third party or as a result of
> > > > any virus being
> > > > >passed on.
> > > > >
> > > > >In addition, certain Marketing collateral may be added from
> > > > time to time to
> > > > >promote Baltimore Technologies products, services, Global
> > > > e-Security or
> > > > >appearance at trade shows and conferences.
> > > > >
> > > > >This footnote confirms that this email message has been
> > swept by
> > > > >Baltimore MIMEsweeper for Content Security threats, including
> > > > >computer viruses.
> > > > >
> > > > >
> > > > --
> > > >
> > > > Alex Alten
> > > >
> > > > Alten@Home.Com
> > > >
> > > >
> > >
> >
> > --
> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > Member, MIT Student Information Processing Board (SIPB)
> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> > warlord@MIT.EDU PGP key available
> >
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Tue Aug 7 16:23:54 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f77NNsN13806;
Tue, 7 Aug 2001 16:23:54 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13963
Tue, 7 Aug 2001 18:47:41 -0400 (EDT)
To: "Horn, Mike" <mhorn@virtela.net>
Cc: ipsec@lists.tislabs.com
Subject: Re: IKE must have no Heirs
References: <CCFF88268143CC4181A758DCC0ECDC13DE776E@posthaus.virtela.cc>
From: Derek Atkins <warlord@mit.edu>
Date: 07 Aug 2001 18:54:44 -0400
In-Reply-To: "Horn, Mike"'s message of "Tue, 7 Aug 2001 16:48:00 -0600"
Message-ID: <sjm8zgvcwgb.fsf@rcn.ihtfp.org>
Lines: 213
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
First, all the world is not VPN.
Second, there are alternate keying protocols (KINK, for example)
Third, trying to move IKE to IP_PROTO 50 would not only be WRONG,
it would also be HARD
Fourth, moving IKE to IP_PROTO 50 would make NAT traversal EVEN HARDER
than it already is.
You clearly don't understand the problems.
-derek
"Horn, Mike" <mhorn@virtela.net> writes:
> First, my only goal for being involved in this thread is that I think from
> an operational standpoint the current state of IKE/IPsec is broken. There
> are a LOT of features that have been added by various vendors in a
> proprietary fashion to address these shortcomings. I think that the whole
> VPN user community would benefit if the WG could come to some agreement and
> produce a protocol (or set of protocols) to address the VPN user communities
> needs.
>
> That being said, I thought there was general consensus that AH has not
> proven to be useful, so I didn't include it in my original email. If you
> know of _any_ service provider that is using AH for customer VPN's I would
> be interested to hear who. Again, I'm simply stating that IF IKE is
> replaced by something else, the WG should consider using the IPsec ESP
> protocol number.
>
> I agree Jan's point that all IPsec requires is keys. Right now, the only
> thing to my knowledge that is standardized for automated key exchange for
> use by IPsec is IKE. If that is not fixable to meet the communities stated
> requirements, then something new needs to be developed to fill this gap.
>
> I think that the lack of standardization for things like user
> authentication, has definitely impacted the user community's acceptance of
> IPsec.
>
> Mike Horn
>
>
>
> > -----Original Message-----
> > From: Derek Atkins [mailto:warlord@MIT.EDU]
> > Sent: Tuesday, August 07, 2001 4:31 PM
> > To: Horn, Mike
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: IKE must have no Heirs
> >
> >
> > Note the 'ipsec' has TWO protocol numbers... One for ESP and one for
> > AH. What do _YOU_ mean?
> >
> > -derek
> >
> > "Horn, Mike" <mhorn@virtela.net> writes:
> >
> > > Again speaking from service provider experience, manual
> > keys are not a
> > > scalable option. Some sort of key exchange protocol is
> > definitely required,
> > > right now that means IKE. As for using a single IP
> > protocol number for both
> > > IKE and IPsec, I was merely stating this would reduce the number of
> > > ports/protocols I have to request firewall administrators
> > to allow. From an
> > > operational perspective, dealing with IPsec devices behind
> > firewalls can be
> > > very painful. I will let this thread die, since the IPSEC
> > and IPSRA working
> > > groups face much bigger challenges then determining if IKE
> > and IPsec should
> > > share a protocol number.
> > >
> > > Mike Horn
> > >
> > > > -----Original Message-----
> > > > From: Derek Atkins [mailto:warlord@MIT.EDU]
> > > > Sent: Tuesday, August 07, 2001 3:30 PM
> > > > To: Horn, Mike
> > > > Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com
> > > > Subject: Re: IKE must have no Heirs
> > > >
> > > >
> > > > There is no IPsec (ESP/AH) dependency on IKE. You can
> > key manually
> > > > (which does not use IKE). There is the KINK work, is
> > different than
> > > > IKE.
> > > >
> > > > There is no reason to turn IKE into it's own IP Protocol. Using
> > > > UDP/500 works just fine, and making it's own protocol
> > wont accomplish
> > > > anything.
> > > >
> > > > -derek
> > > >
> > > > "Horn, Mike" <mhorn@virtela.net> writes:
> > > >
> > > > > Actually that is a poor example, there is no built-in
> > > > protocol dependency
> > > > > for BGP to use OSPF. And BGP does use TCP (port 179) for
> > > > communication vs.
> > > > > OSPF using a protocol number (89). IPsec currently has a
> > > > strong dependency
> > > > > on IKE. I do agree that from a network administration
> > and debugging
> > > > > standpoint it would be nice if both IPsec and IKE shared a
> > > > common protocol
> > > > > number. This would help to simplify firewall
> > configurations, etc.
> > > > >
> > > > > Mike Horn
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Alex Alten [mailto:Alten@home.com]
> > > > > > Sent: Tuesday, August 07, 2001 3:06 AM
> > > > > > To: Chris Trobridge
> > > > > > Cc: ipsec@lists.tislabs.com
> > > > > > Subject: RE: IKE must have no Heirs
> > > > > >
> > > > > >
> > > > > > Think about it. Do you do OSPF over IP and then BGP
> > over UDP?
> > > > > > The same applies to IPSEC and key management.
> > > > > >
> > > > > > - Alex
> > > > > >
> > > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> > > > > > >
> > > > > > >
> > > > > > >> -----Original Message-----
> > > > > > >> From: Alex Alten [mailto:Alten@home.com]
> > > > > > >> Sent: 07 August 2001 08:28
> > > > > > >> To: Kory Hamzeh; Hallam-Baker, Phillip
> > > > > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> > > > > > >> Subject: Re: IKE must have no Heirs
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> I second the motion. And also propose no port
> > number (i.e.
> > > > > > do the new
> > > > > > >> one over raw IP).
> > > > > > >>
> > > > > > >> - Alex
> > > > > > >
> > > > > > >What would that achieve? (communicating over raw IP)
> > > > > > >
> > > > > > >Chris
> > > > > > >
> > > > > > >
> > > > > >
> > >-------------------------------------------------------------
> > > > > > --------------
> > > > > > --------------------------------------
> > > > > > >The information contained in this message is confidential
> > > > > > and is intended
> > > > > > >for the addressee(s) only. If you have received this
> > > > > > message in error or
> > > > > > >there are any problems please notify the originator
> > > > > > immediately. The
> > > > > > >unauthorized use, disclosure, copying or alteration of this
> > > > > > message is
> > > > > > >strictly forbidden. Baltimore Technologies plc will not
> > > > be liable for
> > > > > > direct,
> > > > > > >special, indirect or consequential damages arising from
> > > > > > alteration of the
> > > > > > >contents of this message by a third party or as a result of
> > > > > > any virus being
> > > > > > >passed on.
> > > > > > >
> > > > > > >In addition, certain Marketing collateral may be added from
> > > > > > time to time to
> > > > > > >promote Baltimore Technologies products, services, Global
> > > > > > e-Security or
> > > > > > >appearance at trade shows and conferences.
> > > > > > >
> > > > > > >This footnote confirms that this email message has been
> > > > swept by
> > > > > > >Baltimore MIMEsweeper for Content Security threats,
> > including
> > > > > > >computer viruses.
> > > > > > >
> > > > > > >
> > > > > > --
> > > > > >
> > > > > > Alex Alten
> > > > > >
> > > > > > Alten@Home.Com
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > --
> > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > > > Member, MIT Student Information Processing Board (SIPB)
> > > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> > > > warlord@MIT.EDU PGP key available
> > > >
> >
> > --
> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > Member, MIT Student Information Processing Board (SIPB)
> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> > warlord@MIT.EDU PGP key available
> >
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Tue Aug 7 19:42:59 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f782gwN23496;
Tue, 7 Aug 2001 19:42:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14621
Tue, 7 Aug 2001 21:26:54 -0400 (EDT)
Message-ID: <3B709706.4D051BE5@storm.ca>
Date: Tue, 07 Aug 2001 21:33:58 -0400
From: Sandy Harris <sandy@storm.ca>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Simplifying IKE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The Leech, Schiller and Bellovin (LSB?) document mentions:
> the goal: to produce a more secure, simpler, and more robust version of IKE.
I thought it might be useful to inventory some proposed simplifications. Of
course I'll toss in my own opinions while I'm at it, but my goal is less to
get them accepted than to provoke discussion.
>From the Schneier and Ferguson analysis we get:
> 1: eliminate transport mode
It would be possible to eliminate tunnel mode instead, and just use IP-in-IP
over transport where required, but it seems simpler to treat transport as a
degenerate tunnel instead. Either mode can do everything we need, so we need
only one mode. My vote is for tunnel.
> 2. eliminate the AH protocol
> 3. modify ESP to always authenticate; only encryption should be
optional
Fine by me, but I vaguely recall some arguments that IPv6 and/or mobile
IP actually need AH. Could anyone who needs it speak up again?
If it turns out there are really good reasons to keep AH, then I'd say the
simplification is:
2a: eliminate ESP authentication
3a: require AH on all packets. No choice, no null mode. An IPsec connection
authenticates all packets, period.
> 4. modify ESP to ensure it authenticates all data used in the deciphering
of the payload
This is the only recommendation in this paper based on a direct security
flaw, with a proposed attack to demonstrate it. There are others in the
Simpson paper.
I'd say these are the most urgent criticisms, definite entries on the
requirements list for Son of IKE.
( By the way did "Ike" Eisenhower have a son, and should we rename the
protocol? )
> 5. Remove the weak key elimination requirement. ... algorithms that
have large classes of weak keys ... should simply not be used.
Of these, 1, 2, 3 and 5 are straightforward. Methinks these changes
should just go straight into the draft text for "Son", unless strong
objections are raised by this post.
Number 4 is a design task. Volunteers? Is there an existing draft I've
missed?
Then there are possible simplifications not recommended in the Schneier
and Ferguson paper.
We currently have MUST do main mode, SHOULD do aggressive mode, and
there's been discussion of a third mode. Could we cut it to one mode?
There are too many optional items.
Can we drop the commit bit?
Can we drop some (or even all?) of the optional notify messages?
Or perhaps make them required and authenticated, and therefore
more useful?
PFS is currently optional. Why not require it?
In general, review optional items with the intent of dropping as many
as possible and making any really useful ones mandatory. This would
eliminate quite few interoperation problems.
Manually-keyed connections and auto-keyed connections using pre-shared
keys for authentication are currently required. Could we drop either
or both, given that public key authentication has serious advantages
over them? Some discussion of the advantages is at:
http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/config.html#choose
To do this, we would have to specify support for at least one public
key technique as a MUST. I'd say RSA was the obvious possibility, and
we should have only the one MUST for simplicity.
We should also specify a common format for transfer of public key
information -- preferably by pointing to an existing spec, rather
than re-inventing -- and require everyone to import and export keys
in that format, whatever they choose to use internally. That way two
implementations that need to interoperate can get each others' keys.
For ciphers, we currently have DES and null encryption as the only
MUSTs, although we should all know DES is inadequate. 3DES is a
SHOULD, although it is dreadfully slow compared to either the CAST
and Blowfish generation of ciphers or to AES.
I'd like to see AES as the only MUST, with null encryption and 3DES
as SHOULDs.
From owner-ipsec@lists.tislabs.com Tue Aug 7 20:35:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f783Z9N24244;
Tue, 7 Aug 2001 20:35:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14732
Tue, 7 Aug 2001 22:40:48 -0400 (EDT)
Date: Tue, 7 Aug 2001 22:47:10 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Jan Vilhuber <vilhuber@cisco.com>
cc: IP Security List <ipsec@lists.tislabs.com>, Design@lists.freeswan.org
Subject: Re: [Design] Re: opportunistic encryption deployment problems
In-Reply-To: <Pine.LNX.4.21.0108071515330.820-100000@janpc-home.cisco.com>
Message-ID: <Pine.BSI.3.91.1010807211710.1187A-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 7 Aug 2001, Jan Vilhuber wrote:
> [moving to the design list, instead of the ipsec list, as this is a general
> freeswan design question]
Uh, no, it's a *protocol* design issue. We hope that FreeS/WAN will not
be the only implementation of opportunistic encryption, which is why we
submitted it as an IETF draft, and why discussion probably should be cc'ed
to the ipsec list.
> > using an IP address it does not "own". The answer is that (a) it must
> > originate the call, since there is no way to call in to it, (b) it must
> > supply enough information via ID payloads
>
> But this is impossible in main-mode (without fixing it as per improveike
> draft)...
How so? The difficulty in main mode is with shared-secret authentication.
Opportunistic uses RSA-signature authentication, which doesn't have the
same design botch. ID payloads work just fine with signature
authentication.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue Aug 7 21:41:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f784fKN25041;
Tue, 7 Aug 2001 21:41:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14861
Tue, 7 Aug 2001 23:39:39 -0400 (EDT)
Date: Tue, 7 Aug 2001 23:45:23 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Jari Arkko <jari.arkko@piuha.net>
cc: borderlt <border@hns.com>, ipsec@lists.tislabs.com
Subject: Re: Re draft-kaufman-ipsec-improveike-00.txt
In-Reply-To: <3B6FAE9C.4010606@piuha.net>
Message-ID: <Pine.BSI.3.91.1010807234146.2521C-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 7 Aug 2001, Jari Arkko wrote:
> > I suggest we work on more than one keying mechanism...
>
> [agreement] It is important to understand
> that there are conflicting requirements.
I suggest that we should make one good general-purpose protocol work well
(today's IKE does not satisfy this desire in a number of ways) before we
start considering a plethora of specialized variants.
If dim memory serves, there were many cries about how TCP would not meet
everyone's needs, and how there were conflicting requirements, and etc.
etc. etc... but in fact TCP really does meet *most* people's needs, even
if it is not precisely optimal in many cases.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue Aug 7 21:41:24 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f784fNN25053;
Tue, 7 Aug 2001 21:41:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14826
Tue, 7 Aug 2001 23:23:52 -0400 (EDT)
Date: Tue, 7 Aug 2001 23:30:24 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: "Horn, Mike" <mhorn@virtela.net>
cc: ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
In-Reply-To: <CCFF88268143CC4181A758DCC0ECDC13DE774B@posthaus.virtela.cc>
Message-ID: <Pine.BSI.3.91.1010807232730.2521A-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 7 Aug 2001, Horn, Mike wrote:
> I think users will only deploy Son of IKE if it solves all the open
> requirements, not if it just simplifies IKE and adds a single feature like
> NAT traversal. There seems to be a big rift between what the IPSEC and
> IPSRA WGs are doing, and what the vendors are doing on their own.
The intent, as I understand it, is not that Son of IKE solve all mankind's
problems (or even all of IPsec's), but rather that it solve some of
*IKE's* current problems, and be a more tractable (smaller and more
readily understood) base for future work. It's the first step, not the
last one.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue Aug 7 21:42:31 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f784gUN25078;
Tue, 7 Aug 2001 21:42:30 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14752
Tue, 7 Aug 2001 22:51:37 -0400 (EDT)
Date: Tue, 7 Aug 2001 19:57:35 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Henry Spencer <henry@spsystems.net>
cc: IP Security List <ipsec@lists.tislabs.com>, Design@lists.freeswan.org
Subject: Re: [Design] Re: opportunistic encryption deployment problems
In-Reply-To: <Pine.BSI.3.91.1010807211710.1187A-100000@spsystems.net>
Message-ID: <Pine.LNX.4.21.0108071956060.820-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Oh.. you're right. I stand corrected. Duh...
jan
On Tue, 7 Aug 2001, Henry Spencer wrote:
> On Tue, 7 Aug 2001, Jan Vilhuber wrote:
> > [moving to the design list, instead of the ipsec list, as this is a general
> > freeswan design question]
>
> Uh, no, it's a *protocol* design issue. We hope that FreeS/WAN will not
> be the only implementation of opportunistic encryption, which is why we
> submitted it as an IETF draft, and why discussion probably should be cc'ed
> to the ipsec list.
>
> > > using an IP address it does not "own". The answer is that (a) it must
> > > originate the call, since there is no way to call in to it, (b) it must
> > > supply enough information via ID payloads
> >
> > But this is impossible in main-mode (without fixing it as per improveike
> > draft)...
>
> How so? The difficulty in main mode is with shared-secret authentication.
> Opportunistic uses RSA-signature authentication, which doesn't have the
> same design botch. ID payloads work just fine with signature
> authentication.
>
> Henry Spencer
> henry@spsystems.net
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Tue Aug 7 22:06:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7856DN25357;
Tue, 7 Aug 2001 22:06:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14679
Tue, 7 Aug 2001 22:12:11 -0400 (EDT)
Message-Id: <200108080219.f782JIp00242@kebe.east.sun.com>
Subject: Re: Simplifying IKE
In-Reply-To: <3B709706.4D051BE5@storm.ca> from Sandy Harris at "Aug 7, 2001 09:33:58
pm"
To: Sandy Harris <sandy@storm.ca>
Date: Tue, 7 Aug 2001 22:19:18 -0400 (EDT)
CC: ipsec@lists.tislabs.com
From: Dan McDonald <danmcd@East.Sun.COM>
Organization: Sun Microsystems, Inc. - Solaris Internet Engineering
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> >From the Schneier and Ferguson analysis we get:
>
> > 1: eliminate transport mode
>
> It would be possible to eliminate tunnel mode instead, and just use IP-in-IP
> over transport where required, but it seems simpler to treat transport as a
> degenerate tunnel instead. Either mode can do everything we need, so we need
> only one mode. My vote is for tunnel.
I respectfully disagree. If we require tunnel mode everywhere, we run the
risk of further impacting performance by an additional 20(v4) to 40(v6) bytes
of MTU shrinkage.
If you consider tunnels as "transport with next-header == IP/IPv6", then you
can get all of your tunnel-mode functionality back by indicating a richer
selector set for next-header/protocol == IP/IPv6. It's not tough to picture
things this way.
Here's a table if we eliminate the tunnel mode distinction:
Protocol Selector set
-------- ------------
TCP outer IP addresses, port numbers
UDP outer IP addresses, port numbers
ICMP outer IP addresses, code, type
IP/IPv6 outer IP addresses, inner IP addresses, plus selector
set from inner IP protocol that doesn't include
IP addresses. (If inner IP proto == IP, stop with
inner IP addresses.)
Most of the VPN/router vendors I've seen like the ability to protect
different flows across the tunnel differently. My tunnel implementation
(which treats tunnel mode like a case of transport mode) doesn't distinguish
flows right now, but there's nothing stopping me from doing that in the
future.
> > 2. eliminate the AH protocol
> > 3. modify ESP to always authenticate; only encryption should be
> optional
>
> Fine by me, but I vaguely recall some arguments that IPv6 and/or mobile
> IP actually need AH. Could anyone who needs it speak up again?
>
> If it turns out there are really good reasons to keep AH, then I'd say the
> simplification is:
>
> 2a: eliminate ESP authentication
> 3a: require AH on all packets. No choice, no null mode. An IPsec connection
> authenticates all packets, period.
Choice 3a was the original intent of the SIPP security architecture (which
became the 182x series of IPsec RFCs). The biggest complainers about AH I've
seen include:
1.) Hardware people who didn't think you could build AH in hardware.
(There are worked counter-examples.)
2.) People who thought AH processing rules were convoluted.
Now #2 folks may have a point, but simplifying AH rules _may_ help there.
The biggest motivator behind AH was to allow an authenticated source route.
Now as Steve Bellovin has pointed out, unless you can configure a hop-by-hop
key, the middle can send that packet anywhere it wants before it reaches the
end.
I wish there were some ISP/ops types on this list (maybe there are and I'm
just being an airhead). I believe the source route header is primarily used
to see what paths are broken in a network - using the process of elimination.
Using AH (or ESP authentication) insures that the packet came from where it
claims to have come from. THAT is why AH was developed, but ESP
authentication can provide a source-routed packet with similar properties.
> > 4. modify ESP to ensure it authenticates all data used in the deciphering
> of the payload
>
> This is the only recommendation in this paper based on a direct security
> flaw, with a proposed attack to demonstrate it. There are others in the
> Simpson paper.
And if you use Choice 3a above, you get this for free - AH covers the whole
ESP datagram, SPI/IV/etc.
> I'd say these are the most urgent criticisms, definite entries on the
> requirements list for Son of IKE.
None of what you mentioned so far, BTW, deals with IKE. It all deals with
IPsec's basic on-the-wire protocols, none of which were really talked about
in the Security AD's note.
> > 5. Remove the weak key elimination requirement. ... algorithms that
> have large classes of weak keys ... should simply not be used.
No need to change specs to fix this - just issue a BCP/standard on algorithm
choices.
> Then there are possible simplifications not recommended in the Schneier
> and Ferguson paper.
NOW we're in IKE territory...
> We currently have MUST do main mode, SHOULD do aggressive mode, and
> there's been discussion of a third mode. Could we cut it to one mode?
That works for me!
> There are too many optional items.
>
> Can we drop the commit bit?
Who uses it?
> Can we drop some (or even all?) of the optional notify messages?
> Or perhaps make them required and authenticated, and therefore
> more useful?
Hear hear!
> PFS is currently optional. Why not require it?
Agreed.
> Manually-keyed connections and auto-keyed connections using pre-shared
> keys for authentication are currently required. Could we drop either
> or both, given that public key authentication has serious advantages
> over them? Some discussion of the advantages is at:
> http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/config.html#choose
Strongly disagree on manual keying. Many outfits use "keying by {Marine
guard, bodybuilder, steganography}". Also a manual keying interface can
allow better automated KM systems to be built (Shameless plug: RFC 2367).
> We should also specify a common format for transfer of public key
> information -- preferably by pointing to an existing spec, rather
> than re-inventing -- and require everyone to import and export keys
> in that format, whatever they choose to use internally. That way two
> implementations that need to interoperate can get each others' keys.
Now you're tackling PKI problems. I don't envy you the task, especially
given we have a PKIX group that's probably better equipped to handle this.
> For ciphers, we currently have DES and null encryption as the only
> MUSTs, although we should all know DES is inadequate. 3DES is a
> SHOULD, although it is dreadfully slow compared to either the CAST
> and Blowfish generation of ciphers or to AES.
>
> I'd like to see AES as the only MUST, with null encryption and 3DES
> as SHOULDs.
Works for me. But what about hashes?
Dan
From owner-ipsec@lists.tislabs.com Tue Aug 7 22:57:41 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f785vfN27327;
Tue, 7 Aug 2001 22:57:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA15104
Wed, 8 Aug 2001 00:52:18 -0400 (EDT)
Date: Wed, 8 Aug 2001 10:30:35 +0530 (IST)
From: Puja Puri <puja.puri@cdac.ernet.in>
To: ipsec@lists.tislabs.com
Subject: Packet Interceptor Implementation for IPSec
Message-ID: <Pine.GSO.4.10.10108081024530.12382-100000@mailhub.cdac.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I am into implementation of IPSec under linux and as a part of it I need
to develop a packet interceptor which takes packets from the network
adapter and passes it to the IPSec (Bump in the Stack implementation).
I am new in this field and I am stuck at the packet interceptor
implementation ; since i do not want to hamper with the tcp/ip code but
wanna develop a insertable module into the kernel.
Can anyone please help me?? What mechanism for this can be used and how to
go about it??
Puja Puri
Member of Technical Staff
Networking and Internet Software Group
C-DAC
Pune
From owner-ipsec@lists.tislabs.com Tue Aug 7 22:58:25 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f785wPN27346;
Tue, 7 Aug 2001 22:58:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA15096
Wed, 8 Aug 2001 00:50:35 -0400 (EDT)
Date: Tue, 7 Aug 2001 23:04:52 -0600
From: Shane Amante <shane@amante.org>
To: Sandy Harris <sandy@storm.ca>
Cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
Message-ID: <20010807230452.A4676@traveller.amante.org>
Mail-Followup-To: Sandy Harris <sandy@storm.ca>,
ipsec@lists.tislabs.com
References: <3B709706.4D051BE5@storm.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B709706.4D051BE5@storm.ca>; from sandy@storm.ca on Tue, Aug 07, 2001 at 09:33:58PM -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, Aug 07, 2001 at 09:33:58PM -0400, Sandy Harris wrote:
[-- snip --]
> I'd say these are the most urgent criticisms, definite entries on the
> requirements list for Son of IKE.
>
> ( By the way did "Ike" Eisenhower have a son, and should we rename the
> protocol? )
According to the 3rd paragraph of this Web page:
http://www.ibiblio.org/lia/president/EisenhowerLibrary/_General_Materials/DDE_Biography.html
... President Eisenhower named his first son "Doud Dwight". So, how
about calling son-of-IKE, just "Doud" (pronounced Dude?) from now on?
:-)
-shane
From owner-ipsec@lists.tislabs.com Wed Aug 8 01:15:18 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f788FIN19548;
Wed, 8 Aug 2001 01:15:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15622
Wed, 8 Aug 2001 03:14:36 -0400 (EDT)
X-Envelope-To: ipsec@lists.tislabs.com
To: ipsec@lists.tislabs.com
Path: not-for-mail
From: daw@mozart.cs.berkeley.edu (David Wagner)
Newsgroups: isaac.lists.ipsec
Subject: Re: Simplifying IKE
Date: 8 Aug 2001 07:18:29 GMT
Organization: University of California, Berkeley
Lines: 13
Distribution: isaac
Message-ID: <9kqp45$pqf$1@abraham.cs.berkeley.edu>
References: <3B709706.4D051BE5@storm.ca>
NNTP-Posting-Host: mozart.cs.berkeley.edu
X-Trace: abraham.cs.berkeley.edu 997255109 26447 128.32.45.153 (8 Aug 2001 07:18:29 GMT)
X-Complaints-To: news@abraham.cs.berkeley.edu
NNTP-Posting-Date: 8 Aug 2001 07:18:29 GMT
X-Newsreader: trn 4.0-test74 (May 26, 2000)
Originator: daw@mozart.cs.berkeley.edu (David Wagner)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Sandy Harris wrote:
>The Leech, Schiller and Bellovin (LSB?) document mentions:
>> the goal: to produce a more secure, simpler, and more robust version of IKE.
>
>From the Schneier and Ferguson analysis we get:
>> 1: eliminate transport mode
>> 2. eliminate the AH protocol
>> 3. modify ESP to always authenticate [...]
>> 4. modify ESP to ensure it authenticates all data [...]
What do any of those have to do with IKE? Those are all about
the packet-level format, which has very little to do with IKE, as
far as I can see.
From owner-ipsec@lists.tislabs.com Wed Aug 8 01:16:06 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f788G6N19698;
Wed, 8 Aug 2001 01:16:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15651
Wed, 8 Aug 2001 03:23:58 -0400 (EDT)
To: ipsec@lists.tislabs.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: son of IKE
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Wed, 08 Aug 2001 16:30:52 +0900
Message-Id: <20010808073052.806CF7BA@starfruit.itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
just curious - is there any chance for Photuris?
itojun
From owner-ipsec@lists.tislabs.com Wed Aug 8 02:22:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f789MqN28325;
Wed, 8 Aug 2001 02:22:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA15774
Wed, 8 Aug 2001 04:21:28 -0400 (EDT)
Message-ID: <3B70F758.92D93CDB@isi.edu>
Date: Wed, 08 Aug 2001 01:24:56 -0700
From: Joe Touch <touch@ISI.EDU>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sandy Harris <sandy@storm.ca>
CC: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
References: <3B709706.4D051BE5@storm.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Sandy Harris wrote:
>
> The Leech, Schiller and Bellovin (LSB?) document mentions:
>
> > the goal: to produce a more secure, simpler, and more robust version of IKE.
>
> I thought it might be useful to inventory some proposed simplifications. Of
> course I'll toss in my own opinions while I'm at it, but my goal is less to
> get them accepted than to provoke discussion.
>
> >From the Schneier and Ferguson analysis we get:
>
> > 1: eliminate transport mode
>
> It would be possible to eliminate tunnel mode instead, and just use IP-in-IP
> over transport where required, but it seems simpler to treat transport as a
> degenerate tunnel instead. Either mode can do everything we need, so we need
> only one mode. My vote is for tunnel.
We address this issue in (the currently recently-expired, but in update)
draft-touch-ipsec-vpn-01.txt
There is one difference between the two ways of doing tunnel:
1) tunnel mode keys before routing occurs,
requiring sychronization between key databases and
routing databases when dynamic routing is used to
determine keyed path, e.g., for VPNs that use
dynamic routing with IPsec'd virtual links
2) transport mode + IPIP encapsulation routes before keying
this allows VPNs with dynamic routing using
existing routing software
---
Tunnel-mode everywhere means an additional 20-40 bytes of overhead
everywhere as well, as Dan indicates in his later post. Finally,
tunnel mode requires replication of tunneling capability, already
part of multicast and mobile IP.
While we aren't advocating the removal of tunnel mode per se,
our draft describes how transport mode is the more complete and less
costly subset.
Though, as others have indicated, these are wire-protocol issues
rather than IKE (or simpler-IKE) issues.
Joe
From owner-ipsec@lists.tislabs.com Wed Aug 8 02:25:22 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f789PMN28380;
Wed, 8 Aug 2001 02:25:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA15914
Wed, 8 Aug 2001 04:45:43 -0400 (EDT)
From: "Geoffrey Huang" <ghuang@cisco.com>
To: <ipsec@lists.tislabs.com>
Subject: (More) immediate changes to help interop problems?
Date: Wed, 8 Aug 2001 01:57:17 -0700
Message-ID: <HPEELIIJFCBDLBLJNPFIIELACCAA.ghuang@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi there,
So I've seen many messages concerning long-term development for the next
IKE, but what happened to discussion on fixing some shortcomings that
immediately affect interoperability? Andrew K. mentioned a few yesterday
during his presentation, but off the top of my head, I can think of a few
ambiguities:
- Rekeying/Ph. 1 Responder Lifetime
- Unreliable Delete/Notifies
- Optional Cert Request Payload
- Some way to detect dead peers/stale SAs
I'm just thinking of issues in currently deployed scenarios...
-g
From owner-ipsec@lists.tislabs.com Wed Aug 8 02:41:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f789fwN28797;
Wed, 8 Aug 2001 02:41:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15968
Wed, 8 Aug 2001 05:02:55 -0400 (EDT)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B8028A29@hhdata3.cdsemea.baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
Date: Wed, 8 Aug 2001 07:59:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I have to admit I started in the "keep tunnelling - los transport" camp, but
with more experience I would definitely prefer transport mode + IP-in-IP.
This makes gateways and end-to-end cases identical. It also separates
routing issues associated with tunnelling from IPSEC.
I'd also like to see all IPSEC traffic between two hosts carried by just one
SA. I can't see any value in using multiple SAs between to hosts. IPSEC
should be just providing a secure pipe between two hosts - what goes through
it is better regulated by a firewall. There is an argument that you might
want to use different strengths of crypto for performance reasons but there
is generally a focus on performing one type of encryption really well rather
than supporting multiple types.
I'm less keen on AH and would lose it if at all possible. Authenticated ESP
provides authentication, integrity and anti-replay of the IP payload - what
do you care if the IP header has been tampered with? (what is missing from
ESP auth - just the destination IP address?). Per-hop use of SAs currently
appears limited as keys are typically only shared by the end-points.
I would like to see things like null encryption and specific algorithms not
being MUST (or even plaintext bypass). My main reason for this is that you
can reject these by policy anyway but that exclusion from build is required
for products that go through tough security evaluations.
Chris
> From the Schneier and Ferguson analysis we get:
>
> > 1: eliminate transport mode
>
> It would be possible to eliminate tunnel mode instead, and
> just use IP-in-IP
> over transport where required, but it seems simpler to treat
> transport as a
> degenerate tunnel instead. Either mode can do everything we
> need, so we need
> only one mode. My vote is for tunnel.
>
> > 2. eliminate the AH protocol
> > 3. modify ESP to always authenticate; only encryption should be
> optional
>
> Fine by me, but I vaguely recall some arguments that IPv6
> and/or mobile
> IP actually need AH. Could anyone who needs it speak up again?
>
> If it turns out there are really good reasons to keep AH,
> then I'd say the
> simplification is:
>
> 2a: eliminate ESP authentication
> 3a: require AH on all packets. No choice, no null mode. An
> IPsec connection
> authenticates all packets, period.
>
> > 4. modify ESP to ensure it authenticates all data used in
> the deciphering
> of the payload
>
> This is the only recommendation in this paper based on a
> direct security
> flaw, with a proposed attack to demonstrate it. There are
> others in the
> Simpson paper.
>
> I'd say these are the most urgent criticisms, definite entries on the
> requirements list for Son of IKE.
>
> ( By the way did "Ike" Eisenhower have a son, and should we rename the
> protocol? )
>
> > 5. Remove the weak key elimination requirement. ... algorithms that
> have large classes of weak keys ... should simply not be used.
>
> Of these, 1, 2, 3 and 5 are straightforward. Methinks these changes
> should just go straight into the draft text for "Son", unless strong
> objections are raised by this post.
>
> Number 4 is a design task. Volunteers? Is there an existing draft I've
> missed?
>
> Then there are possible simplifications not recommended in
> the Schneier
> and Ferguson paper.
>
> We currently have MUST do main mode, SHOULD do aggressive mode, and
> there's been discussion of a third mode. Could we cut it to one mode?
>
> There are too many optional items.
>
> Can we drop the commit bit?
>
> Can we drop some (or even all?) of the optional notify messages?
> Or perhaps make them required and authenticated, and therefore
> more useful?
>
> PFS is currently optional. Why not require it?
>
> In general, review optional items with the intent of dropping as many
> as possible and making any really useful ones mandatory. This would
> eliminate quite few interoperation problems.
>
> Manually-keyed connections and auto-keyed connections using pre-shared
> keys for authentication are currently required. Could we drop either
> or both, given that public key authentication has serious advantages
> over them? Some discussion of the advantages is at:
> http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/confi
g.html#choose
To do this, we would have to specify support for at least one public
key technique as a MUST. I'd say RSA was the obvious possibility, and
we should have only the one MUST for simplicity.
We should also specify a common format for transfer of public key
information -- preferably by pointing to an existing spec, rather
than re-inventing -- and require everyone to import and export keys
in that format, whatever they choose to use internally. That way two
implementations that need to interoperate can get each others' keys.
For ciphers, we currently have DES and null encryption as the only
MUSTs, although we should all know DES is inadequate. 3DES is a
SHOULD, although it is dreadfully slow compared to either the CAST
and Blowfish generation of ciphers or to AES.
I'd like to see AES as the only MUST, with null encryption and 3DES
as SHOULDs.
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
From owner-ipsec@lists.tislabs.com Wed Aug 8 02:46:30 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f789kTN28875;
Wed, 8 Aug 2001 02:46:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15992
Wed, 8 Aug 2001 05:06:19 -0400 (EDT)
From: Bill Manning <bmanning@ISI.EDU>
Message-Id: <200108080913.f789DNM20119@zed.isi.edu>
Subject: Re: Wes Hardaker: opportunistic encryption deployment problems
To: henry@spsystems.net (Henry Spencer)
Date: Wed, 8 Aug 2001 02:13:23 -0700 (PDT)
Cc: bmanning@ISI.EDU (Bill Manning), hugh@road.xisp.net (Hugh Daniel),
ipsec@lists.tislabs.com,
design@lists.freeswan.org (FreeS/WAN Design Issues)
In-Reply-To: <Pine.BSI.3.91.1010807160811.25170D-100000@spsystems.net> from "Henry Spencer" at Aug 07, 2001 04:12:28 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
%
% On Tue, 7 Aug 2001, Bill Manning wrote:
% > One point. Instead of TXT records for stuffing bits into, there is
% > the CERT record which was designed for just such stuff.
%
% Well, for small values of "designed". :-) CERT itself is fine; the problem
% is that the stuff inside it is X.509, which we have been resisting getting
% involved with.
Not really. CERT can contain a number of different CERT types,
at least that is what I have been told.
% We chose TXT because we simply wanted to convey a gateway address and a
% key, and we wanted to parse it with 10 lines of code, not 10,000.
$DEITY help you when you grab a random TXT record... :)
%
% Henry Spencer
% henry@spsystems.net
%
--
--bill
From owner-ipsec@lists.tislabs.com Wed Aug 8 02:50:33 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f789oXN28942;
Wed, 8 Aug 2001 02:50:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA16044
Wed, 8 Aug 2001 05:11:59 -0400 (EDT)
Message-ID: <3B710406.1175A60@F-Secure.com>
Date: Wed, 08 Aug 2001 12:19:02 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan McDonald <danmcd@East.Sun.COM>
CC: Sandy Harris <sandy@storm.ca>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
References: <200108080219.f782JIp00242@kebe.east.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dan McDonald wrote:
>
> > >From the Schneier and Ferguson analysis we get:
> >
> > > 1: eliminate transport mode
IPsec changes don't simplify IKE, at least not to any extent that
would help anyone, and should not be considered.
> > > 2. eliminate the AH protocol
AH is useless, so yes, although it doesn't really simplify IKE.
> > > 3. modify ESP to always authenticate; only encryption should be
> > optional
I don't care. Our product will refuse to do ESP without authentication in any case.
> > We currently have MUST do main mode, SHOULD do aggressive mode, and
> > there's been discussion of a third mode. Could we cut it to one mode?
>
> That works for me!
>
> > There are too many optional items.
> >
> > Can we drop the commit bit?
>
> Who uses it?
I guess someone in past figured out that running IKE on satellite lines
is necessary, so they decided to optimize as much as possible. The result
was that both aggressive mode and quick mode both have three messages.
The problem with three messages is that the initiator will often start sending
actual traffic too soon, or quick mode packets, before the responder is ready. Thus
the need for packet buffers, commit bit, whatever. This optimization causes design
complications that I'd very much prefer to get rid of.
Thus my preference would be to have a four packet phase 1 (base mode) and
a four packet quick mode.
The other reason I prefer base mode is that the responder can select the
proper policy based on the first packet.
If main mode had the possibility to send a group identity in packet one
and actual identity in packet five, I wouldn't object to just having main mode,
since it does have an even number of packets.
>
> > Can we drop some (or even all?) of the optional notify messages?
> > Or perhaps make them required and authenticated, and therefore
> > more useful?
>
> Hear hear!
It would be good to specify exactly when they are to be sent.
>
> > PFS is currently optional. Why not require it?
>
> Agreed.
It's useless, so it should be thrown out. Just reduce phase 1 lifetime
or use a larger DH/elliptic group in phase 1.
And specify re-keying exactly.
>
> > Manually-keyed connections and auto-keyed connections using pre-shared
> > keys for authentication are currently required. Could we drop either
> > or both, given that public key authentication has serious advantages
> > over them? Some discussion of the advantages is at:
> > http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/config.html#choose
>
> Strongly disagree on manual keying. Many outfits use "keying by {Marine
> guard, bodybuilder, steganography}". Also a manual keying interface can
> allow better automated KM systems to be built (Shameless plug: RFC 2367).
Manual keying is useless. Preshared keying is useful in some cases.
Ari
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Integrated Solutions for Enterprise Security
From owner-ipsec@lists.tislabs.com Wed Aug 8 03:24:18 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78AOHN02156;
Wed, 8 Aug 2001 03:24:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA16174
Wed, 8 Aug 2001 05:39:56 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010808104236.01e5c210@localhost>
X-Sender: rgm-sec@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 08 Aug 2001 10:44:31 +0100
To: Bill Manning <bmanning@ISI.EDU>, henry@spsystems.net (Henry Spencer)
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: Wes Hardaker: opportunistic encryption deployment problems
Cc: bmanning@ISI.EDU (Bill Manning), hugh@road.xisp.net (Hugh Daniel),
ipsec@lists.tislabs.com,
design@lists.freeswan.org (FreeS/WAN Design Issues)
In-Reply-To: <200108080913.f789DNM20119@zed.isi.edu>
References: <Pine.BSI.3.91.1010807160811.25170D-100000@spsystems.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 02:13 AM 8/8/2001 -0700, Bill Manning wrote:
>% We chose TXT because we simply wanted to convey a gateway address and a
>% key, and we wanted to parse it with 10 lines of code, not 10,000.
>
> $DEITY help you when you grab a random TXT record... :)
What about the OPT record?
RFC 2671
Then you get IANA to assign an OPT attribute.
But clearly, check out CERT first.
Robert Moskowitz
ICSA
Security Interest EMail: rgm-sec@htt-consult.com
From owner-ipsec@lists.tislabs.com Wed Aug 8 04:25:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78BP3N06695;
Wed, 8 Aug 2001 04:25:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA16402
Wed, 8 Aug 2001 06:43:38 -0400 (EDT)
Date: Wed, 8 Aug 2001 06:50:26 -0400
From: Theodore Tso <tytso@mit.edu>
To: ipsec@lists.tislabs.com, saag@mit.edu
Subject: NIST Modes of Operation Papers On-Line
Message-ID: <20010808065026.B7491@thunk.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
The papers for the upcoming NIST Modes of Operation workshop are now available.
Folks who are interested in new modes for AES may find this of interest.
- Ted
--
--vkogqOf2sHV7VnPd
Content-Type: message/rfc822
Content-Disposition: inline
>From tytso Tue Aug 7 16:14:01 2001
Return-Path: <owner-extdom.iscsi-security@sj-msg-core-3.cisco.com>
Received: from po14.mit.edu [18.7.21.72]
by localhost with IMAP (fetchmail-5.8.14)
for tytso@localhost (single-drop); Tue, 07 Aug 2001 16:14:01 -0400 (EDT)
Received: from fort-point-station.mit.edu by po14.mit.edu (8.9.2/4.7) id NAA14890; Tue, 7 Aug 2001 13:02:35 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA25488
for <tytso@mit.edu>; Tue, 7 Aug 2001 13:02:35 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f77GoiJ27798
for <iscsi-security@external.cisco.com>; Tue, 7 Aug 2001 09:51:07 -0700 (PDT)
Received: from proxy1.cisco.com (localhost [127.0.0.1])
by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f77Gqec06958
for <iscsi-security@external.cisco.com>; Tue, 7 Aug 2001 09:52:41 -0700 (PDT)
Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38])
by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f77GqEr12035
for <iscsi-security@external.cisco.com>; Tue, 7 Aug 2001 09:52:14 -0700 (PDT)
Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom
MMS-3 SMTP Relay (MMS v4.7)); Tue, 07 Aug 2001 09:48:52 -0700
X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5
Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com
[10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
id JAA06811 for <iscsi-security@external.cisco.com>; Tue, 7 Aug 2001
09:48:58 -0700 (PDT)
Received: from ltjtardo (dhcpe2-sj1-067 [10.16.75.67]) by
mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id JAA15684 for
<iscsi-security@external.cisco.com>; Tue, 7 Aug 2001 09:48:58 -0700 (
PDT)
From: "Joseph Tardo" <jtardo@broadcom.com>
To: iscsi-security@external.cisco.com
Subject: NIST Modes of Operation Papers On-Line
Date: Tue, 7 Aug 2001 09:48:57 -0700
Message-ID: <NDBBJJDNOJJEFGHAECHIOEJFDCAA.jtardo@broadcom.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <F66A04C29AD9034A8205949AD0C90104D57922@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
X-WSS-ID: 176EC47E36034-01-01
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Bernard:
Here is the URL.
--Joe
http://csrc.nist.gov/encryption/modes/proposedmodes/index.html
--vkogqOf2sHV7VnPd--
From owner-ipsec@lists.tislabs.com Wed Aug 8 05:33:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78CX2N12380;
Wed, 8 Aug 2001 05:33:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16534
Wed, 8 Aug 2001 07:45:19 -0400 (EDT)
Date: Wed, 8 Aug 2001 07:51:45 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
cc: Bill Manning <bmanning@ISI.EDU>, Hugh Daniel <hugh@road.xisp.net>,
ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
In-Reply-To: <5.1.0.14.2.20010808104236.01e5c210@localhost>
Message-ID: <Pine.BSI.3.91.1010808074913.9901A-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 8 Aug 2001, Robert Moskowitz wrote:
> What about the OPT record?
> RFC 2671
OPT is not really intended to go in a DNS database at all -- it's a way
of sneaking extensibility into DNS's poorly-designed protocol.
Moreover, RFC 2671 specifically forbids caching it.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Wed Aug 8 05:37:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78Cb8N12450;
Wed, 8 Aug 2001 05:37:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16589
Wed, 8 Aug 2001 07:54:14 -0400 (EDT)
Date: Wed, 8 Aug 2001 14:01:59 +0200 (Israel Standard Time)
From: Arne Ansper <arne@ats.cyber.ee>
To: Chris Trobridge <CTrobridge@baltimore.com>
cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
In-Reply-To: <F86F34FDF1F9D411B7A40008C74C27B8028A29@hhdata3.cdsemea.baltimore.com>
Message-ID: <Pine.WNT.4.33.0108081351570.172-100000@viluvere.itsise>
X-X-Sender: arne@kiku.itsise
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-info: Headers changed by Barricade
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> I'd also like to see all IPSEC traffic between two hosts carried by just one
> SA. I can't see any value in using multiple SAs between to hosts. IPSEC
there is. and it's not related to security at all.
suppose you have slow internet connection that is used only for VPN
traffic. your access router has no way to distinguish between different
sessions inside your VPN so it will put all the packets into same queue.
if somebody is moving large file using ftp your telnet connection will be
very very slow.
without encryption the routers will put packets from separate sessions
(defined by src&dst IP, protocol and ports) into seprate queues (cisco
calls them classes IIRC) and even if you are downloading some huge file
your telnet session is still usable.
with encryption the SPI is the only parameter that can be used to classify
the packets. if you are using a single SA between two hosts it's
impossible for routers to distinguish between packets from different
sessions and the interactive applications suffer really bad.
arne
From owner-ipsec@lists.tislabs.com Wed Aug 8 05:38:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78CcrN12502;
Wed, 8 Aug 2001 05:38:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16614
Wed, 8 Aug 2001 08:01:05 -0400 (EDT)
From: Steve.Robinson@psti.com
Subject: Re: Simplifying IKE
To: Sandy Harris <sandy@storm.ca>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
Message-ID: <OFF3221DFC.55F00D4A-ON80256AA2.003F5E91@psti.com>
Date: Wed, 8 Aug 2001 08:12:19 -0400
X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at
08/08/2001 01:12:55 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
A few comments:
2a: eliminate ESP authentication
3a: require AH on all packets. No choice, no null mode. An IPsec connection
authenticates all packets, period.
4. modify ESP to ensure it authenticates all data used in the deciphering
of the payload
STEVE: One of the fundamental goals of the Ferguson and Schneider paper
was to see the simplification of IPsec. I think that unless justification
can be found by the IPv6/mobile camp, we should push forward to eliminate
AH altogether and not try to come up with compromise solutions.
Also, I think that there is going to be a LOT of resistance to making any
modifications to ESP. Look at the chaos that is the IKE group. I've
followed this thread in amazement, watching it degenerate and wondering if
anything remotely useful will come of the constant bickering. Attempting
to make any modifications to ESP, no matter how small or trivial, will
probably cause a similar nonproductive uproar. Perhaps the better idea is
to scrap the name ESP and move ahead with a new alternative with a new
protocol number that we could call the IP Authenticating, Encapsulating
Packet Security (AEPS -- or something like that, just different from ESP).
This alternative would take ESP and alter it, so that IP header compression
can be added, and the tail section (padding, authentication data and all)
can be moved to the AEPS header to make implementing it that much easier.
This would allow vendors, during a transition period, to be backwards
compatible with existing IPsec implementations that support ESP as is,
while still moving forward with the new standard.
I'd also propose that we allow the diehard faction that says IPsec MUST be
completely backwards compatible to have their way. When negotiating an SA,
simply do not allow the negotiation of AH, or transport mode in any future
implementations. Eventually, the standard will move towards what people are
doing and eventually, the simplified model, with only AEPS will become the
standard and AH and ESP can be obsoleted (well, it would be nice if this
would work, I can dream, can't I? ;-).
To do this, we would have to specify support for at least one public
key technique as a MUST. I'd say RSA was the obvious possibility, and
we should have only the one MUST for simplicity.
STEVE: I agree with you on this, but in practice, unless a PKI standard is
settled on, my boss is not going to approve of me implementing a
proprietary solution unless a consensus is reached in the IPsec community
first. My gut feeling is that it isn't gonna happen unless the work at the
NIST on PKI suddenly becomes accepted as a standard.
I'd like to see AES as the only MUST, with null encryption and 3DES
as SHOULDs.
STEVE: I'd like this as well, but AES in what modes and key sizes/block
rounds? What makes the most sense in the networking environment that we
are working in? Is there any work currently being done to study what
mode/key size/block size combinations are cryptographically sound, but
degrade performance the least?
From owner-ipsec@lists.tislabs.com Wed Aug 8 05:44:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78CieN13335;
Wed, 8 Aug 2001 05:44:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16671
Wed, 8 Aug 2001 08:10:10 -0400 (EDT)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B8028A30@hhdata3.cdsemea.baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: Arne Ansper <arne@ats.cyber.ee>
Cc: ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
Date: Wed, 8 Aug 2001 13:13:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
There is always TOS. Packet length, even?
How can you use the SPI to sort traffic? This assumes the access router
knows which SPI corresponds to which traffic.
Actually classifying traffic after applying ESP is a major hasssle for ISPs.
OTOH, they don't often understand the security consequences of leaking the
sort of info classification uses - which is often into the application
layer!
Chris
> > I'd also like to see all IPSEC traffic between two hosts
> carried by just one
> > SA. I can't see any value in using multiple SAs between to
> hosts. IPSEC
>
> there is. and it's not related to security at all.
>
> suppose you have slow internet connection that is used only for VPN
> traffic. your access router has no way to distinguish between
> different
> sessions inside your VPN so it will put all the packets into
> same queue.
> if somebody is moving large file using ftp your telnet
> connection will be
> very very slow.
>
> without encryption the routers will put packets from separate sessions
> (defined by src&dst IP, protocol and ports) into seprate queues (cisco
> calls them classes IIRC) and even if you are downloading some
> huge file
> your telnet session is still usable.
>
> with encryption the SPI is the only parameter that can be
> used to classify
> the packets. if you are using a single SA between two hosts it's
> impossible for routers to distinguish between packets from different
> sessions and the interactive applications suffer really bad.
>
> arne
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
From owner-ipsec@lists.tislabs.com Wed Aug 8 06:15:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78DFmN14140;
Wed, 8 Aug 2001 06:15:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16755
Wed, 8 Aug 2001 08:34:15 -0400 (EDT)
Message-ID: <005701c12008$11168400$4e8d21d9@sfanninglaptop>
From: "Scott Fanning" <sfanning@cisco.com>
To: "Geoffrey Huang" <ghuang@cisco.com>, <ipsec@lists.tislabs.com>
References: <HPEELIIJFCBDLBLJNPFIIELACCAA.ghuang@cisco.com>
Subject: Re: (More) immediate changes to help interop problems?
Date: Wed, 8 Aug 2001 05:45:53 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I agree. I also would like to see the commit bit gone (not many people
support it anyway, nor do it right).
I think the fact we still have bakeoffs to test IKE interop, tells us that
we need to simplify what we have.
At one IETF, I was sure I heard a call and a straw vote for IKE reved to V2,
with the new hash, and additional changes. I would like to fix those things
we can fix now, allowing current users to continue to use IKE, while we
debate a new, and improved key exchange,
My 2 cents
Scott
----- Original Message -----
From: "Geoffrey Huang" <ghuang@cisco.com>
To: <ipsec@lists.tislabs.com>
Sent: Wednesday, August 08, 2001 1:57 AM
Subject: (More) immediate changes to help interop problems?
> Hi there,
>
> So I've seen many messages concerning long-term development for the next
> IKE, but what happened to discussion on fixing some shortcomings that
> immediately affect interoperability? Andrew K. mentioned a few yesterday
> during his presentation, but off the top of my head, I can think of a few
> ambiguities:
>
> - Rekeying/Ph. 1 Responder Lifetime
> - Unreliable Delete/Notifies
> - Optional Cert Request Payload
> - Some way to detect dead peers/stale SAs
>
> I'm just thinking of issues in currently deployed scenarios...
>
> -g
>
From owner-ipsec@lists.tislabs.com Wed Aug 8 06:40:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78DeoN14663;
Wed, 8 Aug 2001 06:40:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16834
Wed, 8 Aug 2001 08:52:50 -0400 (EDT)
Message-ID: <3B7136EA.A8B1AE7C@isi.edu>
Date: Wed, 08 Aug 2001 05:56:10 -0700
From: Joe Touch <touch@ISI.EDU>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve.Robinson@psti.com
CC: Sandy Harris <sandy@storm.ca>, ipsec@lists.tislabs.com,
owner-ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
References: <OFF3221DFC.55F00D4A-ON80256AA2.003F5E91@psti.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Steve.Robinson@psti.com wrote:
>
> A few comments:
>
> 2a: eliminate ESP authentication
> 3a: require AH on all packets. No choice, no null mode. An IPsec connection
> authenticates all packets, period.
Null mode is useful, if only for debugging and performance measurement.
Jor
From owner-ipsec@lists.tislabs.com Wed Aug 8 06:46:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78DkbN14816;
Wed, 8 Aug 2001 06:46:37 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16780
Wed, 8 Aug 2001 08:41:54 -0400 (EDT)
Message-Id: <200108081248.f78CmLu72505@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Dan McDonald <danmcd@East.Sun.COM>
cc: Sandy Harris <sandy@storm.ca>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of Tue, 07 Aug 2001 22:19:18 EDT.
<200108080219.f782JIp00242@kebe.east.sun.com>
Date: Wed, 08 Aug 2001 14:48:21 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
> 2a: eliminate ESP authentication
> 3a: require AH on all packets. No choice, no null mode. An IPsec
> connection authenticates all packets, period.
Choice 3a was the original intent of the SIPP security architecture (which
became the 182x series of IPsec RFCs)....
The biggest motivator behind AH was to allow an authenticated source route.
Now as Steve Bellovin has pointed out, unless you can configure a hop-by-hop
key, the middle can send that packet anywhere it wants before it reaches the
end.
I wish there were some ISP/ops types on this list (maybe there are and I'm
just being an airhead). I believe the source route header is primarily used
to see what paths are broken in a network - using the process of elimination.
Using AH (or ESP authentication) insures that the packet came from where it
claims to have come from. THAT is why AH was developed, but ESP
authentication can provide a source-routed packet with similar properties.
=> (about the last statement) how? ESP authentication doesn't cover headers.
Regards
Francis.Dupont@enst-bretagne.fr
PS: I am not in favor to reduce IPsec to VPNs, the thing which will happen
if we remove AH then transport mode...
From owner-ipsec@lists.tislabs.com Wed Aug 8 06:51:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78DpmN14920;
Wed, 8 Aug 2001 06:51:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16880
Wed, 8 Aug 2001 09:09:27 -0400 (EDT)
Message-Id: <200108072105.f77L5dV29951@coredump.cis.upenn.edu>
To: Mike Ditto <ford@apollo.incog.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Phase 1 IDs ("son of IKE")
In-reply-to: Your message of "Tue, 07 Aug 2001 14:07:37 PDT."
<200108072107.OAA10431@potomac.incog.com>
Date: Tue, 07 Aug 2001 17:05:39 -0400
From: "Angelos D. Keromytis" <angelos@cis.upenn.edu>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <200108072107.OAA10431@potomac.incog.com>, Mike Ditto writes:
>
>I don't think it's more complicated. Instead of saying "the responder
>must ignore the hint or use it as the value of the subsequent IDir
>payload," you say "the responder may use the hint in an
>implementation-defined way to influence its selection of its own
>identity."
Oh, I see. That'd be fine.
-Angelos
From owner-ipsec@lists.tislabs.com Wed Aug 8 07:02:56 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78E2tN15248;
Wed, 8 Aug 2001 07:02:55 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16929
Wed, 8 Aug 2001 09:12:28 -0400 (EDT)
Message-ID: <CCFF88268143CC4181A758DCC0ECDC13DE7772@posthaus.virtela.cc>
From: "Horn, Mike" <mhorn@virtela.net>
To: "'Derek Atkins'" <warlord@mit.edu>
Cc: ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
Date: Tue, 7 Aug 2001 17:19:11 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Derek,
Want to keep this friendly, but obviously I don't agree with your points.
You have a vested interest in KINK, I have a vested interest in IPsec VPNs.
This influences both of our views. I noticed you didn't respond to my
question about AH...
>
> First, all the world is not VPN.
see above.
> Second, there are alternate keying protocols (KINK, for example)
Has KINK produced any _standards_ other than the requirements (RFC 3129)?
How many IPsec vendors currently offer production support for KINK?
> Third, trying to move IKE to IP_PROTO 50 would not only be WRONG,
> it would also be HARD
I am not saying that IKE should be moved to IP_PROTO 50. If you read my
email, "Again, I'm simply stating that **IF** IKE is replaced by something
else, the WG should consider using the IPsec ESP protocol number." I agree
that moving existing implementations of IKE to 50 would be HARD (you don't
explain why it would be wrong).
> Fourth, moving IKE to IP_PROTO 50 would make NAT traversal EVEN HARDER
> than it already is.
Need to think about this further. One of the proposed solutions is to use
UDP encapsulation, but this is based on the fact that *currently* IPsec
typically uses IKE on port 500 and ESP on protocol 50. If the IPsec
architecture were changed other solutions might offer themselves. How does
KINK propose to solve NAT traversal?
>
> You clearly don't understand the problems.
Everyone has a right to their own opinions, even the clueless...
>
> -derek
>
> "Horn, Mike" <mhorn@virtela.net> writes:
>
> > First, my only goal for being involved in this thread is
> that I think from
> > an operational standpoint the current state of IKE/IPsec is
> broken. There
> > are a LOT of features that have been added by various vendors in a
> > proprietary fashion to address these shortcomings. I think
> that the whole
> > VPN user community would benefit if the WG could come to
> some agreement and
> > produce a protocol (or set of protocols) to address the VPN
> user communities
> > needs.
> >
> > That being said, I thought there was general consensus that
> AH has not
> > proven to be useful, so I didn't include it in my original
> email. If you
> > know of _any_ service provider that is using AH for
> customer VPN's I would
> > be interested to hear who. Again, I'm simply stating that IF IKE is
> > replaced by something else, the WG should consider using
> the IPsec ESP
> > protocol number.
> >
> > I agree Jan's point that all IPsec requires is keys. Right
> now, the only
> > thing to my knowledge that is standardized for automated
> key exchange for
> > use by IPsec is IKE. If that is not fixable to meet the
> communities stated
> > requirements, then something new needs to be developed to
> fill this gap.
> >
> > I think that the lack of standardization for things like user
> > authentication, has definitely impacted the user
> community's acceptance of
> > IPsec.
> >
> > Mike Horn
> >
> >
> >
> > > -----Original Message-----
> > > From: Derek Atkins [mailto:warlord@MIT.EDU]
> > > Sent: Tuesday, August 07, 2001 4:31 PM
> > > To: Horn, Mike
> > > Cc: ipsec@lists.tislabs.com
> > > Subject: Re: IKE must have no Heirs
> > >
> > >
> > > Note the 'ipsec' has TWO protocol numbers... One for ESP
> and one for
> > > AH. What do _YOU_ mean?
> > >
> > > -derek
> > >
> > > "Horn, Mike" <mhorn@virtela.net> writes:
> > >
> > > > Again speaking from service provider experience, manual
> > > keys are not a
> > > > scalable option. Some sort of key exchange protocol is
> > > definitely required,
> > > > right now that means IKE. As for using a single IP
> > > protocol number for both
> > > > IKE and IPsec, I was merely stating this would reduce
> the number of
> > > > ports/protocols I have to request firewall administrators
> > > to allow. From an
> > > > operational perspective, dealing with IPsec devices behind
> > > firewalls can be
> > > > very painful. I will let this thread die, since the IPSEC
> > > and IPSRA working
> > > > groups face much bigger challenges then determining if IKE
> > > and IPsec should
> > > > share a protocol number.
> > > >
> > > > Mike Horn
> > > >
> > > > > -----Original Message-----
> > > > > From: Derek Atkins [mailto:warlord@MIT.EDU]
> > > > > Sent: Tuesday, August 07, 2001 3:30 PM
> > > > > To: Horn, Mike
> > > > > Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com
> > > > > Subject: Re: IKE must have no Heirs
> > > > >
> > > > >
> > > > > There is no IPsec (ESP/AH) dependency on IKE. You can
> > > key manually
> > > > > (which does not use IKE). There is the KINK work, is
> > > different than
> > > > > IKE.
> > > > >
> > > > > There is no reason to turn IKE into it's own IP
> Protocol. Using
> > > > > UDP/500 works just fine, and making it's own protocol
> > > wont accomplish
> > > > > anything.
> > > > >
> > > > > -derek
> > > > >
> > > > > "Horn, Mike" <mhorn@virtela.net> writes:
> > > > >
> > > > > > Actually that is a poor example, there is no built-in
> > > > > protocol dependency
> > > > > > for BGP to use OSPF. And BGP does use TCP (port 179) for
> > > > > communication vs.
> > > > > > OSPF using a protocol number (89). IPsec currently has a
> > > > > strong dependency
> > > > > > on IKE. I do agree that from a network administration
> > > and debugging
> > > > > > standpoint it would be nice if both IPsec and IKE shared a
> > > > > common protocol
> > > > > > number. This would help to simplify firewall
> > > configurations, etc.
> > > > > >
> > > > > > Mike Horn
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Alex Alten [mailto:Alten@home.com]
> > > > > > > Sent: Tuesday, August 07, 2001 3:06 AM
> > > > > > > To: Chris Trobridge
> > > > > > > Cc: ipsec@lists.tislabs.com
> > > > > > > Subject: RE: IKE must have no Heirs
> > > > > > >
> > > > > > >
> > > > > > > Think about it. Do you do OSPF over IP and then BGP
> > > over UDP?
> > > > > > > The same applies to IPSEC and key management.
> > > > > > >
> > > > > > > - Alex
> > > > > > >
> > > > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >> -----Original Message-----
> > > > > > > >> From: Alex Alten [mailto:Alten@home.com]
> > > > > > > >> Sent: 07 August 2001 08:28
> > > > > > > >> To: Kory Hamzeh; Hallam-Baker, Phillip
> > > > > > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> > > > > > > >> Subject: Re: IKE must have no Heirs
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> I second the motion. And also propose no port
> > > number (i.e.
> > > > > > > do the new
> > > > > > > >> one over raw IP).
> > > > > > > >>
> > > > > > > >> - Alex
> > > > > > > >
> > > > > > > >What would that achieve? (communicating over raw IP)
> > > > > > > >
> > > > > > > >Chris
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > >-------------------------------------------------------------
> > > > > > > --------------
> > > > > > > --------------------------------------
> > > > > > > >The information contained in this message is
> confidential
> > > > > > > and is intended
> > > > > > > >for the addressee(s) only. If you have received this
> > > > > > > message in error or
> > > > > > > >there are any problems please notify the originator
> > > > > > > immediately. The
> > > > > > > >unauthorized use, disclosure, copying or
> alteration of this
> > > > > > > message is
> > > > > > > >strictly forbidden. Baltimore Technologies plc will not
> > > > > be liable for
> > > > > > > direct,
> > > > > > > >special, indirect or consequential damages arising from
> > > > > > > alteration of the
> > > > > > > >contents of this message by a third party or as
> a result of
> > > > > > > any virus being
> > > > > > > >passed on.
> > > > > > > >
> > > > > > > >In addition, certain Marketing collateral may
> be added from
> > > > > > > time to time to
> > > > > > > >promote Baltimore Technologies products,
> services, Global
> > > > > > > e-Security or
> > > > > > > >appearance at trade shows and conferences.
> > > > > > > >
> > > > > > > >This footnote confirms that this email message has been
> > > > > swept by
> > > > > > > >Baltimore MIMEsweeper for Content Security threats,
> > > including
> > > > > > > >computer viruses.
> > > > > > > >
> > > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Alex Alten
> > > > > > >
> > > > > > > Alten@Home.Com
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media
> Laboratory
> > > > > Member, MIT Student Information Processing
> Board (SIPB)
> > > > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA
> N1NWH
> > > > > warlord@MIT.EDU PGP key
> available
> > > > >
> > >
> > > --
> > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > > Member, MIT Student Information Processing Board (SIPB)
> > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> > > warlord@MIT.EDU PGP key available
> > >
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
>
From owner-ipsec@lists.tislabs.com Wed Aug 8 07:15:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78EFGN15561;
Wed, 8 Aug 2001 07:15:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16899
Wed, 8 Aug 2001 09:10:28 -0400 (EDT)
Message-ID: <CCFF88268143CC4181A758DCC0ECDC13DE776E@posthaus.virtela.cc>
From: "Horn, Mike" <mhorn@virtela.net>
To: "'Derek Atkins'" <warlord@mit.edu>
Cc: ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
Date: Tue, 7 Aug 2001 16:48:00 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
First, my only goal for being involved in this thread is that I think from
an operational standpoint the current state of IKE/IPsec is broken. There
are a LOT of features that have been added by various vendors in a
proprietary fashion to address these shortcomings. I think that the whole
VPN user community would benefit if the WG could come to some agreement and
produce a protocol (or set of protocols) to address the VPN user communities
needs.
That being said, I thought there was general consensus that AH has not
proven to be useful, so I didn't include it in my original email. If you
know of _any_ service provider that is using AH for customer VPN's I would
be interested to hear who. Again, I'm simply stating that IF IKE is
replaced by something else, the WG should consider using the IPsec ESP
protocol number.
I agree Jan's point that all IPsec requires is keys. Right now, the only
thing to my knowledge that is standardized for automated key exchange for
use by IPsec is IKE. If that is not fixable to meet the communities stated
requirements, then something new needs to be developed to fill this gap.
I think that the lack of standardization for things like user
authentication, has definitely impacted the user community's acceptance of
IPsec.
Mike Horn
> -----Original Message-----
> From: Derek Atkins [mailto:warlord@MIT.EDU]
> Sent: Tuesday, August 07, 2001 4:31 PM
> To: Horn, Mike
> Cc: ipsec@lists.tislabs.com
> Subject: Re: IKE must have no Heirs
>
>
> Note the 'ipsec' has TWO protocol numbers... One for ESP and one for
> AH. What do _YOU_ mean?
>
> -derek
>
> "Horn, Mike" <mhorn@virtela.net> writes:
>
> > Again speaking from service provider experience, manual
> keys are not a
> > scalable option. Some sort of key exchange protocol is
> definitely required,
> > right now that means IKE. As for using a single IP
> protocol number for both
> > IKE and IPsec, I was merely stating this would reduce the number of
> > ports/protocols I have to request firewall administrators
> to allow. From an
> > operational perspective, dealing with IPsec devices behind
> firewalls can be
> > very painful. I will let this thread die, since the IPSEC
> and IPSRA working
> > groups face much bigger challenges then determining if IKE
> and IPsec should
> > share a protocol number.
> >
> > Mike Horn
> >
> > > -----Original Message-----
> > > From: Derek Atkins [mailto:warlord@MIT.EDU]
> > > Sent: Tuesday, August 07, 2001 3:30 PM
> > > To: Horn, Mike
> > > Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com
> > > Subject: Re: IKE must have no Heirs
> > >
> > >
> > > There is no IPsec (ESP/AH) dependency on IKE. You can
> key manually
> > > (which does not use IKE). There is the KINK work, is
> different than
> > > IKE.
> > >
> > > There is no reason to turn IKE into it's own IP Protocol. Using
> > > UDP/500 works just fine, and making it's own protocol
> wont accomplish
> > > anything.
> > >
> > > -derek
> > >
> > > "Horn, Mike" <mhorn@virtela.net> writes:
> > >
> > > > Actually that is a poor example, there is no built-in
> > > protocol dependency
> > > > for BGP to use OSPF. And BGP does use TCP (port 179) for
> > > communication vs.
> > > > OSPF using a protocol number (89). IPsec currently has a
> > > strong dependency
> > > > on IKE. I do agree that from a network administration
> and debugging
> > > > standpoint it would be nice if both IPsec and IKE shared a
> > > common protocol
> > > > number. This would help to simplify firewall
> configurations, etc.
> > > >
> > > > Mike Horn
> > > >
> > > > > -----Original Message-----
> > > > > From: Alex Alten [mailto:Alten@home.com]
> > > > > Sent: Tuesday, August 07, 2001 3:06 AM
> > > > > To: Chris Trobridge
> > > > > Cc: ipsec@lists.tislabs.com
> > > > > Subject: RE: IKE must have no Heirs
> > > > >
> > > > >
> > > > > Think about it. Do you do OSPF over IP and then BGP
> over UDP?
> > > > > The same applies to IPSEC and key management.
> > > > >
> > > > > - Alex
> > > > >
> > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: Alex Alten [mailto:Alten@home.com]
> > > > > >> Sent: 07 August 2001 08:28
> > > > > >> To: Kory Hamzeh; Hallam-Baker, Phillip
> > > > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> > > > > >> Subject: Re: IKE must have no Heirs
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> I second the motion. And also propose no port
> number (i.e.
> > > > > do the new
> > > > > >> one over raw IP).
> > > > > >>
> > > > > >> - Alex
> > > > > >
> > > > > >What would that achieve? (communicating over raw IP)
> > > > > >
> > > > > >Chris
> > > > > >
> > > > > >
> > > > >
> >-------------------------------------------------------------
> > > > > --------------
> > > > > --------------------------------------
> > > > > >The information contained in this message is confidential
> > > > > and is intended
> > > > > >for the addressee(s) only. If you have received this
> > > > > message in error or
> > > > > >there are any problems please notify the originator
> > > > > immediately. The
> > > > > >unauthorized use, disclosure, copying or alteration of this
> > > > > message is
> > > > > >strictly forbidden. Baltimore Technologies plc will not
> > > be liable for
> > > > > direct,
> > > > > >special, indirect or consequential damages arising from
> > > > > alteration of the
> > > > > >contents of this message by a third party or as a result of
> > > > > any virus being
> > > > > >passed on.
> > > > > >
> > > > > >In addition, certain Marketing collateral may be added from
> > > > > time to time to
> > > > > >promote Baltimore Technologies products, services, Global
> > > > > e-Security or
> > > > > >appearance at trade shows and conferences.
> > > > > >
> > > > > >This footnote confirms that this email message has been
> > > swept by
> > > > > >Baltimore MIMEsweeper for Content Security threats,
> including
> > > > > >computer viruses.
> > > > > >
> > > > > >
> > > > > --
> > > > >
> > > > > Alex Alten
> > > > >
> > > > > Alten@Home.Com
> > > > >
> > > > >
> > > >
> > >
> > > --
> > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > > Member, MIT Student Information Processing Board (SIPB)
> > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> > > warlord@MIT.EDU PGP key available
> > >
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
>
From owner-ipsec@lists.tislabs.com Wed Aug 8 07:18:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78EIKN15654;
Wed, 8 Aug 2001 07:18:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17042
Wed, 8 Aug 2001 09:30:44 -0400 (EDT)
Message-ID: <3B713FC8.8AF53557@isi.edu>
Date: Wed, 08 Aug 2001 06:34:00 -0700
From: Joe Touch <touch@ISI.EDU>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve.Robinson@psti.com
CC: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com,
Sandy Harris <sandy@storm.ca>
Subject: Re: Simplifying IKE
References: <OF11BDFF1E.43F6E6B0-ON80256AA2.004A92C1@psti.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Steve.Robinson@psti.com wrote:
>
> Hi Joe,
>
> Please look a little closer, all my comments are prefaced by "STEVE:"
Apologies for my misattribution.
> I have no problems
> with including NULL mode, but what I don't want to see is a situation where
> we are using ESP for one thing on a packet and AH for another, simply for
> what I perceive as political reasons. I'd much prefer to use a single
> protocol and simplify our efforts.
A simpler protocol would be great. I would like to retain NULL mode for
any particular component, though, in the design. Limtations in how they
are used for real data can be enforced in the attribute sets exchanged.
Joe
From owner-ipsec@lists.tislabs.com Wed Aug 8 07:27:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78ERTN15842;
Wed, 8 Aug 2001 07:27:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16898
Wed, 8 Aug 2001 09:10:28 -0400 (EDT)
Message-ID: <CCFF88268143CC4181A758DCC0ECDC13DE7764@posthaus.virtela.cc>
From: "Horn, Mike" <mhorn@virtela.net>
To: "'Derek Atkins'" <warlord@mit.edu>
Cc: ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
Date: Tue, 7 Aug 2001 15:42:48 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Again speaking from service provider experience, manual keys are not a
scalable option. Some sort of key exchange protocol is definitely required,
right now that means IKE. As for using a single IP protocol number for both
IKE and IPsec, I was merely stating this would reduce the number of
ports/protocols I have to request firewall administrators to allow. From an
operational perspective, dealing with IPsec devices behind firewalls can be
very painful. I will let this thread die, since the IPSEC and IPSRA working
groups face much bigger challenges then determining if IKE and IPsec should
share a protocol number.
Mike Horn
> -----Original Message-----
> From: Derek Atkins [mailto:warlord@MIT.EDU]
> Sent: Tuesday, August 07, 2001 3:30 PM
> To: Horn, Mike
> Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com
> Subject: Re: IKE must have no Heirs
>
>
> There is no IPsec (ESP/AH) dependency on IKE. You can key manually
> (which does not use IKE). There is the KINK work, is different than
> IKE.
>
> There is no reason to turn IKE into it's own IP Protocol. Using
> UDP/500 works just fine, and making it's own protocol wont accomplish
> anything.
>
> -derek
>
> "Horn, Mike" <mhorn@virtela.net> writes:
>
> > Actually that is a poor example, there is no built-in
> protocol dependency
> > for BGP to use OSPF. And BGP does use TCP (port 179) for
> communication vs.
> > OSPF using a protocol number (89). IPsec currently has a
> strong dependency
> > on IKE. I do agree that from a network administration and debugging
> > standpoint it would be nice if both IPsec and IKE shared a
> common protocol
> > number. This would help to simplify firewall configurations, etc.
> >
> > Mike Horn
> >
> > > -----Original Message-----
> > > From: Alex Alten [mailto:Alten@home.com]
> > > Sent: Tuesday, August 07, 2001 3:06 AM
> > > To: Chris Trobridge
> > > Cc: ipsec@lists.tislabs.com
> > > Subject: RE: IKE must have no Heirs
> > >
> > >
> > > Think about it. Do you do OSPF over IP and then BGP over UDP?
> > > The same applies to IPSEC and key management.
> > >
> > > - Alex
> > >
> > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Alex Alten [mailto:Alten@home.com]
> > > >> Sent: 07 August 2001 08:28
> > > >> To: Kory Hamzeh; Hallam-Baker, Phillip
> > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> > > >> Subject: Re: IKE must have no Heirs
> > > >>
> > > >>
> > > >>
> > > >> I second the motion. And also propose no port number (i.e.
> > > do the new
> > > >> one over raw IP).
> > > >>
> > > >> - Alex
> > > >
> > > >What would that achieve? (communicating over raw IP)
> > > >
> > > >Chris
> > > >
> > > >
> > > >-------------------------------------------------------------
> > > --------------
> > > --------------------------------------
> > > >The information contained in this message is confidential
> > > and is intended
> > > >for the addressee(s) only. If you have received this
> > > message in error or
> > > >there are any problems please notify the originator
> > > immediately. The
> > > >unauthorized use, disclosure, copying or alteration of this
> > > message is
> > > >strictly forbidden. Baltimore Technologies plc will not
> be liable for
> > > direct,
> > > >special, indirect or consequential damages arising from
> > > alteration of the
> > > >contents of this message by a third party or as a result of
> > > any virus being
> > > >passed on.
> > > >
> > > >In addition, certain Marketing collateral may be added from
> > > time to time to
> > > >promote Baltimore Technologies products, services, Global
> > > e-Security or
> > > >appearance at trade shows and conferences.
> > > >
> > > >This footnote confirms that this email message has been
> swept by
> > > >Baltimore MIMEsweeper for Content Security threats, including
> > > >computer viruses.
> > > >
> > > >
> > > --
> > >
> > > Alex Alten
> > >
> > > Alten@Home.Com
> > >
> > >
> >
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
>
From owner-ipsec@lists.tislabs.com Wed Aug 8 07:54:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78EsRN16503;
Wed, 8 Aug 2001 07:54:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17192
Wed, 8 Aug 2001 09:54:17 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Horn, Mike" <mhorn@virtela.net>
Cc: ipsec@lists.tislabs.com
Subject: Re: IKE must have no Heirs
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 08 Aug 2001 15:00:47 +0100
Message-Id: <20010808140047.194A37B4B@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <CCFF88268143CC4181A758DCC0ECDC13DE7764@posthaus.virtela.cc>, "Horn,
Mike" writes:
>Again speaking from service provider experience, manual keys are not a
>scalable option. Some sort of key exchange protocol is definitely required,
>right now that means IKE. As for using a single IP protocol number for both
>IKE and IPsec, I was merely stating this would reduce the number of
>ports/protocols I have to request firewall administrators to allow. From an
>operational perspective, dealing with IPsec devices behind firewalls can be
>very painful.
In fact, overloading protocol or port numbers is a major problem for
firewalls -- you don't know exactly what you're letting through.
--Steve Bellovin, http://www.research.att.com/~smb
From owner-ipsec@lists.tislabs.com Wed Aug 8 08:02:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78F2JN16701;
Wed, 8 Aug 2001 08:02:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17293
Wed, 8 Aug 2001 10:19:52 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15217.19461.896582.163323@thomasm-u1.cisco.com>
Date: Wed, 8 Aug 2001 07:26:13 -0700 (PDT)
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: Dan McDonald <danmcd@East.Sun.COM>, Sandy Harris <sandy@storm.ca>,
ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <200108081248.f78CmLu72505@givry.rennes.enst-bretagne.fr>
References: <200108080219.f782JIp00242@kebe.east.sun.com>
<200108081248.f78CmLu72505@givry.rennes.enst-bretagne.fr>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Francis Dupont writes:
> PS: I am not in favor to reduce IPsec to VPNs, the thing which will happen
> if we remove AH then transport mode...
Francis,
I'm not in favor of VPN only IPsec either, but I don't
understand removal of AH would be a step in that direction.
The very existence of AH, I think, is at the root of
a lot of the misunderstanding that happened with MIPv6.
It may not have eliminated all of the misuses of IPsec,
but it seems like a pretty vivid example of how more
options == more confusion of how they all work (or
don't work as the case were).
Mike
From owner-ipsec@lists.tislabs.com Wed Aug 8 08:07:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78F7cN16873;
Wed, 8 Aug 2001 08:07:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17300
Wed, 8 Aug 2001 10:19:55 -0400 (EDT)
Date: Wed, 08 Aug 2001 06:58:51 -0700
From: Derrell Piper <ddp@cips.nokia.com>
To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
cc: Dan McDonald <danmcd@East.Sun.COM>, Sandy Harris <sandy@storm.ca>,
ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
Message-ID: <461410.997253930@el-air-1.electric-loft.org>
In-Reply-To: <3B710406.1175A60@F-Secure.com>
References: <200108080219.f782JIp00242@kebe.east.sun.com>
<3B710406.1175A60@F-Secure.com>
X-Mailer: Mulberry/2.1.0b3 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The other property that commit-bit processing buys you is that the third
message of QM is now protected by the IKE retransmit timer and thus QM is
guaranteed to complete enough for both sides to generate IPsec SA's, even
when the last message (the ISAKMP Notify "CONNECTED") is lost. If you
don't use commit-bit processing, the last message of QM can be dropped and
this leaves you in the particularly bad state where one side has SA's and
the other doesn't.
Personally, I would rather burn a full network exchange to ensure that my
really expensive key agreement protocol actually completes instead of
having to just hope that the network didn't drop my last packet, which is
what you're betting on today when you don't use the commit-bit.
Derrell
--On Wednesday, August 8, 2001 12:19 PM +0300 Ari Huttunen
<Ari.Huttunen@F-Secure.com> wrote:
>> > Can we drop the commit bit?
>>
>> Who uses it?
>
> I guess someone in past figured out that running IKE on satellite lines
> is necessary, so they decided to optimize as much as possible. The result
> was that both aggressive mode and quick mode both have three messages.
> The problem with three messages is that the initiator will often start
> sending actual traffic too soon, or quick mode packets, before the
> responder is ready. Thus the need for packet buffers, commit bit,
> whatever. This optimization causes design complications that I'd very
> much prefer to get rid of.
>
> Thus my preference would be to have a four packet phase 1 (base mode) and
> a four packet quick mode.
>
> The other reason I prefer base mode is that the responder can select the
> proper policy based on the first packet.
>
> If main mode had the possibility to send a group identity in packet one
> and actual identity in packet five, I wouldn't object to just having main
> mode, since it does have an even number of packets.
From owner-ipsec@lists.tislabs.com Wed Aug 8 08:10:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FAhN16984;
Wed, 8 Aug 2001 08:10:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17004
Wed, 8 Aug 2001 09:24:45 -0400 (EDT)
From: Steve.Robinson@psti.com
Subject: Re: Simplifying IKE
To: Joe Touch <touch@ISI.EDU>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com,
Sandy Harris <sandy@storm.ca>
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
Message-ID: <OF11BDFF1E.43F6E6B0-ON80256AA2.004A92C1@psti.com>
Date: Wed, 8 Aug 2001 09:36:01 -0400
X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at
08/08/2001 02:36:36 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Joe,
Please look a little closer, all my comments are prefaced by "STEVE:" I
cut the other sections from Sandy's original e-mail. I have no problems
with including NULL mode, but what I don't want to see is a situation where
we are using ESP for one thing on a packet and AH for another, simply for
what I perceive as political reasons. I'd much prefer to use a single
protocol and simplify our efforts.
Take Care,
Steve
Joe Touch
<touch@ISI.ED To: Steve.Robinson@psti.com
U> cc: Sandy Harris <sandy@storm.ca>, ipsec@lists.tislabs.com,
owner-ipsec@lists.tislabs.com
08/08/01 Subject: Re: Simplifying IKE
08:56 AM
Steve.Robinson@psti.com wrote:
>
> A few comments:
>
> 2a: eliminate ESP authentication
> 3a: require AH on all packets. No choice, no null mode. An IPsec
connection
> authenticates all packets, period.
Null mode is useful, if only for debugging and performance measurement.
Jor
From owner-ipsec@lists.tislabs.com Wed Aug 8 08:14:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FEwN17175;
Wed, 8 Aug 2001 08:14:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17419
Wed, 8 Aug 2001 10:34:47 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA5B@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Steve.Robinson@psti.com'" <Steve.Robinson@psti.com>,
Sandy Harris
<sandy@storm.ca>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
Date: Wed, 8 Aug 2001 07:41:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C12018.3B48B850"
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_000_01C12018.3B48B850
Content-Type: text/plain;
charset="iso-8859-1"
> STEVE: I agree with you on this, but in practice, unless a
> PKI standard is
> settled on, my boss is not going to approve of me implementing a
> proprietary solution unless a consensus is reached in the
> IPsec community
> first. My gut feeling is that it isn't gonna happen unless
> the work at the
> NIST on PKI suddenly becomes accepted as a standard.
Why not simply plug into XKMS?
All IPSEC cares about is the delivery of authenticated, validated
keys. It should not need to know if the PKI is based on X509/PKIX,
PGP, SPKI or YAPKI.
Phill
------_=_NextPart_000_01C12018.3B48B850
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C12018.3B48B850--
From owner-ipsec@lists.tislabs.com Wed Aug 8 08:17:37 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FHaN17250;
Wed, 8 Aug 2001 08:17:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17385
Wed, 8 Aug 2001 10:32:21 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15217.20193.161145.884054@thomasm-u1.cisco.com>
Date: Wed, 8 Aug 2001 07:38:25 -0700 (PDT)
To: "Horn, Mike" <mhorn@virtela.net>
Cc: "'Derek Atkins'" <warlord@mit.edu>, ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
In-Reply-To: <CCFF88268143CC4181A758DCC0ECDC13DE7772@posthaus.virtela.cc>
References: <CCFF88268143CC4181A758DCC0ECDC13DE7772@posthaus.virtela.cc>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Horn, Mike writes:
> Derek,
>
> Want to keep this friendly, but obviously I don't agree with your points.
> You have a vested interest in KINK, I have a vested interest in IPsec VPNs.
> This influences both of our views. I noticed you didn't respond to my
> question about AH...
>
> >
> > First, all the world is not VPN.
>
> see above.
>
> > Second, there are alternate keying protocols (KINK, for example)
>
> Has KINK produced any _standards_ other than the requirements (RFC 3129)?
> How many IPsec vendors currently offer production support for KINK?
KINK is considerably farther ahead than SOI(lent-green?).
We should be able to go to last call soon after this
meeting. Many of Radia's improve-ike suggestions are
part of the KINK base spec. To give an idea of complexity,
it took me about 1 month of 2/3's time to implement almost
all of the requirements of the spec, and I expect that
it will take a similar amount of time to clean it up to
a feature complete status. So we're not talking about
major development time here. If nothing else, I'm hoping
that KINK will serve as a test of many of Radia's improvements
to see if they actually do help with interoperability, etc.
Mike
From owner-ipsec@lists.tislabs.com Wed Aug 8 08:33:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FXkN17982;
Wed, 8 Aug 2001 08:33:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17526
Wed, 8 Aug 2001 10:49:16 -0400 (EDT)
Date: Wed, 8 Aug 2001 10:55:41 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <200108081248.f78CmLu72505@givry.rennes.enst-bretagne.fr>
Message-ID: <Pine.BSI.3.91.1010808104616.10441C-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 8 Aug 2001, Francis Dupont wrote:
> ...I believe the source route header is primarily used to see
> what paths are broken in a network - using the process of elimination.
Actually, the source route header is increasingly frequently ignored (or
considered grounds for dropping the packet) by implementations, because of
its utility for various forms of attack.
> PS: I am not in favor to reduce IPsec to VPNs, the thing which will happen
> if we remove AH then transport mode...
Can you explain that statement? ESP tunnels can do everything AH or
transport mode can do, although sometimes at very slightly greater cost.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Wed Aug 8 08:45:46 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FjjN20216;
Wed, 8 Aug 2001 08:45:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17564
Wed, 8 Aug 2001 11:00:19 -0400 (EDT)
Message-ID: <20010808150724.14839.qmail@web4602.mail.yahoo.com>
Date: Wed, 8 Aug 2001 08:07:24 -0700 (PDT)
From: shiwen chen <sxc4305@yahoo.com>
Subject: Preserve client IP Address with IPSec
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
Could anyone please help me with the following
questions?
when a IPsec client is accessing to an Intranet host,
is it possible to preserve the original IP source
address of the client? so that the intranet host will
be able to read the client's original IP.
Thanks
SC
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
From owner-ipsec@lists.tislabs.com Wed Aug 8 08:45:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FjlN20234;
Wed, 8 Aug 2001 08:45:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17573
Wed, 8 Aug 2001 11:01:12 -0400 (EDT)
Message-Id: <200108081456.f78EudA01495@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: Re draft-kaufman-ipsec-improveike-00.txt
In-reply-to: Your message of "Tue, 07 Aug 2001 23:45:23 EDT."
<Pine.BSI.3.91.1010807234146.2521C-100000@spsystems.net>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 08 Aug 2001 10:56:39 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Henry" == Henry Spencer <henry@spsystems.net> writes:
Henry> If dim memory serves, there were many cries about how TCP would not meet
Henry> everyone's needs, and how there were conflicting requirements, and etc.
Henry> etc. etc... but in fact TCP really does meet *most* people's needs, even
Henry> if it is not precisely optimal in many cases.
At this point, if we switch from UDP, it should be to SCTP.
During the original debate SCTP did not exist.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
From owner-ipsec@lists.tislabs.com Wed Aug 8 08:46:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78Fk1N20285;
Wed, 8 Aug 2001 08:46:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17580
Wed, 8 Aug 2001 11:01:28 -0400 (EDT)
Date: Wed, 8 Aug 2001 11:08:00 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Arne Ansper <arne@ats.cyber.ee>
cc: ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
In-Reply-To: <Pine.WNT.4.33.0108081351570.172-100000@viluvere.itsise>
Message-ID: <Pine.BSI.3.91.1010808110541.10441D-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 8 Aug 2001, Arne Ansper wrote:
> suppose you have slow internet connection that is used only for VPN
> traffic. your access router has no way to distinguish between different
> sessions inside your VPN so it will put all the packets into same queue.
Surely this is what TOS is for. (Note that RFC 2401 calls for TOS to be
copied into the outer header, although I'm told that there is now
consensus that this ought to be configurable.)
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Wed Aug 8 09:38:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78GcoN23201;
Wed, 8 Aug 2001 09:38:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17828
Wed, 8 Aug 2001 11:54:44 -0400 (EDT)
Message-Id: <200108081601.f78G11u73217@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Michael Thomas <mat@cisco.com>
cc: Dan McDonald <danmcd@East.Sun.COM>, Sandy Harris <sandy@storm.ca>,
ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of Wed, 08 Aug 2001 07:26:13 PDT.
<15217.19461.896582.163323@thomasm-u1.cisco.com>
Date: Wed, 08 Aug 2001 18:01:01 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
Francis Dupont writes:
> PS: I am not in favor to reduce IPsec to VPNs, the thing which will
> happen if we remove AH then transport mode...
Francis,
I'm not in favor of VPN only IPsec either,
=> but VPNs are the current market so if we remove everything not used
today only VPN stuff will remain. AH seems to be the first victim of
the "simplifying IKE" process and transport mode will be the second
(even if this has near nothing to do with the IKE issue and transport
mode is more primitive than tunnel mode: tunnel mode is used in VPNs
so it cannot be removed). IMHO this is just "remove everything we
don't like or don't use" but the net result can be a VPN only IPsec.
but I don't understand removal of AH would be a step in that direction.
=> reread all the not IKE stuff in this thread...
The very existence of AH, I think, is at the root of
a lot of the misunderstanding that happened with MIPv6.
=> I disagree, the purpose of AH is the protection of payload
and headers (something ESP should not do because there already is AH)
and for a signaling protocol like MIPv6 AH is both simpler and cheaper]
to use. The trouble of IPsec with MIPv6 is more IKE (the thing we are
supposed to simplify): obviously to run IKE phases 1 & 2 in order
to protect BUs (sometime a single small packet) is overkilling
It may not have eliminated all of the misuses of IPsec,
=> misuses = other uses than VPNs (:-) ?
(note you can seriously answer)
but it seems like a pretty vivid example of how more
options == more confusion of how they all work (or
don't work as the case were).
=> I disagree: AH for MIPv6 works, this is not deployable
(because of global PKI/authorization issue) and nor efficient
(as concrete tests have shown). And I believe we'll still see
IPsec and MIPv6 together in the future because IPsec only
provides a good security service in the network layer
(i.e. not everywhere but somewhere).
Regards
Francis.Dupont@enst-bretagne.fr
PS: what the MIPv6 misadventure has shown too is that there is a place
for more than one keying protocol.
From owner-ipsec@lists.tislabs.com Wed Aug 8 09:41:06 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78Gf5N23244;
Wed, 8 Aug 2001 09:41:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17852
Wed, 8 Aug 2001 12:00:25 -0400 (EDT)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B8028A35@hhdata3.cdsemea.baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: Rick Smith at Secure Computing <rick_smith@securecomputing.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
Date: Wed, 8 Aug 2001 17:04:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
That's an interesting idea. I think one of the reasons for putting IKE in
user space might have been because it is so much more complicated than the
ESP/AH - it's much safer to keep it out of the kernel!
Chris
> -----Original Message-----
> From: Rick Smith at Secure Computing
> [mailto:rick_smith@securecomputing.com]
> Sent: 07 August 2001 19:49
> To: Alex Alten; Kory Hamzeh; Hallam-Baker, Phillip
> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> Subject: Re: IKE must have no Heirs
>
>
> At 02:28 AM 8/7/2001, Alex Alten wrote:
>
> >I second the motion. And also propose no port number (i.e. do the new
> >one over raw IP).
>
> There is a benefit to this approach if, in some future
> universe, we ever
> try to implement a protocol stack using least privilege to maximize
> security assurance. It gives us an easy way of putting all
> parts of IPsec
> within the same trust boundary and of keeping it better
> separated from
> other protocol processing.
>
> Otherwise you are stuck with a uniform level of trust for all of the
> software in the protocol stack, crypto and non-crypto, including the
> mechanism that binds ports to processes. I know, this isn't a
> problem today
> because protocol stacks run in kernel mode and therefore we
> (have no other
> choice but to) "trust" the entire protocol stack.
>
> It is, of course, feasible to ignore the issues of
> incremental trust and/or
> build additional mechanisms to bring together what is built
> asunder. But it
> seems cleaner, design-wise, to keep the key management close
> to the code
> that actually uses the resulting keys.
>
> Rick.
> smith@securecomputing.com
>
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
From owner-ipsec@lists.tislabs.com Wed Aug 8 10:01:43 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78H1hN23546;
Wed, 8 Aug 2001 10:01:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17887
Wed, 8 Aug 2001 12:18:46 -0400 (EDT)
Message-Id: <200108081624.f78GOhu73295@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Henry Spencer <henry@spsystems.net>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of Wed, 08 Aug 2001 10:55:41 EDT.
<Pine.BSI.3.91.1010808104616.10441C-100000@spsystems.net>
Date: Wed, 08 Aug 2001 18:24:43 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
On Wed, 8 Aug 2001, Francis Dupont wrote:
> ...I believe the source route header is primarily used to see
> what paths are broken in a network - using the process of elimination.
=> you haven't quoted me but the message I answered to...
Actually, the source route header is increasingly frequently ignored (or
considered grounds for dropping the packet) by implementations, because of
its utility for various forms of attack.
=> I agree but the reason seems to be more the lack of 3 addresses
filtering in common routers used as (very) poor man firewalls +
FUD about source routing. I believe we can consider source routing
as not available on the IPv4 Internet (IPv6 tries to fix that so
the game is still played for it).
> PS: I am not in favor to reduce IPsec to VPNs, the thing which will happen
> if we remove AH then transport mode...
Can you explain that statement?
=> read my answer to Michael Thomas for my arguments/fears.
ESP tunnels can do everything AH or transport mode can do,
although sometimes at very slightly greater cost.
=> yes but as you have written there is a cost. And from the routing
point of view to replace tunnel mode by transport mode with IP-in-IP
(yes, I know they are not the same thing) has many advantages.
Regards
Francis.Dupont@enst-bretagne.fr
PS: as a champion of the tunnel mode, can you help me in order to
have RFC 2401 5.1.2.1 footnote 3 (including its note) correctly
implemented. Of course for dual stack implementations it should
be nice to get (as specified by RFC 2401 too) mixed IP version tunnels.
(this seems more useful than to reopen the AH hater thread again)
From owner-ipsec@lists.tislabs.com Wed Aug 8 10:07:22 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78H7MN23664;
Wed, 8 Aug 2001 10:07:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17916
Wed, 8 Aug 2001 12:29:11 -0400 (EDT)
Date: Wed, 8 Aug 2001 12:35:37 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <200108081624.f78GOhu73295@givry.rennes.enst-bretagne.fr>
Message-ID: <Pine.BSI.3.91.1010808122553.14256B-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 8 Aug 2001, Francis Dupont wrote:
> > PS: I am not in favor to reduce IPsec to VPNs, the thing which will happen
> > if we remove AH then transport mode...
>
> Can you explain that statement?
>
> => read my answer to Michael Thomas for my arguments/fears.
I read your answer, and I fear I am no wiser. You still haven't explained
why dumping AH and transport mode would "reduce IPsec to VPNs", perhaps
because it is not clear what you mean by "VPNs" or what your envisioned
non-"VPN" applications for IPsec are (and why they can't be done with ESP
tunnels).
> ESP tunnels can do everything AH or transport mode can do,
> although sometimes at very slightly greater cost.
>
> => yes but as you have written there is a cost.
Quite so, however my claim is that it is very seldom a significant cost.
We commonly accept general-purpose mechanisms whose costs are slightly
higher than necessary for any particular application, for the sake of
generality and simplicity. Numbers matter; a claim that the costs of
simplification are unacceptable needs to be justified numerically.
> And from the routing
> point of view to replace tunnel mode by transport mode with IP-in-IP
> (yes, I know they are not the same thing) has many advantages.
My feeling is that many of the purported advantages are actually accidents
of particular implementations, not fundamental to the protocols.
> PS: as a champion of the tunnel mode, can you help me in order to
> have RFC 2401 5.1.2.1 footnote 3 (including its note) correctly
> implemented.
I'm certainly interested in helping: I don't immediately see what help
you are asking for...
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Wed Aug 8 10:16:15 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78HGFN23973;
Wed, 8 Aug 2001 10:16:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17970
Wed, 8 Aug 2001 12:41:01 -0400 (EDT)
Message-ID: <8DCFE693DDFFD111AC4100A0C9B8DB9405DF1F7C@hdsmsx33.hd.intel.com>
From: "Eissa, Mohamed" <mohamed.eissa@intel.com>
To: ipsec@lists.tislabs.com
Subject: Matching ID with cetificate's subjectName and subjectAltName
Date: Wed, 8 Aug 2001 09:40:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
The "PKIX profile for IKE" draft mentioned that the ID used in IKE
negotiation, must match with the subjectName or SubjectAltName within the
peer certificate.
Can someone please help me to understand the risk involved with not doing
this match during MAIN/AGGR modes?
Mohamed Eissa
Intel of Canada
From owner-ipsec@lists.tislabs.com Wed Aug 8 10:31:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78HVJN24256;
Wed, 8 Aug 2001 10:31:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17995
Wed, 8 Aug 2001 12:48:17 -0400 (EDT)
Message-ID: <49B96FCC784BC54F9675A6B558C3464E328F05@MAIL.NetOctave.com>
From: David Blaker <DBlaker@NetOctave.com>
To: Steve.Robinson@psti.com, Joe Touch <touch@ISI.EDU>
Cc: ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
Date: Wed, 8 Aug 2001 12:51:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Please be aware that from a hardware point of view, and I suspect also from
a software point of view, processing 2 SAs per packet will definitely
degrade the performance, as opposed to including both authentication and
encryption in a single SA a la ESP. This is because of the extra lookups and
repeated packet processing, as opposed to the cryptography.
David Blaker, CTO
NetOctave, Inc.
P.O. Box 14824
Research Triangle Park, NC 27709
Phone (919) 463-9903 x.206 / Fax (919) 463-9905
email mailto:dblaker@netoctave.com
website http://www.netoctave.com
-----Original Message-----
From: Steve.Robinson@psti.com [mailto:Steve.Robinson@psti.com]
Sent: Wednesday, August 08, 2001 9:36 AM
To: Joe Touch
Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com; Sandy Harris
Subject: Re: Simplifying IKE
Hi Joe,
Please look a little closer, all my comments are prefaced by "STEVE:" I
cut the other sections from Sandy's original e-mail. I have no problems
with including NULL mode, but what I don't want to see is a situation where
we are using ESP for one thing on a packet and AH for another, simply for
what I perceive as political reasons. I'd much prefer to use a single
protocol and simplify our efforts.
Take Care,
Steve
Joe Touch
<touch@ISI.ED To: Steve.Robinson@psti.com
U> cc: Sandy Harris
<sandy@storm.ca>, ipsec@lists.tislabs.com,
owner-ipsec@lists.tislabs.com
08/08/01 Subject: Re: Simplifying IKE
08:56 AM
Steve.Robinson@psti.com wrote:
>
> A few comments:
>
> 2a: eliminate ESP authentication
> 3a: require AH on all packets. No choice, no null mode. An IPsec
connection
> authenticates all packets, period.
Null mode is useful, if only for debugging and performance measurement.
Jor
From owner-ipsec@lists.tislabs.com Wed Aug 8 10:40:25 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78HeON24467;
Wed, 8 Aug 2001 10:40:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18068
Wed, 8 Aug 2001 13:01:05 -0400 (EDT)
Message-Id: <200108081707.f78H77u73516@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Henry Spencer <henry@spsystems.net>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of Wed, 08 Aug 2001 12:35:37 EDT.
<Pine.BSI.3.91.1010808122553.14256B-100000@spsystems.net>
Date: Wed, 08 Aug 2001 19:07:07 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
I read your answer, and I fear I am no wiser. You still haven't explained
why dumping AH and transport mode would "reduce IPsec to VPNs"
=> assume that you have a IPsec implementation with AH, ESP, even IPCOMP,
transport and tunnel modes, a IKE you know how to configure (:-), ...
So the only application where you'd like to use ESP in tunnel mode
is VPNs, for end-to-end transport mode is easier/cheaper, if you need
authentication only AH is easier/cheaper and give more.
because it is not clear what you mean by "VPNs"
=> protection (confidentiality first) of traffic between two points
with at least one of the two ends being a SG.
or what your envisioned non-"VPN" applications for IPsec are
=> an example: protect a BGP session between two routers (authentication
is enough, network layer is mandatory because of fake TCP RSTs).
(and why they can't be done with ESP tunnels).
=> I didn't say that, everything can be done with ESP tunnels but
with more complexity and higher cost.
> ESP tunnels can do everything AH or transport mode can do,
> although sometimes at very slightly greater cost.
>
> => yes but as you have written there is a cost.
Quite so, however my claim is that it is very seldom a significant cost.
We commonly accept general-purpose mechanisms whose costs are slightly
higher than necessary for any particular application, for the sake of
generality and simplicity. Numbers matter; a claim that the costs of
simplification are unacceptable needs to be justified numerically.
=> it seems you'd like to apply the market argument: the market is VPNs
so keep only the ESP in tunnel mode. I understand that but I don't like it.
> PS: as a champion of the tunnel mode, can you help me in order to
> have RFC 2401 5.1.2.1 footnote 3 (including its note) correctly
> implemented.
I'm certainly interested in helping: I don't immediately see what help
you are asking for...
=> too many implementations check when they should not (I like to get
a MUST NOT here) the outer source address for ESP tunnels. The reason
seems to be security, if there is a real issue the RFC must be fixed
ASAP, if there is none the implementations must be fixed ASAP.
If we keep only ESP in tunnel mode I'd like to get it correctly
implemented...
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Wed Aug 8 10:59:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78HxAN24777;
Wed, 8 Aug 2001 10:59:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18124
Wed, 8 Aug 2001 13:14:26 -0400 (EDT)
Message-Id: <3.0.5.32.20010808191436.035bdb60@smtp.datafellows.com>
X-Sender: joern@smtp.datafellows.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 08 Aug 2001 19:14:36 +0200
To: ipsec@lists.tislabs.com
From: Joern Sierwald <joern.sierwald@F-Secure.com>
Subject: Re: Matching ID with cetificate's subjectName and
subjectAltName
In-Reply-To: <8DCFE693DDFFD111AC4100A0C9B8DB9405DF1F7C@hdsmsx33.hd.intel
.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 NAA18097
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 09:40 08.08.01 -0700, Eissa, Mohamed wrote:
>Hi,
>
>The "PKIX profile for IKE" draft mentioned that the ID used in IKE
>negotiation, must match with the subjectName or SubjectAltName within the
>peer certificate.
>
>Can someone please help me to understand the risk involved with not doing
>this match during MAIN/AGGR modes?
>
>Mohamed Eissa
>Intel of Canada
>
Risk? The protocol is simply useless if you don't check it.
Example:
You contact server 192.168.22.9. Now, the server sends a certificate
with DN = "C=US, O=corp". The certificate is still valid and
the signature check succeeds.
Now. What good this is? Anybody with a valid certificate can
the hook of the server 192.168.22.9 and place his own there,
and you won't notice. He won't have the private key of the server, but
that does not matter. He puts his _own_ private key and cert there.
You won't notice because you accept all certificates.
So, the main goal, making sure that the server is really the server
you expect it to be, can't be reached.
=> A client must know which certificate to expect.
Solution (1):
You tell the client which certificate the server will use. The
full DN. letter by letter.
Solution (2):
You put the IP address (or dns) into the certificate.
The client will check that the cert actually contains the ID
it's expecting.
Solution (1) is subjectName, solution (2) is SubjectAltName.
The IKE ID simply tells the client which (server) cert to use. It points
to a certificate. After all, the client could ignore all
certs sent by the server, take the IKE ID and ask LDAP for
a cert.
Again:
The client contacts server 192.168.22.9. The server answeres
with IKE ID 192.168.22.9. The client is happy with that. The
client also receives one or several certs. It looks for the one
with SubjectAltName 192.168.22.9 and checks the signature with it.
Jörn
From owner-ipsec@lists.tislabs.com Wed Aug 8 11:28:31 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78ISVN25321;
Wed, 8 Aug 2001 11:28:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18175
Wed, 8 Aug 2001 13:43:07 -0400 (EDT)
Message-Id: <200108081749.f78HmtR00738@dharkins@lounge.orgatty.lounge.org>
To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: Your message of "Wed, 08 Aug 2001 12:19:02 +0300."
<3B710406.1175A60@F-Secure.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <735.997292935.1@lounge.org>
Date: Wed, 08 Aug 2001 10:48:55 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
My tentative text on the subject is to get rid of the commit bit and
have a 3 message exchange. The problem with the existing 3 message
exchanage (w/o the commit bit being used) is that the Responder will not
instantiate her SAs until receipt of the 3rd message from the Initiator
to avoid a resource consumption attack but the Initiator will instantiate
his SAs upon receipt of the 2nd message from the Responder. This results
in a race between the first few IPsec-protected packets and the final
message. If the former win they get dropped.
My proposal is that the Responder instantiate the SAs when she sends
the 2nd message back to the Initiator. She will be setting a timer to
deal with non-receipt of the 3rd message and if the timer fires
RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
and she can delete these SAs from her SADB.
In addition to this text there is new text instructing implementations
to deal with receipt of an offer to create an IPsec SA with a SPI that
is currently in use as an error, and new text instructing the Initiator
to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in case
it is dropped and he receives a retransmitted 2nd message from the
Responder.
This is much simpler than what we have and solves the race problem.
What it does, though, is allow for some resources to be temporarily
consumed due to the replay of an old message. I don't view this as that
big of a problem though since it is temporary (RETRANSMIT_TIME *
RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
the SADB) and the number of possible packets that can be replayed is
limited and bounded by the life of the IKE SA.
Thoughts?
Dan.
On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
>
> Dan McDonald wrote:
> >
> > > >From the Schneier and Ferguson analysis we get:
> > >
> > > Can we drop the commit bit?
> >
> > Who uses it?
>
> I guess someone in past figured out that running IKE on satellite lines
> is necessary, so they decided to optimize as much as possible. The result
> was that both aggressive mode and quick mode both have three messages.
> The problem with three messages is that the initiator will often start sendin
>g
> actual traffic too soon, or quick mode packets, before the responder is ready
>. Thus
> the need for packet buffers, commit bit, whatever. This optimization causes d
>esign
> complications that I'd very much prefer to get rid of.
From owner-ipsec@lists.tislabs.com Wed Aug 8 11:37:52 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78IbqN25529;
Wed, 8 Aug 2001 11:37:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18210
Wed, 8 Aug 2001 13:56:49 -0400 (EDT)
Message-Id: <200108081802.f78I2XR00772@dharkins@lounge.orgatty.lounge.org>
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: Your message of "Wed, 08 Aug 2001 18:01:01 +0200."
<200108081601.f78G11u73217@givry.rennes.enst-bretagne.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <769.997293753.1@lounge.org>
Date: Wed, 08 Aug 2001 11:02:33 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 08 Aug 2001 18:01:01 +0200 you wrote
>
> The very existence of AH, I think, is at the root of
> a lot of the misunderstanding that happened with MIPv6.
>
> => I disagree, the purpose of AH is the protection of payload
> and headers (something ESP should not do because there already is AH)
> and for a signaling protocol like MIPv6 AH is both simpler and cheaper]
> to use. The trouble of IPsec with MIPv6 is more IKE (the thing we are
> supposed to simplify): obviously to run IKE phases 1 & 2 in order
> to protect BUs (sometime a single small packet) is overkilling
Well, not really, and none of the simplifications being proposed or
planned for IKE would help MIPv6.
The problem with MIPv6 is that the Binding Update is a destination
option which they would like authenticated. But there is no way for
an IPsec selector to be defined to identify certain types of destination
options. The choice is to authenticate _everything_ which they don't
want to do or authenticate _nothing_ which they can't do. This has
nothing to do with IKE.
While the overkill of a phase 1 and phase 2 to merely authenticate a
single Binding Update is a problem the other, larger problem is that
there is no global PKI to deal with authentication. Even a protocol
(SKIP for instance) which could handle the key establishment in a
single message-- definitely not overkill-- would not work because
there is no global PKI to support it.
Dan.
From owner-ipsec@lists.tislabs.com Wed Aug 8 12:17:41 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78JHeN26381;
Wed, 8 Aug 2001 12:17:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18343
Wed, 8 Aug 2001 14:29:45 -0400 (EDT)
Message-Id: <200108081835.f78IZhJ09105@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
cc: Henry Spencer <henry@spsystems.net>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of "Wed, 08 Aug 2001 19:07:07 +0200."
<200108081707.f78H77u73516@givry.rennes.enst-bretagne.fr>
Reply-to: sommerfeld@East.Sun.COM
Date: Wed, 08 Aug 2001 14:35:42 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
AH or not-AH has nothing to do with VPN or end-to-end IPsec use.
As Steve Bellovin has pointed out on numerous occasions, the IP header
in transport-mode ESP can be "authenticated" merely by doing a compare
of the source and destination addresses against static state in the
SA...
- Bill
From owner-ipsec@lists.tislabs.com Wed Aug 8 12:42:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78JgZN26786;
Wed, 8 Aug 2001 12:42:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19375
Wed, 8 Aug 2001 14:46:47 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Subject: RE: Simplifying IKE
Date: Wed, 8 Aug 2001 11:52:09 -0700
Message-ID: <2E33960095B58E40A4D3345AB9F65EC1A4E8D6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Simplifying IKE
thread-index: AcEgNK10eOnzsdKdSGWr8JBshP/ougABZ55w
From: "Brian Swander" <briansw@windows.microsoft.com>
To: "Dan Harkins" <dharkins@lounge.org>,
"Ari Huttunen" <Ari.Huttunen@F-Secure.com>
Cc: <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 08 Aug 2001 18:52:10.0429 (UTC) FILETIME=[3AC5DED0:01C1203B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA19372
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I'd prefer to keep the commit bit. Otherwise the responder is forced to
add SAs before the final QM hash from the initiator is processed,
opening the responder up to adding potentially suspect SAs into the
system.
I am not so concerned with the resources in an attack, but more worried
about an attacker potentially getting an SA into the system that could
be exploited. I don't see how this could be done today (all I can see
is the obvious replay attack Dan is talking about), but that doesn't
mean that such an exploit doesn't exist. So, I am much more comfortable
with the one extra packet and the assurance that everything is ok with
the negotiation before SAs are added.
Of course, if someone has a proof that the security can't be violated by
adding the responder SAs early, then I'd agree to eliminating the commit
bit (except for backwards compatibility, when we'd still need to support
it).
bs
-----Original Message-----
From: Dan Harkins [mailto:dharkins@lounge.org]
Sent: Wednesday, August 08, 2001 10:49 AM
To: Ari Huttunen
Cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
My tentative text on the subject is to get rid of the commit bit and
have a 3 message exchange. The problem with the existing 3 message
exchanage (w/o the commit bit being used) is that the Responder will not
instantiate her SAs until receipt of the 3rd message from the Initiator
to avoid a resource consumption attack but the Initiator will
instantiate
his SAs upon receipt of the 2nd message from the Responder. This results
in a race between the first few IPsec-protected packets and the final
message. If the former win they get dropped.
My proposal is that the Responder instantiate the SAs when she sends
the 2nd message back to the Initiator. She will be setting a timer to
deal with non-receipt of the 3rd message and if the timer fires
RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
and she can delete these SAs from her SADB.
In addition to this text there is new text instructing implementations
to deal with receipt of an offer to create an IPsec SA with a SPI that
is currently in use as an error, and new text instructing the Initiator
to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in
case
it is dropped and he receives a retransmitted 2nd message from the
Responder.
This is much simpler than what we have and solves the race problem.
What it does, though, is allow for some resources to be temporarily
consumed due to the replay of an old message. I don't view this as that
big of a problem though since it is temporary (RETRANSMIT_TIME *
RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
the SADB) and the number of possible packets that can be replayed is
limited and bounded by the life of the IKE SA.
Thoughts?
Dan.
On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
>
> Dan McDonald wrote:
> >
> > > >From the Schneier and Ferguson analysis we get:
> > >
> > > Can we drop the commit bit?
> >
> > Who uses it?
>
> I guess someone in past figured out that running IKE on satellite
lines
> is necessary, so they decided to optimize as much as possible. The
result
> was that both aggressive mode and quick mode both have three messages.
> The problem with three messages is that the initiator will often start
sendin
>g
> actual traffic too soon, or quick mode packets, before the responder
is ready
>. Thus
> the need for packet buffers, commit bit, whatever. This optimization
causes d
>esign
> complications that I'd very much prefer to get rid of.
From owner-ipsec@lists.tislabs.com Wed Aug 8 13:39:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78KdTN27875;
Wed, 8 Aug 2001 13:39:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19812
Wed, 8 Aug 2001 15:54:57 -0400 (EDT)
To: ipsec@lists.tislabs.com
Subject: How to get ID: "PKIX profile for IKE" ?
From: Ryu Inada <ryu@fujixerox.co.jp>
Message-Id: <200108090502.HFC54360.VSZ@fujixerox.co.jp>
X-Mailer: Winbiff [Version 2.33PL2]
X-Accept-Language: ja,en
Date: Thu, 9 Aug 2001 05:02:13 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi.
Does anyone know how to get ID:"PKIX profile for IKE" ?
I could not found IETF's ID archives.
Thanks.
Ryu Inada
--
Ryu Inada
ryu@fujixerox.co.jp
From owner-ipsec@lists.tislabs.com Wed Aug 8 13:39:30 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78KdTN27882;
Wed, 8 Aug 2001 13:39:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19736
Wed, 8 Aug 2001 15:45:48 -0400 (EDT)
Message-Id: <200108081939.f78JdWr11860@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of "Wed, 08 Aug 2001 11:02:33 PDT."
<200108081802.f78I2XR00772@dharkins@lounge.orgatty.lounge.org>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 08 Aug 2001 15:39:32 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Dan" == Dan Harkins <dharkins@lounge.org> writes:
Dan> The problem with MIPv6 is that the Binding Update is a destination
Dan> option which they would like authenticated. But there is no way for
Dan> an IPsec selector to be defined to identify certain types of destination
Dan> options. The choice is to authenticate _everything_ which they don't
Dan> want to do or authenticate _nothing_ which they can't do. This has
Dan> nothing to do with IKE.
Well, there is no standard way.
Within a unified stack, (not BITW or BITS) the packets with the binding
update can easily be marked for IPsec processor via out-of-band means
(i.e. in the control structure).
Dan> While the overkill of a phase 1 and phase 2 to merely authenticate a
Dan> single Binding Update is a problem the other, larger problem is that
Dan> there is no global PKI to deal with authentication. Even a protocol
This is the same problem that Opportunistic Encryption struggles with.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO3GVc4qHRg3pndX9AQGT1QQA1xP5VcoQ3wMAOb4hHteJ5QAox9/NO40U
c1i3FNop74RouKJrvHZ4iwMmxNNiB1ZlCOA11JdD1+JnoLSU39+jIkAumMBbbqcA
hfHnecU1f4N2B5tfWkgKzqmGsL/fjYBZJaBx4cBBlsUbqb6efHtjVm7DdC1ChWRE
egwFZSM0mWo=
=r74V
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Wed Aug 8 13:39:33 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78KdXN27899;
Wed, 8 Aug 2001 13:39:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19753
Wed, 8 Aug 2001 15:49:05 -0400 (EDT)
To: sommerfeld@East.Sun.COM
Cc: Francis Dupont <Francis.Dupont@enst-bretagne.fr>,
Henry Spencer <henry@spsystems.net>, ipsec@lists.tislabs.com
In-reply-to: sommerfeld's message of Wed, 08 Aug 2001 14:35:42 -0400.
<200108081835.f78IZhJ09105@thunk.east.sun.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: Simplifying IKE
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Thu, 09 Aug 2001 04:55:49 +0900
Message-Id: <20010808195549.596F27BB@starfruit.itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>AH or not-AH has nothing to do with VPN or end-to-end IPsec use.
>
>As Steve Bellovin has pointed out on numerous occasions, the IP header
>in transport-mode ESP can be "authenticated" merely by doing a compare
>of the source and destination addresses against static state in the
>SA...
if you think about extension headers/IP options, IMHO the above
statement is not correct. AH is needed for a good reason.
what bothering me in IPsec spec is that it includes tunnel mode.
IPsec specification should only talk about transport mode, and tunnel
mode should be "IPsec transport mode + some sort of tunnelling".
there are a lot of (really, a lot of) tunnelling specifications around
so you have no problem referring those.
also, "bundle" should be dropped from RFC2401 as the concept of
"bundle" conflicts with the way AH and ESP are defined - they are
independent protocol, and can easily be handled/negotiated completely
separately.
btw - are we really going to simplify IPsec too, not just IKE?
if not, we should stop talking about IPsec mods.
itojun
From owner-ipsec@lists.tislabs.com Wed Aug 8 13:50:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78KoRN28144;
Wed, 8 Aug 2001 13:50:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19868
Wed, 8 Aug 2001 16:08:47 -0400 (EDT)
To: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: Your message of "Wed, 08 Aug 2001 14:35:42 -0400"
<200108081835.f78IZhJ09105@thunk.east.sun.com>
References: <200108081835.f78IZhJ09105@thunk.east.sun.com>
X-Mailer: Cue version 0.6 (010413-1707/sakane)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Message-Id: <20010809051536G.sakane@kame.net>
Date: Thu, 09 Aug 2001 05:15:36 +0900
From: Shoichi Sakane <sakane@kame.net>
X-Dispatcher: imput version 20000228(IM140)
Lines: 7
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> As Steve Bellovin has pointed out on numerous occasions, the IP header
> in transport-mode ESP can be "authenticated" merely by doing a compare
> of the source and destination addresses against static state in the
> SA...
but we need to survey whether there is really no ip extention header
to be protected or not, don't we ?.
From owner-ipsec@lists.tislabs.com Wed Aug 8 14:11:04 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78LB3N28461;
Wed, 8 Aug 2001 14:11:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19933
Wed, 8 Aug 2001 16:23:09 -0400 (EDT)
From: "sankar ramamoorthi" <sankar@nexsi.com>
To: "Dan Harkins" <dharkins@lounge.org>,
"Ari Huttunen" <Ari.Huttunen@F-Secure.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Wed, 8 Aug 2001 13:31:43 -0700
Message-ID: <DIEPJEEKAPMEEKEELGGCCEAADEAA.sankar@nexsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200108081749.f78HmtR00738@dharkins@lounge.orgatty.lounge.org>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> Sent: Wednesday, August 08, 2001 10:49 AM
> To: Ari Huttunen
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Simplifying IKE
>
>
> My tentative text on the subject is to get rid of the commit bit and
> have a 3 message exchange. The problem with the existing 3 message
> exchanage (w/o the commit bit being used) is that the Responder will not
> instantiate her SAs until receipt of the 3rd message from the Initiator
> to avoid a resource consumption attack but the Initiator will instantiate
> his SAs upon receipt of the 2nd message from the Responder. This results
> in a race between the first few IPsec-protected packets and the final
> message. If the former win they get dropped.
>
> My proposal is that the Responder instantiate the SAs when she sends
> the 2nd message back to the Initiator. She will be setting a timer to
> deal with non-receipt of the 3rd message and if the timer fires
> RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> and she can delete these SAs from her SADB.
What happens if the initiator starts sending data before the responder
receives the third message?
Will the ipsec packet from initiator be processed since responder has
established the SA on receipt of the second message? If so, can the
responder treat succesful processing of the data packet as succesful
authentication of the initiator and mark the SA as valid(basically
treat the condition same as processing a successful third message).
Personally I prefer a 4 packet exchange model for QM.
>
> In addition to this text there is new text instructing implementations
> to deal with receipt of an offer to create an IPsec SA with a SPI that
> is currently in use as an error, and new text instructing the Initiator
> to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in case
> it is dropped and he receives a retransmitted 2nd message from the
> Responder.
>
> This is much simpler than what we have and solves the race problem.
> What it does, though, is allow for some resources to be temporarily
> consumed due to the replay of an old message. I don't view this as that
> big of a problem though since it is temporary (RETRANSMIT_TIME *
> RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
> the SADB) and the number of possible packets that can be replayed is
> limited and bounded by the life of the IKE SA.
>
> Thoughts?
>
> Dan.
>
> On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> >
> > Dan McDonald wrote:
> > >
> > > > >From the Schneier and Ferguson analysis we get:
> > > >
> > > > Can we drop the commit bit?
> > >
> > > Who uses it?
> >
> > I guess someone in past figured out that running IKE on satellite lines
> > is necessary, so they decided to optimize as much as possible.
> The result
> > was that both aggressive mode and quick mode both have three messages.
> > The problem with three messages is that the initiator will
> often start sendin
> >g
> > actual traffic too soon, or quick mode packets, before the
> responder is ready
> >. Thus
> > the need for packet buffers, commit bit, whatever. This
> optimization causes d
> >esign
> > complications that I'd very much prefer to get rid of.
>
From owner-ipsec@lists.tislabs.com Wed Aug 8 14:12:25 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78LCON28580;
Wed, 8 Aug 2001 14:12:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19918
Wed, 8 Aug 2001 16:17:52 -0400 (EDT)
To: "Brian Swander" <briansw@windows.microsoft.com>
Cc: "Dan Harkins" <dharkins@lounge.org>,
"Ari Huttunen" <Ari.Huttunen@F-Secure.com>, ipsec@lists.tislabs.com
In-reply-to: briansw's message of Wed, 08 Aug 2001 11:52:09 MST.
<2E33960095B58E40A4D3345AB9F65EC1A4E8D6@win-msg-01.wingroup.windeploy.ntdev.microsoft.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: Simplifying IKE
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Thu, 09 Aug 2001 05:24:25 +0900
Message-Id: <20010808202425.525497BB@starfruit.itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>I'd prefer to keep the commit bit. Otherwise the responder is forced to
>add SAs before the final QM hash from the initiator is processed,
>opening the responder up to adding potentially suspect SAs into the
>system.
regarding to commit bit processing, we should really look again
about 3-phase commit protocol as discussed in distributed database
textbooks, and follow their suggestions.
it's very wrong for both ends to go unsynchronized on packet losses.
itojun
From owner-ipsec@lists.tislabs.com Wed Aug 8 14:39:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78LdBN11024;
Wed, 8 Aug 2001 14:39:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20029
Wed, 8 Aug 2001 16:53:13 -0400 (EDT)
Date: Wed, 8 Aug 2001 13:59:37 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: sankar ramamoorthi <sankar@nexsi.com>
cc: Dan Harkins <dharkins@lounge.org>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
In-Reply-To: <DIEPJEEKAPMEEKEELGGCCEAADEAA.sankar@nexsi.com>
Message-ID: <Pine.LNX.4.21.0108081358030.4332-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 8 Aug 2001, sankar ramamoorthi wrote:
>
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> > Sent: Wednesday, August 08, 2001 10:49 AM
> > To: Ari Huttunen
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: Simplifying IKE
> >
> >
> > My tentative text on the subject is to get rid of the commit bit and
> > have a 3 message exchange. The problem with the existing 3 message
> > exchanage (w/o the commit bit being used) is that the Responder will not
> > instantiate her SAs until receipt of the 3rd message from the Initiator
> > to avoid a resource consumption attack but the Initiator will instantiate
> > his SAs upon receipt of the 2nd message from the Responder. This results
> > in a race between the first few IPsec-protected packets and the final
> > message. If the former win they get dropped.
> >
> > My proposal is that the Responder instantiate the SAs when she sends
> > the 2nd message back to the Initiator. She will be setting a timer to
> > deal with non-receipt of the 3rd message and if the timer fires
> > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> > and she can delete these SAs from her SADB.
>
> What happens if the initiator starts sending data before the responder
> receives the third message?
>
> Will the ipsec packet from initiator be processed since responder has
> established the SA on receipt of the second message? If so, can the
> responder treat succesful processing of the data packet as succesful
> authentication of the initiator and mark the SA as valid(basically
> treat the condition same as processing a successful third message).
>
> Personally I prefer a 4 packet exchange model for QM.
>
Or figure out a way to address the replay issues, and drop the 3rd message,
making a 2 message exchange. I favor an even number of messages. Whether
that's 2 or 4 I don't MUCH care (2 would be preferable if we can figure out
how). An odd number of messages leads to kludges concerning how and when to
install resources and timers to detect the lack of 3rd message, and so forth.
If need be, I'm all for 4 messages, as well.
jan
> >
> > In addition to this text there is new text instructing implementations
> > to deal with receipt of an offer to create an IPsec SA with a SPI that
> > is currently in use as an error, and new text instructing the Initiator
> > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in case
> > it is dropped and he receives a retransmitted 2nd message from the
> > Responder.
> >
> > This is much simpler than what we have and solves the race problem.
> > What it does, though, is allow for some resources to be temporarily
> > consumed due to the replay of an old message. I don't view this as that
> > big of a problem though since it is temporary (RETRANSMIT_TIME *
> > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
> > the SADB) and the number of possible packets that can be replayed is
> > limited and bounded by the life of the IKE SA.
> >
> > Thoughts?
> >
> > Dan.
> >
> > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> > >
> > > Dan McDonald wrote:
> > > >
> > > > > >From the Schneier and Ferguson analysis we get:
> > > > >
> > > > > Can we drop the commit bit?
> > > >
> > > > Who uses it?
> > >
> > > I guess someone in past figured out that running IKE on satellite lines
> > > is necessary, so they decided to optimize as much as possible.
> > The result
> > > was that both aggressive mode and quick mode both have three messages.
> > > The problem with three messages is that the initiator will
> > often start sendin
> > >g
> > > actual traffic too soon, or quick mode packets, before the
> > responder is ready
> > >. Thus
> > > the need for packet buffers, commit bit, whatever. This
> > optimization causes d
> > >esign
> > > complications that I'd very much prefer to get rid of.
> >
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Wed Aug 8 14:53:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78LrPN20911;
Wed, 8 Aug 2001 14:53:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20017
Wed, 8 Aug 2001 16:51:59 -0400 (EDT)
Date: Wed, 8 Aug 2001 13:57:15 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Brian Swander <briansw@windows.microsoft.com>
cc: Dan Harkins <dharkins@lounge.org>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1A4E8D6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <Pine.LNX.4.21.0108081353080.4332-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 8 Aug 2001, Brian Swander wrote:
> I'd prefer to keep the commit bit. Otherwise the responder is forced to
> add SAs before the final QM hash from the initiator is processed,
> opening the responder up to adding potentially suspect SAs into the
> system.
>
I'd actually prefer to formalize the concept that the commit-bit is trying to
address:
1) Either expand quick mode to 4 messages. That's unambiguous, and leads to
better interop. A commit bit is really a kludge.
2) If you think about it, the 3rd message is only needed to prevent replay
attacks of old messages. If we addressed this some other way (say a timestamp
field, but that has obvious other problems), then we could drop the 3rd
message, and have 2, which is again 'good (tm)'.
Dan also outlined some other ways to address this problem, and while they
work, I don't much care for them, since they're really work-arounds to the
problem above. It would be preferable to address the replay attacks in some
other way (if possible) and do away with the 3rd message, or bite the bullet
and create a 4th message as an ACK to make the exchange as unambiguous as
possible.
I point out that KINK manages to use 2 messages, which are (used to be)
essentially a quick mode exchange. It uses kerberos to handle the replay
attacks, which involves timestamps. There are surely other ways of addressing
the replay issue, like a counter or something else. If we could use two
messages for quick mode, that would solve all this commit-bit versus 'when to
install the resources' issues....
jan
> I am not so concerned with the resources in an attack, but more worried
> about an attacker potentially getting an SA into the system that could
> be exploited. I don't see how this could be done today (all I can see
> is the obvious replay attack Dan is talking about), but that doesn't
> mean that such an exploit doesn't exist. So, I am much more comfortable
> with the one extra packet and the assurance that everything is ok with
> the negotiation before SAs are added.
>
> Of course, if someone has a proof that the security can't be violated by
> adding the responder SAs early, then I'd agree to eliminating the commit
> bit (except for backwards compatibility, when we'd still need to support
> it).
>
> bs
>
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Wednesday, August 08, 2001 10:49 AM
> To: Ari Huttunen
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Simplifying IKE
>
> My tentative text on the subject is to get rid of the commit bit and
> have a 3 message exchange. The problem with the existing 3 message
> exchanage (w/o the commit bit being used) is that the Responder will not
> instantiate her SAs until receipt of the 3rd message from the Initiator
> to avoid a resource consumption attack but the Initiator will
> instantiate
> his SAs upon receipt of the 2nd message from the Responder. This results
> in a race between the first few IPsec-protected packets and the final
> message. If the former win they get dropped.
>
> My proposal is that the Responder instantiate the SAs when she sends
> the 2nd message back to the Initiator. She will be setting a timer to
> deal with non-receipt of the 3rd message and if the timer fires
> RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> and she can delete these SAs from her SADB.
>
> In addition to this text there is new text instructing implementations
> to deal with receipt of an offer to create an IPsec SA with a SPI that
> is currently in use as an error, and new text instructing the Initiator
> to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in
> case
> it is dropped and he receives a retransmitted 2nd message from the
> Responder.
>
> This is much simpler than what we have and solves the race problem.
> What it does, though, is allow for some resources to be temporarily
> consumed due to the replay of an old message. I don't view this as that
> big of a problem though since it is temporary (RETRANSMIT_TIME *
> RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
> the SADB) and the number of possible packets that can be replayed is
> limited and bounded by the life of the IKE SA.
>
> Thoughts?
>
> Dan.
>
> On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> >
> > Dan McDonald wrote:
> > >
> > > > >From the Schneier and Ferguson analysis we get:
> > > >
> > > > Can we drop the commit bit?
> > >
> > > Who uses it?
> >
> > I guess someone in past figured out that running IKE on satellite
> lines
> > is necessary, so they decided to optimize as much as possible. The
> result
> > was that both aggressive mode and quick mode both have three messages.
> > The problem with three messages is that the initiator will often start
> sendin
> >g
> > actual traffic too soon, or quick mode packets, before the responder
> is ready
> >. Thus
> > the need for packet buffers, commit bit, whatever. This optimization
> causes d
> >esign
> > complications that I'd very much prefer to get rid of.
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Wed Aug 8 15:18:59 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78MIwN21541;
Wed, 8 Aug 2001 15:18:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20171
Wed, 8 Aug 2001 17:33:19 -0400 (EDT)
From: "Scott G. Kelly" <skelly@redcreek.com>
To: Derrell Piper <ddp@cips.nokia.com>
Cc: Ari Huttunen <Ari.Huttunen@F-Secure.com>,
Dan McDonald
<danmcd@East.Sun.COM>, Sandy Harris <sandy@storm.ca>,
ipsec@lists.tislabs.com
Message-ID: <3B71B1E3.C618C83A@redcreek.com>
Date: Wed, 08 Aug 2001 14:40:51 -0700
Organization: RedCreek Communications
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: Simplifying IKE
References: <200108080219.f782JIp00242@kebe.east.sun.com>
<3B710406.1175A60@F-Secure.com> <461410.997253930@el-air-1.electric-loft.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I agree with Derrell - if you remove commit bit, you must add a
mandatory fourth qm message (which would be fine with me).
Scott
Derrell Piper wrote:
>
> The other property that commit-bit processing buys you is that the third
> message of QM is now protected by the IKE retransmit timer and thus QM is
> guaranteed to complete enough for both sides to generate IPsec SA's, even
> when the last message (the ISAKMP Notify "CONNECTED") is lost. If you
> don't use commit-bit processing, the last message of QM can be dropped and
> this leaves you in the particularly bad state where one side has SA's and
> the other doesn't.
>
> Personally, I would rather burn a full network exchange to ensure that my
> really expensive key agreement protocol actually completes instead of
> having to just hope that the network didn't drop my last packet, which is
> what you're betting on today when you don't use the commit-bit.
>
> Derrell
>
> --On Wednesday, August 8, 2001 12:19 PM +0300 Ari Huttunen
> <Ari.Huttunen@F-Secure.com> wrote:
>
> >> > Can we drop the commit bit?
> >>
> >> Who uses it?
> >
> > I guess someone in past figured out that running IKE on satellite lines
> > is necessary, so they decided to optimize as much as possible. The result
> > was that both aggressive mode and quick mode both have three messages.
> > The problem with three messages is that the initiator will often start
> > sending actual traffic too soon, or quick mode packets, before the
> > responder is ready. Thus the need for packet buffers, commit bit,
> > whatever. This optimization causes design complications that I'd very
> > much prefer to get rid of.
> >
> > Thus my preference would be to have a four packet phase 1 (base mode) and
> > a four packet quick mode.
> >
> > The other reason I prefer base mode is that the responder can select the
> > proper policy based on the first packet.
> >
> > If main mode had the possibility to send a group identity in packet one
> > and actual identity in packet five, I wouldn't object to just having main
> > mode, since it does have an even number of packets.
From owner-ipsec@lists.tislabs.com Wed Aug 8 16:30:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f78NU7N24901;
Wed, 8 Aug 2001 16:30:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20336
Wed, 8 Aug 2001 18:40:57 -0400 (EDT)
Message-ID: <D1C012AEFCFBD111AC4100A0C9B8DB6F0976A84A@hdsmsx30.hd.intel.com>
From: "Treleaven, Russell" <russell.treleaven@intel.com>
To: ipsec@lists.tislabs.com
Subject: pki alt-subject and unstructured name
Date: Wed, 8 Aug 2001 15:47:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
I am trying to locate the authoritative document regarding alt-subject and
unstructured name fields in x509 certificates.
What I'm trying to find out is how they are used to map enrollment requests
from one scep server to multiple ca's?
Sincerely,
Russell Treleaven
Intel Canada
From owner-ipsec@lists.tislabs.com Wed Aug 8 19:22:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f792MHN27319;
Wed, 8 Aug 2001 19:22:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20741
Wed, 8 Aug 2001 21:25:40 -0400 (EDT)
Message-Id: <200108090131.f791VhT00646@dharkins@lounge.orgatty.lounge.org>
To: "sankar ramamoorthi" <sankar@nexsi.com>
Cc: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: Your message of "Wed, 08 Aug 2001 13:31:43 PDT."
<DIEPJEEKAPMEEKEELGGCCEAADEAA.sankar@nexsi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <643.997320703.1@lounge.org>
Date: Wed, 08 Aug 2001 18:31:43 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 08 Aug 2001 13:31:43 PDT you wrote
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> > Sent: Wednesday, August 08, 2001 10:49 AM
> > To: Ari Huttunen
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: Simplifying IKE
> >
> >
> > My tentative text on the subject is to get rid of the commit bit and
> > have a 3 message exchange. The problem with the existing 3 message
> > exchanage (w/o the commit bit being used) is that the Responder will not
> > instantiate her SAs until receipt of the 3rd message from the Initiator
> > to avoid a resource consumption attack but the Initiator will instantiate
> > his SAs upon receipt of the 2nd message from the Responder. This results
> > in a race between the first few IPsec-protected packets and the final
> > message. If the former win they get dropped.
> >
> > My proposal is that the Responder instantiate the SAs when she sends
> > the 2nd message back to the Initiator. She will be setting a timer to
> > deal with non-receipt of the 3rd message and if the timer fires
> > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> > and she can delete these SAs from her SADB.
>
> What happens if the initiator starts sending data before the responder
> receives the third message?
Nothing. That's the whole idea.
> Will the ipsec packet from initiator be processed since responder has
> established the SA on receipt of the second message? If so, can the
> responder treat succesful processing of the data packet as succesful
> authentication of the initiator and mark the SA as valid(basically
> treat the condition same as processing a successful third message).
I prefer not to make such a linkage (between the IPsec processing engine
and the key management system) since there is still a message that IKE must
process and receipt of that message will dictate whether the SAs stay
or go.
> Personally I prefer a 4 packet exchange model for QM.
What shortcoming in the scheme I described is solved with a 4 packet
exchange?
Dan.
From owner-ipsec@lists.tislabs.com Wed Aug 8 19:32:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f792WnN27457;
Wed, 8 Aug 2001 19:32:49 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20713
Wed, 8 Aug 2001 21:19:39 -0400 (EDT)
Message-Id: <200108090125.f791PcT00595@dharkins@lounge.orgatty.lounge.org>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: Your message of "Wed, 08 Aug 2001 15:39:32 EDT."
<200108081939.f78JdWr11860@marajade.sandelman.ottawa.on.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <592.997320338.1@lounge.org>
Date: Wed, 08 Aug 2001 18:25:38 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 08 Aug 2001 15:39:32 EDT you wrote
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> >>>>> "Dan" == Dan Harkins <dharkins@lounge.org> writes:
> Dan> The problem with MIPv6 is that the Binding Update is a destination
> Dan> option which they would like authenticated. But there is no way for
> Dan> an IPsec selector to be defined to identify certain types of destin
>ation
> Dan> options. The choice is to authenticate _everything_ which they don'
>t
> Dan> want to do or authenticate _nothing_ which they can't do. This has
> Dan> nothing to do with IKE.
>
> Well, there is no standard way.
>
> Within a unified stack, (not BITW or BITS) the packets with the binding
> update can easily be marked for IPsec processor via out-of-band means
> (i.e. in the control structure).
Then the problem is on the other end. The selector either says every
packet _MUST_ be IPsec-protected or else it _MUST NOT_ be IPsec-protected.
Either way, if some packets--those with Binding Updates-- are received with
IPsec protection and others-- those without Binding Updates-- are not then
we're going to have a problem.
Dan.
From owner-ipsec@lists.tislabs.com Wed Aug 8 19:34:00 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f792Y0N27476;
Wed, 8 Aug 2001 19:34:00 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20779
Wed, 8 Aug 2001 21:36:55 -0400 (EDT)
Message-Id: <200108090142.f791glT00666@dharkins@lounge.orgatty.lounge.org>
To: Jan Vilhuber <vilhuber@cisco.com>
Cc: Brian Swander <briansw@windows.microsoft.com>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: Your message of "Wed, 08 Aug 2001 13:57:15 PDT."
<Pine.LNX.4.21.0108081353080.4332-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <663.997321367.1@lounge.org>
Date: Wed, 08 Aug 2001 18:42:47 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Why is one mandated processing of packets a solution and another a
"work around"? If the "work around" solves the problem in one less
message then why isn't that preferable? Wouldn't adding a timestamp to
the exchange be a "kludge"? Or a "work around"?
The only reason the Responder doesn't instantiate the SAs after sending
the 2nd message today is because of concerns about a resource consumption
attack. I feel those concerns are small due to the small time in which
the bogus SAs would be in the SADB, the inability of an attacker to use
them (due to the inability of a 3rd party to know SKEYID state), and the
small (and quantifiable) number of messages that can possibly be exchanged.
Instantiate them and delete them if the 3rd message is never received!
So we have very few messages which can be replayed and a well-defined
method of dealing with the cases in which they are replayed. Why is that
not satisfactory? What is the problem with this that is solved by adding
a 4th message?
Dan.
On Wed, 08 Aug 2001 13:57:15 PDT you wrote
> I'd actually prefer to formalize the concept that the commit-bit is trying to
> address:
>
> 1) Either expand quick mode to 4 messages. That's unambiguous, and leads to
> better interop. A commit bit is really a kludge.
>
> 2) If you think about it, the 3rd message is only needed to prevent replay
> attacks of old messages. If we addressed this some other way (say a timestamp
> field, but that has obvious other problems), then we could drop the 3rd
> message, and have 2, which is again 'good (tm)'.
>
> Dan also outlined some other ways to address this problem, and while they
> work, I don't much care for them, since they're really work-arounds to the
> problem above. It would be preferable to address the replay attacks in some
> other way (if possible) and do away with the 3rd message, or bite the bullet
> and create a 4th message as an ACK to make the exchange as unambiguous as
> possible.
>
> I point out that KINK manages to use 2 messages, which are (used to be)
> essentially a quick mode exchange. It uses kerberos to handle the replay
> attacks, which involves timestamps. There are surely other ways of addressing
> the replay issue, like a counter or something else. If we could use two
> messages for quick mode, that would solve all this commit-bit versus 'when to
> install the resources' issues....
>
> jan
>
>
>
> > I am not so concerned with the resources in an attack, but more worried
> > about an attacker potentially getting an SA into the system that could
> > be exploited. I don't see how this could be done today (all I can see
> > is the obvious replay attack Dan is talking about), but that doesn't
> > mean that such an exploit doesn't exist. So, I am much more comfortable
> > with the one extra packet and the assurance that everything is ok with
> > the negotiation before SAs are added.
> >
> > Of course, if someone has a proof that the security can't be violated by
> > adding the responder SAs early, then I'd agree to eliminating the commit
> > bit (except for backwards compatibility, when we'd still need to support
> > it).
> >
> > bs
> >
> > -----Original Message-----
> > From: Dan Harkins [mailto:dharkins@lounge.org]
> > Sent: Wednesday, August 08, 2001 10:49 AM
> > To: Ari Huttunen
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: Simplifying IKE
> >
> > My tentative text on the subject is to get rid of the commit bit and
> > have a 3 message exchange. The problem with the existing 3 message
> > exchanage (w/o the commit bit being used) is that the Responder will not
> > instantiate her SAs until receipt of the 3rd message from the Initiator
> > to avoid a resource consumption attack but the Initiator will
> > instantiate
> > his SAs upon receipt of the 2nd message from the Responder. This results
> > in a race between the first few IPsec-protected packets and the final
> > message. If the former win they get dropped.
> >
> > My proposal is that the Responder instantiate the SAs when she sends
> > the 2nd message back to the Initiator. She will be setting a timer to
> > deal with non-receipt of the 3rd message and if the timer fires
> > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> > and she can delete these SAs from her SADB.
> >
> > In addition to this text there is new text instructing implementations
> > to deal with receipt of an offer to create an IPsec SA with a SPI that
> > is currently in use as an error, and new text instructing the Initiator
> > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in
> > case
> > it is dropped and he receives a retransmitted 2nd message from the
> > Responder.
> >
> > This is much simpler than what we have and solves the race problem.
> > What it does, though, is allow for some resources to be temporarily
> > consumed due to the replay of an old message. I don't view this as that
> > big of a problem though since it is temporary (RETRANSMIT_TIME *
> > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
> > the SADB) and the number of possible packets that can be replayed is
> > limited and bounded by the life of the IKE SA.
> >
> > Thoughts?
> >
> > Dan.
> >
> > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> > >
> > > Dan McDonald wrote:
> > > >
> > > > > >From the Schneier and Ferguson analysis we get:
> > > > >
> > > > > Can we drop the commit bit?
> > > >
> > > > Who uses it?
> > >
> > > I guess someone in past figured out that running IKE on satellite
> > lines
> > > is necessary, so they decided to optimize as much as possible. The
> > result
> > > was that both aggressive mode and quick mode both have three messages.
> > > The problem with three messages is that the initiator will often start
> > sendin
> > >g
> > > actual traffic too soon, or quick mode packets, before the responder
> > is ready
> > >. Thus
> > > the need for packet buffers, commit bit, whatever. This optimization
> > causes d
> > >esign
> > > complications that I'd very much prefer to get rid of.
> >
>
> --
> Jan Vilhuber vilhuber@cisco.com
> Cisco Systems, San Jose (408) 527-0847
>
From owner-ipsec@lists.tislabs.com Wed Aug 8 19:54:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f792sSN27876;
Wed, 8 Aug 2001 19:54:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20847
Wed, 8 Aug 2001 21:57:50 -0400 (EDT)
From: "sankar ramamoorthi" <sankar@nexsi.com>
To: "Dan Harkins" <dharkins@lounge.org>
Cc: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>, <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Wed, 8 Aug 2001 19:04:25 -0700
Message-ID: <DIEPJEEKAPMEEKEELGGCAEAIDEAA.sankar@nexsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <200108090131.f791VhT00646@dharkins@lounge.orgatty.lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Wednesday, August 08, 2001 6:32 PM
> To: sankar ramamoorthi
> Cc: Ari Huttunen; ipsec@lists.tislabs.com
> Subject: Re: Simplifying IKE
>
>
> On Wed, 08 Aug 2001 13:31:43 PDT you wrote
> > > -----Original Message-----
> > > From: owner-ipsec@lists.tislabs.com
> > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> > > Sent: Wednesday, August 08, 2001 10:49 AM
> > > To: Ari Huttunen
> > > Cc: ipsec@lists.tislabs.com
> > > Subject: Re: Simplifying IKE
> > >
> > >
> > > My tentative text on the subject is to get rid of the commit bit and
> > > have a 3 message exchange. The problem with the existing 3 message
> > > exchanage (w/o the commit bit being used) is that the
> Responder will not
> > > instantiate her SAs until receipt of the 3rd message from the
> Initiator
> > > to avoid a resource consumption attack but the Initiator will
> instantiate
> > > his SAs upon receipt of the 2nd message from the Responder.
> This results
> > > in a race between the first few IPsec-protected packets and the final
> > > message. If the former win they get dropped.
> > >
> > > My proposal is that the Responder instantiate the SAs when she sends
> > > the 2nd message back to the Initiator. She will be setting a timer to
> > > deal with non-receipt of the 3rd message and if the timer fires
> > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> > > and she can delete these SAs from her SADB.
> >
> > What happens if the initiator starts sending data before the responder
> > receives the third message?
>
> Nothing. That's the whole idea.
which means in the worst case packets from the sender will be dropped for
the duration (RETRANSMIT_TIMER_LIMIT * round-trip-time).
This leads to an ambiguous state where the packets may or not be dropped
by the responder. It is also possible that if initiator is sending data
at a high rate, it could affect the responder from retransmitting message2
and getting message3.
With a 4 packet exhange scheme, each party knows for sure the other side
has the SA established before sending data. The state transitions seem
to be much cleaner here.
Both solutions require that the COMFORT_LEVEL_TIME is set be greater
than equal to (RETRANSMIT_TIMER_LIMIT * round-trip-time) to ensure the
initiator keeps the state around long enough for the responder to
move from processed-message1-state to processed-message3-state
(or processed-message2-state to processed-message4-state in the case of
4 packet exchange).
>
> > Will the ipsec packet from initiator be processed since responder has
> > established the SA on receipt of the second message? If so, can the
> > responder treat succesful processing of the data packet as succesful
> > authentication of the initiator and mark the SA as valid(basically
> > treat the condition same as processing a successful third message).
>
> I prefer not to make such a linkage (between the IPsec processing engine
> and the key management system) since there is still a message
> that IKE must
> process and receipt of that message will dictate whether the SAs stay
> or go.
>
I agree - this was just an idea that I threw around to see if
it is possible to come up with a 2 message solution.
> > Personally I prefer a 4 packet exchange model for QM.
>
> What shortcoming in the scheme I described is solved with a 4 packet
> exchange?
>
see above.
> Dan.
>
From owner-ipsec@lists.tislabs.com Wed Aug 8 19:57:56 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f792vtN28302;
Wed, 8 Aug 2001 19:57:55 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20848
Wed, 8 Aug 2001 21:57:51 -0400 (EDT)
Date: Wed, 8 Aug 2001 19:04:14 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Dan Harkins <dharkins@lounge.org>
cc: Brian Swander <briansw@windows.microsoft.com>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <200108090142.f791glT00666@dharkins@lounge.orgatty.lounge.org>
Message-ID: <Pine.LNX.4.21.0108081854160.4332-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 8 Aug 2001, Dan Harkins wrote:
> Why is one mandated processing of packets a solution and another a
> "work around"? If the "work around" solves the problem in one less
> message then why isn't that preferable? Wouldn't adding a timestamp to
> the exchange be a "kludge"? Or a "work around"?
>
As you say, both work. One strikes me as more aesthetically pleasing, or
cleaner, i.e. a 4th message is part of the protocol, and you don't need much
verbiage to tell people how to handle the sync between IKE and ipsec in a 3
message scenario. It's therefore much cleaner and offers better chances of
passing interop (the more verbiage to explain something, the more you give
people to argue what was meant by the verbiage).
> The only reason the Responder doesn't instantiate the SAs after sending
> the 2nd message today is because of concerns about a resource consumption
> attack. I feel those concerns are small due to the small time in which
> the bogus SAs would be in the SADB, the inability of an attacker to use
> them (due to the inability of a 3rd party to know SKEYID state), and the
> small (and quantifiable) number of messages that can possibly be exchanged.
> Instantiate them and delete them if the 3rd message is never received!
>
Or wait for a 4th message to confirm. I grant you they are almost the same.
> So we have very few messages which can be replayed and a well-defined
> method of dealing with the cases in which they are replayed. Why is that
> not satisfactory? What is the problem with this that is solved by adding
> a 4th message?
>
It's an explicit ACK, rather than relying on implicit behaviour of lacking
the 3rd message. It just strikes me as cleaner. it's all software. We can
implement almost anything in software. Question is how. And obviously
different people have different ideas of 'cleanliness' and different
definition of 'obvious' (as we can tell from dangling SA and continuous
channel fiascos).
Telling IPSec to instantiate a single SA, and then later possibly revoking
it, just doesn't seem as clean to me. I'd rather only tell ipsec to go ahead
and do its thing when IKE is completely 100% sure that we're done.
I also realize that KINK does what you propose. I didn't much like it there,
either. So be it. The very fact that it has to be explained, rather than
having a protocol definition, makes me nervous. But if it can be explained
very simply, and you are confident that people won't find things they claim
were open to interpretation (what do you mean I shouldn't delete my IPSec
Sa's when the IKE SA that created them dies?! Duh...), then I'm OK with it.
To put it a different way: Define the protocol, and when the protocol has
unambiguously finished, THEN (and only then) tell ipsec to proceed. This
doesn't leave things open to interpretation of exactly when one SA should be
instantiated and when the next should be instantiated, and so on. Maybe I'm
just being pedantic. Being pedantic should be a good thing right now, so we
don't repeat the past with son-of-IKE (did we decide it's 'doud', pronounced
'dude'?? ;)
Different folks, different strokes...
jan
> Dan.
>
> On Wed, 08 Aug 2001 13:57:15 PDT you wrote
> > I'd actually prefer to formalize the concept that the commit-bit is trying to
> > address:
> >
> > 1) Either expand quick mode to 4 messages. That's unambiguous, and leads to
> > better interop. A commit bit is really a kludge.
> >
> > 2) If you think about it, the 3rd message is only needed to prevent replay
> > attacks of old messages. If we addressed this some other way (say a timestamp
> > field, but that has obvious other problems), then we could drop the 3rd
> > message, and have 2, which is again 'good (tm)'.
> >
> > Dan also outlined some other ways to address this problem, and while they
> > work, I don't much care for them, since they're really work-arounds to the
> > problem above. It would be preferable to address the replay attacks in some
> > other way (if possible) and do away with the 3rd message, or bite the bullet
> > and create a 4th message as an ACK to make the exchange as unambiguous as
> > possible.
> >
> > I point out that KINK manages to use 2 messages, which are (used to be)
> > essentially a quick mode exchange. It uses kerberos to handle the replay
> > attacks, which involves timestamps. There are surely other ways of addressing
> > the replay issue, like a counter or something else. If we could use two
> > messages for quick mode, that would solve all this commit-bit versus 'when to
> > install the resources' issues....
> >
> > jan
> >
> >
> >
> > > I am not so concerned with the resources in an attack, but more worried
> > > about an attacker potentially getting an SA into the system that could
> > > be exploited. I don't see how this could be done today (all I can see
> > > is the obvious replay attack Dan is talking about), but that doesn't
> > > mean that such an exploit doesn't exist. So, I am much more comfortable
> > > with the one extra packet and the assurance that everything is ok with
> > > the negotiation before SAs are added.
> > >
> > > Of course, if someone has a proof that the security can't be violated by
> > > adding the responder SAs early, then I'd agree to eliminating the commit
> > > bit (except for backwards compatibility, when we'd still need to support
> > > it).
> > >
> > > bs
> > >
> > > -----Original Message-----
> > > From: Dan Harkins [mailto:dharkins@lounge.org]
> > > Sent: Wednesday, August 08, 2001 10:49 AM
> > > To: Ari Huttunen
> > > Cc: ipsec@lists.tislabs.com
> > > Subject: Re: Simplifying IKE
> > >
> > > My tentative text on the subject is to get rid of the commit bit and
> > > have a 3 message exchange. The problem with the existing 3 message
> > > exchanage (w/o the commit bit being used) is that the Responder will not
> > > instantiate her SAs until receipt of the 3rd message from the Initiator
> > > to avoid a resource consumption attack but the Initiator will
> > > instantiate
> > > his SAs upon receipt of the 2nd message from the Responder. This results
> > > in a race between the first few IPsec-protected packets and the final
> > > message. If the former win they get dropped.
> > >
> > > My proposal is that the Responder instantiate the SAs when she sends
> > > the 2nd message back to the Initiator. She will be setting a timer to
> > > deal with non-receipt of the 3rd message and if the timer fires
> > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> > > and she can delete these SAs from her SADB.
> > >
> > > In addition to this text there is new text instructing implementations
> > > to deal with receipt of an offer to create an IPsec SA with a SPI that
> > > is currently in use as an error, and new text instructing the Initiator
> > > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in
> > > case
> > > it is dropped and he receives a retransmitted 2nd message from the
> > > Responder.
> > >
> > > This is much simpler than what we have and solves the race problem.
> > > What it does, though, is allow for some resources to be temporarily
> > > consumed due to the replay of an old message. I don't view this as that
> > > big of a problem though since it is temporary (RETRANSMIT_TIME *
> > > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
> > > the SADB) and the number of possible packets that can be replayed is
> > > limited and bounded by the life of the IKE SA.
> > >
> > > Thoughts?
> > >
> > > Dan.
> > >
> > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> > > >
> > > > Dan McDonald wrote:
> > > > >
> > > > > > >From the Schneier and Ferguson analysis we get:
> > > > > >
> > > > > > Can we drop the commit bit?
> > > > >
> > > > > Who uses it?
> > > >
> > > > I guess someone in past figured out that running IKE on satellite
> > > lines
> > > > is necessary, so they decided to optimize as much as possible. The
> > > result
> > > > was that both aggressive mode and quick mode both have three messages.
> > > > The problem with three messages is that the initiator will often start
> > > sendin
> > > >g
> > > > actual traffic too soon, or quick mode packets, before the responder
> > > is ready
> > > >. Thus
> > > > the need for packet buffers, commit bit, whatever. This optimization
> > > causes d
> > > >esign
> > > > complications that I'd very much prefer to get rid of.
> > >
> >
> > --
> > Jan Vilhuber vilhuber@cisco.com
> > Cisco Systems, San Jose (408) 527-0847
> >
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Wed Aug 8 20:16:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f793G6N28663;
Wed, 8 Aug 2001 20:16:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20891
Wed, 8 Aug 2001 22:11:23 -0400 (EDT)
Date: Wed, 8 Aug 2001 19:17:52 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Dan Harkins <dharkins@lounge.org>
cc: Brian Swander <briansw@windows.microsoft.com>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.LNX.4.21.0108081854160.4332-100000@janpc-home.cisco.com>
Message-ID: <Pine.LNX.4.21.0108081915350.4332-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
P.S. I really would prefer a 2 message version, if some smart cookie out
there can figure out how to guard against replay attacks. That would be the
coolest...
jan
On Wed, 8 Aug 2001, Jan Vilhuber wrote:
> On Wed, 8 Aug 2001, Dan Harkins wrote:
>
> > Why is one mandated processing of packets a solution and another a
> > "work around"? If the "work around" solves the problem in one less
> > message then why isn't that preferable? Wouldn't adding a timestamp to
> > the exchange be a "kludge"? Or a "work around"?
> >
> As you say, both work. One strikes me as more aesthetically pleasing, or
> cleaner, i.e. a 4th message is part of the protocol, and you don't need much
> verbiage to tell people how to handle the sync between IKE and ipsec in a 3
> message scenario. It's therefore much cleaner and offers better chances of
> passing interop (the more verbiage to explain something, the more you give
> people to argue what was meant by the verbiage).
>
> > The only reason the Responder doesn't instantiate the SAs after sending
> > the 2nd message today is because of concerns about a resource consumption
> > attack. I feel those concerns are small due to the small time in which
> > the bogus SAs would be in the SADB, the inability of an attacker to use
> > them (due to the inability of a 3rd party to know SKEYID state), and the
> > small (and quantifiable) number of messages that can possibly be exchanged.
> > Instantiate them and delete them if the 3rd message is never received!
> >
>
> Or wait for a 4th message to confirm. I grant you they are almost the same.
>
> > So we have very few messages which can be replayed and a well-defined
> > method of dealing with the cases in which they are replayed. Why is that
> > not satisfactory? What is the problem with this that is solved by adding
> > a 4th message?
> >
> It's an explicit ACK, rather than relying on implicit behaviour of lacking
> the 3rd message. It just strikes me as cleaner. it's all software. We can
> implement almost anything in software. Question is how. And obviously
> different people have different ideas of 'cleanliness' and different
> definition of 'obvious' (as we can tell from dangling SA and continuous
> channel fiascos).
>
> Telling IPSec to instantiate a single SA, and then later possibly revoking
> it, just doesn't seem as clean to me. I'd rather only tell ipsec to go ahead
> and do its thing when IKE is completely 100% sure that we're done.
>
> I also realize that KINK does what you propose. I didn't much like it there,
> either. So be it. The very fact that it has to be explained, rather than
> having a protocol definition, makes me nervous. But if it can be explained
> very simply, and you are confident that people won't find things they claim
> were open to interpretation (what do you mean I shouldn't delete my IPSec
> Sa's when the IKE SA that created them dies?! Duh...), then I'm OK with it.
>
> To put it a different way: Define the protocol, and when the protocol has
> unambiguously finished, THEN (and only then) tell ipsec to proceed. This
> doesn't leave things open to interpretation of exactly when one SA should be
> instantiated and when the next should be instantiated, and so on. Maybe I'm
> just being pedantic. Being pedantic should be a good thing right now, so we
> don't repeat the past with son-of-IKE (did we decide it's 'doud', pronounced
> 'dude'?? ;)
>
> Different folks, different strokes...
> jan
>
>
>
>
>
> > Dan.
> >
> > On Wed, 08 Aug 2001 13:57:15 PDT you wrote
> > > I'd actually prefer to formalize the concept that the commit-bit is trying to
> > > address:
> > >
> > > 1) Either expand quick mode to 4 messages. That's unambiguous, and leads to
> > > better interop. A commit bit is really a kludge.
> > >
> > > 2) If you think about it, the 3rd message is only needed to prevent replay
> > > attacks of old messages. If we addressed this some other way (say a timestamp
> > > field, but that has obvious other problems), then we could drop the 3rd
> > > message, and have 2, which is again 'good (tm)'.
> > >
> > > Dan also outlined some other ways to address this problem, and while they
> > > work, I don't much care for them, since they're really work-arounds to the
> > > problem above. It would be preferable to address the replay attacks in some
> > > other way (if possible) and do away with the 3rd message, or bite the bullet
> > > and create a 4th message as an ACK to make the exchange as unambiguous as
> > > possible.
> > >
> > > I point out that KINK manages to use 2 messages, which are (used to be)
> > > essentially a quick mode exchange. It uses kerberos to handle the replay
> > > attacks, which involves timestamps. There are surely other ways of addressing
> > > the replay issue, like a counter or something else. If we could use two
> > > messages for quick mode, that would solve all this commit-bit versus 'when to
> > > install the resources' issues....
> > >
> > > jan
> > >
> > >
> > >
> > > > I am not so concerned with the resources in an attack, but more worried
> > > > about an attacker potentially getting an SA into the system that could
> > > > be exploited. I don't see how this could be done today (all I can see
> > > > is the obvious replay attack Dan is talking about), but that doesn't
> > > > mean that such an exploit doesn't exist. So, I am much more comfortable
> > > > with the one extra packet and the assurance that everything is ok with
> > > > the negotiation before SAs are added.
> > > >
> > > > Of course, if someone has a proof that the security can't be violated by
> > > > adding the responder SAs early, then I'd agree to eliminating the commit
> > > > bit (except for backwards compatibility, when we'd still need to support
> > > > it).
> > > >
> > > > bs
> > > >
> > > > -----Original Message-----
> > > > From: Dan Harkins [mailto:dharkins@lounge.org]
> > > > Sent: Wednesday, August 08, 2001 10:49 AM
> > > > To: Ari Huttunen
> > > > Cc: ipsec@lists.tislabs.com
> > > > Subject: Re: Simplifying IKE
> > > >
> > > > My tentative text on the subject is to get rid of the commit bit and
> > > > have a 3 message exchange. The problem with the existing 3 message
> > > > exchanage (w/o the commit bit being used) is that the Responder will not
> > > > instantiate her SAs until receipt of the 3rd message from the Initiator
> > > > to avoid a resource consumption attack but the Initiator will
> > > > instantiate
> > > > his SAs upon receipt of the 2nd message from the Responder. This results
> > > > in a race between the first few IPsec-protected packets and the final
> > > > message. If the former win they get dropped.
> > > >
> > > > My proposal is that the Responder instantiate the SAs when she sends
> > > > the 2nd message back to the Initiator. She will be setting a timer to
> > > > deal with non-receipt of the 3rd message and if the timer fires
> > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> > > > and she can delete these SAs from her SADB.
> > > >
> > > > In addition to this text there is new text instructing implementations
> > > > to deal with receipt of an offer to create an IPsec SA with a SPI that
> > > > is currently in use as an error, and new text instructing the Initiator
> > > > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in
> > > > case
> > > > it is dropped and he receives a retransmitted 2nd message from the
> > > > Responder.
> > > >
> > > > This is much simpler than what we have and solves the race problem.
> > > > What it does, though, is allow for some resources to be temporarily
> > > > consumed due to the replay of an old message. I don't view this as that
> > > > big of a problem though since it is temporary (RETRANSMIT_TIME *
> > > > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
> > > > the SADB) and the number of possible packets that can be replayed is
> > > > limited and bounded by the life of the IKE SA.
> > > >
> > > > Thoughts?
> > > >
> > > > Dan.
> > > >
> > > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> > > > >
> > > > > Dan McDonald wrote:
> > > > > >
> > > > > > > >From the Schneier and Ferguson analysis we get:
> > > > > > >
> > > > > > > Can we drop the commit bit?
> > > > > >
> > > > > > Who uses it?
> > > > >
> > > > > I guess someone in past figured out that running IKE on satellite
> > > > lines
> > > > > is necessary, so they decided to optimize as much as possible. The
> > > > result
> > > > > was that both aggressive mode and quick mode both have three messages.
> > > > > The problem with three messages is that the initiator will often start
> > > > sendin
> > > > >g
> > > > > actual traffic too soon, or quick mode packets, before the responder
> > > > is ready
> > > > >. Thus
> > > > > the need for packet buffers, commit bit, whatever. This optimization
> > > > causes d
> > > > >esign
> > > > > complications that I'd very much prefer to get rid of.
> > > >
> > >
> > > --
> > > Jan Vilhuber vilhuber@cisco.com
> > > Cisco Systems, San Jose (408) 527-0847
> > >
> >
>
> --
> Jan Vilhuber vilhuber@cisco.com
> Cisco Systems, San Jose (408) 527-0847
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Thu Aug 9 01:41:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f798fcN26635;
Thu, 9 Aug 2001 01:41:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21993
Thu, 9 Aug 2001 03:54:12 -0400 (EDT)
Message-Id: <200108090800.f7980D700535@dharkins@lounge.orgatty.lounge.org>
To: "sankar ramamoorthi" <sankar@nexsi.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: Your message of "Wed, 08 Aug 2001 19:04:25 PDT."
<DIEPJEEKAPMEEKEELGGCAEAIDEAA.sankar@nexsi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <532.997344013.1@lounge.org>
Date: Thu, 09 Aug 2001 01:00:13 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I'm obviously explaining myself poorly and that's not a good way
to start of this discussion....
On Wed, 08 Aug 2001 19:04:25 PDT you wrote
>
>
> > -----Original Message-----
> > From: Dan Harkins [mailto:dharkins@lounge.org]
> > Sent: Wednesday, August 08, 2001 6:32 PM
> > To: sankar ramamoorthi
> > Cc: Ari Huttunen; ipsec@lists.tislabs.com
> > Subject: Re: Simplifying IKE
> >
> >
> > On Wed, 08 Aug 2001 13:31:43 PDT you wrote
> > > > -----Original Message-----
> > > > From: owner-ipsec@lists.tislabs.com
> > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> > > > Sent: Wednesday, August 08, 2001 10:49 AM
> > > > To: Ari Huttunen
> > > > Cc: ipsec@lists.tislabs.com
> > > > Subject: Re: Simplifying IKE
> > > >
> > > >
> > > > My tentative text on the subject is to get rid of the commit bit and
> > > > have a 3 message exchange. The problem with the existing 3 message
> > > > exchanage (w/o the commit bit being used) is that the
> > Responder will not
> > > > instantiate her SAs until receipt of the 3rd message from the
> > Initiator
> > > > to avoid a resource consumption attack but the Initiator will
> > instantiate
> > > > his SAs upon receipt of the 2nd message from the Responder.
> > This results
> > > > in a race between the first few IPsec-protected packets and the final
> > > > message. If the former win they get dropped.
> > > >
> > > > My proposal is that the Responder instantiate the SAs when she sends
> > > > the 2nd message back to the Initiator. She will be setting a timer to
> > > > deal with non-receipt of the 3rd message and if the timer fires
> > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> > > > and she can delete these SAs from her SADB.
> > >
> > > What happens if the initiator starts sending data before the responder
> > > receives the third message?
> >
> > Nothing. That's the whole idea.
>
> which means in the worst case packets from the sender will be dropped for
> the duration (RETRANSMIT_TIMER_LIMIT * round-trip-time).
No, they are not dropped in any case. They are properly received because
the Responder has instantiated the SAs before she sends the 2nd message.
> This leads to an ambiguous state where the packets may or not be dropped
> by the responder. It is also possible that if initiator is sending data
> at a high rate, it could affect the responder from retransmitting message2
> and getting message3.
No it doesn't matter how fast the Initiator sends packets (assuming you
mean IPsec-protected packets) because the Responder will have properly
instantiated SAs _before_ the Initiator has. By the time the Initiator
has all the information to instantiate his own SAs the Responder will
already have instantiated hers. No packet loss.
> With a 4 packet exhange scheme, each party knows for sure the other side
> has the SA established before sending data. The state transitions seem
> to be much cleaner here.
I think you're misunderstanding what I'm proposing. If the Responder
instantiates her SAs when she sends the 2nd message then what's the
problem? How does this not work? The Responder has SAs ready before
the Initiator does so there is no packet loss.
> > > Will the ipsec packet from initiator be processed since responder has
> > > established the SA on receipt of the second message? If so, can the
> > > responder treat succesful processing of the data packet as succesful
> > > authentication of the initiator and mark the SA as valid(basically
> > > treat the condition same as processing a successful third message).
> >
> > I prefer not to make such a linkage (between the IPsec processing engine
> > and the key management system) since there is still a message
> > that IKE must
> > process and receipt of that message will dictate whether the SAs stay
> > or go.
> >
>
> I agree - this was just an idea that I threw around to see if
> it is possible to come up with a 2 message solution.
If you can come up with a 2 message solution I think we will all be
happy. Please do so; I cannot come up with one that is simpler than the
3 message one I'm proposing.
> > > Personally I prefer a 4 packet exchange model for QM.
> >
> > What shortcoming in the scheme I described is solved with a 4 packet
> > exchange?
> >
>
> see above.
I don't see a shortcoming above. Can you describe to me a situation that
will not work with what I propose but will work with a 4 message exchange?
Dan.
From owner-ipsec@lists.tislabs.com Thu Aug 9 01:41:41 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f798ffN26647;
Thu, 9 Aug 2001 01:41:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21633
Thu, 9 Aug 2001 03:28:13 -0400 (EDT)
Message-ID: <20010809073520.51370.qmail@web12304.mail.yahoo.com>
Date: Thu, 9 Aug 2001 00:35:20 -0700 (PDT)
From: Eva Jencusova <jencusova@yahoo.com>
Subject: Hash and Prf in IKE
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello,
I have one problem with IKE, in RFC 2409 in section
3.2 is written:
"prf(key, msg) is the keyed pseudo-random function--
often a keyed hash function"
And in section 5:
"Four different authentication methods are allowed
with either Main Mode or Aggressive Mode-- digital
signature, two forms of authentication with public key
encryption, or pre-shared key. The value SKEYID is
computed seperately for each authentication method.
For public key encryption:
SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R)"
- and here is the my problem problem prf function is
used to generate HASH_I and HASH_R as a a keyed hash
function and nowhere in the document I found what
"hash(Ni_b|Nr_b)" means.
Can anybody tell me?
Thans,
Eva Jencusova
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
From owner-ipsec@lists.tislabs.com Thu Aug 9 01:42:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f798gYN26666;
Thu, 9 Aug 2001 01:42:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21639
Thu, 9 Aug 2001 03:31:10 -0400 (EDT)
Message-ID: <00c401c120a6$e7688050$4e8d21d9@sfanninglaptop>
From: "Scott Fanning" <sfanning@cisco.com>
To: "Treleaven, Russell" <russell.treleaven@intel.com>,
<ipsec@lists.tislabs.com>
References: <D1C012AEFCFBD111AC4100A0C9B8DB6F0976A84A@hdsmsx30.hd.intel.com>
Subject: Re: pki alt-subject and unstructured name
Date: Thu, 9 Aug 2001 00:42:53 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I think the PKIX mailing list would be the place for that answer.
Scott
----- Original Message -----
From: "Treleaven, Russell" <russell.treleaven@intel.com>
To: <ipsec@lists.tislabs.com>
Sent: Wednesday, August 08, 2001 3:47 PM
Subject: pki alt-subject and unstructured name
> Hi,
>
> I am trying to locate the authoritative document regarding alt-subject and
> unstructured name fields in x509 certificates.
>
> What I'm trying to find out is how they are used to map enrollment
requests
> from one scep server to multiple ca's?
>
> Sincerely,
>
> Russell Treleaven
> Intel Canada
From owner-ipsec@lists.tislabs.com Thu Aug 9 03:27:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79ARAN03811;
Thu, 9 Aug 2001 03:27:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA22602
Thu, 9 Aug 2001 05:39:47 -0400 (EDT)
Message-Id: <200108090946.f799kJu76577@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Dan Harkins <dharkins@lounge.org>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of Wed, 08 Aug 2001 11:02:33 PDT.
<200108081802.f78I2XR00772@dharkins@lounge.orgatty.lounge.org>
Date: Thu, 09 Aug 2001 11:46:19 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
> ... The trouble of IPsec with MIPv6 is more IKE (the thing we are
> supposed to simplify): obviously to run IKE phases 1 & 2 in order
> to protect BUs (sometime a single small packet) is overkilling
Well, not really, and none of the simplifications being proposed or
planned for IKE would help MIPv6.
=> I disagree, it should help at least for other cases than the "random"
correspondent, for instance for the mobile node to home agent home
registration.
The problem with MIPv6 is that the Binding Update is a destination
option which they would like authenticated.
=> I believe you don't like piggybacking. I agree and it seems many
of us too (cf. the thread about it in the mobileip mailing list).
Just assume we have got the head of piggybacking...
But there is no way for
an IPsec selector to be defined to identify certain types of destination
options. The choice is to authenticate _everything_ which they don't
want to do or authenticate _nothing_ which they can't do. This has
nothing to do with IKE.
=> if we may not hack a bit the definition of selectors (a thing which
we have to fix for ICMPv6) we can put BUs in a payload (a new protocol
or if we believe this is too expensive UDP with a well know port).
This is an implementation detail, not a basic issue.
While the overkill of a phase 1 and phase 2 to merely authenticate a
single Binding Update is a problem the other, larger problem is that
there is no global PKI to deal with authentication.
=> I agree but this is not a IPsec problem, i.e. if we need strong
authentication and authorization then this can work only with
a global PKI.
Even a protocol
(SKIP for instance) which could handle the key establishment in a
single message-- definitely not overkill-- would not work because
there is no global PKI to support it.
=> this shows this issue is out of the scope of IPsec, i.e. MIPv6
has a problem with the authentication/authorization requirement,
not with IPsec itself. Unfortunately this disables quick but
not dirty solutions like "just sign BUs"...
But as I've said there are other contexts than the "random"
correspondent so there is still in interest in the IPsec/MIPv6
discussion.
Regards
Francis.Dupont@enst-bretagne.fr
PS: there are real advantages to be able to secure (with ESP in tunnel mode)
the home agent to mobile node tunnel. HIP is a good candidate, the son of
IKE (or others) will be compared with HIP for this task. Tests have shown
that IKE has abyssal performance in this case but is the best available
tool (for the security point of view).
From owner-ipsec@lists.tislabs.com Thu Aug 9 03:27:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79ARAN03812;
Thu, 9 Aug 2001 03:27:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA22624
Thu, 9 Aug 2001 05:46:41 -0400 (EDT)
Message-ID: <3B725DA2.F1C63038@F-Secure.com>
Date: Thu, 09 Aug 2001 12:53:38 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Harkins <dharkins@lounge.org>
CC: Jan Vilhuber <vilhuber@cisco.com>,
Brian Swander <briansw@windows.microsoft.com>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
References: <200108090142.f791glT00666@dharkins@lounge.orgatty.lounge.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dan Harkins wrote:
>
> Why is one mandated processing of packets a solution and another a
> "work around"? If the "work around" solves the problem in one less
> message then why isn't that preferable? Wouldn't adding a timestamp to
> the exchange be a "kludge"? Or a "work around"?
>
> The only reason the Responder doesn't instantiate the SAs after sending
> the 2nd message today is because of concerns about a resource consumption
> attack. I feel those concerns are small due to the small time in which
> the bogus SAs would be in the SADB, the inability of an attacker to use
> them (due to the inability of a 3rd party to know SKEYID state), and the
> small (and quantifiable) number of messages that can possibly be exchanged.
> Instantiate them and delete them if the 3rd message is never received!
>
> So we have very few messages which can be replayed and a well-defined
> method of dealing with the cases in which they are replayed. Why is that
> not satisfactory? What is the problem with this that is solved by adding
> a 4th message?
>
> Dan.
It would seem that both of these methods work, and I'd be relatively happy
with either one of them. I would prefer 4 messages, because it feels cleaner.
How about doing it this way: there are people on this list who verify
protocols using formal methods and one main gripe we have is that IKE has
been too hard to fully verify.. So.. Those people decide which alternative
is easier to formally verify and we pick that one.
Ari
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Integrated Solutions for Enterprise Security
From owner-ipsec@lists.tislabs.com Thu Aug 9 03:36:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79AaqN04756;
Thu, 9 Aug 2001 03:36:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA22651
Thu, 9 Aug 2001 05:57:48 -0400 (EDT)
Message-Id: <200108091003.f79A3iu76648@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: sommerfeld@East.Sun.COM
cc: Henry Spencer <henry@spsystems.net>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of Wed, 08 Aug 2001 14:35:42 EDT.
<200108081835.f78IZhJ09105@thunk.east.sun.com>
Date: Thu, 09 Aug 2001 12:03:44 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
AH or not-AH has nothing to do with VPN or end-to-end IPsec use.
=> the sub-thread is more about ESP tunnel mode vs. others.
VPNs don't need AH at all, even you can do AH in tunnel mode this
just adds bits for no benefit. Tunnel mode for end-to-end IPsec
adds bits and removes some properties (cf your next statement).
As Steve Bellovin has pointed out on numerous occasions, the IP header
in transport-mode ESP can be "authenticated" merely by doing a compare
of the source and destination addresses against static state in the
SA...
=> this "authentication" by side effect is mandatory according to RFC
2401 5.2.1 step 2 but:
- it doesn't work with tunnel mode
- it covers only the source address, not enough for interesting cases
like MIPv6 BUs (where both the care-of and the home addresses
(two source addresses) have to be protected).
I believe this is why AH is useful only for IPv6 (IPv4 options are
not used/usable: no need to protect them).
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Thu Aug 9 03:55:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79AteN05635;
Thu, 9 Aug 2001 03:55:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22711
Thu, 9 Aug 2001 06:15:41 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Geoffrey Huang'" <ghuang@cisco.com>, <ipsec@lists.tislabs.com>
Subject: RE: (More) immediate changes to help interop problems?
Date: Thu, 9 Aug 2001 11:10:04 +0100
Message-Id: <001401c120bc$02802ea0$a79321d9@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <HPEELIIJFCBDLBLJNPFIIELACCAA.ghuang@cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> So I've seen many messages concerning long-term development
> for the next
> IKE, but what happened to discussion on fixing some shortcomings that
> immediately affect interoperability? Andrew K. mentioned a
> few yesterday
> during his presentation, but off the top of my head, I can
> think of a few
> ambiguities:
>
> - Rekeying/Ph. 1 Responder Lifetime
> - Unreliable Delete/Notifies
> - Optional Cert Request Payload
> - Some way to detect dead peers/stale SAs
>
> I'm just thinking of issues in currently deployed scenarios...
Didn't I mention all of the above in my presentation? (I know it wasn't in
great depth, but we didn't make great use of our alloted time.)
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
From owner-ipsec@lists.tislabs.com Thu Aug 9 04:19:15 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79BJFN06214;
Thu, 9 Aug 2001 04:19:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22770
Thu, 9 Aug 2001 06:34:40 -0400 (EDT)
From: "Geoffrey Huang" <ghuang@cisco.com>
To: <andrew.krywaniuk@alcatel.com>, <ipsec@lists.tislabs.com>
Subject: RE: (More) immediate changes to help interop problems?
Date: Thu, 9 Aug 2001 03:45:50 -0700
Message-ID: <HPEELIIJFCBDLBLJNPFIIELBCCAA.ghuang@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <001401c120bc$02802ea0$a79321d9@andrewk3.ca.newbridge.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> > So I've seen many messages concerning long-term development
> > for the next
> > IKE, but what happened to discussion on fixing some shortcomings that
> > immediately affect interoperability? Andrew K. mentioned a
> > few yesterday
> > during his presentation, but off the top of my head, I can
> > think of a few
> > ambiguities:
> >
> > - Rekeying/Ph. 1 Responder Lifetime
> > - Unreliable Delete/Notifies
> > - Optional Cert Request Payload
> > - Some way to detect dead peers/stale SAs
> >
> > I'm just thinking of issues in currently deployed scenarios...
>
> Didn't I mention all of the above in my presentation? (I know it wasn't in
> great depth, but we didn't make great use of our alloted time.)
You certainly did, as I mention above -- I'm just wondering why the
discussion about this hasn't continued...
-g
> Andrew
> -------------------------------------------
> Upon closer inspection, I saw that the line
> dividing black from white was in fact a shade
> of grey. As I drew nearer still, the grey area
> grew larger. And then I was enlightened.
>
>
From owner-ipsec@lists.tislabs.com Thu Aug 9 04:32:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79BWvN06524;
Thu, 9 Aug 2001 04:32:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22797
Thu, 9 Aug 2001 06:43:00 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15218.27317.608127.580477@thomasm-u1.cisco.com>
Date: Thu, 9 Aug 2001 03:49:25 -0700 (PDT)
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: Michael Thomas <mat@cisco.com>, Dan McDonald <danmcd@East.Sun.COM>,
Sandy Harris <sandy@storm.ca>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <200108081601.f78G11u73217@givry.rennes.enst-bretagne.fr>
References: <15217.19461.896582.163323@thomasm-u1.cisco.com>
<200108081601.f78G11u73217@givry.rennes.enst-bretagne.fr>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Francis Dupont writes:
> => but VPNs are the current market so if we remove everything not used
> today only VPN stuff will remain. AH seems to be the first victim of
> the "simplifying IKE" process and transport mode will be the second
> (even if this has near nothing to do with the IKE issue and transport
> mode is more primitive than tunnel mode: tunnel mode is used in VPNs
> so it cannot be removed). IMHO this is just "remove everything we
> don't like or don't use" but the net result can be a VPN only IPsec.
This seems rather alarmist. I'm pretty
convinced that most of the people who
would like to see AH nuked aren't in favor
of a VPN-only IPsec. In fact, I don't recall
hearing anybody on this list make that suggestion.
> => I disagree, the purpose of AH is the protection of payload
> and headers (something ESP should not do because there already is AH)
> and for a signaling protocol like MIPv6 AH is both simpler and cheaper]
ESP-NULL shouldn't be any more expensive than AH.
In fact, it should be cheaper since it just calls
the hashing algorithm over a single block rather
than having to deal with the bits and dregs
that AH needs to omit.
> to use. The trouble of IPsec with MIPv6 is more IKE (the thing we are
> supposed to simplify): obviously to run IKE phases 1 & 2 in order
> to protect BUs (sometime a single small packet) is overkilling
That assumes you only care about BU's...
> but it seems like a pretty vivid example of how more
> options == more confusion of how they all work (or
> don't work as the case were).
>
> => I disagree: AH for MIPv6 works, this is not deployable
> (because of global PKI/authorization issue) and nor efficient
> (as concrete tests have shown). And I believe we'll still see
> IPsec and MIPv6 together in the future because IPsec only
> provides a good security service in the network layer
> (i.e. not everywhere but somewhere).
ESP could work for BU's as well; I wrote a
draft that describes how. I have yet to see
something concrete that AH actually provides
that ESP cannot.
BTW: we don't need to burn a new protocol
number for BU's to get it to work with
IPsec: we could just make it a UDP packet.
Mike
From owner-ipsec@lists.tislabs.com Thu Aug 9 05:11:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79CB8N12339;
Thu, 9 Aug 2001 05:11:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22962
Thu, 9 Aug 2001 07:27:17 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Jan Vilhuber'" <vilhuber@cisco.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Thu, 9 Aug 2001 12:25:06 +0100
Message-Id: <001601c120c6$13a309f0$a79321d9@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <Pine.LNX.4.21.0108081915350.4332-100000@janpc-home.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Guarding against replay attacks is easy. Just use
draft-ietf-ipsec-antireplay-00.txt.
I can see a rationale for 2, 3, or 4 message exchanges. It's just an
engineering tradeoff. As soon as we start using the above draft, we can stop
worrying about replayed messages. Therefore, the only thing to worry about
is lost packets.
Tim Jenkins pointed out a long time ago that you can't solve a packet loss
problem by extending the exchange. There will always be a new last packet,
and the last packet can't be ACK'ed, only NACK'ed. However, there is some
value in delaying use of the SA until the peer has added in in order to
avoid spurious INVALID-SPI messages that the peer might generate (although I
might add that even these can be avoided if the IKE process pre-notifies the
IPsec process of which SPIs are currently pending negotiation.
However, if we add the replay protection and eliminate PFS then I don't see
any particular reason why we couldn't make quick mode only 2 packets. If,
over my strenuous objections, we still wanted to support PFS then a 3rd
message would be required. And a 4th message if you want to make the
exchange even (although I don't personally see the value of this argument).
I have listed avoiding INVALID-SPI messages as the main reason for delaying
use of the SA. Another would be avoiding the (small) wasted bandwidth of
occasionally sending a message that the peer can't decrypt yet. Having the
router drop the first packet of a flow is a common scenario on the Internet
already; TCP will retransmit the packet soon enough. There is no reason to
get paranoid about the ocasional lost packet here and there.
If the peer had buffer space, it could save the message and decrypt it
later. Delaying the use of the SA until the peer has ACK'ed doesn't fix the
problem; it only potentially allows you to shift the storage buffer from the
receiver to the sender. (If we snuff out the replay problem as I suggest
then there is no possibility of a state-clogging attack, so it doesn't
really matter which side has the buffer.)
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber
> Sent: Thursday, August 09, 2001 3:18 AM
> To: Dan Harkins
> Cc: Brian Swander; Ari Huttunen; ipsec@lists.tislabs.com
> Subject: Re: Simplifying IKE
>
>
> P.S. I really would prefer a 2 message version, if some smart
> cookie out
> there can figure out how to guard against replay attacks.
> That would be the
> coolest...
>
> jan
>
>
>
> On Wed, 8 Aug 2001, Jan Vilhuber wrote:
>
> > On Wed, 8 Aug 2001, Dan Harkins wrote:
> >
> > > Why is one mandated processing of packets a solution
> and another a
> > > "work around"? If the "work around" solves the problem in one less
> > > message then why isn't that preferable? Wouldn't adding a
> timestamp to
> > > the exchange be a "kludge"? Or a "work around"?
> > >
> > As you say, both work. One strikes me as more aesthetically
> pleasing, or
> > cleaner, i.e. a 4th message is part of the protocol, and
> you don't need much
> > verbiage to tell people how to handle the sync between IKE
> and ipsec in a 3
> > message scenario. It's therefore much cleaner and offers
> better chances of
> > passing interop (the more verbiage to explain something,
> the more you give
> > people to argue what was meant by the verbiage).
> >
> > > The only reason the Responder doesn't instantiate the
> SAs after sending
> > > the 2nd message today is because of concerns about a
> resource consumption
> > > attack. I feel those concerns are small due to the small
> time in which
> > > the bogus SAs would be in the SADB, the inability of an
> attacker to use
> > > them (due to the inability of a 3rd party to know SKEYID
> state), and the
> > > small (and quantifiable) number of messages that can
> possibly be exchanged.
> > > Instantiate them and delete them if the 3rd message is
> never received!
> > >
> >
> > Or wait for a 4th message to confirm. I grant you they are
> almost the same.
> >
> > > So we have very few messages which can be replayed and
> a well-defined
> > > method of dealing with the cases in which they are
> replayed. Why is that
> > > not satisfactory? What is the problem with this that is
> solved by adding
> > > a 4th message?
> > >
> > It's an explicit ACK, rather than relying on implicit
> behaviour of lacking
> > the 3rd message. It just strikes me as cleaner. it's all
> software. We can
> > implement almost anything in software. Question is how. And
> obviously
> > different people have different ideas of 'cleanliness' and different
> > definition of 'obvious' (as we can tell from dangling SA
> and continuous
> > channel fiascos).
> >
> > Telling IPSec to instantiate a single SA, and then later
> possibly revoking
> > it, just doesn't seem as clean to me. I'd rather only tell
> ipsec to go ahead
> > and do its thing when IKE is completely 100% sure that we're done.
> >
> > I also realize that KINK does what you propose. I didn't
> much like it there,
> > either. So be it. The very fact that it has to be
> explained, rather than
> > having a protocol definition, makes me nervous. But if it
> can be explained
> > very simply, and you are confident that people won't find
> things they claim
> > were open to interpretation (what do you mean I shouldn't
> delete my IPSec
> > Sa's when the IKE SA that created them dies?! Duh...), then
> I'm OK with it.
> >
> > To put it a different way: Define the protocol, and when
> the protocol has
> > unambiguously finished, THEN (and only then) tell ipsec to
> proceed. This
> > doesn't leave things open to interpretation of exactly when
> one SA should be
> > instantiated and when the next should be instantiated, and
> so on. Maybe I'm
> > just being pedantic. Being pedantic should be a good thing
> right now, so we
> > don't repeat the past with son-of-IKE (did we decide it's
> 'doud', pronounced
> > 'dude'?? ;)
> >
> > Different folks, different strokes...
> > jan
> >
> >
> >
> >
> >
> > > Dan.
> > >
> > > On Wed, 08 Aug 2001 13:57:15 PDT you wrote
> > > > I'd actually prefer to formalize the concept that the
> commit-bit is trying to
> > > > address:
> > > >
> > > > 1) Either expand quick mode to 4 messages. That's
> unambiguous, and leads to
> > > > better interop. A commit bit is really a kludge.
> > > >
> > > > 2) If you think about it, the 3rd message is only
> needed to prevent replay
> > > > attacks of old messages. If we addressed this some
> other way (say a timestamp
> > > > field, but that has obvious other problems), then we
> could drop the 3rd
> > > > message, and have 2, which is again 'good (tm)'.
> > > >
> > > > Dan also outlined some other ways to address this
> problem, and while they
> > > > work, I don't much care for them, since they're really
> work-arounds to the
> > > > problem above. It would be preferable to address the
> replay attacks in some
> > > > other way (if possible) and do away with the 3rd
> message, or bite the bullet
> > > > and create a 4th message as an ACK to make the exchange
> as unambiguous as
> > > > possible.
> > > >
> > > > I point out that KINK manages to use 2 messages, which
> are (used to be)
> > > > essentially a quick mode exchange. It uses kerberos to
> handle the replay
> > > > attacks, which involves timestamps. There are surely
> other ways of addressing
> > > > the replay issue, like a counter or something else. If
> we could use two
> > > > messages for quick mode, that would solve all this
> commit-bit versus 'when to
> > > > install the resources' issues....
> > > >
> > > > jan
> > > >
> > > >
> > > >
> > > > > I am not so concerned with the resources in an
> attack, but more worried
> > > > > about an attacker potentially getting an SA into the
> system that could
> > > > > be exploited. I don't see how this could be done
> today (all I can see
> > > > > is the obvious replay attack Dan is talking about),
> but that doesn't
> > > > > mean that such an exploit doesn't exist. So, I am
> much more comfortable
> > > > > with the one extra packet and the assurance that
> everything is ok with
> > > > > the negotiation before SAs are added.
> > > > >
> > > > > Of course, if someone has a proof that the security
> can't be violated by
> > > > > adding the responder SAs early, then I'd agree to
> eliminating the commit
> > > > > bit (except for backwards compatibility, when we'd
> still need to support
> > > > > it).
> > > > >
> > > > > bs
> > > > >
> > > > > -----Original Message-----
> > > > > From: Dan Harkins [mailto:dharkins@lounge.org]
> > > > > Sent: Wednesday, August 08, 2001 10:49 AM
> > > > > To: Ari Huttunen
> > > > > Cc: ipsec@lists.tislabs.com
> > > > > Subject: Re: Simplifying IKE
> > > > >
> > > > > My tentative text on the subject is to get rid of
> the commit bit and
> > > > > have a 3 message exchange. The problem with the
> existing 3 message
> > > > > exchanage (w/o the commit bit being used) is that the
> Responder will not
> > > > > instantiate her SAs until receipt of the 3rd message
> from the Initiator
> > > > > to avoid a resource consumption attack but the Initiator will
> > > > > instantiate
> > > > > his SAs upon receipt of the 2nd message from the
> Responder. This results
> > > > > in a race between the first few IPsec-protected
> packets and the final
> > > > > message. If the former win they get dropped.
> > > > >
> > > > > My proposal is that the Responder instantiate the
> SAs when she sends
> > > > > the 2nd message back to the Initiator. She will be
> setting a timer to
> > > > > deal with non-receipt of the 3rd message and if the
> timer fires
> > > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared
> to have failed
> > > > > and she can delete these SAs from her SADB.
> > > > >
> > > > > In addition to this text there is new text
> instructing implementations
> > > > > to deal with receipt of an offer to create an IPsec
> SA with a SPI that
> > > > > is currently in use as an error, and new text
> instructing the Initiator
> > > > > to hold on to the 3rd phase 2 message for some
> COMFORT_LEVEL_TIME in
> > > > > case
> > > > > it is dropped and he receives a retransmitted 2nd
> message from the
> > > > > Responder.
> > > > >
> > > > > This is much simpler than what we have and solves
> the race problem.
> > > > > What it does, though, is allow for some resources to
> be temporarily
> > > > > consumed due to the replay of an old message. I don't
> view this as that
> > > > > big of a problem though since it is temporary
> (RETRANSMIT_TIME *
> > > > > RETRANSMIT_TIMER_LIMIT = total seconds these bogus
> SAs would stay in
> > > > > the SADB) and the number of possible packets that can
> be replayed is
> > > > > limited and bounded by the life of the IKE SA.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Dan.
> > > > >
> > > > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> > > > > >
> > > > > > Dan McDonald wrote:
> > > > > > >
> > > > > > > > >From the Schneier and Ferguson analysis we get:
> > > > > > > >
> > > > > > > > Can we drop the commit bit?
> > > > > > >
> > > > > > > Who uses it?
> > > > > >
> > > > > > I guess someone in past figured out that running
> IKE on satellite
> > > > > lines
> > > > > > is necessary, so they decided to optimize as much
> as possible. The
> > > > > result
> > > > > > was that both aggressive mode and quick mode both
> have three messages.
> > > > > > The problem with three messages is that the
> initiator will often start
> > > > > sendin
> > > > > >g
> > > > > > actual traffic too soon, or quick mode packets,
> before the responder
> > > > > is ready
> > > > > >. Thus
> > > > > > the need for packet buffers, commit bit, whatever.
> This optimization
> > > > > causes d
> > > > > >esign
> > > > > > complications that I'd very much prefer to get rid of.
> > > > >
> > > >
> > > > --
> > > > Jan Vilhuber
> vilhuber@cisco.com
> > > > Cisco Systems, San Jose
> (408) 527-0847
> > > >
> > >
> >
> > --
> > Jan Vilhuber
> vilhuber@cisco.com
> > Cisco Systems, San Jose
> (408) 527-0847
> >
> >
>
> --
> Jan Vilhuber
> vilhuber@cisco.com
> Cisco Systems, San Jose
> (408) 527-0847
>
From owner-ipsec@lists.tislabs.com Thu Aug 9 05:12:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79CClN13205;
Thu, 9 Aug 2001 05:12:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22986
Thu, 9 Aug 2001 07:32:33 -0400 (EDT)
From: "Lars Eggert" <larse@ISI.EDU>
To: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Thu, 9 Aug 2001 12:34:07 -0000
MIME-Version: 1.0
Message-ID: <DGEIIENGBBMIPHJOBIIEKEHFCAAA.larse@isi.edu>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200108091003.f79A3iu76648@givry.rennes.enst-bretagne.fr>
Content-Type: multipart/signed;
boundary="----=_NextPart_000_0036_01C120CF.93FCEC70";
micalg=SHA1;
protocol="application/x-pkcs7-signature"
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0036_01C120CF.93FCEC70
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
> As Steve Bellovin has pointed out on numerous occasions, the IP
header
> in transport-mode ESP can be "authenticated" merely by doing a
compare
> of the source and destination addresses against static state in the
> SA...
>
> => this "authentication" by side effect is mandatory according to RFC
> 2401 5.2.1 step 2 but:
> - it doesn't work with tunnel mode
I'm probably missing something obvious, but why doesn't comparing the SA
against the (two) IP headers work for tunnel mode?
Lars
--
Lars Eggert <larse@isi.edu> Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
------=_NextPart_000_0036_01C120CF.93FCEC70
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF9DCCAtgw
ggJBoAMCAQICAwMjBTANBgkqhkiG9w0BAQQFADCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE
CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAx
OTk5LjkuMTYwHhcNMDAwODI0MjAzMDA4WhcNMDEwODI0MjAzMDA4WjBUMQ8wDQYDVQQEEwZFZ2dl
cnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MRwwGgYJKoZIhvcNAQkBFg1s
YXJzZUBpc2kuZWR1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPXJ9w2zneu+G7DyBIO+vb
7+yc/wZ25hjvHtaQl3K9zBviiKk2lZgiQwY/bXhm/UquC+e0Zob6N66AAZC3SfrhW6yBwjNDpANG
2cyB1ANMCRVJDZ4tFJCRr6cA/HpIUomDv1YQQeaApAEy1l0wFi1i/+ZM5ymbuNMlWD7tbqfThQID
AQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMBgGA1Ud
EQQRMA+BDWxhcnNlQGlzaS5lZHUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY
x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQCLrl8z+NIJo+FGgD0lblfYWS1IWETnOQikVU+m
/fcZY882udywrXcd9mazQHWs3La9TtSEUj++wlCAEnJ9+QsWAwKOne5Fm8EGMYPWrjKMM7nJ8wyO
q6oGlm1GnmineVN3TV9oDnxkIHmzEJvQ5FLG9dHy1z0Mk7QkilAgtrq8gDCCAxQwggJ9oAMCAQIC
AQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsT
H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv
bTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQswCQYDVQQGEwJaQTEVMBMGA1UE
CBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGc
I3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc
9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8C
AwEAAaM3MDUwEgYDVR0TAQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH
58ayDjANBgkqhkiG9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKl
N9idtxcoVgWL3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLk
XJeu/H6syg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAq4wggKqAgEBMIGcMIGUMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAyMFMAkGBSsOAwIaBQCgggFnMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDgwOTEyMzQwNVowIwYJKoZI
hvcNAQkEMRYEFJXi3mG1xK0G2gPR+sl7A3yv2jntMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIGtBgkrBgEEAYI3EAQxgZ8wgZwwgZQxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0
ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMTk5
OS45LjE2AgMDIwUwDQYJKoZIhvcNAQEBBQAEgYBWSmILxu1I77JL7yaoSQsmq9he0XPBAuqqDvm4
HMTQCoSbWH8uPbR1hLywRhGAjXKNDhd5k3KxQt46duL8vRH4qX9p6kn0bVtCobQO/ocp3GQ1N1Z5
iqbEbz5/nBIv214EsD4kZYUzC7XIf1aXNMpZBso0e56bjbYeKsYZiYGDQwAAAAAAAA==
------=_NextPart_000_0036_01C120CF.93FCEC70--
From owner-ipsec@lists.tislabs.com Thu Aug 9 05:18:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79CIDN14167;
Thu, 9 Aug 2001 05:18:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23008
Thu, 9 Aug 2001 07:37:38 -0400 (EDT)
Message-ID: <008e01c120c8$3ce25b20$700110ac@roc.com>
Reply-To: "jyothi" <vjyothi@intotoinc.com>
From: "jyothi" <vjyothi@intotoinc.com>
To: <ipsec@lists.tislabs.com>
Subject: Position of certificate payload in IKE Aggressive Mode as Initiator
Date: Thu, 9 Aug 2001 17:11:31 +0530
Organization: Intoto Inc
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
Hi,
Kindly clarify the following doubt.
Scenario : IKE Phase 1 Negotiation (Aggressive Mode) authenticated
with signatures
As an Initiator, can the certificate payload be sent in first message
or is it mandatory to be sent in third message only. In the subsection
Certificate Payload of section ISAKMP Payloads contained in RFC 2408, the
following statement is present. "The Certificate Payload MUST be accepted at
any point during an exchange". I understand from this statement that the
responder has to accept Certificate payload either in first message or third
message, which in turn provides the base for the assunption that initiator
can send the certificate payload in first msg or third msg.
thanks
sankar
From owner-ipsec@lists.tislabs.com Thu Aug 9 05:49:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79CnvN15347;
Thu, 9 Aug 2001 05:49:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23053
Thu, 9 Aug 2001 07:47:47 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Dan McDonald'" <danmcd@East.Sun.COM>, "'Sandy Harris'" <sandy@storm.ca>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Thu, 9 Aug 2001 12:45:38 +0100
Message-Id: <001801c120c8$eb0361e0$a79321d9@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <200108080219.f782JIp00242@kebe.east.sun.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> > > 4. modify ESP to ensure it authenticates all data used in
> the deciphering
> > of the payload
> >
> > This is the only recommendation in this paper based on a
> direct security
> > flaw, with a proposed attack to demonstrate it. There are
> others in the
> > Simpson paper.
>
> And if you use Choice 3a above, you get this for free - AH
> covers the whole
> ESP datagram, SPI/IV/etc.
If my memory serves me correctly, Ferguson/Schneier were actually suggesting
that
1. encryption be applied AFTER authentication
or, failing that, that
2. the encryption/decryption key be included in the data which is hashed
This is to prevent an esoteric attack they describe which is infeasible and
wouldn't cause any damage anyway. That is not a compelling reason to
redesign ESP.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
From owner-ipsec@lists.tislabs.com Thu Aug 9 05:50:01 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79Co0N15356;
Thu, 9 Aug 2001 05:50:00 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23052
Thu, 9 Aug 2001 07:47:46 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Dan Harkins'" <dharkins@lounge.org>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Thu, 9 Aug 2001 12:33:52 +0100
Message-Id: <001701c120c8$e7b659c0$a79321d9@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <200108081749.f78HmtR00738@dharkins@lounge.orgatty.lounge.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> In addition to this text there is [...]
> new text instructing the
> Initiator
> to hold on to the 3rd phase 2 message for some
> COMFORT_LEVEL_TIME in case
> it is dropped and he receives a retransmitted 2nd message from the
> Responder.
>
> This is much simpler than what we have and solves the race problem.
> What it does, though, is allow for some resources to be temporarily
> consumed due to the replay of an old message. I don't view
> this as that
> big of a problem though since it is temporary (RETRANSMIT_TIME *
> RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
> the SADB) and the number of possible packets that can be replayed is
> limited and bounded by the life of the IKE SA.
This is in fact what my implementation has been doing for quite some time. I
had never thought that this "new behaviour" was disallowed by the existing
RFCs. It seemed like the logical thing to do... But as I pointed out in
another message, the replay problem should still be quenched at the source
by providing a counter.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> Sent: Wednesday, August 08, 2001 6:49 PM
> To: Ari Huttunen
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Simplifying IKE
>
>
> My tentative text on the subject is to get rid of the commit bit and
> have a 3 message exchange. The problem with the existing 3 message
> exchanage (w/o the commit bit being used) is that the
> Responder will not
> instantiate her SAs until receipt of the 3rd message from the
> Initiator
> to avoid a resource consumption attack but the Initiator will
> instantiate
> his SAs upon receipt of the 2nd message from the Responder.
> This results
> in a race between the first few IPsec-protected packets and the final
> message. If the former win they get dropped.
>
> My proposal is that the Responder instantiate the SAs when she sends
> the 2nd message back to the Initiator. She will be setting a timer to
> deal with non-receipt of the 3rd message and if the timer fires
> RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed
> and she can delete these SAs from her SADB.
>
> In addition to this text there is new text instructing
> implementations
> to deal with receipt of an offer to create an IPsec SA with a SPI that
> is currently in use as an error, and new text instructing the
> Initiator
> to hold on to the 3rd phase 2 message for some
> COMFORT_LEVEL_TIME in case
> it is dropped and he receives a retransmitted 2nd message from the
> Responder.
>
> This is much simpler than what we have and solves the race problem.
> What it does, though, is allow for some resources to be temporarily
> consumed due to the replay of an old message. I don't view
> this as that
> big of a problem though since it is temporary (RETRANSMIT_TIME *
> RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in
> the SADB) and the number of possible packets that can be replayed is
> limited and bounded by the life of the IKE SA.
>
> Thoughts?
>
> Dan.
>
> On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> >
> > Dan McDonald wrote:
> > >
> > > > >From the Schneier and Ferguson analysis we get:
> > > >
> > > > Can we drop the commit bit?
> > >
> > > Who uses it?
> >
> > I guess someone in past figured out that running IKE on
> satellite lines
> > is necessary, so they decided to optimize as much as
> possible. The result
> > was that both aggressive mode and quick mode both have
> three messages.
> > The problem with three messages is that the initiator will
> often start sendin
> >g
> > actual traffic too soon, or quick mode packets, before the
> responder is ready
> >. Thus
> > the need for packet buffers, commit bit, whatever. This
> optimization causes d
> >esign
> > complications that I'd very much prefer to get rid of.
>
>
From owner-ipsec@lists.tislabs.com Thu Aug 9 06:13:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DD2N15942;
Thu, 9 Aug 2001 06:13:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23151
Thu, 9 Aug 2001 08:27:55 -0400 (EDT)
Message-ID: <3B72846A.4010300@kolumbus.fi>
Date: Thu, 09 Aug 2001 15:39:06 +0300
From: Jari Arkko <jari.arkko@kolumbus.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Vilhuber <vilhuber@cisco.com>
Cc: sankar ramamoorthi <sankar@nexsi.com>, Dan Harkins <dharkins@lounge.org>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
References: <Pine.LNX.4.21.0108081358030.4332-100000@janpc-home.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Jan Vilhuber wrote:
>
> making a 2 message exchange. I favor an even number of messages. Whether
> that's 2 or 4 I don't MUCH care (2 would be preferable if we can figure out
> how).
I'd just like to repeat my preference for the minimal number of messages
even in this context. When these things are used over cellular links with
relatively long delays, additional messages really affect the delays before
you can start work.
Jari
From owner-ipsec@lists.tislabs.com Thu Aug 9 06:22:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DMVN16135;
Thu, 9 Aug 2001 06:22:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23168
Thu, 9 Aug 2001 08:32:49 -0400 (EDT)
Message-ID: <001f01c120d0$5fc05090$0101a8c0@mv.lucent.com>
From: "David W. Faucher" <dfaucher@lucent.com>
To: "Jan Vilhuber" <vilhuber@cisco.com>
Cc: <ipsec@lists.tislabs.com>
References: <Pine.LNX.4.21.0108081915350.4332-100000@janpc-home.cisco.com>
Subject: Re: Simplifying IKE
Date: Thu, 9 Aug 2001 07:35:37 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I believe that using the Message ID field as a counter
has already been suggested, and in this case should work
to prevent replay attacks.
----- Original Message -----
From: "Jan Vilhuber" <vilhuber@cisco.com>
To: "Dan Harkins" <dharkins@lounge.org>
Cc: "Brian Swander" <briansw@windows.microsoft.com>; "Ari Huttunen"
<Ari.Huttunen@F-Secure.com>; <ipsec@lists.tislabs.com>
Sent: Wednesday, August 08, 2001 9:17 PM
Subject: Re: Simplifying IKE
> P.S. I really would prefer a 2 message version, if some smart cookie out
> there can figure out how to guard against replay attacks. That would be
the
> coolest...
>
> jan
>
>
>
> On Wed, 8 Aug 2001, Jan Vilhuber wrote:
>
> > On Wed, 8 Aug 2001, Dan Harkins wrote:
> >
> > > Why is one mandated processing of packets a solution and another a
> > > "work around"? If the "work around" solves the problem in one less
> > > message then why isn't that preferable? Wouldn't adding a timestamp to
> > > the exchange be a "kludge"? Or a "work around"?
> > >
> > As you say, both work. One strikes me as more aesthetically pleasing, or
> > cleaner, i.e. a 4th message is part of the protocol, and you don't need
much
> > verbiage to tell people how to handle the sync between IKE and ipsec in
a 3
> > message scenario. It's therefore much cleaner and offers better chances
of
> > passing interop (the more verbiage to explain something, the more you
give
> > people to argue what was meant by the verbiage).
> >
> > > The only reason the Responder doesn't instantiate the SAs after
sending
> > > the 2nd message today is because of concerns about a resource
consumption
> > > attack. I feel those concerns are small due to the small time in which
> > > the bogus SAs would be in the SADB, the inability of an attacker to
use
> > > them (due to the inability of a 3rd party to know SKEYID state), and
the
> > > small (and quantifiable) number of messages that can possibly be
exchanged.
> > > Instantiate them and delete them if the 3rd message is never received!
> > >
> >
> > Or wait for a 4th message to confirm. I grant you they are almost the
same.
> >
> > > So we have very few messages which can be replayed and a
well-defined
> > > method of dealing with the cases in which they are replayed. Why is
that
> > > not satisfactory? What is the problem with this that is solved by
adding
> > > a 4th message?
> > >
> > It's an explicit ACK, rather than relying on implicit behaviour of
lacking
> > the 3rd message. It just strikes me as cleaner. it's all software. We
can
> > implement almost anything in software. Question is how. And obviously
> > different people have different ideas of 'cleanliness' and different
> > definition of 'obvious' (as we can tell from dangling SA and continuous
> > channel fiascos).
> >
> > Telling IPSec to instantiate a single SA, and then later possibly
revoking
> > it, just doesn't seem as clean to me. I'd rather only tell ipsec to go
ahead
> > and do its thing when IKE is completely 100% sure that we're done.
> >
> > I also realize that KINK does what you propose. I didn't much like it
there,
> > either. So be it. The very fact that it has to be explained, rather than
> > having a protocol definition, makes me nervous. But if it can be
explained
> > very simply, and you are confident that people won't find things they
claim
> > were open to interpretation (what do you mean I shouldn't delete my
IPSec
> > Sa's when the IKE SA that created them dies?! Duh...), then I'm OK with
it.
> >
> > To put it a different way: Define the protocol, and when the protocol
has
> > unambiguously finished, THEN (and only then) tell ipsec to proceed. This
> > doesn't leave things open to interpretation of exactly when one SA
should be
> > instantiated and when the next should be instantiated, and so on. Maybe
I'm
> > just being pedantic. Being pedantic should be a good thing right now, so
we
> > don't repeat the past with son-of-IKE (did we decide it's 'doud',
pronounced
> > 'dude'?? ;)
> >
> > Different folks, different strokes...
> > jan
> >
> >
> >
> >
> >
> > > Dan.
> > >
> > > On Wed, 08 Aug 2001 13:57:15 PDT you wrote
> > > > I'd actually prefer to formalize the concept that the commit-bit is
trying to
> > > > address:
> > > >
> > > > 1) Either expand quick mode to 4 messages. That's unambiguous, and
leads to
> > > > better interop. A commit bit is really a kludge.
> > > >
> > > > 2) If you think about it, the 3rd message is only needed to prevent
replay
> > > > attacks of old messages. If we addressed this some other way (say a
timestamp
> > > > field, but that has obvious other problems), then we could drop the
3rd
> > > > message, and have 2, which is again 'good (tm)'.
> > > >
> > > > Dan also outlined some other ways to address this problem, and while
they
> > > > work, I don't much care for them, since they're really work-arounds
to the
> > > > problem above. It would be preferable to address the replay attacks
in some
> > > > other way (if possible) and do away with the 3rd message, or bite
the bullet
> > > > and create a 4th message as an ACK to make the exchange as
unambiguous as
> > > > possible.
> > > >
> > > > I point out that KINK manages to use 2 messages, which are (used to
be)
> > > > essentially a quick mode exchange. It uses kerberos to handle the
replay
> > > > attacks, which involves timestamps. There are surely other ways of
addressing
> > > > the replay issue, like a counter or something else. If we could use
two
> > > > messages for quick mode, that would solve all this commit-bit versus
'when to
> > > > install the resources' issues....
> > > >
> > > > jan
> > > >
> > > >
> > > >
> > > > > I am not so concerned with the resources in an attack, but more
worried
> > > > > about an attacker potentially getting an SA into the system that
could
> > > > > be exploited. I don't see how this could be done today (all I can
see
> > > > > is the obvious replay attack Dan is talking about), but that
doesn't
> > > > > mean that such an exploit doesn't exist. So, I am much more
comfortable
> > > > > with the one extra packet and the assurance that everything is ok
with
> > > > > the negotiation before SAs are added.
> > > > >
> > > > > Of course, if someone has a proof that the security can't be
violated by
> > > > > adding the responder SAs early, then I'd agree to eliminating the
commit
> > > > > bit (except for backwards compatibility, when we'd still need to
support
> > > > > it).
> > > > >
> > > > > bs
> > > > >
> > > > > -----Original Message-----
> > > > > From: Dan Harkins [mailto:dharkins@lounge.org]
> > > > > Sent: Wednesday, August 08, 2001 10:49 AM
> > > > > To: Ari Huttunen
> > > > > Cc: ipsec@lists.tislabs.com
> > > > > Subject: Re: Simplifying IKE
> > > > >
> > > > > My tentative text on the subject is to get rid of the commit bit
and
> > > > > have a 3 message exchange. The problem with the existing 3 message
> > > > > exchanage (w/o the commit bit being used) is that the Responder
will not
> > > > > instantiate her SAs until receipt of the 3rd message from the
Initiator
> > > > > to avoid a resource consumption attack but the Initiator will
> > > > > instantiate
> > > > > his SAs upon receipt of the 2nd message from the Responder. This
results
> > > > > in a race between the first few IPsec-protected packets and the
final
> > > > > message. If the former win they get dropped.
> > > > >
> > > > > My proposal is that the Responder instantiate the SAs when she
sends
> > > > > the 2nd message back to the Initiator. She will be setting a timer
to
> > > > > deal with non-receipt of the 3rd message and if the timer fires
> > > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have
failed
> > > > > and she can delete these SAs from her SADB.
> > > > >
> > > > > In addition to this text there is new text instructing
implementations
> > > > > to deal with receipt of an offer to create an IPsec SA with a SPI
that
> > > > > is currently in use as an error, and new text instructing the
Initiator
> > > > > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME
in
> > > > > case
> > > > > it is dropped and he receives a retransmitted 2nd message from the
> > > > > Responder.
> > > > >
> > > > > This is much simpler than what we have and solves the race
problem.
> > > > > What it does, though, is allow for some resources to be
temporarily
> > > > > consumed due to the replay of an old message. I don't view this as
that
> > > > > big of a problem though since it is temporary (RETRANSMIT_TIME *
> > > > > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay
in
> > > > > the SADB) and the number of possible packets that can be replayed
is
> > > > > limited and bounded by the life of the IKE SA.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Dan.
> > > > >
> > > > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote
> > > > > >
> > > > > > Dan McDonald wrote:
> > > > > > >
> > > > > > > > >From the Schneier and Ferguson analysis we get:
> > > > > > > >
> > > > > > > > Can we drop the commit bit?
> > > > > > >
> > > > > > > Who uses it?
> > > > > >
> > > > > > I guess someone in past figured out that running IKE on
satellite
> > > > > lines
> > > > > > is necessary, so they decided to optimize as much as possible.
The
> > > > > result
> > > > > > was that both aggressive mode and quick mode both have three
messages.
> > > > > > The problem with three messages is that the initiator will often
start
> > > > > sendin
> > > > > >g
> > > > > > actual traffic too soon, or quick mode packets, before the
responder
> > > > > is ready
> > > > > >. Thus
> > > > > > the need for packet buffers, commit bit, whatever. This
optimization
> > > > > causes d
> > > > > >esign
> > > > > > complications that I'd very much prefer to get rid of.
> > > > >
> > > >
> > > > --
> > > > Jan Vilhuber
vilhuber@cisco.com
> > > > Cisco Systems, San Jose (408)
527-0847
> > > >
> > >
> >
> > --
> > Jan Vilhuber
vilhuber@cisco.com
> > Cisco Systems, San Jose (408)
527-0847
> >
> >
>
> --
> Jan Vilhuber vilhuber@cisco.com
> Cisco Systems, San Jose (408) 527-0847
>
From owner-ipsec@lists.tislabs.com Thu Aug 9 06:41:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DfaN16520;
Thu, 9 Aug 2001 06:41:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23260
Thu, 9 Aug 2001 08:56:04 -0400 (EDT)
Message-ID: <00a401c120d4$1c09e290$4e8d21d9@sfanninglaptop>
From: "Scott Fanning" <sfanning@cisco.com>
To: "Jari Arkko" <jari.arkko@kolumbus.fi>, "Jan Vilhuber" <vilhuber@cisco.com>
Cc: "sankar ramamoorthi" <sankar@nexsi.com>,
"Dan Harkins" <dharkins@lounge.org>,
"Ari Huttunen" <Ari.Huttunen@F-Secure.com>, <ipsec@lists.tislabs.com>
References: <Pine.LNX.4.21.0108081358030.4332-100000@janpc-home.cisco.com> <3B72846A.4010300@kolumbus.fi>
Subject: Re: Simplifying IKE
Date: Thu, 9 Aug 2001 06:06:28 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This might go to Cheryl Madsons point that this protocol (SOI, IKEv2,
whatever) may not be for everyone. KINK seems to have gone to great lengths
to address the transmission issues. I would prefer a 2 or 4 number exchange.
I would like the initiator to know when to send traffic that can be usefully
used by both parties as opposed to being dropped. That may be worse that one
extra message. That seemed to be the motivation of the dreaded COMMIT bit,
but I would not recommend making it optional.
>From Dan
<snip>
The only reason the Responder doesn't instantiate the SAs after sending
the 2nd message today is because of concerns about a resource consumption
attack. I feel those concerns are small due to the small time in which
the bogus SAs would be in the SADB, the inability of an attacker to use
them (due to the inability of a 3rd party to know SKEYID state), and the
small (and quantifiable) number of messages that can possibly be exchanged.
Instantiate them and delete them if the 3rd message is never received!
<snip>
To Dans point about 3 messages would only allow an SA to consume memory for
a short period of time, I am more concerned with tunnels per second
consuming memory. There may be cases where you could use too much memory as
a result of that, then just establishing one SA at a time. In that case,
especially in memory constrained devices, I would want to remove a much
resources usage as possible.
Scott
----- Original Message -----
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "Jan Vilhuber" <vilhuber@cisco.com>
Cc: "sankar ramamoorthi" <sankar@nexsi.com>; "Dan Harkins"
<dharkins@lounge.org>; "Ari Huttunen" <Ari.Huttunen@F-Secure.com>;
<ipsec@lists.tislabs.com>
Sent: Thursday, August 09, 2001 5:39 AM
Subject: Re: Simplifying IKE
>
>
> Jan Vilhuber wrote:
>
> >
> > making a 2 message exchange. I favor an even number of messages. Whether
> > that's 2 or 4 I don't MUCH care (2 would be preferable if we can figure
out
> > how).
>
> I'd just like to repeat my preference for the minimal number of messages
> even in this context. When these things are used over cellular links with
> relatively long delays, additional messages really affect the delays
before
> you can start work.
>
> Jari
>
From owner-ipsec@lists.tislabs.com Thu Aug 9 06:48:30 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DmTN16680;
Thu, 9 Aug 2001 06:48:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23306
Thu, 9 Aug 2001 09:05:16 -0400 (EDT)
To: ipsec@lists.tislabs.com
Subject: DRAFT: ipsec charter update
From: tytso@mit.edu
Phone: (781) 391-3464
Message-Id: <E15UpaV-00036d-00@think.thunk.org>
Date: Thu, 09 Aug 2001 09:10:59 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The IPSEC wg chairs met with Marcus Leech today, and after discussions
and consultation with him, we have developed the following draft update
to the IPSEC working group charter.
Contained in this proposed update is a timeline for the IKE V2 work
which was discussed at the IPSEC meeting earlier week in London. We
welcome comments and suggestions on improving the revised working group
charter. We would like to submit this charter to the IESG for
consideration by the end of August, so we would appreciate receiving
comments within the next two weeks.
Barbara Fraser
Theodore Ts'o
IPSEC wg chairs
IP Security Protocol (ipsec)
Last Modified: 09-Aug-01
Chair(s):
Barbara Fraser <byfraser@cisco.com>
Theodore Ts'o <tytso@mit.edu>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion:ipsec@lists.tislabs.com
to Subscribe: ipsec-request@lists.tislabs.com
Archive: ftp://ftp.tis.com/pub/lists/ipsec OR
ftp.ans.net/pub/archive/ipsec
Description of Working Group:
=============================
Rapid advances in communication technology have accentuated the need for
security in the Internet. The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP. A
security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality.
The IPSEC working group will restrict itself to the following short-term
work items to improve the existing key management protocol (IKE):
1) Changes to IKE to support NAT/Firewall traversal
2) Changes to IKE to support SCTP
3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
a fast AES mode suitable for use in hardware encryptors
4) IKE MIB documents
5) Sequence number extensions to ESP to support an expanded sequence
number space.
6) Clarification and standardization of rekeying procedures in IKE.
The working group will also update IKE to reflect implementation
experience, new requirements, and protocol analysis of the existing
protocol. The requirements for IKE V2 will be revised and updated as
the first step in this process.
Goals and Milestones:
=====================
Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and
requirements for IPsec and IKE for use with SCTP, to working
group last call.
Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE
MIBs, and SCTP support for considerations as Draft Standards.
Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE
re-keying completed.
Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE
re-keying to working group last call.
Dec 01 Internet-Draft on IKE v2 Requirements to working group last call
Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted
to the working group.
Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number
expansion, and IKE rekeying for consideration as Draft Standards.
Apr 02 Discuss and select the IKE v2 design from candidate approaches.
Sep 02 IKE v2 Internet-Drafts to working group last call
Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as
Proposed Standards.
From owner-ipsec@lists.tislabs.com Thu Aug 9 06:57:41 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DvfN16843;
Thu, 9 Aug 2001 06:57:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23331
Thu, 9 Aug 2001 09:16:49 -0400 (EDT)
Message-ID: <001201c1205b$3e86f7f0$50b12304@ffb5b>
From: "jshukla" <jshukla@earthlink.net>
To: "Francis Dupont" <Francis.Dupont@enst-bretagne.fr>,
"Henry Spencer" <henry@spsystems.net>
Cc: <ipsec@lists.tislabs.com>
References: <200108081624.f78GOhu73295@givry.rennes.enst-bretagne.fr>
Subject: Re: Simplifying IKE
Date: Wed, 8 Aug 2001 15:41:19 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
----- Original Message -----
From: "Francis Dupont" <Francis.Dupont@enst-bretagne.fr>
To: "Henry Spencer" <henry@spsystems.net>
Cc: <ipsec@lists.tislabs.com>
Sent: Wednesday, August 08, 2001 9:24 AM
Subject: Re: Simplifying IKE
>
> In your previous mail you wrote:
>
> On Wed, 8 Aug 2001, Francis Dupont wrote:
> > ...I believe the source route header is primarily used to see
> > what paths are broken in a network - using the process of
elimination.
>
> => you haven't quoted me but the message I answered to...
>
> Actually, the source route header is increasingly frequently ignored
(or
> considered grounds for dropping the packet) by implementations, because
of
> its utility for various forms of attack.
>
Doesn't MIPv6 use the source route header to solve the
triangle routing problem?
regards,
Jayant
From owner-ipsec@lists.tislabs.com Thu Aug 9 06:59:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DxFN16890;
Thu, 9 Aug 2001 06:59:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23325
Thu, 9 Aug 2001 09:15:48 -0400 (EDT)
Date: Thu, 9 Aug 2001 09:22:10 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: "David W. Faucher" <dfaucher@lucent.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <001f01c120d0$5fc05090$0101a8c0@mv.lucent.com>
Message-ID: <Pine.BSI.3.91.1010809092007.192A-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 9 Aug 2001, David W. Faucher wrote:
> I believe that using the Message ID field as a counter
> has already been suggested, and in this case should work
> to prevent replay attacks.
Simply remembering message IDs also works; we've done this. (Indeed, the
current RFCs can be read as requiring it, although the wording is obscure
and that reading is disputed.) But the counter approach is definitely
superior.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Thu Aug 9 07:42:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79EgFN17854;
Thu, 9 Aug 2001 07:42:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23643
Thu, 9 Aug 2001 09:59:05 -0400 (EDT)
From: Steve.Robinson@psti.com
Subject: RE: Simplifying IKE
To: <andrew.krywaniuk@alcatel.com>
Cc: "'Dan McDonald'" <danmcd@East.Sun.COM>, ipsec@lists.tislabs.com,
owner-ipsec@lists.tislabs.com, "'Sandy Harris'" <sandy@storm.ca>
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
Message-ID: <OF9C738F7C.6465F668-ON80256AA3.004CAA27@psti.com>
Date: Thu, 9 Aug 2001 10:10:14 -0400
X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at
08/09/2001 03:10:53 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Andrew,
While I certainly agree that the attack described in the Ferguson/Schneier
paper on ESP was esoteric, I disagree on your conclusion that
no damage will be done. Let's assume that no attack is occurring. What if
the system administrator enters the section of the key used for decryption
incorrectly? Authentication will work correctly, but right now, there is
no verification mechanism in place to assure that the plaintext is not
garbage, and once you pass garbage up to the upper layers, the behaviour is
system specific and unknown -- it could range from catastrophic to no
damage at all. Authenticating the text after decryption assures that the
correct plaintext is passed to the upper layers. If the current order is
only maintained to ward off DoS, then I'd suggest that the argument is
weak, since DoS can only be minimized, not eliminated.
Steve
"Andrew Krywaniuk"
<andrew.krywaniuk@al To: "'Dan McDonald'" <danmcd@East.Sun.COM>, "'Sandy Harris'"
catel.com> <sandy@storm.ca>
Sent by: cc: <ipsec@lists.tislabs.com>
owner-ipsec@lists.ti Subject: RE: Simplifying IKE
slabs.com
08/09/01 07:45 AM
Please respond to
andrew.krywaniuk
> > > 4. modify ESP to ensure it authenticates all data used in
> the deciphering
> > of the payload
> >
> > This is the only recommendation in this paper based on a
> direct security
> > flaw, with a proposed attack to demonstrate it. There are
> others in the
> > Simpson paper.
>
> And if you use Choice 3a above, you get this for free - AH
> covers the whole
> ESP datagram, SPI/IV/etc.
If my memory serves me correctly, Ferguson/Schneier were actually
suggesting
that
1. encryption be applied AFTER authentication
or, failing that, that
2. the encryption/decryption key be included in the data which is hashed
This is to prevent an esoteric attack they describe which is infeasible and
wouldn't cause any damage anyway. That is not a compelling reason to
redesign ESP.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
From owner-ipsec@lists.tislabs.com Thu Aug 9 08:28:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79FS6N21163;
Thu, 9 Aug 2001 08:28:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23766
Thu, 9 Aug 2001 10:34:28 -0400 (EDT)
From: "Geoffrey Huang" <ghuang@cisco.com>
To: <tytso@mit.edu>, <ipsec@lists.tislabs.com>
Subject: RE: DRAFT: ipsec charter update
Date: Thu, 9 Aug 2001 07:44:52 -0700
Message-ID: <HPEELIIJFCBDLBLJNPFIEELDCCAA.ghuang@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-reply-to: <E15UpaV-00036d-00@think.thunk.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> The IPSEC wg chairs met with Marcus Leech today, and after discussions
> and consultation with him, we have developed the following draft update
> to the IPSEC working group charter.
>
> Contained in this proposed update is a timeline for the IKE V2 work
> which was discussed at the IPSEC meeting earlier week in London. We
> welcome comments and suggestions on improving the revised working group
> charter. We would like to submit this charter to the IESG for
> consideration by the end of August, so we would appreciate receiving
> comments within the next two weeks.
>
> Barbara Fraser
> Theodore Ts'o
> IPSEC wg chairs
>
>
> IP Security Protocol (ipsec)
>
> Last Modified: 09-Aug-01
>
> Chair(s):
> Barbara Fraser <byfraser@cisco.com>
> Theodore Ts'o <tytso@mit.edu>
>
> Security Area Director(s):
> Jeffrey Schiller <jis@mit.edu>
> Marcus Leech <mleech@nortelnetworks.com>
>
> Security Area Advisor:
> Jeffrey Schiller <jis@mit.edu>
>
> Mailing Lists:
> General Discussion:ipsec@lists.tislabs.com
> to Subscribe: ipsec-request@lists.tislabs.com
> Archive: ftp://ftp.tis.com/pub/lists/ipsec OR
> ftp.ans.net/pub/archive/ipsec
>
> Description of Working Group:
> =============================
>
> Rapid advances in communication technology have accentuated the need for
> security in the Internet. The IP Security Protocol Working Group
> (IPSEC) will develop mechanisms to protect client protocols of IP. A
> security protocol in the network layer will be developed to provide
> cryptographic security services that will flexibly support combinations
> of authentication, integrity, access control, and confidentiality.
>
> The IPSEC working group will restrict itself to the following short-term
> work items to improve the existing key management protocol (IKE):
>
> 1) Changes to IKE to support NAT/Firewall traversal
>
> 2) Changes to IKE to support SCTP
>
> 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
> a fast AES mode suitable for use in hardware encryptors
>
> 4) IKE MIB documents
>
> 5) Sequence number extensions to ESP to support an expanded sequence
> number space.
>
> 6) Clarification and standardization of rekeying procedures in IKE.
I think there's more at issue than just rekeying. There are other
ambiguities that also need addressing: when to send a cert_req payload,
unacknowledged notifications, phase 1 lifetime etc. (I sent a mail on this
previously, and Andrew K. mentioned it in his presentation).
-g
> The working group will also update IKE to reflect implementation
> experience, new requirements, and protocol analysis of the existing
> protocol. The requirements for IKE V2 will be revised and updated as
> the first step in this process.
>
> Goals and Milestones:
> =====================
>
> Aug 01 Internet Drafts on NAT and Firewall traversal, IKE
> MIBs, and
> requirements for IPsec and IKE for use with SCTP, to working
> group last call.
>
> Sep 01 Submit revised Internet-Drafts of NAT and Firewall
> traversal, IKE
> MIBs, and SCTP support for considerations as Draft Standards.
>
> Oct 01 Internet-Drafts on sequence number expansion in
> IKE, and IKE
> re-keying completed.
>
> Dec 01 Internet-Drafts on AES/SHA-2, sequence number
> expansion, and IKE
> re-keying to working group last call.
>
> Dec 01 Internet-Draft on IKE v2 Requirements to working
> group last call
>
> Dec 01 Internet-Drafts describing candidate IKE v2
> approaches submitted
> to the working group.
>
> Feb 01 Submit revised Internet-Drafts on AES/SHA-2,
> sequence number
> expansion, and IKE rekeying for consideration as Draft Standards.
>
> Apr 02 Discuss and select the IKE v2 design from candidate
> approaches.
>
> Sep 02 IKE v2 Internet-Drafts to working group last call
>
> Dec 02 Submit IKE v2 Internet-Drafts to the IESG for
> consideration as
> Proposed Standards.
>
>
>
>
>
From owner-ipsec@lists.tislabs.com Thu Aug 9 08:42:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79FgZN23274;
Thu, 9 Aug 2001 08:42:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23893
Thu, 9 Aug 2001 10:56:29 -0400 (EDT)
Message-Id: <200108091502.f79F2ou77622@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "Lars Eggert" <larse@ISI.EDU>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of Thu, 09 Aug 2001 12:34:07 -0000.
<DGEIIENGBBMIPHJOBIIEKEHFCAAA.larse@isi.edu>
Date: Thu, 09 Aug 2001 17:02:49 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
> => this "authentication" by side effect is mandatory according to RFC
> 2401 5.2.1 step 2 but:
> - it doesn't work with tunnel mode
I'm probably missing something obvious, but why doesn't comparing the SA
against the (two) IP headers work for tunnel mode?
=> RFC 2401 specifies that only the inner addresses must be checked
in tunnel mode (inbound processing rules, 5.2.1). The outer destination
is used for SA lookup so must be right, the outer source should not be
checked (5.1.2.1 footnote 3 note). Many implementations incorrectly
implement an outer source address check in tunnel mode and this does
not work well with mobility/multihoming/NAT/...
Regards
Francis.Dupont@enst-bretagne.fr
PS: the outer/inner header stuff for SADB and SPD is the only difference
from the security point of view between tunnel mode and transport + IPinIP
for ESP (AH tunnel mode is different but not used).
From owner-ipsec@lists.tislabs.com Thu Aug 9 08:57:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79FvfN25538;
Thu, 9 Aug 2001 08:57:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23965
Thu, 9 Aug 2001 11:05:20 -0400 (EDT)
From: "sankar ramamoorthi" <sankar@nexsi.com>
To: "Dan Harkins" <dharkins@lounge.org>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Thu, 9 Aug 2001 08:11:57 -0700
Message-ID: <DIEPJEEKAPMEEKEELGGCEEBDDEAA.sankar@nexsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <200108090800.f7980D700535@dharkins@lounge.orgatty.lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> Sent: Thursday, August 09, 2001 1:00 AM
> To: sankar ramamoorthi
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Simplifying IKE
>
>
> I'm obviously explaining myself poorly and that's not a good way
> to start of this discussion....
>
> On Wed, 08 Aug 2001 19:04:25 PDT you wrote
> >
> >
> > > -----Original Message-----
> > > From: Dan Harkins [mailto:dharkins@lounge.org]
> > > Sent: Wednesday, August 08, 2001 6:32 PM
> > > To: sankar ramamoorthi
> > > Cc: Ari Huttunen; ipsec@lists.tislabs.com
> > > Subject: Re: Simplifying IKE
> > >
> > >
> > > On Wed, 08 Aug 2001 13:31:43 PDT you wrote
> > > > > -----Original Message-----
> > > > > From: owner-ipsec@lists.tislabs.com
> > > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> > > > > Sent: Wednesday, August 08, 2001 10:49 AM
> > > > > To: Ari Huttunen
> > > > > Cc: ipsec@lists.tislabs.com
> > > > > Subject: Re: Simplifying IKE
> > > > >
> > > > >
> > > > > My tentative text on the subject is to get rid of the
> commit bit and
> > > > > have a 3 message exchange. The problem with the existing 3 message
> > > > > exchanage (w/o the commit bit being used) is that the
> > > Responder will not
> > > > > instantiate her SAs until receipt of the 3rd message from the
> > > Initiator
> > > > > to avoid a resource consumption attack but the Initiator will
> > > instantiate
> > > > > his SAs upon receipt of the 2nd message from the Responder.
> > > This results
> > > > > in a race between the first few IPsec-protected packets
> and the final
> > > > > message. If the former win they get dropped.
> > > > >
> > > > > My proposal is that the Responder instantiate the SAs
> when she sends
> > > > > the 2nd message back to the Initiator. She will be
> setting a timer to
> > > > > deal with non-receipt of the 3rd message and if the timer fires
> > > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to
> have failed
> > > > > and she can delete these SAs from her SADB.
> > > >
> > > > What happens if the initiator starts sending data before
> the responder
> > > > receives the third message?
> > >
> > > Nothing. That's the whole idea.
> >
> > which means in the worst case packets from the sender will be
> dropped for
> > the duration (RETRANSMIT_TIMER_LIMIT * round-trip-time).
>
> No, they are not dropped in any case. They are properly received because
> the Responder has instantiated the SAs before she sends the 2nd message.
>
Got it. I misunderstood this part.
Does it mean the bogus SAs even though they are short-lived can receive
packets? This is the part that bothers me. If packets can be received on
the bogus SA, what prevents some one to replay data packets through the
bogus SA (If QM message 1 can be replayed then it is possible for ipsec
packets from a previous session to be replayed as well). Such packets will
then be accepted as valid packets. Does it not open up a security hole?
What am I missing?
> > This leads to an ambiguous state where the packets may or not be dropped
> > by the responder. It is also possible that if initiator is sending data
> > at a high rate, it could affect the responder from
> retransmitting message2
> > and getting message3.
>
> No it doesn't matter how fast the Initiator sends packets (assuming you
> mean IPsec-protected packets) because the Responder will have properly
> instantiated SAs _before_ the Initiator has. By the time the Initiator
> has all the information to instantiate his own SAs the Responder will
> already have instantiated hers. No packet loss.
So for this short duration all SA(including bogus SAs) are treated equal
ie: the responder assumes the SAs are properly instantiated even though
the third message is not received yet.
>
> > With a 4 packet exhange scheme, each party knows for sure the other side
> > has the SA established before sending data. The state transitions seem
> > to be much cleaner here.
>
> I think you're misunderstanding what I'm proposing. If the Responder
> instantiates her SAs when she sends the 2nd message then what's the
> problem? How does this not work? The Responder has SAs ready before
> the Initiator does so there is no packet loss.
>
> > > > Will the ipsec packet from initiator be processed since
> responder has
> > > > established the SA on receipt of the second message? If so, can the
> > > > responder treat succesful processing of the data packet as succesful
> > > > authentication of the initiator and mark the SA as valid(basically
> > > > treat the condition same as processing a successful third message).
> > >
> > > I prefer not to make such a linkage (between the IPsec
> processing engine
> > > and the key management system) since there is still a message
> > > that IKE must
> > > process and receipt of that message will dictate whether the SAs stay
> > > or go.
> > >
> >
> > I agree - this was just an idea that I threw around to see if
> > it is possible to come up with a 2 message solution.
>
> If you can come up with a 2 message solution I think we will all be
> happy. Please do so; I cannot come up with one that is simpler than the
> 3 message one I'm proposing.
>
> > > > Personally I prefer a 4 packet exchange model for QM.
> > >
> > > What shortcoming in the scheme I described is solved with a 4 packet
> > > exchange?
> > >
> >
> > see above.
>
> I don't see a shortcoming above. Can you describe to me a situation that
> will not work with what I propose but will work with a 4 message exchange?
>
> Dan.
>
From owner-ipsec@lists.tislabs.com Thu Aug 9 14:30:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79LUmN03328;
Thu, 9 Aug 2001 14:30:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24059
Thu, 9 Aug 2001 11:25:20 -0400 (EDT)
Message-Id: <200108091531.f79FVku77722@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "jshukla" <jshukla@earthlink.net>
cc: "Henry Spencer" <henry@spsystems.net>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of Wed, 08 Aug 2001 15:41:19 PDT.
<001201c1205b$3e86f7f0$50b12304@ffb5b>
Date: Thu, 09 Aug 2001 17:31:46 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
Doesn't MIPv6 use the source route header to solve the
triangle routing problem?
=> yes but the discussion was about the IPv4 source routing which
is beyond repair.
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Thu Aug 9 14:52:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79Lq5N03722;
Thu, 9 Aug 2001 14:52:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24121
Thu, 9 Aug 2001 11:43:18 -0400 (EDT)
Message-Id: <200108091549.f79Fnfu77810@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Steve.Robinson@psti.com
cc: andrew.krywaniuk@alcatel.com, "'Dan McDonald'" <danmcd@East.Sun.COM>,
ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com,
"'Sandy Harris'" <sandy@storm.ca>
Subject: Re: Simplifying IKE
In-reply-to: Your message of Thu, 09 Aug 2001 10:10:14 EDT.
<OF9C738F7C.6465F668-ON80256AA3.004CAA27@psti.com>
Date: Thu, 09 Aug 2001 17:49:41 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
While I certainly agree that the attack described in the Ferguson/Schneier
paper on ESP was esoteric, I disagree on your conclusion that
no damage will be done. Let's assume that no attack is occurring. What if
the system administrator enters the section of the key used for decryption
incorrectly? Authentication will work correctly, but right now, there is
no verification mechanism in place to assure that the plaintext is not
garbage, and once you pass garbage up to the upper layers, the behaviour is
system specific and unknown -- it could range from catastrophic to no
damage at all.
=> I don't buy this argument: upper layers are reading to eat garbage
because garbage can occur on lower layer transmisson errors. They
usually use a checksum for that.
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Thu Aug 9 14:52:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79Lq8N03734;
Thu, 9 Aug 2001 14:52:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24130
Thu, 9 Aug 2001 11:46:02 -0400 (EDT)
Date: Thu, 9 Aug 2001 09:52:33 -0600
From: Shane Amante <shane@amante.org>
To: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
Message-ID: <20010809095233.A2618@ns1.amante.org>
Mail-Followup-To: ipsec@lists.tislabs.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Another advantage for adopting a 2-message exchange is large-delay
satellite links. In particular, consumer satellite broadband
companies, such as Starband and other companies on the horizon, are
using GEO satellites which have a substantial delay of > ~500ms RTT,
just to get across the satellite link. Note, thatdoesn't necessarily
include RTT time from the ground-station through the terrestrial
Internet to the ultimate destination.
Also, Dan, have you defined and/or suggested a value of the
RETRANSMIT_TIMER_LIMIT? I would suggest that it has to either: a) be
hard-coded relatively high to accomodate large-delay
satellite/cellular links; or, b) be set at some reasonable default,
but optionally configurable by the end-user so they may set it higher
or lower depending on their particular application.
Does this sound reasonable?
-shane
Jan Vilhuber wrote:
> > making a 2 message exchange. I favor an even number of messages. Whether
> > that's 2 or 4 I don't MUCH care (2 would be preferable if we can figure out
> > how).
>
> I'd just like to repeat my preference for the minimal number of messages
> even in this context. When these things are used over cellular links with
> relatively long delays, additional messages really affect the delays before
> you can start work.
>
> Jari
From owner-ipsec@lists.tislabs.com Thu Aug 9 15:13:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79MDiN04050;
Thu, 9 Aug 2001 15:13:44 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24361
Thu, 9 Aug 2001 17:35:29 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15218.49481.508600.823194@thomasm-u1.cisco.com>
Date: Thu, 9 Aug 2001 09:58:49 -0700 (PDT)
To: daw@mozart.cs.berkeley.edu (David Wagner)
Cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
Newsgroups: isaac.lists.ipsec
In-Reply-To: <9kqp45$pqf$1@abraham.cs.berkeley.edu>
References: <3B709706.4D051BE5@storm.ca>
<9kqp45$pqf$1@abraham.cs.berkeley.edu>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
They aren't directly related, but their existence
definitely increase complexity of IKE. Unless we
completely change code bases, that may well be
water under the bridge for IKE though.
MIke
David Wagner writes:
> Sandy Harris wrote:
> >The Leech, Schiller and Bellovin (LSB?) document mentions:
> >> the goal: to produce a more secure, simpler, and more robust version of IKE.
> >
> >From the Schneier and Ferguson analysis we get:
> >> 1: eliminate transport mode
> >> 2. eliminate the AH protocol
> >> 3. modify ESP to always authenticate [...]
> >> 4. modify ESP to ensure it authenticates all data [...]
>
> What do any of those have to do with IKE? Those are all about
> the packet-level format, which has very little to do with IKE, as
> far as I can see.
From owner-ipsec@lists.tislabs.com Thu Aug 9 15:18:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f79MIlN04170;
Thu, 9 Aug 2001 15:18:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24324
Thu, 9 Aug 2001 17:20:28 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15218.49850.736269.868270@thomasm-u1.cisco.com>
Date: Thu, 9 Aug 2001 10:04:58 -0700 (PDT)
To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Cc: Dan McDonald <danmcd@East.Sun.COM>, Sandy Harris <sandy@storm.ca>,
ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <3B710406.1175A60@F-Secure.com>
References: <200108080219.f782JIp00242@kebe.east.sun.com>
<3B710406.1175A60@F-Secure.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ari Huttunen writes:
> Thus my preference would be to have a four packet phase 1 (base mode) and
> a four packet quick mode.
Gad. Doesn't anybody care about link up times??? There
a lots of things which are quite sensitive
(user experiencewise) to startup delay. Just
this amount of signaling would be enough to
dissuade anybody from casually using IKE for,
oh say, transport mode, and would be pretty
sucky for everything else too. As Jari points
out, there are plenty of link layers that
punish you for these kinds of excesses.
Also: it needs to be said that the when
security flies in the face usability, it is
well documented which one is jettisoned...
Mike
From owner-ipsec@lists.tislabs.com Thu Aug 9 17:26:46 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A0QjN06193;
Thu, 9 Aug 2001 17:26:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24678
Thu, 9 Aug 2001 19:46:06 -0400 (EDT)
Message-Id: <200108092352.f79NqSJ20568@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: Michael Thomas <mat@cisco.com>
cc: Ari Huttunen <Ari.Huttunen@F-Secure.com>,
Dan McDonald <Dan.McDonald@sun.com>, Sandy Harris <sandy@storm.ca>,
ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of "Thu, 09 Aug 2001 10:04:58 PDT."
<15218.49850.736269.868270@thomasm-u1.cisco.com>
Reply-to: sommerfeld@East.Sun.COM
Date: Thu, 09 Aug 2001 19:52:28 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Ari Huttunen writes:
> > Thus my preference would be to have a four packet phase 1 (base mode) and
> > a four packet quick mode.
>
> Gad. Doesn't anybody care about link up times???
Smooshing phase 1 and phase 2 together begins to look very attractive
when quick mode isn't very (quick).
- Bill
From owner-ipsec@lists.tislabs.com Thu Aug 9 18:34:15 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A1YEN07196;
Thu, 9 Aug 2001 18:34:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24884
Thu, 9 Aug 2001 20:54:23 -0400 (EDT)
Date: Thu, 9 Aug 2001 18:00:53 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Bill Sommerfeld <sommerfeld@East.Sun.COM>
cc: Michael Thomas <mat@cisco.com>, Ari Huttunen <Ari.Huttunen@F-Secure.com>,
Dan McDonald <Dan.McDonald@sun.com>, Sandy Harris <sandy@storm.ca>,
ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <200108092352.f79NqSJ20568@thunk.east.sun.com>
Message-ID: <Pine.LNX.4.21.0108091759420.5064-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 9 Aug 2001, Bill Sommerfeld wrote:
> > Ari Huttunen writes:
> > > Thus my preference would be to have a four packet phase 1 (base mode) and
> > > a four packet quick mode.
> >
> > Gad. Doesn't anybody care about link up times???
>
> Smooshing phase 1 and phase 2 together begins to look very attractive
> when quick mode isn't very (quick).
>
In the above example it's still half of a full exchange. I find that
acceptable for some applications (by no means all).
If you want faster setup times, we'll need another protocol (or use KINK and
install kerberos; depends on your customers' needs).
jan
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Thu Aug 9 18:37:43 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A1bgN07231;
Thu, 9 Aug 2001 18:37:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24870
Thu, 9 Aug 2001 20:52:52 -0400 (EDT)
Date: Thu, 9 Aug 2001 17:59:22 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Michael Thomas <mat@cisco.com>
cc: Ari Huttunen <Ari.Huttunen@F-Secure.com>,
Dan McDonald <danmcd@East.Sun.COM>, Sandy Harris <sandy@storm.ca>,
ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <15218.49850.736269.868270@thomasm-u1.cisco.com>
Message-ID: <Pine.LNX.4.21.0108091757010.5064-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 9 Aug 2001, Michael Thomas wrote:
> Ari Huttunen writes:
> > Thus my preference would be to have a four packet phase 1 (base mode) and
> > a four packet quick mode.
>
> Gad. Doesn't anybody care about link up times??? There
> a lots of things which are quite sensitive
> (user experiencewise) to startup delay.
One should point out that main-mode and quick-mode together comprise 6+3
messages (== 9. Make that 10, if you use the commit-bit). You'd actually save
a message (two actually, if you compare apples to apples) by doing base-mode
(4) and a 4 message quick mode. You'd also gain (arguably) some stability in
the protocol.
Of course a 2 message exchange would be even better. No arguments there. Am I
correct in assuming that people agree there's a 2 message exchange by using
some counter mechanism (proposed by Andrew K, I believe), but only if there's
no PFS (and why is that? Can someone explain? All relevant payloads seem to
be in QM1 and QM2 even with PFS)?
Also, we should start to realize that trying to create a single keying
protocol that solves ALL problems is not worthwhile (we've done this in IKE
and it's caused major confusion). If you want shorter setup times, there
should be a different keying protocol for that (say KINK, or something else
we would have to design, if people don't want to use kerberos).
It's either a single protocol with lots of options and knobs to tune
behaviour, or multiple fairly fixed and well-defined protocols that are
suited for different tasks... There's no 'one-size fits all' keying protocol.
Or rather, there is: it's called IKE.
jan
P.S. I can live with Dan's 3 message exchange IFF it's so well defined that
there's nothing left to the imagination of coders (nothing optional, all
assumptions spelled out including pseudo-code that says in which order to do
things; yes, one could assume we're all adults and don't need such excessive
hand-holding, but the past has shown that's not true at all; the pseudo code
approach is used in the kerberos rfc's, and no one seems to mind overly)...
> Just
> this amount of signaling would be enough to
> dissuade anybody from casually using IKE for,
> oh say, transport mode, and would be pretty
> sucky for everything else too. As Jari points
> out, there are plenty of link layers that
> punish you for these kinds of excesses.
>
> Also: it needs to be said that the when
> security flies in the face usability, it is
> well documented which one is jettisoned...
>
> Mike
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Thu Aug 9 19:09:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A29YN07810;
Thu, 9 Aug 2001 19:09:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24947
Thu, 9 Aug 2001 21:32:59 -0400 (EDT)
Date: Thu, 9 Aug 2001 21:39:18 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Jan Vilhuber <vilhuber@cisco.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.LNX.4.21.0108091757010.5064-100000@janpc-home.cisco.com>
Message-ID: <Pine.BSI.3.91.1010809213609.8177B-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> It's either a single protocol with lots of options and knobs to tune
> behaviour, or multiple fairly fixed and well-defined protocols that are
> suited for different tasks... There's no 'one-size fits all' keying protocol.
That may be true, but it is not a self-evident fact. And often it
suffices for a protocol to be "one size fits almost all".
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Thu Aug 9 19:28:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A2S7N08074;
Thu, 9 Aug 2001 19:28:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25001
Thu, 9 Aug 2001 21:47:22 -0400 (EDT)
Date: Thu, 9 Aug 2001 18:53:26 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Henry Spencer <henry@spsystems.net>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.BSI.3.91.1010809213609.8177B-100000@spsystems.net>
Message-ID: <Pine.LNX.4.21.0108091841020.5064-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 9 Aug 2001, Henry Spencer wrote:
> On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> > It's either a single protocol with lots of options and knobs to tune
> > behaviour, or multiple fairly fixed and well-defined protocols that are
> > suited for different tasks... There's no 'one-size fits all' keying protocol.
>
> That may be true, but it is not a self-evident fact.
Hm.. I think it is. The fact that both main mode and aggressive mode exist,
is proof that there's (at least) two camps that needed to be satisfied in
IKE. One camp wants more security and versatility (negotiation, if you can
call it that), and another camp wants more speed and is willing to sacrifice
identity protection and negotiation.
The existence of KINK is another proof. There's obviously people that need
extremely fast and light-weight keying, which KINK (again arguably) provides
(for certain scenarios).
Personally, I consider that incontrovertible evidence, if not proof.
> And often it
> suffices for a protocol to be "one size fits almost all".
>
That doesn't really contradict what I said, of course. If you can get a good
fit for 90%, then you still need a separate protocol for the other 10% (if
they have a strong enough case, which I would argue they have and point at
the KINK WG again). I believe (and again KINK is evidence) that there ISN'T a
fit for 90%. More like 60/40.
All this back and forth in this WG is yet another piece of evidence that
there's no one-size-fits all (or even almost all). Some want AH, others want
to get rid of it. Some want main mode, other want aggressive mode. Ad
nauseum...
I'm not advocating we do them in parallel. Let's define some requirements
that simplifies as much as possible, agree on what can be left out to acheive
that, and send people that don't agree off to write their own requirements
(can't the WG chairs appoint sub-committee's to explore and recommend? Maybe
we should do that).
I think it's actually crucial we spell out what the camps are and what they
need. We currently (I claim) have NO good requirements to go off and revise
IKE, since we don't really know what we're optimizing it for. Do we want
maximum security? Or fast setup? Unless someone shows me an exchange that
combines both, I'm going to continue to claim that those two are mutually
exclusive (I'd be happy to be proven wrong). As long as that dichotomy exists
(amongst others), we'll need two protocols (or one that can do both...
whoops... we already did that once).
Or maybe we just point over to KINK and say "there's your fast setup" and
deal only with the one that does maximum security? Fine by me. But we need to
spell it out, so we can all start working in the same direction...
jan
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Thu Aug 9 19:40:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A2eTN08232;
Thu, 9 Aug 2001 19:40:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25031
Thu, 9 Aug 2001 22:01:10 -0400 (EDT)
Date: Thu, 9 Aug 2001 22:07:29 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Jan Vilhuber <vilhuber@cisco.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.LNX.4.21.0108091841020.5064-100000@janpc-home.cisco.com>
Message-ID: <Pine.BSI.3.91.1010809215525.8177D-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> > > ...There's no 'one-size fits all' keying protocol.
> > That may be true, but it is not a self-evident fact.
>
> Hm.. I think it is. The fact that both main mode and aggressive mode exist,
> is proof that there's (at least) two camps that needed to be satisfied in
> IKE. One camp wants more security and versatility (negotiation, if you can
> call it that), and another camp wants more speed and is willing to sacrifice
> identity protection and negotiation.
Not quite. What you have established is that some people *think* there is
a need for two approaches. That doesn't make it true! Especially since
that design work was, to a large extent, done in advance of real live
implementation experience.
> The existence of KINK is another proof. There's obviously people that need
> extremely fast and light-weight keying, which KINK (again arguably) provides
> (for certain scenarios).
Again, there are people who *think* they need better keying performance,
but that doesn't make it true. (There were a lot of people who thought
they needed better data-transfer protocol performance than TCP/IP could
deliver. They put a lot of work into "lightweight" alternatives, most of
which are dead and forgotten, superseded by TCP/IP.)
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Thu Aug 9 19:46:00 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A2jxN08327;
Thu, 9 Aug 2001 19:45:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25048
Thu, 9 Aug 2001 22:12:07 -0400 (EDT)
Date: Thu, 9 Aug 2001 19:18:10 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Henry Spencer <henry@spsystems.net>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.BSI.3.91.1010809215525.8177D-100000@spsystems.net>
Message-ID: <Pine.LNX.4.21.0108091910410.5268-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hm.. Not sure where to go with this discussion. What's the difference between
people (and not just one or two) *thinking* they need something, and it being
true that they need it? If there's enough of them, then it becomes true. We
don't really NEED this internet thing at all, really. I'd be just as happy
sitting in a cave and grooving with a pict...
If you want to go convince the aggressive mode (or whatever you want to call
it... low number of messages/low setup-time/whatever) camp that they don't
REALLY need it, be my guest.
I could argue in reverse saying that just because you don't think they need
it doesn't make it true that they don't need it. It's a rather pointless
argument. Fact is that there's a camp that (thinks they) needs fewer messages
at the expense of some features (and some security). Let's hold a straw-poll
to count the percentages... Who calls for such a thing? The chairs? Let's
count. I'm trying to figure out what people want, afterall. If no one cares
about speedy setup times, then let's axe aggressive mode and be done with it.
I'm actually OK with that. I suspect plenty of people won't.
They think they need it, you think they don't. Fine. They still exist, and
there's enough of them to not just be blown off because you don't think
they're right...
jan
On Thu, 9 Aug 2001, Henry Spencer wrote:
> On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> > > > ...There's no 'one-size fits all' keying protocol.
> > > That may be true, but it is not a self-evident fact.
> >
> > Hm.. I think it is. The fact that both main mode and aggressive mode exist,
> > is proof that there's (at least) two camps that needed to be satisfied in
> > IKE. One camp wants more security and versatility (negotiation, if you can
> > call it that), and another camp wants more speed and is willing to sacrifice
> > identity protection and negotiation.
>
> Not quite. What you have established is that some people *think* there is
> a need for two approaches. That doesn't make it true! Especially since
> that design work was, to a large extent, done in advance of real live
> implementation experience.
>
> > The existence of KINK is another proof. There's obviously people that need
> > extremely fast and light-weight keying, which KINK (again arguably) provides
> > (for certain scenarios).
>
> Again, there are people who *think* they need better keying performance,
> but that doesn't make it true. (There were a lot of people who thought
> they needed better data-transfer protocol performance than TCP/IP could
> deliver. They put a lot of work into "lightweight" alternatives, most of
> which are dead and forgotten, superseded by TCP/IP.)
>
> Henry Spencer
> henry@spsystems.net
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Thu Aug 9 19:56:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A2uDN08447;
Thu, 9 Aug 2001 19:56:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25091
Thu, 9 Aug 2001 22:22:34 -0400 (EDT)
Date: Thu, 9 Aug 2001 22:28:52 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Jan Vilhuber <vilhuber@cisco.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.LNX.4.21.0108091910410.5268-100000@janpc-home.cisco.com>
Message-ID: <Pine.BSI.3.91.1010809222124.8177E-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> Hm.. Not sure where to go with this discussion. What's the difference between
> people (and not just one or two) *thinking* they need something, and it being
> true that they need it? If there's enough of them, then it becomes true.
No; belief and reality *are* different. The way you tell the difference
is to design and build a decent-but-not-all-things-to-all-people solution,
and listen to see if the outraged screams and angry grumbling slowly die
away.
You can't settle this on mailing lists or in front of blackboards. As
long as your design is just paper, people will find a thousand reasons why
it's not good enough or why it needs 57 more options. Actual code and
operational experience is needed to show them wrong. That's the way the
IETF is supposed to do things, remember!
We should be aiming for a simple, clean, middle-of-the-road solution with
few options. After that's *in service* for a while, then is the time to
take a hard look at whether anything else is needed.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Thu Aug 9 20:01:01 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A311N08516;
Thu, 9 Aug 2001 20:01:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25108
Thu, 9 Aug 2001 22:27:00 -0400 (EDT)
Date: Thu, 9 Aug 2001 19:33:03 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Henry Spencer <henry@spsystems.net>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.BSI.3.91.1010809222124.8177E-100000@spsystems.net>
Message-ID: <Pine.LNX.4.21.0108091930090.5268-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 9 Aug 2001, Henry Spencer wrote:
> On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> > Hm.. Not sure where to go with this discussion. What's the difference between
> > people (and not just one or two) *thinking* they need something, and it being
> > true that they need it? If there's enough of them, then it becomes true.
>
> No; belief and reality *are* different.
Fine. That's absolutely true. But you're arguing YOUR belief against someone
else's.
Let's hold a strawpoll and see if there's two (or more) camps or not. If
there's sufficient people in whatever camps we identity, we send them off
into sub-committees to hammer out their requirements.
I don't much like making a middle-of-the-road protocols. We just had one.
It's what we're arguing about. I don't think (belief again) that you'll ever
satisfy the two camps (I suspect, believe, pray, that there's only two).
Let's bite the bullet, realize thee ARE more than one camp, and that a
middle-of-the-road approach won't solve this problem. Stand up and be
counted.
jan
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Thu Aug 9 20:01:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A31AN08530;
Thu, 9 Aug 2001 20:01:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25121
Thu, 9 Aug 2001 22:28:39 -0400 (EDT)
Date: Thu, 9 Aug 2001 22:34:57 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Jan Vilhuber <vilhuber@cisco.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.LNX.4.21.0108091930090.5268-100000@janpc-home.cisco.com>
Message-ID: <Pine.BSI.3.91.1010809223402.8177F-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> I don't much like making a middle-of-the-road protocols. We just had one.
No, we had a cover-the-whole-road-with-a-thousand-vague-options protocol.
It's not the same thing.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Thu Aug 9 20:07:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A37GN08593;
Thu, 9 Aug 2001 20:07:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25145
Thu, 9 Aug 2001 22:35:23 -0400 (EDT)
Date: Thu, 9 Aug 2001 19:41:55 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Henry Spencer <henry@spsystems.net>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.BSI.3.91.1010809223402.8177F-100000@spsystems.net>
Message-ID: <Pine.LNX.4.21.0108091935550.5268-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 9 Aug 2001, Henry Spencer wrote:
> On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> > I don't much like making a middle-of-the-road protocols. We just had one.
>
> No, we had a cover-the-whole-road-with-a-thousand-vague-options protocol.
> It's not the same thing.
>
Sigh.. I believe we're actually arguing more or less the same thing, but with
differing degrees.
You're saying satisfy 90%. Personally, I wonder if there IS a 90% in the
ipsec WG. I've yet to see more than, say (making this up now for dramatic
effect) 20% of the people agree on any particular thing.
I say let's figure out the camps, and write a protocol that satisfies ONE of
the camps (and later we'll write another that satisfies the other, if they
decide there's still a need to do so).
A straw-poll should quickly show if there's a 90% that agree on something in
this group. If, so, we'll obviously do what you propose. If not, we'll wind
up doing what I propose (in some way).
As for middle-of-the-road, I fear that it'll be so-so at everything, and not
very good at anything at all (design by committee. It's one of the few things
I DID agree with in the Schneier paper). That'll just prompt people to ignore
it altogether and write their own. I much prefer to write out the
requirements fairly (but not too, and there's the rub) narrow, and write the
darn protocol. People will then know what it's good for and what it's NOT
good for, and hopefully not come whining about 'oh no.. not IKE' again (you
can't imagine how many meetings and discussions I've heard that).
jan
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Thu Aug 9 23:28:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A6S9N18318;
Thu, 9 Aug 2001 23:28:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA25466
Fri, 10 Aug 2001 01:34:11 -0400 (EDT)
Message-Id: <3.0.3.32.20010809223922.00dbaea0@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Thu, 09 Aug 2001 22:39:22 -0700
To: tytso@mit.edu, ipsec@lists.tislabs.com
From: Alex Alten <Alten@home.com>
Subject: Re: DRAFT: ipsec charter update
In-Reply-To: <E15UpaV-00036d-00@think.thunk.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Barbara & Theodore,
Is there a requirements doc for IKE V2? What are the acceptance criteria?
Will there be a security analysis before Last Call by a reputable group of
cryptographers, etc?
- Alex
At 09:10 AM 8/9/2001 -0400, tytso@mit.edu wrote:
>
>The IPSEC wg chairs met with Marcus Leech today, and after discussions
>and consultation with him, we have developed the following draft update
>to the IPSEC working group charter.
>
>Contained in this proposed update is a timeline for the IKE V2 work
>which was discussed at the IPSEC meeting earlier week in London. We
>welcome comments and suggestions on improving the revised working group
>charter. We would like to submit this charter to the IESG for
>consideration by the end of August, so we would appreciate receiving
>comments within the next two weeks.
>
> Barbara Fraser
> Theodore Ts'o
> IPSEC wg chairs
>
>
>IP Security Protocol (ipsec)
>
>Last Modified: 09-Aug-01
>
>Chair(s):
> Barbara Fraser <byfraser@cisco.com>
> Theodore Ts'o <tytso@mit.edu>
>
>Security Area Director(s):
> Jeffrey Schiller <jis@mit.edu>
> Marcus Leech <mleech@nortelnetworks.com>
>
>Security Area Advisor:
> Jeffrey Schiller <jis@mit.edu>
>
>Mailing Lists:
> General Discussion:ipsec@lists.tislabs.com
> to Subscribe: ipsec-request@lists.tislabs.com
> Archive: ftp://ftp.tis.com/pub/lists/ipsec OR
> ftp.ans.net/pub/archive/ipsec
>
>Description of Working Group:
>=============================
>
>Rapid advances in communication technology have accentuated the need for
>security in the Internet. The IP Security Protocol Working Group
>(IPSEC) will develop mechanisms to protect client protocols of IP. A
>security protocol in the network layer will be developed to provide
>cryptographic security services that will flexibly support combinations
>of authentication, integrity, access control, and confidentiality.
>
>The IPSEC working group will restrict itself to the following short-term
>work items to improve the existing key management protocol (IKE):
>
>1) Changes to IKE to support NAT/Firewall traversal
>
>2) Changes to IKE to support SCTP
>
>3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
> a fast AES mode suitable for use in hardware encryptors
>
>4) IKE MIB documents
>
>5) Sequence number extensions to ESP to support an expanded sequence
> number space.
>
>6) Clarification and standardization of rekeying procedures in IKE.
>
>The working group will also update IKE to reflect implementation
>experience, new requirements, and protocol analysis of the existing
>protocol. The requirements for IKE V2 will be revised and updated as
>the first step in this process.
>
>Goals and Milestones:
>=====================
>
>Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and
> requirements for IPsec and IKE for use with SCTP, to working
> group last call.
>
>Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE
> MIBs, and SCTP support for considerations as Draft Standards.
>
>Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE
> re-keying completed.
>
>Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE
> re-keying to working group last call.
>
>Dec 01 Internet-Draft on IKE v2 Requirements to working group last call
>
>Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted
> to the working group.
>
>Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number
> expansion, and IKE rekeying for consideration as Draft Standards.
>
>Apr 02 Discuss and select the IKE v2 design from candidate approaches.
>
>Sep 02 IKE v2 Internet-Drafts to working group last call
>
>Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as
> Proposed Standards.
>
>
>
>
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Fri Aug 10 03:30:41 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AAUfN13347;
Fri, 10 Aug 2001 03:30:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26018
Fri, 10 Aug 2001 05:55:24 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15219.45309.512663.854766@thomasm-u1.cisco.com>
Date: Fri, 10 Aug 2001 03:01:33 -0700 (PDT)
To: Henry Spencer <henry@spsystems.net>
Cc: Jan Vilhuber <vilhuber@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.BSI.3.91.1010809222124.8177E-100000@spsystems.net>
References: <Pine.LNX.4.21.0108091910410.5268-100000@janpc-home.cisco.com>
<Pine.BSI.3.91.1010809222124.8177E-100000@spsystems.net>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Henry Spencer writes:
> On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> > Hm.. Not sure where to go with this discussion. What's the difference between
> > people (and not just one or two) *thinking* they need something, and it being
> > true that they need it? If there's enough of them, then it becomes true.
>
> No; belief and reality *are* different. The way you tell the difference
> is to design and build a decent-but-not-all-things-to-all-people solution,
> and listen to see if the outraged screams and angry grumbling slowly die
> away.
Ah, the beloved OS vendor to the masses stance.
Glad to know where you stand.
Mike
From owner-ipsec@lists.tislabs.com Fri Aug 10 03:30:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AAUgN13355;
Fri, 10 Aug 2001 03:30:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25991
Fri, 10 Aug 2001 05:36:55 -0400 (EDT)
Message-Id: <200108100942.f7A9gsu80466@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "Horn, Mike" <mhorn@virtela.net>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of Thu, 09 Aug 2001 21:38:01 MDT.
<CCFF88268143CC4181A758DCC0ECDC13F7B926@posthaus.virtela.cc>
Date: Fri, 10 Aug 2001 11:42:54 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
=> note I am not the authors of the AH for IPv4 source routing idea
(which was given as a *historical* suggested main use of AH).
So don't blame me if your poll shows AH is not used for that
(I'll be very surprised if you get another answer :-).
PS: don't blame Dan McDonald (the real author) too because
he made very clear in his mail that the idea was an "old motivator".
BTW to forward Dan's whole message to ISP/ops (i.e. NANOG) is
still interesting because if the IPv4 source routing is dead
this is not (yet?) the case for the IPv6 one.
There are "ISP/ops" types on this list. I do not know of anyone using AH
for securing source-routed packets being used for debugging. In fact I know
of very few people using AH for *anything*. I have forwarded the question
to the NANOG (North American Network Operators Group). I will summarize
replies and forward to the IPSEC mailing list.
=> please do this for the complete original message.
Also, I think that keeping
transport mode is important. One common VPN application for transport mode
is securing IP in IP tunnels (see draft-touch-ipsec-vpn-01.txt).
=> I believe there will be more opposition to remove transport mode
than AH. BTW the current task (and the name of the thread) is to clean up
IKE only (and we can say it needs this :-).
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Fri Aug 10 03:30:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AAUiN13371;
Fri, 10 Aug 2001 03:30:44 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26010
Fri, 10 Aug 2001 05:53:54 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15219.45210.406744.263294@thomasm-u1.cisco.com>
Date: Fri, 10 Aug 2001 02:59:54 -0700 (PDT)
To: Henry Spencer <henry@spsystems.net>
Cc: Jan Vilhuber <vilhuber@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.BSI.3.91.1010809215525.8177D-100000@spsystems.net>
References: <Pine.LNX.4.21.0108091841020.5064-100000@janpc-home.cisco.com>
<Pine.BSI.3.91.1010809215525.8177D-100000@spsystems.net>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Henry Spencer writes:
> > The existence of KINK is another proof. There's obviously people that need
> > extremely fast and light-weight keying, which KINK (again arguably) provides
> > (for certain scenarios).
>
> Again, there are people who *think* they need better keying performance,
> but that doesn't make it true. (There were a lot of people who thought
> they needed better data-transfer protocol performance than TCP/IP could
> deliver. They put a lot of work into "lightweight" alternatives, most of
> which are dead and forgotten, superseded by TCP/IP.)
I don't know how much proof you need. An eight exchange
setup with the requisite public key operations would
make IKE an unsuitable alternative for end to end keying
for, say, SIP traffic where people have built in expectations
of post dial delay. In fact, even a two message exchange
with cheap symmetric keying is problematic; there's a lot of
other baggage than just key agreement when you're trying
to set up a call.
Mike
From owner-ipsec@lists.tislabs.com Fri Aug 10 04:09:55 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AB9sN14809;
Fri, 10 Aug 2001 04:09:55 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26207
Fri, 10 Aug 2001 06:32:55 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15219.47586.613484.396301@thomasm-u1.cisco.com>
Date: Fri, 10 Aug 2001 03:39:30 -0700 (PDT)
To: Jan Vilhuber <vilhuber@cisco.com>
Cc: Henry Spencer <henry@spsystems.net>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.LNX.4.21.0108091841020.5064-100000@janpc-home.cisco.com>
References: <Pine.BSI.3.91.1010809213609.8177B-100000@spsystems.net>
<Pine.LNX.4.21.0108091841020.5064-100000@janpc-home.cisco.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On thing that might help to show that there really is
a division in the problem space is that VPN's generally
compete with the time it takes a modem to train --
ie, they are replacing dial and its expectations which
has a lot of head room for fat. It's hard to imagine
how you coujld make a VPN startup worse than that.
On the other hand, we have transport like uses
which have the expectation that anything you add
beyond SYN/SYN-ACK/ACK is unwanted overhead (or
less). Many thing are already piling on with
just-one-more-exchangeitus, and security (along
with signaled QoS) deliver us pretty quickly to
hell by way of handbasket.
So, I really don't have a very good opinion on
how to make the engineering tradeoffs, but it
seems as long as there is transport mode IPsec,
this sort of debate is going to go on.
[and to the fans of killing transport, do tell
what the viable alternative is to IPsec, and
please don't say TLS since it doesn't work with
UDP]
Mike
Jan Vilhuber writes:
> On Thu, 9 Aug 2001, Henry Spencer wrote:
>
> > On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> > > It's either a single protocol with lots of options and knobs to tune
> > > behaviour, or multiple fairly fixed and well-defined protocols that are
> > > suited for different tasks... There's no 'one-size fits all' keying protocol.
> >
> > That may be true, but it is not a self-evident fact.
>
> Hm.. I think it is. The fact that both main mode and aggressive mode exist,
> is proof that there's (at least) two camps that needed to be satisfied in
> IKE. One camp wants more security and versatility (negotiation, if you can
> call it that), and another camp wants more speed and is willing to sacrifice
> identity protection and negotiation.
>
> The existence of KINK is another proof. There's obviously people that need
> extremely fast and light-weight keying, which KINK (again arguably) provides
> (for certain scenarios).
>
> Personally, I consider that incontrovertible evidence, if not proof.
>
>
> > And often it
> > suffices for a protocol to be "one size fits almost all".
> >
> That doesn't really contradict what I said, of course. If you can get a good
> fit for 90%, then you still need a separate protocol for the other 10% (if
> they have a strong enough case, which I would argue they have and point at
> the KINK WG again). I believe (and again KINK is evidence) that there ISN'T a
> fit for 90%. More like 60/40.
>
> All this back and forth in this WG is yet another piece of evidence that
> there's no one-size-fits all (or even almost all). Some want AH, others want
> to get rid of it. Some want main mode, other want aggressive mode. Ad
> nauseum...
>
> I'm not advocating we do them in parallel. Let's define some requirements
> that simplifies as much as possible, agree on what can be left out to acheive
> that, and send people that don't agree off to write their own requirements
> (can't the WG chairs appoint sub-committee's to explore and recommend? Maybe
> we should do that).
>
> I think it's actually crucial we spell out what the camps are and what they
> need. We currently (I claim) have NO good requirements to go off and revise
> IKE, since we don't really know what we're optimizing it for. Do we want
> maximum security? Or fast setup? Unless someone shows me an exchange that
> combines both, I'm going to continue to claim that those two are mutually
> exclusive (I'd be happy to be proven wrong). As long as that dichotomy exists
> (amongst others), we'll need two protocols (or one that can do both...
> whoops... we already did that once).
>
> Or maybe we just point over to KINK and say "there's your fast setup" and
> deal only with the one that does maximum security? Fine by me. But we need to
> spell it out, so we can all start working in the same direction...
>
> jan
> --
> Jan Vilhuber vilhuber@cisco.com
> Cisco Systems, San Jose (408) 527-0847
>
From owner-ipsec@lists.tislabs.com Fri Aug 10 06:00:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AD0QN19432;
Fri, 10 Aug 2001 06:00:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26404
Fri, 10 Aug 2001 08:11:25 -0400 (EDT)
From: Steve.Robinson@psti.com
Subject: Re: Simplifying IKE
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: andrew.krywaniuk@alcatel.com, "'Dan McDonald'" <danmcd@East.Sun.COM>,
ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com,
"'Sandy Harris'" <sandy@storm.ca>
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
Message-ID: <OF3D62F91F.1F96E82A-ON80256AA4.0040E368@psti.com>
Date: Fri, 10 Aug 2001 08:22:32 -0400
X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at
08/10/2001 01:23:15 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Francis Dupont
<Francis.Dupont@enst-br To: Steve.Robinson@psti.com
etagne.fr> cc: andrew.krywaniuk@alcatel.com, "'Dan McDonald'"
Sent by: <danmcd@East.Sun.COM>, ipsec@lists.tislabs.com,
owner-ipsec@lists.tisla owner-ipsec@lists.tislabs.com, "'Sandy Harris'" <sandy@storm.ca>
bs.com Subject: Re: Simplifying IKE
08/09/01 11:49 AM
In your previous mail you wrote:
While I certainly agree that the attack described in the
Ferguson/Schneier
paper on ESP was esoteric, I disagree on your conclusion that
no damage will be done. Let's assume that no attack is occurring. What
if
the system administrator enters the section of the key used for
decryption
incorrectly? Authentication will work correctly, but right now, there
is
no verification mechanism in place to assure that the plaintext is not
garbage, and once you pass garbage up to the upper layers, the behaviour
is
system specific and unknown -- it could range from catastrophic to no
damage at all.
=> I don't buy this argument: upper layers are reading to eat garbage
because garbage can occur on lower layer transmisson errors. They
usually use a checksum for that.
STEVE:
Yes, checksums, when used, will catch the garbage. But I still like to
follow the ideals of robust programming and not rely on the upper layer for
catching what could be a bad design in the lower layers. I like the
principals behind object oriented design, in that the lower layers
shouldn't know what the upper layers are doing, and visa versa -- so each
layer should do what it can to make sure that the data received is not
garbage, and if the need is there, to make sure that the data it is passing
up to the next layer isn't garbage either. Knowledge of upper layer
behaviour, in my mind, violates the principals of separating layer
behaviour. I also realize that in practice this is not always possible.
However, I believe that this reason alone is NOT good enough to justify
modification of an established protocol. My personal preference is for the
eventual simplification of IPsec by having a single security protocol.
>From what I have seen historically from this thread, it is probably better
to establish a new protocol that will obsolete AH and ESP some time down
the road, rather than attempt modification of either of the two established
protocols we have.
Anyway, I won't comment further on this, it is kinda off topic, and I know
the working group is currently concentrating it's efforts on IKE
modifications.
Take Care,
steve.robinson@psti.com
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Fri Aug 10 06:22:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ADM3N20020;
Fri, 10 Aug 2001 06:22:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26436
Fri, 10 Aug 2001 08:42:38 -0400 (EDT)
Date: Thu, 09 Aug 2001 18:17:12 -0700
From: Derrell Piper <ddp@cips.nokia.com>
To: sommerfeld@East.Sun.COM, Michael Thomas <mat@cisco.com>
cc: Ari Huttunen <Ari.Huttunen@F-Secure.com>,
Dan McDonald <Dan.McDonald@sun.com>, Sandy Harris <sandy@storm.ca>,
ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
Message-ID: <976979.997381032@el-air-2.electric-loft.org>
In-Reply-To: <200108092352.f79NqSJ20568@thunk.east.sun.com>
References: <200108092352.f79NqSJ20568@thunk.east.sun.com>
X-Mailer: Mulberry/2.1.0b3 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
QM with PFS has never really been all that "quick". However, it seems a
valuable attribute that the relatively long-lived Phase 1 IKE SA's allow
for seamless Phase 2 rekeying (when done right). This would be much harder
if there were just one single negotiation.
Derrell
--On Thursday, August 9, 2001 7:52 PM -0400 Bill Sommerfeld
<sommerfeld@East.Sun.COM> wrote:
>> Ari Huttunen writes:
>> > Thus my preference would be to have a four packet phase 1 (base mode)
>> > and a four packet quick mode.
>>
>> Gad. Doesn't anybody care about link up times???
>
> Smooshing phase 1 and phase 2 together begins to look very attractive
> when quick mode isn't very (quick).
>
> - Bill
>
>
From owner-ipsec@lists.tislabs.com Fri Aug 10 07:07:15 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AE7EN21443;
Fri, 10 Aug 2001 07:07:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26497
Fri, 10 Aug 2001 09:15:42 -0400 (EDT)
Message-ID: <CCFF88268143CC4181A758DCC0ECDC13DE7781@posthaus.virtela.cc>
From: "Horn, Mike" <mhorn@virtela.net>
To: "'tytso@mit.edu'" <tytso@mit.edu>, ipsec@lists.tislabs.com
Subject: RE: DRAFT: ipsec charter update
Date: Thu, 9 Aug 2001 22:31:16 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I think this is definitely a step in the right direction, but it seems in
direct conflict with the position statement that was just sent out by Marcus
Leech. Does this have approval from the IESG and IAB? Also, how does this
fit in with the work going on to simplify IKE? Are things like removing AH,
aggresive mode, etc. still open for discussion? Again, it's great to see
the working group moving forward to provide standardized solutions for known
problems.
Mike Horn
> -----Original Message-----
> From: tytso@mit.edu [mailto:tytso@mit.edu]
> Sent: Thursday, August 09, 2001 7:11 AM
> To: ipsec@lists.tislabs.com
> Subject: DRAFT: ipsec charter update
>
>
>
> The IPSEC wg chairs met with Marcus Leech today, and after discussions
> and consultation with him, we have developed the following
> draft update
> to the IPSEC working group charter.
>
> Contained in this proposed update is a timeline for the IKE V2 work
> which was discussed at the IPSEC meeting earlier week in London. We
> welcome comments and suggestions on improving the revised
> working group
> charter. We would like to submit this charter to the IESG for
> consideration by the end of August, so we would appreciate receiving
> comments within the next two weeks.
>
> Barbara Fraser
> Theodore Ts'o
> IPSEC wg chairs
>
>
> IP Security Protocol (ipsec)
>
> Last Modified: 09-Aug-01
>
> Chair(s):
> Barbara Fraser <byfraser@cisco.com>
> Theodore Ts'o <tytso@mit.edu>
>
> Security Area Director(s):
> Jeffrey Schiller <jis@mit.edu>
> Marcus Leech <mleech@nortelnetworks.com>
>
> Security Area Advisor:
> Jeffrey Schiller <jis@mit.edu>
>
> Mailing Lists:
> General Discussion:ipsec@lists.tislabs.com
> to Subscribe: ipsec-request@lists.tislabs.com
> Archive: ftp://ftp.tis.com/pub/lists/ipsec OR
> ftp.ans.net/pub/archive/ipsec
>
> Description of Working Group:
> =============================
>
> Rapid advances in communication technology have accentuated
> the need for
> security in the Internet. The IP Security Protocol Working Group
> (IPSEC) will develop mechanisms to protect client protocols of IP. A
> security protocol in the network layer will be developed to provide
> cryptographic security services that will flexibly support
> combinations
> of authentication, integrity, access control, and confidentiality.
>
> The IPSEC working group will restrict itself to the following
> short-term
> work items to improve the existing key management protocol (IKE):
>
> 1) Changes to IKE to support NAT/Firewall traversal
>
> 2) Changes to IKE to support SCTP
>
> 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
> a fast AES mode suitable for use in hardware encryptors
>
> 4) IKE MIB documents
>
> 5) Sequence number extensions to ESP to support an expanded sequence
> number space.
>
> 6) Clarification and standardization of rekeying procedures in IKE.
>
> The working group will also update IKE to reflect implementation
> experience, new requirements, and protocol analysis of the existing
> protocol. The requirements for IKE V2 will be revised and updated as
> the first step in this process.
>
> Goals and Milestones:
> =====================
>
> Aug 01 Internet Drafts on NAT and Firewall traversal,
> IKE MIBs, and
> requirements for IPsec and IKE for use with SCTP, to working
> group last call.
>
> Sep 01 Submit revised Internet-Drafts of NAT and
> Firewall traversal, IKE
> MIBs, and SCTP support for considerations as Draft Standards.
>
> Oct 01 Internet-Drafts on sequence number expansion in
> IKE, and IKE
> re-keying completed.
>
> Dec 01 Internet-Drafts on AES/SHA-2, sequence number
> expansion, and IKE
> re-keying to working group last call.
>
> Dec 01 Internet-Draft on IKE v2 Requirements to
> working group last call
>
> Dec 01 Internet-Drafts describing candidate IKE v2
> approaches submitted
> to the working group.
>
> Feb 01 Submit revised Internet-Drafts on AES/SHA-2,
> sequence number
> expansion, and IKE rekeying for consideration as Draft
> Standards.
>
> Apr 02 Discuss and select the IKE v2 design from
> candidate approaches.
>
> Sep 02 IKE v2 Internet-Drafts to working group last call
>
> Dec 02 Submit IKE v2 Internet-Drafts to the IESG for
> consideration as
> Proposed Standards.
>
>
>
>
From owner-ipsec@lists.tislabs.com Fri Aug 10 07:08:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AE8hN21506;
Fri, 10 Aug 2001 07:08:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26503
Fri, 10 Aug 2001 09:16:43 -0400 (EDT)
Reply-To: <jeevas@future.futsoft.com>
From: "JEEVA" <jeevas@future.futsoft.com>
To: <ipsec@lists.tislabs.com>
Subject: openBSD testing doubts
Date: Fri, 10 Aug 2001 12:43:03 +0530
Message-Id: <000001c1216b$e6ab7c60$2a05080a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Disposition-Notification-To: "JEEVA" <jeevas@future.futsoft.com>
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all,
we are working in openBSD2.9 ipsec code. we first tested for manual key
between two hosts .
In Host A:
sysctl -w net.inet.esp.enable=1
sysctl -w net.inet.esp.enable=1
ipsecadm new esp -spi 1000 -src HostA -dst HostB -forcetunnel enc
3des -auth sha1 -key
7762d8707255d974168cbb1d274f8bed4cbd3364dd -authkey
6a20367e21c66e5a40739db293cfef2a4e6659f
ipsecadm new esp -spi 1001 -src HostB -dst HostA -forcetunnel enc
3des -auth sha1 -key
7762d8707255d974168cbb1d274f8bed4cbd3364dd -authkey
6a20367e21c66e5a40739db293cfef2a4e6659f
ipsecadm flow -proto esp -dst HostB -addr HostA 255.255.255.255 HostB
255.255.255.255 -in -require
upto this working fine. but when i try to enter
ipsecadm flow -proto esp -dst HostB -addr HostA 255.255.255.255
HostB 255.255.255.255 -out -require
it's giving Sendto : not permitted error in runtime. so, i deleted this
line , i kept only inbound flow in HostA
Host B:
sysctl -w net.inet.esp.enable=1
sysctl -w net.inet.esp.enable=1
ipsecadm new esp -spi 1001 -src HostB -dst HostA -forcetunnel enc
3des -auth sha1 -key
7762d8707255d974168cbb1d274f8bed4cbd3364dd -authkey
6a20367e21c66e5a40739db293cfef2a4e6659f
ipsecadm new esp -spi 1000 -src HostB -dst HostA -forcetunnel enc
3des -auth sha1 -key
7762d8707255d974168cbb1d274f8bed4cbd3364dd -authkey
6a20367e21c66e5a40739db293cfef2a4e6659f
ipsecadm flow -proto esp -dst HostA -addr HostA 255.255.255.255 HostB
255.255.255.255 -in -require
upto this working fine. but when i try to enter
ipsecadm flow -proto esp -dst HostA -addr HostA 255.255.255.255
HostB 255.255.255.255 -out -require
it's giving Sendto : not permitted error in runtime. so, i deleted this
line , i kept only inbound flow in HostA
After this:
i checked both hosts with ping and tcpdump
it's giving
icmp_request
icmp_reply
then i kept different keys(enc and auth key) and tested between both
hosts.
again its giving
icmp_request
icmp_reply
i checked with both Hosts by using netstat -rn
it's giving correct SA details in both sides.
but i checked with netstat -ss -p esp
it's giving only
esp:
not giving any details .
i donno how actually we have to findout whether manual keying is working or
not.
Note: here i kept ipf.filter=NO in /etc/rc.conf and i enabled forwarded
capacity also(sysctl -w inet.net.forwarded.enable=1)
expecting ur reply,
thanks,
jeeva
From owner-ipsec@lists.tislabs.com Fri Aug 10 07:10:31 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AEAVN21574;
Fri, 10 Aug 2001 07:10:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26486
Fri, 10 Aug 2001 09:14:42 -0400 (EDT)
Message-ID: <CCFF88268143CC4181A758DCC0ECDC13F7B926@posthaus.virtela.cc>
From: "Horn, Mike" <mhorn@virtela.net>
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
Date: Thu, 9 Aug 2001 21:38:01 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Francis,
There are "ISP/ops" types on this list. I do not know of anyone using AH
for securing source-routed packets being used for debugging. In fact I know
of very few people using AH for *anything*. I have forwarded the question
to the NANOG (North American Network Operators Group). I will summarize
replies and forward to the IPSEC mailing list. Also, I think that keeping
transport mode is important. One common VPN application for transport mode
is securing IP in IP tunnels (see draft-touch-ipsec-vpn-01.txt).
Mike Horn
> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr]
> Sent: Wednesday, August 08, 2001 6:48 AM
> To: Dan McDonald
> Cc: Sandy Harris; ipsec@lists.tislabs.com
> Subject: Re: Simplifying IKE
>
>
> In your previous mail you wrote:
>
> > 2a: eliminate ESP authentication
> > 3a: require AH on all packets. No choice, no null mode. An IPsec
> > connection authenticates all packets, period.
>
> Choice 3a was the original intent of the SIPP security
> architecture (which
> became the 182x series of IPsec RFCs)....
>
> The biggest motivator behind AH was to allow an
> authenticated source route.
> Now as Steve Bellovin has pointed out, unless you can
> configure a hop-by-hop
> key, the middle can send that packet anywhere it wants
> before it reaches the
> end.
>
> I wish there were some ISP/ops types on this list (maybe
> there are and I'm
> just being an airhead). I believe the source route header
> is primarily used
> to see what paths are broken in a network - using the
> process of elimination.
> Using AH (or ESP authentication) insures that the packet
> came from where it
> claims to have come from. THAT is why AH was developed, but ESP
> authentication can provide a source-routed packet with
> similar properties.
>
> => (about the last statement) how? ESP authentication doesn't
> cover headers.
>
> Regards
>
> Francis.Dupont@enst-bretagne.fr
>
> PS: I am not in favor to reduce IPsec to VPNs, the thing
> which will happen
> if we remove AH then transport mode...
>
From owner-ipsec@lists.tislabs.com Fri Aug 10 07:10:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AEAWN21585;
Fri, 10 Aug 2001 07:10:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26509
Fri, 10 Aug 2001 09:17:43 -0400 (EDT)
From: Ghislaine Labouret <Ghislaine.Labouret@hsc.fr>
To: ipsec@lists.tislabs.com
Subject: Re: DRAFT: ipsec charter update
Date: Fri, 10 Aug 2001 11:18:32 +0100
Organization: HSC (Herve Schauer Consultants)
References: <E15UpaV-00036d-00@think.thunk.org>
In-Reply-To: <E15UpaV-00036d-00@think.thunk.org>
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: <20010810101741.65ED510E8D@itesec.hsc.fr>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 09 Aug 2001 09:10:59 -0400, tytso@mit.edu wrote:
> The IPSEC working group will restrict itself to the following short-term
> work items to improve the existing key management protocol (IKE):
As JI pointed out yesterday during SAAG, there are two work areas: IPsec
transforms and key management. If we keep them in the same group, I
think the charter should clearly mention those two areas and not just
IKE. Especially since (1) the work items list includes transforms-level
items and (2) architecture and transforms evolutions have been subject
to discussions on the list recently (SA identification, death to AH...).
Also, if we want to head toward two groups, starting to list the work
items for each might prove useful.
Sincerely,
--
Ghislaine Labouret, Network security consultant
Hervé Schauer Consultants (HSC) - http://www.hsc.fr/
Phone (+33)-141-409-700 - Fax (+33)-141-409-709
From owner-ipsec@lists.tislabs.com Fri Aug 10 07:17:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AEH7N21900;
Fri, 10 Aug 2001 07:17:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26638
Fri, 10 Aug 2001 09:34:21 -0400 (EDT)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B8028A86@hhdata3.cdsemea.baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: ipsec@lists.tislabs.com
Cc: Derrell Piper <ddp@cips.nokia.com>
Subject: RE: Simplifying IKE
Date: Fri, 10 Aug 2001 14:37:42 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This assumes that the phase 1 does live longer than phase 2. Quite apart
from implementations killing off the phase 1 before the renogitation, it may
well be policy that the phase 1 SA has a similar life to the pase 2 SA.
Chris
> QM with PFS has never really been all that "quick". However,
> it seems a
> valuable attribute that the relatively long-lived Phase 1 IKE
> SA's allow
> for seamless Phase 2 rekeying (when done right). This would
> be much harder
> if there were just one single negotiation.
>
> Derrell
>
> --On Thursday, August 9, 2001 7:52 PM -0400 Bill Sommerfeld
> <sommerfeld@East.Sun.COM> wrote:
>
> >> Ari Huttunen writes:
> >> > Thus my preference would be to have a four packet
> phase 1 (base mode)
> >> > and a four packet quick mode.
> >>
> >> Gad. Doesn't anybody care about link up times???
> >
> > Smooshing phase 1 and phase 2 together begins to look very
> attractive
> > when quick mode isn't very (quick).
> >
> > - Bill
> >
> >
>
>
>
>
>
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
From owner-ipsec@lists.tislabs.com Fri Aug 10 08:33:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AFX9N06456;
Fri, 10 Aug 2001 08:33:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26828
Fri, 10 Aug 2001 10:30:43 -0400 (EDT)
Date: Fri, 10 Aug 2001 16:37:46 +0200 (MET DST)
From: Hakan Olsson <ho@crt.se>
To: JEEVA <jeevas@future.futsoft.com>
Cc: <ipsec@lists.tislabs.com>
Subject: Re: openBSD testing doubts
In-Reply-To: <000001c1216b$e6ab7c60$2a05080a@future.futsoft.com>
Message-ID: <Pine.GSO.4.33.0108101633240.12719-100000@spitfire.crt.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
First, this is not the place for questions such as this. Try the
misc@openbsd.org list.
Second, start by reading vpn(8), then look at /usr/share/ipsec/rc.vpn.
You should find what you're looking for there.
/H
--
Håkan Olsson <ho@crt.se> (+46) 708 437 337 Carlstedt Research
Unix, Networking, Security (+46) 31 701 4264 & Technology AB
From owner-ipsec@lists.tislabs.com Fri Aug 10 08:49:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AFnlN11629;
Fri, 10 Aug 2001 08:49:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26966
Fri, 10 Aug 2001 11:06:50 -0400 (EDT)
Message-ID: <9A4F653B0A375841AC75A8D17712B9C9011964CC@sottmxs04.entrust.com>
From: Andrew Codrington <Andrew.Codrington@entrust.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Entrust CA services for Espoo IPSec interop event
Date: Fri, 10 Aug 2001 11:13:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C121AE.FB87C650"
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_01C121AE.FB87C650
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
For the purposes of the August 2001 Espoo, FI IPSec interoperability =
testing
event, Entrust has set up 3 Certification Authorities.=20
Configuration and enrollment instructions are provided here:
<http://204.101.128.45> http://204.101.128.45
=20
Two are cross-certified, using RSA keys, and the third is using DSA =
keys.
PKCS#10 and SCEP enrollment requests are granted automatically.=20
Please contact <mailto:IPSecBakeoff2001@entrust.com>
IPSecBakeoff2001@entrust.com for PKIX-CMP enrollment reference numbers =
and
authentication codes if you are testing a PKIX-CMP implementation or =
using
Entrust Toolkits.=20
=20
Best regards,
Andrew
--
Andrew Codrington
Product Manager, VPN Solutions
andrew.codrington@entrust.com
Phone: (613) 270-3422
Fax: (613) 270-2505
Cell: (613) 262-5264
=20
Entrust=AE
Securing the Internet
=20
------_=_NextPart_001_01C121AE.FB87C650
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1218D.7373D180">
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:DoNotRelyOnCSS/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:DocumentKind>DocumentEmail</w:DocumentKind>
<w:EnvelopeVis/>
=
<w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEv=
ery>
=
<w:DisplayVerticalDrawingGridEvery>0</w:DisplayVerticalDrawingGridEvery>=
<w:UseMarginsForDrawingGridOrigin/>
<w:Compatibility>
<w:FootnoteLayoutLikeWW8/>
<w:ShapeLayoutLikeWW8/>
<w:AlignTablesRowByRow/>
<w:ForgetLastTabAlignment/>
<w:DoNotUseHTMLParagraphAutoSpacing/>
<w:LayoutRawTableWidth/>
<w:LayoutTableRowsApart/>
</w:Compatibility>
</w:WordDocument>
</xml><![endif]-->
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0cm;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";
mso-ansi-language:EN-US;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;
text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
{margin:0cm;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";
mso-ansi-language:EN-US;}
span.EmailStyle15
{mso-style-type:personal-compose;
mso-ansi-font-size:10.0pt;
mso-ascii-font-family:Arial;
mso-hansi-font-family:Arial;
mso-bidi-font-family:Arial;
color:black;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;
mso-header-margin:36.0pt;
mso-footer-margin:36.0pt;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=3DEN-CA link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>
<div class=3DSection1>
<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 color=3Dteal face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Arial;color:teal'>For the purposes of the August 2001 =
Espoo, FI
IPSec interoperability testing event, Entrust has set up 3 =
Certification
Authorities. </span></font><font size=3D3 color=3Dteal><span =
style=3D'font-size:12.0pt;
color:teal;mso-ansi-language:EN-CA'><o:p></o:p></span></font></p>
<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 color=3Dteal face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Arial;color:teal'>Configuration and enrollment instructions =
are
provided here:</span></font><font color=3Dteal><span lang=3DEN-US =
style=3D'color:
teal'><o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'><a
href=3D"http://204.101.128.45"><font face=3D"Times New Roman"><span
style=3D'font-family:"Times New =
Roman"'>http://204.101.128.45</span></font></a><o:p></o:p></span></font>=
</p>
<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'><![if =
!supportEmptyParas]> <![endif]><o:p></o:p></span></font></p>
<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 color=3Dteal face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Arial;color:teal'>Two are cross-certified, using RSA keys, =
and the
third is using DSA keys.</span></font><font size=3D3 =
color=3Dblack><span
style=3D'font-size:12.0pt;color:black;mso-color-alt:windowtext;mso-ansi-=
language:
EN-CA'><o:p></o:p></span></font></p>
<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 color=3Dteal face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Arial;color:teal'>PKCS#10 and SCEP enrollment requests are =
granted
automatically. </span></font><font color=3Dblack><span lang=3DEN-US
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 color=3Dteal face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Arial;color:teal'>Please contact </span></font><font =
color=3Dblack><span
lang=3DEN-US style=3D'mso-bidi-font-family:Arial;color:black'><a
href=3D"mailto:IPSecBakeoff2001@entrust.com"><font color=3Dteal><span
style=3D'color:teal;text-decoration:none;text-underline:none'>IPSecBakeo=
ff2001@entrust.com</span></font></a>
</span></font><font color=3Dteal face=3DArial><span lang=3DEN-US =
style=3D'font-family:
Arial;color:teal'>for PKIX-CMP enrollment reference numbers and =
authentication
codes if you are testing a PKIX-CMP implementation or using Entrust =
Toolkits.</span></font><font
color=3Dblue face=3DArial><span lang=3DEN-US =
style=3D'font-family:Arial;color:blue'> </span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial'><![if =
!supportEmptyParas]> <![endif]><o:p></o:p></span></font></span></p>=
<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial'>Best
regards,<o:p></o:p></span></font></span></p>
<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial'>Andrew<o:p></o:p></span></f=
ont></span></p>
<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Arial'>--<o:p></o:p></span></font>=
</span></p>
<p class=3DMsoAutoSig><!--[if supportFields]><font color=3Dblack><span =
lang=3DEN-US=20
style=3D'color:black'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes"> </span>AUTOTEXTLIST \s "E-mail=20
Signature" <span =
style=3D'mso-element:field-separator'></span></span></font><![endif]--><=
font
color=3Dblack><span lang=3DEN-US style=3D'color:black'>Andrew =
Codrington</span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoAutoSig><font size=3D2 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:10.0pt;color:black'>Product Manager, =
VPN Solutions</span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoAutoSig><font size=3D2 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US =
style=3D'font-size:10.0pt;color:black'>andrew.codrington@entrust.com</sp=
an></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoAutoSig><font size=3D2 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:10.0pt;color:black'>Phone: (613) =
270-3422</span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoAutoSig><font size=3D2 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:10.0pt;color:black'>Fax: (613) =
270-2505</span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoAutoSig><font size=3D2 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:10.0pt;color:black'>Cell: (613) =
262-5264</span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoAutoSig><font size=3D2 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:10.0pt;color:black'><![if =
!supportEmptyParas]> <![endif]></span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoAutoSig><font size=3D2 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US =
style=3D'font-size:10.0pt;color:black'>Entrust=AE</span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoAutoSig><font size=3D2 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:10.0pt;color:black'>Securing the =
Internet</span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
<p class=3DMsoNormal><!--[if supportFields]><font color=3Dblack><span =
lang=3DEN-US=20
style=3D'color:black'><span =
style=3D'mso-element:field-end'></span></span></font><![endif]--><font
color=3Dblack><span lang=3DEN-US style=3D'color:black'><![if =
!supportEmptyParas]> <![endif]></span></font><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>
</div>
</body>
</html>
------_=_NextPart_001_01C121AE.FB87C650--
From owner-ipsec@lists.tislabs.com Fri Aug 10 09:42:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AGgoN18132;
Fri, 10 Aug 2001 09:42:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27067
Fri, 10 Aug 2001 11:52:05 -0400 (EDT)
From: mcnelson@mindspring.com
Date: Fri, 10 Aug 2001 11:59:13 -0400
To: tytso@mit.edu
Cc: ipsec@lists.tislabs.com
Subject: Re: DRAFT: ipsec charter update
Message-ID: <Springmail.105.997459153.0.05861900@www.springmail.com>
X-Originating-IP: 208.37.68.36
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Barbara and Theodore,
How is "client protocol of IP" defined?
Usually one thinks of the legitimate, sensible and/or meaningful clients of a security service as being the n+1 layer entities (see x.800).
I feel that it is very likely that herein lies the root cause of the problem and that if so, no amount of ad-hoc improvement within the current paradigm is going to make it go away.
If we want simplicity and effectiveness we should focus our attention narrowly on the simple paradigm of n layer mechanisms that implement services for n+1 layer entities.
The charter as stated seems to only further the basic underlying difficulties. The now legacy approach has led to a nearly decade long effort and the apparent need of a 12 inch high stack of paper to describe how to encrypt an IP datagram.
Let's try something new.
Regards,
Mitch Nelson
Dr. Mitchell C. Nelson
Director, Software Services
Datatek Applications, Inc.
tytso@mit.edu wrote:
> The IPSEC wg chairs met with Marcus Leech today, and after discussions
and consultation with him, we have developed the following draft update
to the IPSEC working group charter.
Contained in this proposed update is a timeline for the IKE V2 work
which was discussed at the IPSEC meeting earlier week in London. We
welcome comments and suggestions on improving the revised working group
charter. We would like to submit this charter to the IESG for
consideration by the end of August, so we would appreciate receiving
comments within the next two weeks.
Barbara Fraser
Theodore Ts'o
IPSEC wg chairs
IP Security Protocol (ipsec)
Last Modified: 09-Aug-01
Chair(s):
Barbara Fraser
Theodore Ts'o
Security Area Director(s):
Jeffrey Schiller
Marcus Leech
Security Area Advisor:
Jeffrey Schiller
Mailing Lists:
General Discussion:ipsec@lists.tislabs.com
to Subscribe: ipsec-request@lists.tislabs.com
Archive: ftp://ftp.tis.com/pub/lists/ipsec OR
ftp.ans.net/pub/archive/ipsec
Description of Working Group:
=============================
Rapid advances in communication technology have accentuated the need for
security in the Internet. The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP. A
security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality.
The IPSEC working group will restrict itself to the following short-term
work items to improve the existing key management protocol (IKE):
1) Changes to IKE to support NAT/Firewall traversal
2) Changes to IKE to support SCTP
3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
a fast AES mode suitable for use in hardware encryptors
4) IKE MIB documents
5) Sequence number extensions to ESP to support an expanded sequence
number space.
6) Clarification and standardization of rekeying procedures in IKE.
The working group will also update IKE to reflect implementation
experience, new requirements, and protocol analysis of the existing
protocol. The requirements for IKE V2 will be revised and updated as
the first step in this process.
Goals and Milestones:
=====================
Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and
requirements for IPsec and IKE for use with SCTP, to working
group last call.
Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE
MIBs, and SCTP support for considerations as Draft Standards.
Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE
re-keying completed.
Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE
re-keying to working group last call.
Dec 01 Internet-Draft on IKE v2 Requirements to working group last call
Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted
to the working group.
Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number
expansion, and IKE rekeying for consideration as Draft Standards.
Apr 02 Discuss and select the IKE v2 design from candidate approaches.
Sep 02 IKE v2 Internet-Drafts to working group last call
Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as
Proposed Standards.
From owner-ipsec@lists.tislabs.com Fri Aug 10 10:29:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AHT6N19307;
Fri, 10 Aug 2001 10:29:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27134
Fri, 10 Aug 2001 12:41:10 -0400 (EDT)
Date: Fri, 10 Aug 2001 12:25:49 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Michael Thomas <mat@cisco.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <15219.45309.512663.854766@thomasm-u1.cisco.com>
Message-ID: <Pine.BSI.3.91.1010810122311.19309E-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, 10 Aug 2001, Michael Thomas wrote:
> > No; belief and reality *are* different. The way you tell the difference
> > is to design and build a decent-but-not-all-things-to-all-people solution,
> > and listen to see if the outraged screams and angry grumbling slowly die
> > away.
>
> Ah, the beloved OS vendor to the masses stance.
No, actually, the Unix/TCP-IP/C stance. Build a decent general-purpose
solution, and most of the people who were complaining about needing custom
solutions will discover that general-purpose solutions really are good
enough for them after all.
Of course, if instead you build a crappy general-purpose solution, this
will just reinforce their belief that they need custom solutions.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Fri Aug 10 11:23:24 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AINNN20508;
Fri, 10 Aug 2001 11:23:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27255
Fri, 10 Aug 2001 13:32:33 -0400 (EDT)
Message-Id: <4.3.2.7.1.20010810102631.00c99af0@golf.cpgdesign.analog.com>
X-Sender: ramana@golf.cpgdesign.analog.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 10 Aug 2001 10:35:41 -0700
To: "jyothi" <vjyothi@intotoinc.com>, <ipsec@lists.tislabs.com>
From: Ramana Yarlagadda <ramana@chiplogic.com>
Subject: Re: Position of certificate payload in IKE Aggressive Mode as
Initiator
Cc: kalyan_bade@yahoo.com
In-Reply-To: <008e01c120c8$3ce25b20$700110ac@roc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Jyothi
At 05:11 PM 8/9/01 +0530, jyothi wrote:
>Hi,
> Kindly clarify the following doubt.
>
> Scenario : IKE Phase 1 Negotiation (Aggressive Mode) authenticated
>with signatures
> As an Initiator, can the certificate payload be sent in first message
>or is it mandatory to be sent in third message only. In the subsection
>Certificate Payload of section ISAKMP Payloads contained in RFC 2408, the
>following statement is present. "The Certificate Payload MUST be accepted at
>any point during an exchange". I understand from this statement that the
>responder has to accept Certificate payload either in first message or third
>message, which in turn provides the base for the assunption that initiator
>can send the certificate payload in first msg or third msg.
I think NO, looking at the section 5.1.
-cheers
-ramana
From owner-ipsec@lists.tislabs.com Fri Aug 10 13:44:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AKikN23500;
Fri, 10 Aug 2001 13:44:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27437
Fri, 10 Aug 2001 15:33:52 -0400 (EDT)
Message-ID: <3B7439E1.5040404@kolumbus.fi>
Date: Fri, 10 Aug 2001 22:45:37 +0300
From: Jari Arkko <jari.arkko@kolumbus.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Henry Spencer <henry@spsystems.net>
Cc: Jan Vilhuber <vilhuber@cisco.com>, ipsec@lists.tislabs.com
Subject: Scope for the new keying protocol [Was: Simplifying IKE]
References: <Pine.BSI.3.91.1010809213609.8177B-100000@spsystems.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Henry Spencer wrote:
>
> That may be true, but it is not a self-evident fact. And often it
> suffices for a protocol to be "one size fits almost all".
Indeed true.
I'm just afraid that we end up with a definition of "almost all"
that includes DSL geeks but excludes a billion mobile users...
Jari
From owner-ipsec@lists.tislabs.com Fri Aug 10 13:44:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AKimN23515;
Fri, 10 Aug 2001 13:44:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27456
Fri, 10 Aug 2001 15:52:00 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010810125636.042051a8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 10 Aug 2001 12:57:47 -0700
To: ipsec@lists.tislabs.com
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: DRAFT: ipsec charter update
In-Reply-To: <Springmail.105.997459153.0.05861900@www.springmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>Barbara and Theodore,
>
>How is "client protocol of IP" defined?
Maybe this is a nit, but why "client protocol" and not "host protocol?"
Mark
>Usually one thinks of the legitimate, sensible and/or meaningful clients
>of a security service as being the n+1 layer entities (see x.800).
>
>I feel that it is very likely that herein lies the root cause of the
>problem and that if so, no amount of ad-hoc improvement within the current
>paradigm is going to make it go away.
>
>If we want simplicity and effectiveness we should focus our attention
>narrowly on the simple paradigm of n layer mechanisms that implement
>services for n+1 layer entities.
>
>The charter as stated seems to only further the basic underlying
>difficulties. The now legacy approach has led to a nearly decade long
>effort and the apparent need of a 12 inch high stack of paper to describe
>how to encrypt an IP datagram.
>
>Let's try something new.
>
>Regards,
>Mitch Nelson
>
>
>Dr. Mitchell C. Nelson
>Director, Software Services
>Datatek Applications, Inc.
>
>
>
>
>
>tytso@mit.edu wrote:
> > The IPSEC wg chairs met with Marcus Leech today, and after discussions
>and consultation with him, we have developed the following draft update
>to the IPSEC working group charter.
>
>Contained in this proposed update is a timeline for the IKE V2 work
>which was discussed at the IPSEC meeting earlier week in London. We
>welcome comments and suggestions on improving the revised working group
>charter. We would like to submit this charter to the IESG for
>consideration by the end of August, so we would appreciate receiving
>comments within the next two weeks.
>
> Barbara Fraser
> Theodore Ts'o
> IPSEC wg chairs
>
>
>IP Security Protocol (ipsec)
>
>Last Modified: 09-Aug-01
>
>Chair(s):
> Barbara Fraser
> Theodore Ts'o
>
>Security Area Director(s):
> Jeffrey Schiller
> Marcus Leech
>
>Security Area Advisor:
> Jeffrey Schiller
>
>Mailing Lists:
> General Discussion:ipsec@lists.tislabs.com
> to Subscribe: ipsec-request@lists.tislabs.com
> Archive: ftp://ftp.tis.com/pub/lists/ipsec OR
> ftp.ans.net/pub/archive/ipsec
>
>Description of Working Group:
>=============================
>
>Rapid advances in communication technology have accentuated the need for
>security in the Internet. The IP Security Protocol Working Group
>(IPSEC) will develop mechanisms to protect client protocols of IP. A
>security protocol in the network layer will be developed to provide
>cryptographic security services that will flexibly support combinations
>of authentication, integrity, access control, and confidentiality.
>
>The IPSEC working group will restrict itself to the following short-term
>work items to improve the existing key management protocol (IKE):
>
>1) Changes to IKE to support NAT/Firewall traversal
>
>2) Changes to IKE to support SCTP
>
>3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
> a fast AES mode suitable for use in hardware encryptors
>
>4) IKE MIB documents
>
>5) Sequence number extensions to ESP to support an expanded sequence
> number space.
>
>6) Clarification and standardization of rekeying procedures in IKE.
>
>The working group will also update IKE to reflect implementation
>experience, new requirements, and protocol analysis of the existing
>protocol. The requirements for IKE V2 will be revised and updated as
>the first step in this process.
>
>Goals and Milestones:
>=====================
>
>Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and
> requirements for IPsec and IKE for use with SCTP, to working
> group last call.
>
>Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE
> MIBs, and SCTP support for considerations as Draft Standards.
>
>Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE
> re-keying completed.
>
>Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE
> re-keying to working group last call.
>
>Dec 01 Internet-Draft on IKE v2 Requirements to working group last call
>
>Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted
> to the working group.
>
>Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number
> expansion, and IKE rekeying for consideration as Draft Standards.
>
>Apr 02 Discuss and select the IKE v2 design from candidate approaches.
>
>Sep 02 IKE v2 Internet-Drafts to working group last call
>
>Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as
> Proposed Standards.
From owner-ipsec@lists.tislabs.com Sat Aug 11 13:50:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BKohN29702;
Sat, 11 Aug 2001 13:50:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29300
Sat, 11 Aug 2001 15:29:56 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15221.35105.650068.940786@thomasm-u1.cisco.com>
Date: Sat, 11 Aug 2001 12:36:01 -0700 (PDT)
To: Chris Trobridge <CTrobridge@baltimore.com>
Cc: Arne Ansper <arne@ats.cyber.ee>, ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
In-Reply-To: <F86F34FDF1F9D411B7A40008C74C27B8028A30@hhdata3.cdsemea.baltimore.com>
References: <F86F34FDF1F9D411B7A40008C74C27B8028A30@hhdata3.cdsemea.baltimore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
RFC 2207 allows you to select RSVP flows based on the SPI.
Mike
Chris Trobridge writes:
> There is always TOS. Packet length, even?
>
> How can you use the SPI to sort traffic? This assumes the access router
> knows which SPI corresponds to which traffic.
>
> Actually classifying traffic after applying ESP is a major hasssle for ISPs.
> OTOH, they don't often understand the security consequences of leaking the
> sort of info classification uses - which is often into the application
> layer!
>
> Chris
>
> > > I'd also like to see all IPSEC traffic between two hosts
> > carried by just one
> > > SA. I can't see any value in using multiple SAs between to
> > hosts. IPSEC
> >
> > there is. and it's not related to security at all.
> >
> > suppose you have slow internet connection that is used only for VPN
> > traffic. your access router has no way to distinguish between
> > different
> > sessions inside your VPN so it will put all the packets into
> > same queue.
> > if somebody is moving large file using ftp your telnet
> > connection will be
> > very very slow.
> >
> > without encryption the routers will put packets from separate sessions
> > (defined by src&dst IP, protocol and ports) into seprate queues (cisco
> > calls them classes IIRC) and even if you are downloading some
> > huge file
> > your telnet session is still usable.
> >
> > with encryption the SPI is the only parameter that can be
> > used to classify
> > the packets. if you are using a single SA between two hosts it's
> > impossible for routers to distinguish between packets from different
> > sessions and the interactive applications suffer really bad.
> >
> > arne
>
>
> -----------------------------------------------------------------------------------------------------------------
> The information contained in this message is confidential and is intended
> for the addressee(s) only. If you have received this message in error or
> there are any problems please notify the originator immediately. The
> unauthorized use, disclosure, copying or alteration of this message is
> strictly forbidden. Baltimore Technologies plc will not be liable for direct,
> special, indirect or consequential damages arising from alteration of the
> contents of this message by a third party or as a result of any virus being
> passed on.
>
> In addition, certain Marketing collateral may be added from time to time to
> promote Baltimore Technologies products, services, Global e-Security or
> appearance at trade shows and conferences.
>
> This footnote confirms that this email message has been swept by
> Baltimore MIMEsweeper for Content Security threats, including
> computer viruses.
>
From owner-ipsec@lists.tislabs.com Sat Aug 11 13:50:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BKouN29717;
Sat, 11 Aug 2001 13:50:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29358
Sat, 11 Aug 2001 16:08:06 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15221.37384.191416.901953@thomasm-u1.cisco.com>
Date: Sat, 11 Aug 2001 13:14:00 -0700 (PDT)
To: Henry Spencer <henry@spsystems.net>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: Wes Hardaker: opportunistic encryption deployment problems
In-Reply-To: <Pine.BSI.3.91.1010807161306.25170E-100000@spsystems.net>
References: <15216.5899.191140.121446@thomasm-u1.cisco.com>
<Pine.BSI.3.91.1010807161306.25170E-100000@spsystems.net>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Henry Spencer writes:
> On Tue, 7 Aug 2001, Michael Thomas wrote:
> > I guess I have to ask a really dumb question. Given the
> > likelihood of DNSSEC any time soon, why don't we just
> > ignore any pretense of authentication with opportunistic
> > encryption and just accept the MITM attack inherent with
> > ephemeral DH exchanges?
>
> We thought about that, but decided that some authentication was better
> than none, especially since it would upgrade transparently to full
> authentication. It's one thing to accept security loopholes as a
> temporary measure, and another to define a protocol that will always have
> security loopholes.
Well... How is this especially different than just
using self-signed certificates and having a wide
open policy? I don't think there's anything protocolwise
that even needs to be done there. Clearly you can upgrade
that by using rooted certs in the future as well.
I guess what bothers me is that you are expecting to
use DNS as a directory service for certs which it
wasn't really intended for thus making an already
complicated situation even more complicated, but
not changing the fundamental situation (PKI are hard).
>
> > Also: it seems to me that expecting
> > a secure DNS isn't actually opportunistic at all: it's
> > trying to assert a different source of (sometimes strong) identity...
>
> This basically boils down to what you think "opportunistic" means. We
> don't see it as meaning "will talk to anybody, no setup necessary" but
> rather "will talk to anybody who's set up for it". Some amount of setup
> is clearly necessary anyway; we'd have liked to be able to talk to an
> IPsec-capable host that's unaware of opportunistic encryption, but it
> isn't possible.
I guess that I view that there's probably an 80/20 rule
here which is being missed: *most* people aren't going
to go to the lengths of creating an active MITM attack
to snoop on boring old every day conversations.
Thus encrypting everything -- by accepting MITM attacks
where there is no pragmatic alternative -- will kill
off all of the passive snooping. Given the advent of
wireless and the worthlessness of certain L2's so-called
security, this is not an academic issue. Trying to insert
an upgrade path back to the mythical global PKI rather
misses the point: if there were such a beast, we could
should be able to use IKE as-is (or at least we ought
to be able to envision how to do that). Also: I
think the MIP experience sez that we ought to
consider whether we'd want such a PKI even if
it were possible.
Mike
From owner-ipsec@lists.tislabs.com Sat Aug 11 14:33:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BLXFN01522;
Sat, 11 Aug 2001 14:33:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29403
Sat, 11 Aug 2001 16:50:04 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15221.39915.19720.320652@thomasm-u1.cisco.com>
Date: Sat, 11 Aug 2001 13:56:11 -0700 (PDT)
To: Henry Spencer <henry@spsystems.net>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.BSI.3.91.1010810122311.19309E-100000@spsystems.net>
References: <15219.45309.512663.854766@thomasm-u1.cisco.com>
<Pine.BSI.3.91.1010810122311.19309E-100000@spsystems.net>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Henry Spencer writes:
> On Fri, 10 Aug 2001, Michael Thomas wrote:
> > > No; belief and reality *are* different. The way you tell the difference
> > > is to design and build a decent-but-not-all-things-to-all-people solution,
> > > and listen to see if the outraged screams and angry grumbling slowly die
> > > away.
> >
> > Ah, the beloved OS vendor to the masses stance.
>
> No, actually, the Unix/TCP-IP/C stance. Build a decent general-purpose
> solution, and most of the people who were complaining about needing custom
> solutions will discover that general-purpose solutions really are good
> enough for them after all.
>
> Of course, if instead you build a crappy general-purpose solution, this
> will just reinforce their belief that they need custom solutions.
The general unix philosophy is to build small building
blocks which can be bolted together too instead of
overarching "solutions" (what was the problem again?).
Not directly related here, but I think that what needs
to be kept in mind here is that assumptions about VPN-like
scenarios and their timing requirements are not necessarily
good ones. Ideally, we'd have a base level exchange which
is lightweight which can be used in conjunction with something
else if the base mechanism doesn't provide all the required
functionality. This way, the people who don't care about the
extended functionality don't get it shoved down their throats.
And I'd say an 8 message exchange just to talk
to your opportunistically encrypted name-the-application-service
is pretty obnoxiously overweight (talk about slow-start!).
Mike
From owner-ipsec@lists.tislabs.com Sat Aug 11 15:21:37 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BMLbN02301;
Sat, 11 Aug 2001 15:21:37 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29493
Sat, 11 Aug 2001 17:29:33 -0400 (EDT)
Date: Sat, 11 Aug 2001 17:33:53 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Michael Thomas <mat@cisco.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <15221.39915.19720.320652@thomasm-u1.cisco.com>
Message-ID: <Pine.BSI.3.91.1010811172240.11857A-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Sat, 11 Aug 2001, Michael Thomas wrote:
> > No, actually, the Unix/TCP-IP/C stance. Build a decent general-purpose
> > solution, and most of the people who were complaining about needing custom
> > solutions will discover that general-purpose solutions really are good
> > enough...
>
> The general unix philosophy is to build small building
> blocks which can be bolted together too instead of
> overarching "solutions" (what was the problem again?).
That's *part* of the general Unix philosophy, but not all of it.
Where problems looked diverse and flexibility seemed needed, then yes,
building blocks and tools for combining them were provided.
But when a single good compromise solution seemed possible, that solution
was implemented and no alternatives, variations, or options were provided.
For example, Unix offered exactly one filesystem user interface, and a
very simple one it was too. This radical simplification (by the standards
of the time) did wonders for the building-block philosophy at higher
levels, because there was little room for incompatible views about what a
file looked like.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Sat Aug 11 15:48:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BMm9N02635;
Sat, 11 Aug 2001 15:48:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29550
Sat, 11 Aug 2001 18:04:19 -0400 (EDT)
Message-ID: <3B75AD92.E10C9445@storm.ca>
Date: Sat, 11 Aug 2001 18:11:30 -0400
From: Sandy Harris <sandy@storm.ca>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Is base mode dead?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
With all the discussion of simplifying IKE, main mode vs. aggressive,
the commit bit, ... I thought it was time I had a look at 'base mode'.
I cannot find either an draft or an RFC. Is it dead?
From owner-ipsec@lists.tislabs.com Sat Aug 11 18:41:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7C1f9N05670;
Sat, 11 Aug 2001 18:41:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29754
Sat, 11 Aug 2001 20:39:55 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15221.53705.987014.155031@thomasm-u1.cisco.com>
Date: Sat, 11 Aug 2001 17:46:01 -0700 (PDT)
To: Henry Spencer <henry@spsystems.net>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <Pine.BSI.3.91.1010811172240.11857A-100000@spsystems.net>
References: <15221.39915.19720.320652@thomasm-u1.cisco.com>
<Pine.BSI.3.91.1010811172240.11857A-100000@spsystems.net>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
All of this is rather tangential to what is really
at hand, of course. I notice that you haven't
responded to the issue I brought up about the
suitability of IKE in situations where user
expectations haven't been set by near-infinite
modem training times.
Mike
Henry Spencer writes:
> On Sat, 11 Aug 2001, Michael Thomas wrote:
> > > No, actually, the Unix/TCP-IP/C stance. Build a decent general-purpose
> > > solution, and most of the people who were complaining about needing custom
> > > solutions will discover that general-purpose solutions really are good
> > > enough...
> >
> > The general unix philosophy is to build small building
> > blocks which can be bolted together too instead of
> > overarching "solutions" (what was the problem again?).
>
> That's *part* of the general Unix philosophy, but not all of it.
>
> Where problems looked diverse and flexibility seemed needed, then yes,
> building blocks and tools for combining them were provided.
>
> But when a single good compromise solution seemed possible, that solution
> was implemented and no alternatives, variations, or options were provided.
> For example, Unix offered exactly one filesystem user interface, and a
> very simple one it was too. This radical simplification (by the standards
> of the time) did wonders for the building-block philosophy at higher
> levels, because there was little room for incompatible views about what a
> file looked like.
>
> Henry Spencer
> henry@spsystems.net
>
From owner-ipsec@lists.tislabs.com Sun Aug 12 03:11:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CAB5N07723;
Sun, 12 Aug 2001 03:11:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00343
Sun, 12 Aug 2001 05:16:02 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Derrell Piper'" <ddp@cips.nokia.com>, <sommerfeld@East.Sun.COM>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Sun, 12 Aug 2001 10:04:52 +0100
Message-Id: <001801c1230f$3ca480e0$7a31788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <976979.997381032@el-air-2.electric-loft.org>
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is why I have never liked the PFS option. One of the main purposes of
quick mode is to thwart traffic analysis on ESP data without greatly slowing
down the protocol. That's why it's called "quick".
The normal thing to do is to use quick mode w/o PFS and the ultra-paranoid
thing to do is to do more frequent phase 1 rekeys. I can't think of a
realistic threat model that PFS solves. (Michael Richardson did once point
one out to me in which an 'ethical law-enforcement agency' forces you to
reveal your keys, but they are ethically prevented from using those keys to
impersonate you.)
Of all the security vulnerabilities I have seen in the design of security
protocols, a large percentage of them came about solely through the process
of optimization. If we truly want to have a simple and analyzable protocol,
we have to realize that simplicity does not come merely from reducing
options; it also comes from being conservative in our assumptions and from
clearly separating the protocol into independent stages.
A lot of people who complain about the complexity of IKE have also been
tacking on optimizations as part of their solutions. Whenever we try to
optimize the protocol, we have to accept that this is a design tradeoff and
security flaws may result.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell Piper
> Sent: Friday, August 10, 2001 2:17 AM
> To: sommerfeld@East.Sun.COM; Michael Thomas
> Cc: Ari Huttunen; Dan McDonald; Sandy Harris; ipsec@lists.tislabs.com
> Subject: Re: Simplifying IKE
>
>
> QM with PFS has never really been all that "quick". However,
> it seems a
> valuable attribute that the relatively long-lived Phase 1 IKE
> SA's allow
> for seamless Phase 2 rekeying (when done right). This would
> be much harder
> if there were just one single negotiation.
>
> Derrell
>
> --On Thursday, August 9, 2001 7:52 PM -0400 Bill Sommerfeld
> <sommerfeld@East.Sun.COM> wrote:
>
> >> Ari Huttunen writes:
> >> > Thus my preference would be to have a four packet
> phase 1 (base mode)
> >> > and a four packet quick mode.
> >>
> >> Gad. Doesn't anybody care about link up times???
> >
> > Smooshing phase 1 and phase 2 together begins to look very
> attractive
> > when quick mode isn't very (quick).
> >
> > - Bill
> >
> >
>
>
>
>
From owner-ipsec@lists.tislabs.com Sun Aug 12 03:11:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CABCN07737;
Sun, 12 Aug 2001 03:11:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00349
Sun, 12 Aug 2001 05:16:05 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'jyothi'" <vjyothi@intotoinc.com>, <ipsec@lists.tislabs.com>
Subject: RE: Position of certificate payload in IKE Aggressive Mode as Initiator
Date: Sun, 12 Aug 2001 10:10:43 +0100
Message-Id: <001a01c1230f$42458b20$7a31788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <008e01c120c8$3ce25b20$700110ac@roc.com>
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
One of the things I talked about in my improveike presentation was
simplifying parsing by restricting the messages in which certain payloads
can appear. I specifically mentioned certreq and vendorid, but I would
suggest that this be applied to the certificate payload as well.
Let me put it this way:
If you put the certificate in the 3rd message, EVERYONE will handle it.
If you put the certificate in the 1st message, many people WILL NOT handle
it, and even if they do, you are relying on mostly untested code.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of jyothi
> Sent: Thursday, August 09, 2001 12:42 PM
> To: ipsec@lists.tislabs.com
> Subject: Position of certificate payload in IKE Aggressive Mode as
> Initiator
>
>
> Hi,
> Kindly clarify the following doubt.
>
> Scenario : IKE Phase 1 Negotiation (Aggressive Mode)
> authenticated
> with signatures
> As an Initiator, can the certificate payload be sent in
> first message
> or is it mandatory to be sent in third message only. In the subsection
> Certificate Payload of section ISAKMP Payloads contained in
> RFC 2408, the
> following statement is present. "The Certificate Payload MUST
> be accepted at
> any point during an exchange". I understand from this
> statement that the
> responder has to accept Certificate payload either in first
> message or third
> message, which in turn provides the base for the assunption
> that initiator
> can send the certificate payload in first msg or third msg.
>
> thanks
> sankar
>
>
From owner-ipsec@lists.tislabs.com Sun Aug 12 03:13:25 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CADON08572;
Sun, 12 Aug 2001 03:13:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00346
Sun, 12 Aug 2001 05:16:03 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: <Steve.Robinson@psti.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Sun, 12 Aug 2001 10:09:40 +0100
Message-Id: <001901c1230f$3f8077b0$7a31788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <OF9C738F7C.6465F668-ON80256AA3.004CAA27@psti.com>
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> While I certainly agree that the attack described in the
> Ferguson/Schneier
> paper on ESP was esoteric, I disagree on your conclusion that
> no damage will be done. Let's assume that no attack is
> occurring. What if
> the system administrator enters the section of the key used
> for decryption
> incorrectly?
IPsec is typically used with negotiated keying. Manual keying is most useful
as a hook to allow arbitrary key exchange mechanisms. If you decide to hand
enter the keys, you had better be extra careful that the information you
type is correct.
> Authentication will work correctly, but right
> now, there is
> no verification mechanism in place to assure that the plaintext is not
> garbage, and once you pass garbage up to the upper layers,
> the behaviour is
> system specific and unknown -- it could range from catastrophic to no
> damage at all.
This attack does not allow the bad guy to modify only part of a message or
to control the content of the corrupted message in any way. And in the
situation you bring up, there is no bad guy. Upper layer protocols like TCP
and UDP have checksums. Plus, the chance of creating a correctly formatted
tunnelled IP packet is infinitesimal.
> Authenticating the text after decryption
> assures that the
> correct plaintext is passed to the upper layers.
So does including the key, but without causing the DoS vulnerability. So, to
be a bit lawyerly, redesigning ESP is not necessary, and even if it was, you
wouldn't need to reverse the order of the transforms.
> If the
> current order is
> only maintained to ward off DoS, then I'd suggest that the
> argument is
> weak, since DoS can only be minimized, not eliminated.
That's one of the problems with DoS... there always seems to be a new
vulnerability to be found. However, let's imagine that, some time in the
future, encryption is so widely deployed that a host can have a security
policy which rejects all packets except ESP and IKE (and maybe some ICMP).
Now we have a realistic chance of eliminating DoS simply by making it
infeasible with those two protocols.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: Steve.Robinson@psti.com [mailto:Steve.Robinson@psti.com]
> Sent: Thursday, August 09, 2001 3:10 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: 'Dan McDonald'; ipsec@lists.tislabs.com;
> owner-ipsec@lists.tislabs.com; 'Sandy Harris'
> Subject: RE: Simplifying IKE
>
>
>
> Andrew,
>
> While I certainly agree that the attack described in the
> Ferguson/Schneier
> paper on ESP was esoteric, I disagree on your conclusion that
> no damage will be done. Let's assume that no attack is
> occurring. What if
> the system administrator enters the section of the key used
> for decryption
> incorrectly? Authentication will work correctly, but right
> now, there is
> no verification mechanism in place to assure that the plaintext is not
> garbage, and once you pass garbage up to the upper layers,
> the behaviour is
> system specific and unknown -- it could range from catastrophic to no
> damage at all. Authenticating the text after decryption
> assures that the
> correct plaintext is passed to the upper layers. If the
> current order is
> only maintained to ward off DoS, then I'd suggest that the
> argument is
> weak, since DoS can only be minimized, not eliminated.
>
> Steve
>
>
>
>
>
>
> "Andrew Krywaniuk"
>
> <andrew.krywaniuk@al To: "'Dan
> McDonald'" <danmcd@East.Sun.COM>, "'Sandy Harris'"
> catel.com>
> <sandy@storm.ca>
>
> Sent by: cc:
> <ipsec@lists.tislabs.com>
> owner-ipsec@lists.ti Subject:
> RE: Simplifying IKE
> slabs.com
>
>
>
>
>
> 08/09/01 07:45 AM
>
> Please respond to
>
> andrew.krywaniuk
>
>
>
>
>
>
>
>
>
> > > > 4. modify ESP to ensure it authenticates all data used in
> > the deciphering
> > > of the payload
> > >
> > > This is the only recommendation in this paper based on a
> > direct security
> > > flaw, with a proposed attack to demonstrate it. There are
> > others in the
> > > Simpson paper.
> >
> > And if you use Choice 3a above, you get this for free - AH
> > covers the whole
> > ESP datagram, SPI/IV/etc.
>
>
> If my memory serves me correctly, Ferguson/Schneier were actually
> suggesting
> that
>
> 1. encryption be applied AFTER authentication
>
> or, failing that, that
>
> 2. the encryption/decryption key be included in the data
> which is hashed
>
> This is to prevent an esoteric attack they describe which is
> infeasible and
> wouldn't cause any damage anyway. That is not a compelling reason to
> redesign ESP.
>
> Andrew
> -------------------------------------------
> Upon closer inspection, I saw that the line
> dividing black from white was in fact a shade
> of grey. As I drew nearer still, the grey area
> grew larger. And then I was enlightened.
>
>
>
>
>
>
From owner-ipsec@lists.tislabs.com Sun Aug 12 03:14:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CAEKN08590;
Sun, 12 Aug 2001 03:14:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00353
Sun, 12 Aug 2001 05:16:08 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Geoffrey Huang'" <ghuang@cisco.com>, <andrew.krywaniuk@alcatel.com>,
<ipsec@lists.tislabs.com>
Subject: RE: (More) immediate changes to help interop problems?
Date: Sun, 12 Aug 2001 10:11:13 +0100
Message-Id: <001b01c1230f$443f5f50$7a31788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <HPEELIIJFCBDLBLJNPFIIELBCCAA.ghuang@cisco.com>
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I suspect most people are busy with the IETF and (soon) the bakeoff. Most of
the discussion on the list seems to be coming from non-IETF participants. I
know that I haven't been able to follow the conversation in real-time and I
suspect most other people haven't either.
Hopefully, the discussion will start up on the list next week when we get
back, and we can always discuss this stuff amongst ourselves at the bakeoff.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: Geoffrey Huang [mailto:ghuang@cisco.com]
> Sent: Thursday, August 09, 2001 11:46 AM
> To: andrew.krywaniuk@alcatel.com; ipsec@lists.tislabs.com
> Subject: RE: (More) immediate changes to help interop problems?
>
>
> > > So I've seen many messages concerning long-term development
> > > for the next
> > > IKE, but what happened to discussion on fixing some
> shortcomings that
> > > immediately affect interoperability? Andrew K. mentioned a
> > > few yesterday
> > > during his presentation, but off the top of my head, I can
> > > think of a few
> > > ambiguities:
> > >
> > > - Rekeying/Ph. 1 Responder Lifetime
> > > - Unreliable Delete/Notifies
> > > - Optional Cert Request Payload
> > > - Some way to detect dead peers/stale SAs
> > >
> > > I'm just thinking of issues in currently deployed scenarios...
> >
> > Didn't I mention all of the above in my presentation? (I
> know it wasn't in
> > great depth, but we didn't make great use of our alloted time.)
>
> You certainly did, as I mention above -- I'm just wondering why the
> discussion about this hasn't continued...
>
> -g
>
> > Andrew
> > -------------------------------------------
> > Upon closer inspection, I saw that the line
> > dividing black from white was in fact a shade
> > of grey. As I drew nearer still, the grey area
> > grew larger. And then I was enlightened.
> >
> >
>
>
From owner-ipsec@lists.tislabs.com Sun Aug 12 03:18:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CAIlN08786;
Sun, 12 Aug 2001 03:18:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00339
Sun, 12 Aug 2001 05:15:59 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Scott Fanning'" <sfanning@cisco.com>, <ipsec@lists.tislabs.com>
Subject: RE: (More) immediate changes to help interop problems?
Date: Sat, 11 Aug 2001 22:52:34 +0100
Message-Id: <001301c1230f$350e5d60$7a31788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <005701c12008$11168400$4e8d21d9@sfanninglaptop>
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> I agree. I also would like to see the commit bit gone (not many people
> support it anyway, nor do it right).
>
> I think the fact we still have bakeoffs to test IKE interop,
> tells us that
> we need to simplify what we have.
I think you are exaggerating. The fact that we still have bakeoffs shows
that we are still *ADDING* features to IKE. I expect to be testing NAT
traversal, ECDH, bigger DH groups, maybe revised hash if anyone else has
implemented it.
The concern over complexity is two things:
a) People who say that IKE must contain HIDDEN flaws or implementations must
have security holes.
b) People who say that IKE is too hard to write by new implementers.
I don't know of any 'old' implementation that still needs baking on basic
IKE features.
Are you saying yours does? :-)
> At one IETF, I was sure I heard a call and a straw vote for
> IKE reved to V2,
> with the new hash, and additional changes. I would like to
> fix those things we can fix now
> , allowing current users to continue to use
> IKE, while we
> debate a new, and improved key exchange,
You're free to improve your codebase with experimental
features/anti-features whenever you want. I've already fixed the hash
problem on our gateways. If you want to interoperate, you can use our vendor
id.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott Fanning
> Sent: Wednesday, August 08, 2001 1:46 PM
> To: Geoffrey Huang; ipsec@lists.tislabs.com
> Subject: Re: (More) immediate changes to help interop problems?
>
>
>
> My 2 cents
> Scott
> ----- Original Message -----
> From: "Geoffrey Huang" <ghuang@cisco.com>
> To: <ipsec@lists.tislabs.com>
> Sent: Wednesday, August 08, 2001 1:57 AM
> Subject: (More) immediate changes to help interop problems?
>
>
> > Hi there,
> >
> > So I've seen many messages concerning long-term development
> for the next
> > IKE, but what happened to discussion on fixing some
> shortcomings that
> > immediately affect interoperability? Andrew K. mentioned a
> few yesterday
> > during his presentation, but off the top of my head, I can
> think of a few
> > ambiguities:
> >
> > - Rekeying/Ph. 1 Responder Lifetime
> > - Unreliable Delete/Notifies
> > - Optional Cert Request Payload
> > - Some way to detect dead peers/stale SAs
> >
> > I'm just thinking of issues in currently deployed scenarios...
> >
> > -g
> >
>
>
From owner-ipsec@lists.tislabs.com Sun Aug 12 03:18:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CAIqN08816;
Sun, 12 Aug 2001 03:18:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00359
Sun, 12 Aug 2001 05:16:36 -0400 (EDT)
Message-ID: <001101c12318$2b674520$09a1003e@bilbo>
From: "Sara Bitan" <sarab@cs.Technion.AC.IL>
To: <ipsec@lists.tislabs.com>
References: <E15UpaV-00036d-00@think.thunk.org>
Subject: Re: DRAFT: ipsec charter update
Date: Sun, 12 Aug 2001 12:15:35 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1255"
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
Two issues:
1) The term "client protocols of IP" is not clear. IP is not a server, so
other protocols are not clients. I think the term "protocols that run above
IP" is more appropriate.
2) I think the following paragraph
> The working group will also update IKE to reflect implementation
> experience, new requirements, and protocol analysis of the existing
> protocol. The requirements for IKE V2 will be revised and updated as
> the first step in this process.
is too open ended, and bound to cause problems in the future. I think (see
another mail), that this work should be moved to a new WG, and that indeed
there should be several protocols answering several requirements drafts.
Sara.
----- Original Message -----
From: <tytso@mit.edu>
To: <ipsec@lists.tislabs.com>
Sent: Thursday, August 09, 2001 3:10 PM
Subject: DRAFT: ipsec charter update
>
> The IPSEC wg chairs met with Marcus Leech today, and after discussions
> and consultation with him, we have developed the following draft update
> to the IPSEC working group charter.
>
> Contained in this proposed update is a timeline for the IKE V2 work
> which was discussed at the IPSEC meeting earlier week in London. We
> welcome comments and suggestions on improving the revised working group
> charter. We would like to submit this charter to the IESG for
> consideration by the end of August, so we would appreciate receiving
> comments within the next two weeks.
>
> Barbara Fraser
> Theodore Ts'o
> IPSEC wg chairs
>
>
> IP Security Protocol (ipsec)
>
> Last Modified: 09-Aug-01
>
> Chair(s):
> Barbara Fraser <byfraser@cisco.com>
> Theodore Ts'o <tytso@mit.edu>
>
> Security Area Director(s):
> Jeffrey Schiller <jis@mit.edu>
> Marcus Leech <mleech@nortelnetworks.com>
>
> Security Area Advisor:
> Jeffrey Schiller <jis@mit.edu>
>
> Mailing Lists:
> General Discussion:ipsec@lists.tislabs.com
> to Subscribe: ipsec-request@lists.tislabs.com
> Archive: ftp://ftp.tis.com/pub/lists/ipsec OR
> ftp.ans.net/pub/archive/ipsec
>
> Description of Working Group:
> =============================
>
> Rapid advances in communication technology have accentuated the need for
> security in the Internet. The IP Security Protocol Working Group
> (IPSEC) will develop mechanisms to protect client protocols of IP. A
> security protocol in the network layer will be developed to provide
> cryptographic security services that will flexibly support combinations
> of authentication, integrity, access control, and confidentiality.
>
> The IPSEC working group will restrict itself to the following short-term
> work items to improve the existing key management protocol (IKE):
>
> 1) Changes to IKE to support NAT/Firewall traversal
>
> 2) Changes to IKE to support SCTP
>
> 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
> a fast AES mode suitable for use in hardware encryptors
>
> 4) IKE MIB documents
>
> 5) Sequence number extensions to ESP to support an expanded sequence
> number space.
>
> 6) Clarification and standardization of rekeying procedures in IKE.
>
> The working group will also update IKE to reflect implementation
> experience, new requirements, and protocol analysis of the existing
> protocol. The requirements for IKE V2 will be revised and updated as
> the first step in this process.
>
> Goals and Milestones:
> =====================
>
> Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and
> requirements for IPsec and IKE for use with SCTP, to working
> group last call.
>
> Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE
> MIBs, and SCTP support for considerations as Draft Standards.
>
> Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE
> re-keying completed.
>
> Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE
> re-keying to working group last call.
>
> Dec 01 Internet-Draft on IKE v2 Requirements to working group last call
>
> Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted
> to the working group.
>
> Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number
> expansion, and IKE rekeying for consideration as Draft Standards.
>
> Apr 02 Discuss and select the IKE v2 design from candidate approaches.
>
> Sep 02 IKE v2 Internet-Drafts to working group last call
>
> Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as
> Proposed Standards.
>
>
>
>
From owner-ipsec@lists.tislabs.com Sun Aug 12 09:36:43 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CGahN24273;
Sun, 12 Aug 2001 09:36:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00865
Sun, 12 Aug 2001 11:35:15 -0400 (EDT)
Message-ID: <002a01c12345$a6f64ec0$2100a8c0@server>
From: "Jerry Yao" <jerry.yao@163.net>
To: <ipsec@lists.tislabs.com>
Subject: Multicasting problem
Date: Sun, 12 Aug 2001 23:43:15 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_001F_01C12388.8E5034B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_001F_01C12388.8E5034B0
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: base64
SXMgYW55Ym9keSB3b3JraW5nIGF0IE11bHRpY2FzdGluZyBwcm9ibGVtLiBJIGNhbid0IGZpbmQg
YW55IFJGQyBvciBEcmFmdCBhYm91dCBpdD8NCg==
------=_NextPart_000_001F_01C12388.8E5034B0
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi
MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w
MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E
WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5JcyBhbnlib2R5IHdvcmtpbmcg
YXQgTXVsdGljYXN0aW5nIHByb2JsZW0uIEkgY2FuJ3QgZmluZCBhbnkgDQpSRkMgb3IgRHJhZnQg
YWJvdXQgaXQ/PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo=
------=_NextPart_000_001F_01C12388.8E5034B0--
From owner-ipsec@lists.tislabs.com Sun Aug 12 15:12:34 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CMCXN29970;
Sun, 12 Aug 2001 15:12:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01299
Sun, 12 Aug 2001 17:06:16 -0400 (EDT)
Message-Id: <200108122112.f7CLCAb00674@dharkins@lounge.orgatty.lounge.org>
To: andrew.krywaniuk@alcatel.com
Cc: "'Derrell Piper'" <ddp@cips.nokia.com>, sommerfeld@East.Sun.COM,
ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: Your message of "Sun, 12 Aug 2001 10:04:52 BST."
<001801c1230f$3ca480e0$7a31788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <671.997650729.1@lounge.org>
Date: Sun, 12 Aug 2001 14:12:10 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
No, the main purpose of quick mode was to be able to amortize the
cost of authentication over many SAs. Different SAs can be established
to protect different flows as specified by different selectors without
having to reauthenticate every time. And SAs for a particular flow can
expire and be reestablished, again, without having to reauthenticate.
You may not like PFS but it has been a continued requirement in this
working group. That is why the SKIP folks had to come up an optional
PFS extention. (It is worthwhile to look back at how that Simple protocol
became exceedingly complex-- components at IP, ICMP, and UDP, a PFS
extension, an algorithm discovery extension, a certificate discovery
extension-- in its attempt to satify the requirements from this working
group).
What is "normal" depends on perspective (as well as hardware
acceleration I guess). The Evil Kirk thought it was perfectly normal for
Spock to have a goatee.
Dan.
On Sun, 12 Aug 2001 10:04:52 BST you wrote
> This is why I have never liked the PFS option. One of the main purposes of
> quick mode is to thwart traffic analysis on ESP data without greatly slowing
> down the protocol. That's why it's called "quick".
>
> The normal thing to do is to use quick mode w/o PFS and the ultra-paranoid
> thing to do is to do more frequent phase 1 rekeys. I can't think of a
> realistic threat model that PFS solves. (Michael Richardson did once point
> one out to me in which an 'ethical law-enforcement agency' forces you to
> reveal your keys, but they are ethically prevented from using those keys to
> impersonate you.)
>
> Of all the security vulnerabilities I have seen in the design of security
> protocols, a large percentage of them came about solely through the process
> of optimization. If we truly want to have a simple and analyzable protocol,
> we have to realize that simplicity does not come merely from reducing
> options; it also comes from being conservative in our assumptions and from
> clearly separating the protocol into independent stages.
>
> A lot of people who complain about the complexity of IKE have also been
> tacking on optimizations as part of their solutions. Whenever we try to
> optimize the protocol, we have to accept that this is a design tradeoff and
> security flaws may result.
>
> Andrew
> -------------------------------------------
> Upon closer inspection, I saw that the line
> dividing black from white was in fact a shade
> of grey. As I drew nearer still, the grey area
> grew larger. And then I was enlightened.
>
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell Piper
> > Sent: Friday, August 10, 2001 2:17 AM
> > To: sommerfeld@East.Sun.COM; Michael Thomas
> > Cc: Ari Huttunen; Dan McDonald; Sandy Harris; ipsec@lists.tislabs.com
> > Subject: Re: Simplifying IKE
> >
> >
> > QM with PFS has never really been all that "quick". However,
> > it seems a
> > valuable attribute that the relatively long-lived Phase 1 IKE
> > SA's allow
> > for seamless Phase 2 rekeying (when done right). This would
> > be much harder
> > if there were just one single negotiation.
> >
> > Derrell
> >
> > --On Thursday, August 9, 2001 7:52 PM -0400 Bill Sommerfeld
> > <sommerfeld@East.Sun.COM> wrote:
> >
> > >> Ari Huttunen writes:
> > >> > Thus my preference would be to have a four packet
> > phase 1 (base mode)
> > >> > and a four packet quick mode.
> > >>
> > >> Gad. Doesn't anybody care about link up times???
> > >
> > > Smooshing phase 1 and phase 2 together begins to look very
> > attractive
> > > when quick mode isn't very (quick).
> > >
> > > - Bill
> > >
> > >
> >
> >
> >
> >
>
From owner-ipsec@lists.tislabs.com Sun Aug 12 15:12:34 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CMCYN29973;
Sun, 12 Aug 2001 15:12:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01265
Sun, 12 Aug 2001 17:03:26 -0400 (EDT)
Date: Fri, 10 Aug 2001 06:29:11 -0400
From: Theodore Tso <tytso@mit.edu>
To: Alex Alten <Alten@home.com>
Cc: tytso@mit.edu, ipsec@lists.tislabs.com
Subject: Re: DRAFT: ipsec charter update
Message-ID: <20010810062911.C9293@thunk.org>
References: <E15UpaV-00036d-00@think.thunk.org> <3.0.3.32.20010809223922.00dbaea0@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <3.0.3.32.20010809223922.00dbaea0@mail>; from Alten@Home.Com on Thu, Aug 09, 2001 at 10:39:22PM -0700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, Aug 09, 2001 at 10:39:22PM -0700, Alex Alten wrote:
> Barbara & Theodore,
>
> Is there a requirements doc for IKE V2?
>From the proposed charter (which you included in your e-mail message,
so I assume that meant you read it carefully before you responded :-)...
>The working group will also update IKE to reflect implementation
>experience, new requirements, and protocol analysis of the existing
>protocol. The requirements for IKE V2 will be revised and updated as
>the first step in this process.
>
>Dec 01 Internet-Draft on IKE v2 Requirements to working group last call
> Will there be a security analysis before Last Call by a reputable group of
> cryptographers, etc?
I would think this would be very likely, yes. I will note that there
is a group of reputable cryptographers who regularly do participate in
the ipsec wg, so hopefully this review process will be ongoing during
the whole IKE v2 process.
- Ted
From owner-ipsec@lists.tislabs.com Sun Aug 12 15:12:34 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CMCYN29972;
Sun, 12 Aug 2001 15:12:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01272
Sun, 12 Aug 2001 17:03:36 -0400 (EDT)
Date: Fri, 10 Aug 2001 06:24:53 -0400
From: Theodore Tso <tytso@mit.edu>
To: "Horn, Mike" <mhorn@virtela.net>
Cc: "'tytso@mit.edu'" <tytso@mit.edu>, ipsec@lists.tislabs.com
Subject: Re: DRAFT: ipsec charter update
Message-ID: <20010810062453.B9293@thunk.org>
References: <CCFF88268143CC4181A758DCC0ECDC13DE7781@posthaus.virtela.cc>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <CCFF88268143CC4181A758DCC0ECDC13DE7781@posthaus.virtela.cc>; from mhorn@virtela.net on Thu, Aug 09, 2001 at 10:31:16PM -0600
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, Aug 09, 2001 at 10:31:16PM -0600, Horn, Mike wrote:
> I think this is definitely a step in the right direction, but it seems in
> direct conflict with the position statement that was just sent out by Marcus
> Leech. Does this have approval from the IESG and IAB? Also, how does this
> fit in with the work going on to simplify IKE? Are things like removing AH,
> aggresive mode, etc. still open for discussion? Again, it's great to see
> the working group moving forward to provide standardized solutions for known
> problems.
There's a certain amount of misunderstanding about the the position
statement which Marcus, Jeff, and Steve put together. Marcus and
Steve (Jeff couldn't make it to London) clarified this at the IPSEC wg
meeting on Monday. First of all, IKE is *not* broken, and we're not
abandoning development on IKE (as Network World reported in screaming
front-page headlines).
Secondly, the note was only giving a rationale for the same moratorium
has been place for the last year. So things like the NAT/FW
traversal, SCTP, etc. were never under the moratorium in the first
place.
Barbara and I did consult with Marcus before we drafted the charter,
and the only one thing on the proposed charter which might be
considered new with respect to the moratorium was the rekeying issue,
and presumably this is the one thing which might be in danger of being
turned down by the IESG/IAB when they consider our proposed new
charter. The rekeying clarification was added because there was a
number of people who strongly asked for this at the IPSEC meeting.
It's not really *changing* IKE, as much as we are specifying a
behaviour where the current standards are completely silent.
Personally, I think the odds are 50-50 that the question of getting
IESG/IAB permission is moot, since we tried to standardize rekeying
about a year ago, and the problem was that roughly 50% of the deployed
implementations were doing it one way, and the other 50% were doing it
the other way, and no one seemed willing to change their
implementations. So I'm not sanguine about why we will be successful
now when we weren't successful a year ago, but if people want to give
it a try, I certainly would be very pleased to be proven wrong.
(And as I understand things the current non-standardization doesn't
mean that things are *completely* broken, just that interoperability
with respect to rekeying is just very, very hard.)
- Ted
From owner-ipsec@lists.tislabs.com Sun Aug 12 19:24:04 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7D2O3N04634;
Sun, 12 Aug 2001 19:24:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01767
Sun, 12 Aug 2001 21:27:02 -0400 (EDT)
From: Black_David@emc.com
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5A2@CORPMX14>
To: tytso@mit.edu, ipsec@lists.tislabs.com
Subject: RE: DRAFT: ipsec charter update
Date: Sun, 12 Aug 2001 21:28:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Sorry for the delayed response, but two comments on the following:
> The IPSEC working group will restrict itself to the following short-term
> work items to improve the existing key management protocol (IKE):
>
> 1) Changes to IKE to support NAT/Firewall traversal
>
> 2) Changes to IKE to support SCTP
>
> 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
> a fast AES mode suitable for use in hardware encryptors
- The third item is not about IKE, hence the WG won't be restricted to
IKE (as pointed out by JI and Ghislane).
- Please broaden 3) to allow other fast things that may emerge from
the upcoming NIST modes workshop (e.g., over in the IP Storage
WG, I have a cheering section for UMAC, or something similar).
I presume "fast AES mode ..." translates to "counter mode, or
something equally hardware-friendly", right?
Schedule looks good to me, this looks like any major issues with the
drafts in item 3) would be expected to be discussed in Salt Lake City
and closed there or shortly thereafter.
Thanks,
--David (IP Storage [ips] WG co-chair)
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA 01748
+1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500
black_david@emc.com Mobile: +1 (978) 394-7754
---------------------------------------------------
> -----Original Message-----
> From: tytso@mit.edu [mailto:tytso@mit.edu]
> Sent: Thursday, August 09, 2001 9:11 AM
> To: ipsec@lists.tislabs.com
> Subject: DRAFT: ipsec charter update
>
>
>
> The IPSEC wg chairs met with Marcus Leech today, and after discussions
> and consultation with him, we have developed the following
> draft update
> to the IPSEC working group charter.
>
> Contained in this proposed update is a timeline for the IKE V2 work
> which was discussed at the IPSEC meeting earlier week in London. We
> welcome comments and suggestions on improving the revised
> working group
> charter. We would like to submit this charter to the IESG for
> consideration by the end of August, so we would appreciate receiving
> comments within the next two weeks.
>
> Barbara Fraser
> Theodore Ts'o
> IPSEC wg chairs
>
>
> IP Security Protocol (ipsec)
>
> Last Modified: 09-Aug-01
>
> Chair(s):
> Barbara Fraser <byfraser@cisco.com>
> Theodore Ts'o <tytso@mit.edu>
>
> Security Area Director(s):
> Jeffrey Schiller <jis@mit.edu>
> Marcus Leech <mleech@nortelnetworks.com>
>
> Security Area Advisor:
> Jeffrey Schiller <jis@mit.edu>
>
> Mailing Lists:
> General Discussion:ipsec@lists.tislabs.com
> to Subscribe: ipsec-request@lists.tislabs.com
> Archive: ftp://ftp.tis.com/pub/lists/ipsec OR
> ftp.ans.net/pub/archive/ipsec
>
> Description of Working Group:
> =============================
>
> Rapid advances in communication technology have accentuated
> the need for
> security in the Internet. The IP Security Protocol Working Group
> (IPSEC) will develop mechanisms to protect client protocols of IP. A
> security protocol in the network layer will be developed to provide
> cryptographic security services that will flexibly support
> combinations
> of authentication, integrity, access control, and confidentiality.
>
> The IPSEC working group will restrict itself to the following
> short-term
> work items to improve the existing key management protocol (IKE):
>
> 1) Changes to IKE to support NAT/Firewall traversal
>
> 2) Changes to IKE to support SCTP
>
> 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
> a fast AES mode suitable for use in hardware encryptors
>
> 4) IKE MIB documents
>
> 5) Sequence number extensions to ESP to support an expanded sequence
> number space.
>
> 6) Clarification and standardization of rekeying procedures in IKE.
>
> The working group will also update IKE to reflect implementation
> experience, new requirements, and protocol analysis of the existing
> protocol. The requirements for IKE V2 will be revised and updated as
> the first step in this process.
>
> Goals and Milestones:
> =====================
>
> Aug 01 Internet Drafts on NAT and Firewall traversal,
> IKE MIBs, and
> requirements for IPsec and IKE for use with SCTP, to working
> group last call.
>
> Sep 01 Submit revised Internet-Drafts of NAT and
> Firewall traversal, IKE
> MIBs, and SCTP support for considerations as Draft Standards.
>
> Oct 01 Internet-Drafts on sequence number expansion in
> IKE, and IKE
> re-keying completed.
>
> Dec 01 Internet-Drafts on AES/SHA-2, sequence number
> expansion, and IKE
> re-keying to working group last call.
>
> Dec 01 Internet-Draft on IKE v2 Requirements to
> working group last call
>
> Dec 01 Internet-Drafts describing candidate IKE v2
> approaches submitted
> to the working group.
>
> Feb 01 Submit revised Internet-Drafts on AES/SHA-2,
> sequence number
> expansion, and IKE rekeying for consideration as Draft
> Standards.
>
> Apr 02 Discuss and select the IKE v2 design from
> candidate approaches.
>
> Sep 02 IKE v2 Internet-Drafts to working group last call
>
> Dec 02 Submit IKE v2 Internet-Drafts to the IESG for
> consideration as
> Proposed Standards.
>
>
>
>
From owner-ipsec@lists.tislabs.com Mon Aug 13 05:46:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DCkoN18662;
Mon, 13 Aug 2001 05:46:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02691
Mon, 13 Aug 2001 07:47:11 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Dan Harkins'" <dharkins@lounge.org>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Mon, 13 Aug 2001 12:44:50 +0100
Message-Id: <000701c123ed$7b19e340$b70be982@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <200108122112.f7CLCAb00674@dharkins@lounge.orgatty.lounge.org>
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> > This is why I have never liked the PFS option. One of the
> main purposes of
> > quick mode is to thwart traffic analysis on ESP data
> without greatly slowing
> > down the protocol. That's why it's called "quick".
> No, the main purpose of quick mode was to be able to amortize the
> cost of authentication over many SAs. Different SAs can be established
> to protect different flows as specified by different selectors without
> having to reauthenticate every time. And SAs for a particular flow can
> expire and be reestablished, again, without having to reauthenticate.
And what is the purpose of having different SAs to protect different flows?
(besides thwarting traffic analysis)
"Quick" mode is hardly quick if you have to repeat the Diffie-Hellman
exchange each time. Why can't quick mode be used to amortize the cost of
authentication *AND* forward secrecy over many SAs?
> You may not like PFS but it has been a continued requirement in this
> working group. That is why the SKIP folks had to come up an optional
> PFS extention.
Firstly, the problem with SKIP was that it didn't provide any kind of PFS at
all. If you cracked the RSA private key you could get all session keys
negotiated with that private key. I wasn't following this group that closely
back when SKIP was being proposed, but that's my understanding of the
problem. Am I wrong?
PFS is not optional in IKE because the DH group is not optional in phase 1.
All that is optional is whether you do a single level of PFS or two levels
of PFS. In fact, if you wanted to be ultra-paranoid we could add a 3rd level
of PFS where you refresh the keying material on every packet. How 'bout
that?
Designing the protocol so that cracking (or, more likely, stealing) a
long-term RSA key doesn't compromise all past traffic is a worthwhile
feature. Designing the protocol so that cracking a short-lived IKE phase 1
key doesn't reveal the (even more short-lived) phase 2 keys is a less useful
and more esoteric feature.
It is a shame that this bastard form of forward secrecy came to be known as
*the* PFS mode of IKE because it gives people the mistaken impression that
IKE w/o QM PFS doesn't have any PFS at all.
I suggest that you take some time (as I have done) to consider for each case
of {no PFS, PFS in phase 1, PFS in both phase 1 and phase 2} what is the
work factor for {the hosts to rekey phase 1, the hosts to rekey phase 2, the
attacker to brute force a key} and how much damage is done if {an RSA
private key, phase 1 DH key, phase 2 DH key, etc.} is cracked.
I have come to the conclusion, as have several others, that QM PFS is not
useful in the vast majority of situations as it doesn't make good use of the
engineering tradeoffs. When it is "required", the same threats can be
addressed by other means such as more frequent phase 1 rekeying or by
establishing the phase 1 with a bigger DH modulus.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
From owner-ipsec@lists.tislabs.com Mon Aug 13 06:04:31 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DD4UN19157;
Mon, 13 Aug 2001 06:04:30 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02789
Mon, 13 Aug 2001 08:29:13 -0400 (EDT)
Date: Mon, 13 Aug 2001 00:12:15 +0300 (EET DST)
From: Markus Stenberg <mstenber@ssh.com>
X-X-Sender: <mstenber@torni.hel.fi.ssh.com>
To: Sandy Harris <sandy@storm.ca>
cc: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: Is base mode dead?
In-Reply-To: <3B75AD92.E10C9445@storm.ca>
Message-ID: <Pine.OSF.4.33.0108130007070.16052-100000@torni.hel.fi.ssh.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Sat, 11 Aug 2001, Sandy Harris wrote:
> With all the discussion of simplifying IKE, main mode vs. aggressive,
> the commit bit, ... I thought it was time I had a look at 'base mode'.
>
> I cannot find either an draft or an RFC. Is it dead?
Draft's from about year ago (I think it expired last christmas or so).
It's basically dead, although I suppose it's a shame..
It combines limited DoS protection of MM with identity exposure
of aggressive mode (and just 4 messages).
I think that if we really go for only one exchange, aggressive mode is not
even an option; however, question is, do we want identity hiding or not? It
costs one roundtrip.
In my ideal world there'd be 2 message QM which could be glued on the base
mode so you could have SA's up in 4 messages and still retain IKE SA for
fast further SA's.
But, YMMV.
-Markus
From owner-ipsec@lists.tislabs.com Mon Aug 13 06:09:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DD9eN19266;
Mon, 13 Aug 2001 06:09:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02779
Mon, 13 Aug 2001 08:28:13 -0400 (EDT)
Date: Sun, 12 Aug 2001 11:44:35 -0700
From: Derrell Piper <ddp@cips.nokia.com>
To: ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
Message-ID: <66296.997616674@el-air-5.electric-loft.org>
In-Reply-To: <001801c1230f$3ca480e0$7a31788a@andrewk3.ca.newbridge.com>
References: <001801c1230f$3ca480e0$7a31788a@andrewk3.ca.newbridge.com>
X-Mailer: Mulberry/2.1.0b3 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Andrew,
Normal, of course, is in the eye of the beholder. Nokia has hardware
assist for its DH, so the QM PFS in most of our systems (our low end models
don't have the chip) is essentially free. Moving forward, I think all
vendors will be relying on hardware assist, so this situation only gets
better over time. That is, if you think there is no value to Phase 2 PFS,
which I don't happen to agree with you on. I would be more inclined to
make QM PFS mandatory, if that's viewed as simplifying. However, I think
that the optional nature of QM PFS is one of the better defined parts of
the IKE protocol and removing this wouldn't buy us much.
Derrell
--On Sunday, August 12, 2001 10:04 AM +0100 Andrew Krywaniuk
<andrew.krywaniuk@alcatel.com> wrote:
> The normal thing to do is to use quick mode w/o PFS and the ultra-paranoid
> thing to do is to do more frequent phase 1 rekeys. I can't think of a
> realistic threat model that PFS solves. (Michael Richardson did once point
> one out to me in which an 'ethical law-enforcement agency' forces you to
> reveal your keys, but they are ethically prevented from using those keys
> to impersonate you.)
From owner-ipsec@lists.tislabs.com Mon Aug 13 06:13:46 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DDDjN19512;
Mon, 13 Aug 2001 06:13:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02780
Mon, 13 Aug 2001 08:28:14 -0400 (EDT)
Message-Id: <sb743248.018@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Fri, 10 Aug 2001 19:13:05 -0600
From: "Hilarie Orman" <HORMAN@volera.com>
To: <ipsec@lists.tislabs.com>
Subject: Re: DRAFT: ipsec charter update
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 VAA28228
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Comments on the charter:
The opening sentence has been true for 30 years and will always
be true. All communication technology requires security.
IPsec protects the payloads of IP datagrams and enforces policy for
client protocols; the notion of "protecting" a protocol is imprecise.
Remove any trace of the misconception that confidentiality without
integrity is a possible combination of this flexible system.
Is "protocol analysis of the existing protocol" the same as "analysis
of the existing protocol"?
Include elliptic curve methods.
Hilarie
tytso@mit.edu wrote:
> The IPSEC wg chairs met with Marcus Leech today, and after discussions
and consultation with him, we have developed the following draft update
to the IPSEC working group charter.
Contained in this proposed update is a timeline for the IKE V2 work
which was discussed at the IPSEC meeting earlier week in London. We
welcome comments and suggestions on improving the revised working group
charter. We would like to submit this charter to the IESG for
consideration by the end of August, so we would appreciate receiving
comments within the next two weeks.
Barbara Fraser
Theodore Ts'o
IPSEC wg chairs
IP Security Protocol (ipsec)
Last Modified: 09-Aug-01
Chair(s):
Barbara Fraser
Theodore Ts'o
Security Area Director(s):
Jeffrey Schiller
Marcus Leech
Security Area Advisor:
Jeffrey Schiller
Mailing Lists:
General Discussion:ipsec@lists.tislabs.com
to Subscribe: ipsec-request@lists.tislabs.com
Archive: ftp://ftp.tis.com/pub/lists/ipsec OR
ftp.ans.net/pub/archive/ipsec
Description of Working Group:
=============================
Rapid advances in communication technology have accentuated the need for
security in the Internet. The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP. A
security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality.
The IPSEC working group will restrict itself to the following short-term
work items to improve the existing key management protocol (IKE):
1) Changes to IKE to support NAT/Firewall traversal
2) Changes to IKE to support SCTP
3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
a fast AES mode suitable for use in hardware encryptors
4) IKE MIB documents
5) Sequence number extensions to ESP to support an expanded sequence
number space.
6) Clarification and standardization of rekeying procedures in IKE.
The working group will also update IKE to reflect implementation
experience, new requirements, and protocol analysis of the existing
protocol. The requirements for IKE V2 will be revised and updated as
the first step in this process.
Goals and Milestones:
=====================
Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and
requirements for IPsec and IKE for use with SCTP, to working
group last call.
Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE
MIBs, and SCTP support for considerations as Draft Standards.
Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE
re-keying completed.
Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE
re-keying to working group last call.
Dec 01 Internet-Draft on IKE v2 Requirements to working group last call
Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted
to the working group.
Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number
expansion, and IKE rekeying for consideration as Draft Standards.
Apr 02 Discuss and select the IKE v2 design from candidate approaches.
Sep 02 IKE v2 Internet-Drafts to working group last call
Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as
Proposed Standards.
From owner-ipsec@lists.tislabs.com Mon Aug 13 06:40:54 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DDesN20239;
Mon, 13 Aug 2001 06:40:54 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03148
Mon, 13 Aug 2001 08:53:57 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0
Content-Class: urn:content-classes:message
Subject: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of i-cookie=0
Date: Mon, 13 Aug 2001 06:00:29 -0700
Message-ID: <2E33960095B58E40A4D3345AB9F65EC1013F83FF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of i-cookie=0
thread-index: AcEMMgtP9EnjItSDS1GBLrzefl04PwXvaqRQ
From: "William Dixon" <wdixon@windows.microsoft.com>
To: <ipsec@lists.tislabs.com>
Cc: "Brian Swander" <BRIANSW@windows.microsoft.com>
X-OriginalArrivalTime: 13 Aug 2001 13:00:29.0946 (UTC) FILETIME=[EDF86DA0:01C123F7]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is to post my discussion with some of the authors last week and
echo my microphone comment during the WG meeting. I haven't had a
chance to discuss it with Ari, so Ari and others, comments appreciated.
This issue was raised initially by Steve Kent and others during the
Minneapolis IETF, lamenting the use of 0x00 8 bytes for every ESP data
packet. It comes up again as multiple IPsec keying protocols want to
install and execute simultaneously in the same operating system, using a
common IPsec UDP-ESP encapsulation API, without paying the penalty of
0x00 8bytes for every UDP-ESP data packet.
I'd like to add text to this draft to explain the following, or to make
the draft-ipsec-udp-encaps ISAKMP or 2409 IKE-specific:
The UDP ESP encapsulation requires 8bytes of 0x00 only when the UDP
encapsulation occurs over port 500. The 8 bytes of zero in this case is
required to distinguish data (ESP) from control (ISAKMP, IKE, initiator
cookie) because it was the only way to accommodate existing IKE
implementations that use a 64bit non-zero initiator cookie value, which
in particular may have the upper most bits non-zero
For non-ISAKMP keying protocols, or for non-IKE at least, the UDP port
number for ESP might not be 500.
For other and future IPsec keying protocols, the UDP encapsulation of
ESP should be more efficient that what the current draft specifies. We
have the opportunity to be more efficient on the data encapsulation:
IP-UDP-ESP - no leading 0x00 for the data channel
If the keying protocol wishes to use UDP-ESP, and multiplex that
encapsulation on it's own port, then the keying protocol MUST provide at
least a 4byte 0x00 flag which will share the same position of the
UDP-ESP SPI. Thus a non-zero SPI means data. A zero SPI means control.
This is a bit of a problem for future non-IKE, but ISAKMP-based keying
protocols, where the header is always first and thus the initiator
cookie is always in the position of the SPI. It would be nice to
constrain future ISAKMP implementation initiator cookie values, MUST
have upper 4 bytes=0x00. It's not sufficient to put such a comment in
the UDP-ESP encapsulation draft because once the protocol uses a
non-zero upper 4bytes, they are stuck with backwards compat like we are
with IKE when they want to add UDP-ESP. Thus the initiator cookie is
always a 64bit value, with upper 32bits =0x00, lower 32bits = random, !=
0x00. We lose the full 64bit non-zero value. Does anyone see a problem
?
Tero noted that this data/control flag value doesn't even have to be
0x00 - just whatever the keying protocol specifies as a flag. But then
it would impact SPI selection, as it could never be something the keying
protocol was using as a flag. I'd think for simplicity sake, keying
protocols should always make their data/control flag=0x00, since SPIs
are/should never be zero.
Wm
From owner-ipsec@lists.tislabs.com Mon Aug 13 09:29:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DGTkN00762;
Mon, 13 Aug 2001 09:29:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03479
Mon, 13 Aug 2001 11:30:46 -0400 (EDT)
Message-ID: <20010813153559.65488.qmail@web13906.mail.yahoo.com>
Date: Mon, 13 Aug 2001 08:35:59 -0700 (PDT)
From: Cisco Chic <cisco_chic@yahoo.com>
Subject: IPSec Latency
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi All,
I was wondering if anyone has any information or sites
which talk about how to tweak (if this can be done)
IPSec tunnls (via keepalives) from a dial up client to
a VPN5008?
We have a latency of around 800 milliseconds on a
network and we are trying to determine what the
maximum delay can be in the network to keep the tunnel
up via keepalives. How long can the delay be for the
keepalives and who sends the keepalives or are the
keepalives sent in both directions via remote dial up
access. (we are using static routes)
I know that a keepalive protocol is used by L2TP in
order to allow it to distinguish between a tunnel
outage and prolonged periods of tunnel inactivity. We
are trying to find out if this can be done for IPSec.
We have a open case with cisco tac currently to get
more details and have been looking at third party web
sites and RFCs. Can't find anything about latency but
have found performance issues concerning bw, memory
etc.
Any information or sites you can direct me to would be
great.
Thanks!!
__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
From owner-ipsec@lists.tislabs.com Mon Aug 13 11:07:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DI7rN03405;
Mon, 13 Aug 2001 11:07:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03824
Mon, 13 Aug 2001 13:19:45 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010813100629.03ce38e8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 13 Aug 2001 10:06:58 -0700
To: "Jerry Yao" <jerry.yao@163.net>
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: Multicasting problem
Cc: <ipsec@lists.tislabs.com>
In-Reply-To: <002a01c12345$a6f64ec0$2100a8c0@server>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_59234154==_.ALT"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--=====================_59234154==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Yes, there's the msec working group in the security area of the IETF.
Mark
At 11:43 PM 8/12/2001 +0800, Jerry Yao wrote:
>Is anybody working at Multicasting problem. I can't find any RFC or Draft
>about it?
--=====================_59234154==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Yes, there's the msec working group in the security area of the
IETF.<br>
<br>
Mark<br>
At 11:43 PM 8/12/2001 +0800, Jerry Yao wrote:<br>
<blockquote type=cite cite><font size=2>Is anybody working at
Multicasting problem. I can't find any RFC or Draft about
it?</font></blockquote></html>
--=====================_59234154==_.ALT--
From owner-ipsec@lists.tislabs.com Mon Aug 13 11:08:00 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DI7xN03419;
Mon, 13 Aug 2001 11:07:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03816
Mon, 13 Aug 2001 13:17:18 -0400 (EDT)
To: ipsec@lists.tislabs.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: SHA2 in AH/ESP
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Tue, 14 Aug 2001 02:23:46 +0900
Message-Id: <20010813172347.E40307BA@starfruit.itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
sorry if it is a well-known topic.
draft-ietf-ipsec-ciph-aes-cbc-01.txt refers the following document on
the use of SHA-2 (SHA-256/384/512) within AH/ESP/IKE, however, I can't
seem to find the document. does anyone have the copy somewhere?
what is the name of the i-d? how many bits should we attach to the
AH/ESP crypto checksum field? is it acceptable to truncate to
align border like 96bit, like we do for SHA1?
itojun
> [SHA2-2] Frankel, S. and S. Kelly, "The Use of SHA-256, SHA-384,
> and SHA-512 within ESP, AH and IKE," Work in progress.
From owner-ipsec@lists.tislabs.com Mon Aug 13 11:09:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DI9kN03477;
Mon, 13 Aug 2001 11:09:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03755
Mon, 13 Aug 2001 13:02:01 -0400 (EDT)
Date: Mon, 13 Aug 2001 13:08:40 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: William Dixon <wdixon@windows.microsoft.com>
cc: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0
In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1013F83FF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <Pine.BSI.3.91.1010813125451.9472E-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Mon, 13 Aug 2001, William Dixon wrote:
> If the keying protocol wishes to use UDP-ESP, and multiplex that
> encapsulation on it's own port, then the keying protocol MUST provide at
> least a 4byte 0x00 flag which will share the same position of the
> UDP-ESP SPI. Thus a non-zero SPI means data. A zero SPI means control.
Before attempting to solve this problem, it seems to me that one should
first ask whether it is worth solving.
Do we need yet another re-invention of the Next Protocol field? That's
what this is. We have too many of them already.
People often have to add new ports to firewall configurations. Avoiding
that seems a feeble justification for all this hassle.
Keying protocols and data flow should not share ports, any more than
Telnet and FTP do.
If it is utterly necessary for UDP-ESP and IKE to share a port -- which I
would argue against -- then that should be deemed a special-case exception
for historical reasons, and we should avoid promulgating general design
principles which encourage repeating this mistake. Indeed, we should
explicitly and loudly recommend *against* repeating this mistake.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Mon Aug 13 11:16:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DIGBN03644;
Mon, 13 Aug 2001 11:16:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03848
Mon, 13 Aug 2001 13:30:27 -0400 (EDT)
To: Henry Spencer <henry@spsystems.net>
Cc: William Dixon <wdixon@windows.microsoft.com>, ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0
References: <Pine.BSI.3.91.1010813125451.9472E-100000@spsystems.net>
From: Derek Atkins <warlord@mit.edu>
Date: 13 Aug 2001 13:37:01 -0400
In-Reply-To: Henry Spencer's message of "Mon, 13 Aug 2001 13:08:40 -0400 (EDT)"
Message-ID: <sjmd75z7tfm.fsf@rcn.ihtfp.org>
Lines: 27
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
For NAT traversal, I think it is eminently ideal for the keying and
data streams to share a port.. Otherwise you need twice as many
keepalives to keep the NAT mapping happy.
Speaking as the chair of KINK, I'd like to make sure that KINK does
a similar transposition. I can certainly see carrying ESP within
KINK-like UDP messages on the KINK port.
-derek
Henry Spencer <henry@spsystems.net> writes:
> If it is utterly necessary for UDP-ESP and IKE to share a port -- which I
> would argue against -- then that should be deemed a special-case exception
> for historical reasons, and we should avoid promulgating general design
> principles which encourage repeating this mistake. Indeed, we should
> explicitly and loudly recommend *against* repeating this mistake.
>
> Henry Spencer
> henry@spsystems.net
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Mon Aug 13 12:38:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DJccN05441;
Mon, 13 Aug 2001 12:38:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04397
Mon, 13 Aug 2001 14:51:12 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010813145450.00ac1520@email.nist.gov>
X-Sender: sfrankel@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 13 Aug 2001 14:58:22 -0400
To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
From: Sheila Frankel <sheila.frankel@nist.gov>
Subject: Re: SHA2 in AH/ESP
Cc: ipsec@lists.tislabs.com
In-Reply-To: <20010813172347.E40307BA@starfruit.itojun.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The document is in the works, but has not yet been published as an Internet
Draft. SHA-256 would most likely be truncated to 128 bits.
Sheila Frankel
At 01:23 PM 8/13/01, you wrote:
> sorry if it is a well-known topic.
>
> draft-ietf-ipsec-ciph-aes-cbc-01.txt refers the following document on
> the use of SHA-2 (SHA-256/384/512) within AH/ESP/IKE, however, I
> can't
> seem to find the document. does anyone have the copy somewhere?
> what is the name of the i-d? how many bits should we attach to the
> AH/ESP crypto checksum field? is it acceptable to truncate to
> align border like 96bit, like we do for SHA1?
>
>itojun
>
>
> > [SHA2-2] Frankel, S. and S. Kelly, "The Use of SHA-256, SHA-384,
> > and SHA-512 within ESP, AH and IKE," Work in progress.
From owner-ipsec@lists.tislabs.com Mon Aug 13 13:03:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DK3CN06106;
Mon, 13 Aug 2001 13:03:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04568
Mon, 13 Aug 2001 15:23:13 -0400 (EDT)
Message-ID: <3B782AC3.FFE8D633@storm.ca>
Date: Mon, 13 Aug 2001 15:30:11 -0400
From: Sandy Harris <sandy@storm.ca>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
References: <000701c123ed$7b19e340$b70be982@andrewk3.ca.newbridge.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Andrew Krywaniuk wrote:
> > No, the main purpose of quick mode was to be able to amortize the
> > cost of authentication over many SAs. Different SAs can be established
> > to protect different flows ...
>
> And what is the purpose of having different SAs to protect different flows?
> (besides thwarting traffic analysis)
Far from thwarting traffic analysis, I think that makes it easier. Having
multiple SAs between two gateways gives an analyst more data. He or she
can look at the data in the header that classifies packets by SA.
I discuss this in the FreeS/WAN documentation:
http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/ipsec.html#traffic.resist
Commemnt and criticism solicited.
What I suggest there is that to resist (not thwart!) traffic
analysis, you want at least:
only one tunnel between a pair of hosts
all IPSEC data goes down that tunnel
any other traffic between the hosts goes down it too
(encrypt as much as you possibly can, not just what
you think you need to)
This still won't stop it completely. For that you'd need to insert dummy
traffic to confuse the analyst, and probably take other measures I haven't
thought of.
From owner-ipsec@lists.tislabs.com Mon Aug 13 15:53:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DMrrN11102;
Mon, 13 Aug 2001 15:53:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04940
Mon, 13 Aug 2001 17:47:52 -0400 (EDT)
Message-ID: <3B784CA6.2DD8E1FC@F-Secure.com>
Date: Tue, 14 Aug 2001 00:54:46 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henry Spencer <henry@spsystems.net>
CC: William Dixon <wdixon@windows.microsoft.com>, ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of ,
i-cookie=0
References: <Pine.BSI.3.91.1010813125451.9472E-100000@spsystems.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Henry Spencer wrote:
>
> On Mon, 13 Aug 2001, William Dixon wrote:
> > If the keying protocol wishes to use UDP-ESP, and multiplex that
> > encapsulation on it's own port, then the keying protocol MUST provide at
> > least a 4byte 0x00 flag which will share the same position of the
> > UDP-ESP SPI. Thus a non-zero SPI means data. A zero SPI means control.
>
> Before attempting to solve this problem, it seems to me that one should
> first ask whether it is worth solving.
This is good advice and should be applied to these questions at least:
a) Do we really want to make this draft a generic draft, usable by several
key management protocols? Or do we want to keep it simple, understandable
and IKE-specific? If some other key management protocol needs it, why
should this draft / this WG solve the problem? (In particular, KINK would
probably be better off writing their own simple document on the matter.)
b) What is the actual NEED to save bits on the wire? What are the things we
can tinker with to save them? I.e.
- We can have separate channels for IKE and ESPUDP, which saves 8 bytes
per ESPUDP packet. Then we need NAT-keepalives for both channels. Do these
extra keepalives cause more traffic than is saved? I'm not so sure.
- If we can change IKE header field order and steal one bit of ESP SPI
field, we can also save the 8 bytes per packet, but this is not very
practical. (ISAKMP flags field first, cookies starting at byte 5. This
might be usable for KINK?)
It's also good to remember that UDP header also takes 8 bytes. And 8 bytes of
UDP header followed by 8 bytes of zero should compress pretty well at some
header compression algorithm. And the checksum is also zero.
So, I would prefer not to change this draft if it's not really necessary.
There was quite a lot of discussion about these things among the authors, but
if this WG wants otherwise, I can of course modify the draft.
Yes, I agree completely with the AH-removal choice.
Ari
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
From owner-ipsec@lists.tislabs.com Mon Aug 13 19:27:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E2R7N15944;
Mon, 13 Aug 2001 19:27:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05711
Mon, 13 Aug 2001 21:39:57 -0400 (EDT)
Message-ID: <20010814014708.45906.qmail@web13808.mail.yahoo.com>
Date: Mon, 13 Aug 2001 18:47:08 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: DRAFT: ipsec charter update
To: tytso@mit.edu, ipsec@lists.tislabs.com
In-Reply-To: <E15UpaV-00036d-00@think.thunk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I would like to see the following changes to IKE included in the charter:
* Ability to specify the IPsec SPD description in a flexible manner
in Quick mode.
Currently, the ID payload is overloaded to carry the SPD semantics
in a rather inflexible manner in Quick mode. As such, this has become a
deterrent to successful IKE deployment in many instances.
regards,
suresh
--- tytso@mit.edu wrote:
>
> The IPSEC wg chairs met with Marcus Leech today, and after discussions
> and consultation with him, we have developed the following draft update
> to the IPSEC working group charter.
>
> Contained in this proposed update is a timeline for the IKE V2 work
> which was discussed at the IPSEC meeting earlier week in London. We
> welcome comments and suggestions on improving the revised working group
> charter. We would like to submit this charter to the IESG for
> consideration by the end of August, so we would appreciate receiving
> comments within the next two weeks.
>
> Barbara Fraser
> Theodore Ts'o
> IPSEC wg chairs
>
>
> IP Security Protocol (ipsec)
>
> Last Modified: 09-Aug-01
>
> Chair(s):
> Barbara Fraser <byfraser@cisco.com>
> Theodore Ts'o <tytso@mit.edu>
>
> Security Area Director(s):
> Jeffrey Schiller <jis@mit.edu>
> Marcus Leech <mleech@nortelnetworks.com>
>
> Security Area Advisor:
> Jeffrey Schiller <jis@mit.edu>
>
> Mailing Lists:
> General Discussion:ipsec@lists.tislabs.com
> to Subscribe: ipsec-request@lists.tislabs.com
> Archive: ftp://ftp.tis.com/pub/lists/ipsec OR
> ftp.ans.net/pub/archive/ipsec
>
> Description of Working Group:
> =============================
>
> Rapid advances in communication technology have accentuated the need for
> security in the Internet. The IP Security Protocol Working Group
> (IPSEC) will develop mechanisms to protect client protocols of IP. A
> security protocol in the network layer will be developed to provide
> cryptographic security services that will flexibly support combinations
> of authentication, integrity, access control, and confidentiality.
>
> The IPSEC working group will restrict itself to the following short-term
> work items to improve the existing key management protocol (IKE):
>
> 1) Changes to IKE to support NAT/Firewall traversal
>
> 2) Changes to IKE to support SCTP
>
> 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and
> a fast AES mode suitable for use in hardware encryptors
>
> 4) IKE MIB documents
>
> 5) Sequence number extensions to ESP to support an expanded sequence
> number space.
>
> 6) Clarification and standardization of rekeying procedures in IKE.
>
> The working group will also update IKE to reflect implementation
> experience, new requirements, and protocol analysis of the existing
> protocol. The requirements for IKE V2 will be revised and updated as
> the first step in this process.
>
> Goals and Milestones:
> =====================
>
> Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and
> requirements for IPsec and IKE for use with SCTP, to working
> group last call.
>
> Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE
> MIBs, and SCTP support for considerations as Draft Standards.
>
> Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE
> re-keying completed.
>
> Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE
> re-keying to working group last call.
>
> Dec 01 Internet-Draft on IKE v2 Requirements to working group last call
>
> Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted
> to the working group.
>
> Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number
> expansion, and IKE rekeying for consideration as Draft Standards.
>
> Apr 02 Discuss and select the IKE v2 design from candidate approaches.
>
> Sep 02 IKE v2 Internet-Drafts to working group last call
>
> Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as
> Proposed Standards.
>
>
>
>
=====
__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
From owner-ipsec@lists.tislabs.com Tue Aug 14 01:44:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E8ifN25076;
Tue, 14 Aug 2001 01:44:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA06349
Tue, 14 Aug 2001 03:43:44 -0400 (EDT)
Message-ID: <003901c1249d$86b1a8e0$0300000a@bilbo>
From: "Sara Bitan" <sarab@cs.Technion.AC.IL>
To: <ipsec@lists.tislabs.com>
Subject: Traffic handling and key management "divide and coquer"
Date: Tue, 14 Aug 2001 10:45:51 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1255"
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
I think that we are at a crucial point where we can make a change that will
turn our work to more focused and efficient, and hopefully fruitful. I
suggest we use a "divide and conquer" strategic.
We should first of all separate IPsec transforms traffic handling (i.e. ESP
and AH) and key management work to different WGs (if I understand right,
this was raised by JI in the SAAG meeting).
This process is already happening as we speak - MSEC and KINK are working on
key management protocols that create IPsec SAs, with different
requirements. ESP and AH will still be used for traffic handling.
If we will do the separation, we will soon be able to tell the industry that
the work on the IPsec transforms is done, which I think will be a great
advantage.
I think we should also allow for several key management protocols,
preferably with one framework.
This is the only way we will be able to cater for the requirements of "DSL
geeks" as well as "billion mobile users" (quoting Jari's words).
There are several actions that we need to take for this to happen:
1) Allow working groups other than IPsec to work on key management
protocols, this way we could shut down the IPsec WG and keep on working on
new key management protocols. As I said this is already happening.
2) Limit IPsec wg to only on the following IKE modifications : NAT
traversal, SCTP support and re-keying. The new IKE version should be a minor
version including only minor fixes (as outlined in the new suggested
charter).
3) Re-assure ourselves that the interface between transforms and key
management is clearly defined, and general enough to allow for the addition
of new key management protocols, without having to change the transforms.
4) Have a framework protocol for key management - I think it should be based
on ISAKMP. There is no need to re-invent transforms and proposals syntax for
each new key management protocol.
5) Have different requirements for different key management protocols. With
one common requirement - they should all create IPsec SAs. This way we could
have one requirements document include Identity protection, and allow for a
larger number of messages, and another that has no Identity Protection
requirement, and requires a small number of message. We can also have one or
several WGs in charge of the key management protocols.
Sara.
From owner-ipsec@lists.tislabs.com Tue Aug 14 02:22:46 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E9MkN27064;
Tue, 14 Aug 2001 02:22:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA06443
Tue, 14 Aug 2001 04:39:21 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Sandy Harris'" <sandy@storm.ca>, <ipsec@lists.tislabs.com>
Cc: <dharkins@lounge.org>, <Joel.Snyder@Opus1.COM>
Subject: RE: Simplifying IKE
Date: Tue, 14 Aug 2001 09:36:08 +0100
Message-Id: <000b01c1249c$752ac580$0109e982@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <3B782AC3.FFE8D633@storm.ca>
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> > And what is the purpose of having different SAs to protect
> different flows?
> > (besides thwarting traffic analysis)
>
> Far from thwarting traffic analysis, I think that makes it
> easier. Having
> multiple SAs between two gateways gives an analyst more data.
> He or she
> can look at the data in the header that classifies packets by SA.
Sorry, I meant "traffic analysis" in the more general sense of analyzing
anything about the traffic flow, in this case specifically cryptanalysis of
the data stream. I originally did this in the ipsec-properties draft as well
until someone pointed out that it was vague. Is there a well-defined term
for this type of traffic analysis? "Data analysis"?
While I am personally in favour of sending all traffic down a single tunnel
(in most cases), I did think of one attack which could be thwarted by
separating traffic flows:
Imagine that an attacker can generate traffic on flow A behind a gateway and
read the encrypted traffic on the Internet; he now has the possibility of
doing a chosen-plaintext attack. If the gateway sends traffic across
multiple SAs, then cryptanalysis of the output stream for flow A will only
allow the attacker to crack the key for SA_A (which only protects traffic
which was generated by the attacker).
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
From owner-ipsec@lists.tislabs.com Tue Aug 14 02:52:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E9q6N00629;
Tue, 14 Aug 2001 02:52:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA06528
Tue, 14 Aug 2001 05:06:05 -0400 (EDT)
Message-Id: <200108140912.f7E9CY005751@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: andrew.krywaniuk@alcatel.com
cc: "'Sandy Harris'" <sandy@storm.ca>, ipsec@lists.tislabs.com,
dharkins@lounge.org, Joel.Snyder@Opus1.COM
Subject: Re: Simplifying IKE
In-reply-to: Your message of "Tue, 14 Aug 2001 09:36:08 BST."
<000b01c1249c$752ac580$0109e982@andrewk3.ca.newbridge.com>
Reply-to: sommerfeld@East.Sun.COM
Date: Tue, 14 Aug 2001 05:12:34 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Sorry, I meant "traffic analysis" in the more general sense of analyzing
> anything about the traffic flow, in this case specifically cryptanalysis of
> the data stream.
most folks using the term "traffic analysis" seems to use it to mean
analysis of everything *except* the encryption.. i.e., looking at
message size, volume, origins, and miscellanous cleartext identifiers
(e.g., ip addresses and SPI's for IPsec).
> I originally did this in the ipsec-properties draft as well until
> someone pointed out that it was vague. Is there a well-defined term
> for this type of traffic analysis? "Data analysis"?
cryptanalysis? ;-)
sounds like an active chosen-plaintext attack..
- Bill
From owner-ipsec@lists.tislabs.com Tue Aug 14 06:12:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EDC4N09901;
Tue, 14 Aug 2001 06:12:04 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06948
Tue, 14 Aug 2001 08:06:01 -0400 (EDT)
Message-Id: <200108141213.IAA13485@bcn.East.Sun.COM>
Date: Tue, 14 Aug 2001 08:13:07 -0400 (EDT)
From: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Subject: having and eating cake? agressive mode with identity hiding
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: MJK2awSgirpJinC+H+yHjg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
After the IPsec meeting, some people mentioned to me that if we'd
get rid of one mode, they'd prefer getting rid of main mode and
keeping aggressive mode.
As it turns out, in the paper from which the internet draft presented
at the meeting was based:
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf
it mentions that we can get identity hiding with the public signature key
variant.
It would be nice to have a single IKE protocol. Perhaps this slightly
modified aggressive mode/identity hiding/public signature keys would
be a good choice.
The basic idea is:
message 1:
Alice--->Bob
g^a mod p
message 2:
Bob---->Alice
g^b mod p, {"Bob", proof I'm Bob} encrypted with g^ab mod p
;the proof he's Bob consists of a signature on messages 1 and 2, e.g.
message 3:
Alice---->Bob
{"Alice", proof I'm Alice}g^ab mod p
I might want to add the OAKLEY-style trick where Bob can respond in message
2 with "I am going to want a stateless cookie, so try again, but this
time send cookie c" That way if Bob isn't under attack, he can do the 3 message
exchange, and if he is, he responds to cookie-less message 1's with a cookie,
and responds to valid cookie-containing message 2's with the rest
of the protocol.
Radia
From owner-ipsec@lists.tislabs.com Tue Aug 14 06:12:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EDC4N09900;
Tue, 14 Aug 2001 06:12:04 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07014
Tue, 14 Aug 2001 08:30:40 -0400 (EDT)
Message-Id: <200108141236.f7ECaWu09104@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Michael Thomas <mat@cisco.com>
cc: Henry Spencer <henry@spsystems.net>, ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: Wes Hardaker: opportunistic encryption deployment problems
In-reply-to: Your message of Sat, 11 Aug 2001 13:14:00 PDT.
<15221.37384.191416.901953@thomasm-u1.cisco.com>
Date: Tue, 14 Aug 2001 14:36:32 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
Also: I think the MIP experience sez that we ought to
consider whether we'd want such a PKI even if
it were possible.
=> we leave the technical domain there... I've never seen
a rational argument about this!
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Tue Aug 14 06:19:37 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EDJaN10041;
Tue, 14 Aug 2001 06:19:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07061
Tue, 14 Aug 2001 08:39:12 -0400 (EDT)
Message-Id: <200108131313.f7DDDIB21122@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of "Wed, 08 Aug 2001 18:25:38 PDT."
<200108090125.f791PcT00595@dharkins@lounge.orgatty.lounge.org>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 13 Aug 2001 09:13:18 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Dan" == Dan Harkins <dharkins@lounge.org> writes:
Dan> Then the problem is on the other end. The selector either says every
Dan> packet _MUST_ be IPsec-protected or else it _MUST NOT_ be
Dan> IPsec-protected.
When IPsec is not part of the stack, this is a concern because the policy
checks must be done by the IPsec piece rather than having the crypto status
noted and checked by upper layers.
Dan> Either way, if some packets--those with Binding Updates-- are received with
Dan> IPsec protection and others-- those without Binding Updates-- are not then
Dan> we're going to have a problem.
If the packet has some form of authentication (I'll not prejudge by saying
AH), and this is noted in the control structure, then the piece that
processes the Binding Update says "okay, it was protected".
The TCP layer (or whatever) above it didn't require that the packet was
protected (or not), so it goes on. If the system policy required all packets
to be authenticated, then TCP would check that.
Dan McDonald? Bill Sommerfeld? Itojun?
Does this make sense?
{Has anyone considered putting IKE message inside of a TCP option? This
doesn't help keep the session private, but if the point is to establish
keying so that a Binding Update will work, then this saves a bunch of
latency. You just can't go fix the triangle before your connection comes
up... I keep thinking that MIPv6 is the answer to multi6}
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO3fSbIqHRg3pndX9AQEVGwP6A37XpPsE6EP2SAfMrRCh443NsNCYKGKi
JxF2F5U19q8zwesXcbArhTkPENEYJIgSW3evmLnbu3tZkNpE4YBMSbZTLt9dvQyA
UdqDwjHER79YJgmwfDNTLSQCc6GCwNLrBsqXcIgYlx5AAnJrp+UattHAL8XbV4vb
TddaHJ9BFcA=
=1SaI
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Tue Aug 14 07:32:45 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EEWjN11692;
Tue, 14 Aug 2001 07:32:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07370
Tue, 14 Aug 2001 09:43:02 -0400 (EDT)
Message-ID: <9D6A470BD38ED311908000805F65B4EC054AF990@rndex50.ottawa.mitel.com>
From: "Dilkie, Lee" <Lee_Dilkie@mitel.com>
To: "'andrew.krywaniuk@alcatel.com'" <andrew.krywaniuk@alcatel.com>,
"'Sandy Harris'" <sandy@storm.ca>, ipsec@lists.tislabs.com
Cc: dharkins@lounge.org, Joel.Snyder@Opus1.COM
Subject: RE: Simplifying IKE
Date: Tue, 14 Aug 2001 09:49:43 -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
> Imagine that an attacker can generate traffic on flow A
> behind a gateway and
> read the encrypted traffic on the Internet; he now has the
> possibility of
> doing a chosen-plaintext attack. If the gateway sends traffic across
> multiple SAs, then cryptanalysis of the output stream for
> flow A will only
> allow the attacker to crack the key for SA_A (which only
> protects traffic
> which was generated by the attacker).
>
> Andrew
I'm thinking that an attacker with access to the plaintext side of an IPsec gateway already has far easier attacks than sending a trillion plaintext packets (which I'm sure will go un-noticed) through the gateway and doing an analysis on the results.
I think the point is being missed here. It's the complexity of trying to deal with *every* possible security attack that has led to the current mess. It is just not practical to have the IP layer fully responsible for *all* security. Decide what you can do to protect the privacy of communications in a *reasonable* enviroment. Let the upper, application, layer add it's own authentication (and encryption as well if necessary) because that's where those decisions make more sense. Treat security like the onion, as it's supposed to be treated. It's not a failure to punt the problem and say "look, solving that attack is the responsibility of the application, if the consequences are that severe, then the application needs to be secure as well". Think of IPsec as the default "freebee" security that is inherent in the system, if an application needs more, then let them add more.
My 2 cents worth, I now return you to your previous programming.
Lee Dilkie
Mitel Networks
350 Legget Drive
Kanata, ON, Canada
K2K 2W7
Phone: 1-613-592-5660
"It wasn't easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day."
- Homer Simpson (from "The Simpsons")
From owner-ipsec@lists.tislabs.com Tue Aug 14 08:41:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EFfnN17086;
Tue, 14 Aug 2001 08:41:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07537
Tue, 14 Aug 2001 10:52:59 -0400 (EDT)
From: Sheila Frankel <sheila.frankel@nist.gov>
To: Radia Perlman <Radia.Perlman@sun.com>
Subject: Re: having and eating cake? agressive mode with identity hiding
Message-ID: <997801168.3b793cd0c30c8@email.nist.gov>
Date: Tue, 14 Aug 2001 10:59:28 -0400 (EDT)
Cc: ipsec@lists.tislabs.com
References: <200108141213.IAA13485@bcn.East.Sun.COM>
In-Reply-To: <200108141213.IAA13485@bcn.East.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.5
X-Originating-IP: 65.1.246.246
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
There is one problem that arises from adopting aggressive mode as the single IKE
variant. Since "g^a mod p" is sent in message 1, we lose the capability to
negotiate the Diffie-Hellman group.
Sheila Frankel
NIST
Quoting Radia Perlman <Radia.Perlman@sun.com>:
> It would be nice to have a single IKE protocol. Perhaps this slightly
> modified aggressive mode/identity hiding/public signature keys would
> be a good choice.
>
> The basic idea is:
>
> message 1:
> Alice--->Bob
> g^a mod p
>
> message 2:
> Bob---->Alice
> g^b mod p, {"Bob", proof I'm Bob} encrypted with g^ab mod p
> ;the proof he's Bob consists of a signature on messages 1 and 2,
> e.g.
>
> message 3:
> Alice---->Bob
> {"Alice", proof I'm Alice}g^ab mod p
From owner-ipsec@lists.tislabs.com Tue Aug 14 08:47:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EFlgN18100;
Tue, 14 Aug 2001 08:47:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07567
Tue, 14 Aug 2001 11:06:34 -0400 (EDT)
Message-Id: <200108141513.LAA15508@bcn.East.Sun.COM>
Date: Tue, 14 Aug 2001 11:13:45 -0400 (EDT)
From: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Subject: Re: having and eating cake? agressive mode with identity hiding
To: Radia.Perlman@sun.com, sheila.frankel@nist.gov
Cc: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: kADDpooVp04r/8v7mlHM9A==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Re: Sheila Frankel's pointing out the loss of ability to negotiate the D-H
group.
Is it that important to negotiate it rather than having Alice choose?
If so, how many groups might Alice be willing to propose? If it's
only a handful, then it wouldn't be tragic in the rare case where her choice
was unacceptable to Bob for Bob to reply with "unacceptable D-H choice"
and Alice to cycle through her choices. Or have Bob reply with his list of
acceptable choices.
Radia
From: Sheila Frankel <sheila.frankel@nist.gov>
There is one problem that arises from adopting aggressive mode as the
single IKE
variant. Since "g^a mod p" is sent in message 1, we lose the capability
to
negotiate the Diffie-Hellman group.
Sheila Frankel
NIST
From owner-ipsec@lists.tislabs.com Tue Aug 14 08:47:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EFlgN18101;
Tue, 14 Aug 2001 08:47:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07586
Tue, 14 Aug 2001 11:10:13 -0400 (EDT)
Date: Tue, 14 Aug 2001 11:16:46 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>
cc: ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
In-Reply-To: <000b01c1249c$752ac580$0109e982@andrewk3.ca.newbridge.com>
Message-ID: <Pine.BSI.3.91.1010814110400.3877C-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 14 Aug 2001, Andrew Krywaniuk wrote:
> Sorry, I meant "traffic analysis" in the more general sense of analyzing
> anything about the traffic flow, in this case specifically cryptanalysis of
> the data stream.
That's incorrect; "traffic analysis" is an idiom with a specific meaning
in the cryptography world. Schneier, p219:
Traffic analysis is the analysis of encrypted messages: where they
come from, where they go to, how long they are, when they are sent,
how frequent or infrequent they are, whether they coincide with
outside events like meetings, and more. A lot of good information
is buried in that data, and a cryptanalyst will want to get his hands
on it...
(When he says "analysis of encrypted messages", he means "without
decrypting them"; the context of this is a discussion of how traffic
analysis can assist with cryptanalysis.)
> ...Is there a well-defined term
> for this type of traffic analysis? "Data analysis"?
"Cryptanalysis" is usual. That's a very generic term, which includes
things like chosen-plaintext attacks.
> ...a chosen-plaintext attack. If the gateway sends traffic across
> multiple SAs, then cryptanalysis of the output stream for flow A will only
> allow the attacker to crack the key for SA_A (which only protects traffic
> which was generated by the attacker).
If the encryption scheme is vulnerable to chosen-plaintext attacks, it is
already too weak to be used for protecting important data. Well-chosen
encryption schemes are not vulnerable to (practical) chosen-plaintext
attacks, and so this argument falls apart in real life.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue Aug 14 09:33:22 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EGXMN20669;
Tue, 14 Aug 2001 09:33:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07628
Tue, 14 Aug 2001 11:20:02 -0400 (EDT)
Message-ID: <20010814152715.7635.qmail@web13804.mail.yahoo.com>
Date: Tue, 14 Aug 2001 08:27:15 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
Subject: Re: Traffic handling and key management "divide and coquer"
To: Sara Bitan <sarab@cs.Technion.AC.IL>, ipsec@lists.tislabs.com
In-Reply-To: <003901c1249d$86b1a8e0$0300000a@bilbo>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--- Sara Bitan <sarab@cs.Technion.AC.IL> wrote:
> I think that we are at a crucial point where we can make a change that will
> turn our work to more focused and efficient, and hopefully fruitful. I
> suggest we use a "divide and conquer" strategic.
> We should first of all separate IPsec transforms traffic handling (i.e. ESP
> and AH) and key management work to different WGs (if I understand right,
> this was raised by JI in the SAAG meeting).
I like focused work groups. IPsec WG should be focused on protocols
independent of IKE. IKE WG must be focused on delivering the key
maangement requirements of IPsec.
> This process is already happening as we speak - MSEC and KINK are working on
> key management protocols that create IPsec SAs, with different
> requirements. ESP and AH will still be used for traffic handling.
> If we will do the separation, we will soon be able to tell the industry that
> the work on the IPsec transforms is done, which I think will be a great
> advantage.
>
Yes.
> I think we should also allow for several key management protocols,
> preferably with one framework.
> This is the only way we will be able to cater for the requirements of "DSL
> geeks" as well as "billion mobile users" (quoting Jari's words).
>
> There are several actions that we need to take for this to happen:
> 1) Allow working groups other than IPsec to work on key management
> protocols, this way we could shut down the IPsec WG and keep on working on
> new key management protocols. As I said this is already happening.
> 2) Limit IPsec wg to only on the following IKE modifications : NAT
^^^^^^^^
I would prefer a name like "IKE WG", that is reflective of the
work the WG is focused on.
> traversal, SCTP support and re-keying. The new IKE version should be a minor
I would also suggest including the ability to specify IPsec SPD
in a flexible manner in Quick mode.
Above all, the new-IKE should be focused on servicing the IPsec
protocols. All of the modificications suggested (NAT traversal,
SCTP support, rekeying and support for IPsec SPD) share the
common theme of supporting IPsec deployment. Perhaps an RFC
focused on IPsec-IKE interaction would be immensely useful.
As it stands, IKE is taking center stage due to its complexity.
Issues with Ipsec are considered secondary compared to IKE.
The roles ought to be reversed. Ipsec deployment is the end goal
and as such the eventual focus should be shifted to Ipsec.
IKE should facilitate Ipsec, without taking the center stage
by itself with its complexity and inability to fully support
Ipsec in its deployment.
Thanks.
<... stuff deleted>
> Sara.
>
regards,
suresh
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
From owner-ipsec@lists.tislabs.com Tue Aug 14 09:34:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EGYZN20719;
Tue, 14 Aug 2001 09:34:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07599
Tue, 14 Aug 2001 11:12:30 -0400 (EDT)
Message-Id: <200108141519.AAG12850@mira-sjcm-3.cisco.com>
X-Sender: sfluhrer@mira-sjcm-3
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2
Date: Tue, 14 Aug 2001 08:02:13 -0700
To: "Dilkie, Lee" <Lee_Dilkie@mitel.com>,
"'andrew.krywaniuk@alcatel.com'" <andrew.krywaniuk@alcatel.com>,
"'Sandy Harris'" <sandy@storm.ca>, ipsec@lists.tislabs.com
From: Scott Fluhrer <sfluhrer@cisco.com>
Subject: RE: Simplifying IKE
Cc: dharkins@lounge.org, Joel.Snyder@Opus1.COM
In-Reply-To: <9D6A470BD38ED311908000805F65B4EC054AF990@rndex50.ottawa.mi
tel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 06:49 AM 8/14/01 , Dilkie, Lee wrote:
>> Imagine that an attacker can generate traffic on flow A
>> behind a gateway and
>> read the encrypted traffic on the Internet; he now has the
>> possibility of
>> doing a chosen-plaintext attack. If the gateway sends traffic across
>> multiple SAs, then cryptanalysis of the output stream for
>> flow A will only
>> allow the attacker to crack the key for SA_A (which only
>> protects traffic
>> which was generated by the attacker).
>>
>> Andrew
>
>I'm thinking that an attacker with access to the plaintext side of an IPsec gateway already has far easier attacks than sending a trillion plaintext packets (which I'm sure will go un-noticed) through the gateway and doing an analysis on the results.
Perhaps not. Maybe the attacker is a legitimate user who is authorized
to send traffic via the encrypted connection, but cannot listen in on
traffic from other authorized users. In that case, the attack scenario
is perfectly valid. Of course, the real solution to this attack is to
use an encryption algorithm that is secure against a chosen plaintext
attack. Since that is an attack model used to analyze ciphers, that is
practical.
>
>I think the point is being missed here. It's the complexity of trying to deal with *every* possible security attack that has led to the current mess. It is just not practical to have the IP layer fully responsible for *all* security. Decide what you can do to protect the privacy of communications in a *reasonable* enviroment. Let the upper, application, layer add it's own authentication (and encryption as well if necessary) because that's where those decisions make more sense. Treat security like the onion, as it's supposed to be treated. It's not a failure to punt the problem and say "look, solving that attack is the responsibility of the application, if the consequences are that severe, then the application needs to be secure as well". Think of IPsec as the default "freebee" security that is inherent in the system, if an application needs more, then let them add more.
Actually, (IMHO) it wasn't the huge number of security attacks which
lead to the complexity -- it was the large number of requirements.
Why isn't main mode acceptable for everything? Well, because some
people are concerned (rightly or wrongly) about the additional
messages. Why do we have both AH and ESP authentication transforms?
Because AH is needed in some case (so I have heard it claimed), and
will not work in others (e.g. when NAT is involved). Why do we have
the ESP-NULL "encryption" transform? Certainly not to prevent an
attack on security.
>
>My 2 cents worth, I now return you to your previous programming.
>
>Lee Dilkie
>
>Mitel Networks
>350 Legget Drive
>Kanata, ON, Canada
>K2K 2W7
>
>Phone: 1-613-592-5660
>
>"It wasn't easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day."
> - Homer Simpson (from "The Simpsons")
>
From owner-ipsec@lists.tislabs.com Tue Aug 14 10:05:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EH5RN21393;
Tue, 14 Aug 2001 10:05:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07704
Tue, 14 Aug 2001 12:14:16 -0400 (EDT)
Message-ID: <3B79500C.1367FCD3@storm.ca>
Date: Tue, 14 Aug 2001 12:21:32 -0400
From: Sandy Harris <sandy@storm.ca>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Require AH?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dropping AH has been suggested from time to time. The proposal seems to get
considerable support, but also some opposition. I'm not entirely clear on reasons
for the opposition, but it seems to revolve around things like mobile IP that
may need header authentication and arguably don't always need encryption.
Currently we have three binary choices. Use AH, use ESP authentication, use
ESP encryption. This gives us 8 possibilities:
use none, just do normal IP
two with duplicate authentication in both AH and ESP
(with or without encryption)
two ways to do authentication alone
(AH or ESP-null)
two ways to do encryption + authentication
(AH or ESP authentication)
one way to encrypt without authentication
(ESP with no authentication)
The last is a very bad idea and implementations should prohibit it, but
I think the current protocol definition allows it.
The various lines starting "two ..." all indicate unecessary complications:
more options for IKE to negotiate, more combinations to implement and test,
more things for the SADB to track.
If we dump AH, we get rid of half the options and are left with:
use none, just do normal IP
one way to do authentication alone, ESP-null
one way to do encryption + authentication, ESP
one way to encrypt without authentication
(ESP with no authentication)
The last alternative is unchanged and still a bad idea. We could get rid of
by requiring that ESP always authenticate.
An alternative would be to require AH on all IPsec connections, giving:
use none, just do normal IP
one way to do authentication alone, AH
one way to do encryption + authentication, AH + ESP
This gets rid of that nasty fourth alternative, keeps AH for those that
need it, and lets us drop ESP-null.
If AH is actually needed, which some people have claimed in previous
discussions, then the last strikes me as the best choice.
Of course, this was likely discussed back before authentication was
added to ESP. Why was it rejected then?
From owner-ipsec@lists.tislabs.com Tue Aug 14 10:16:34 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EHGXN21819;
Tue, 14 Aug 2001 10:16:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07740
Tue, 14 Aug 2001 12:33:29 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15225.21556.73706.140436@thomasm-u1.cisco.com>
Date: Tue, 14 Aug 2001 09:39:16 -0700 (PDT)
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Cc: sheila.frankel@nist.gov, ipsec@lists.tislabs.com
Subject: Re: having and eating cake? agressive mode with identity hiding
In-Reply-To: <200108141513.LAA15508@bcn.East.Sun.COM>
References: <200108141513.LAA15508@bcn.East.Sun.COM>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Yes, I think that one of the optimizations that
IKE could use is to take an optimistic approach on
many fronts. This is, expect that what you propose
will work (ie group 2) but allow the ability to
reject that proposal if it's not acceptible. In
the vast majority of cases -- assuming some
stability in ciphersuites which seems reasonable
at this point -- the average case will complete
much quicker. The same can be done for DoS
protection: if you're not under attack, sending
the initiator off to do a return-routability test
is fairly useless, and counterproductive. The
protocol needs to be able support that test so
that the recipient can defend himself if need be,
but that should be the exceptional case.
Given these two things, and then the ability to
squish a quick mode exchange into the final cert
exchange (using an optimistic approach too), we
should be able to get the average initial
main/quick mode exchange to complete in 4 or 5
messages rather than 8 or 9.
Mike
Radia Perlman - Boston Center for Networking writes:
> Re: Sheila Frankel's pointing out the loss of ability to negotiate the D-H
> group.
>
> Is it that important to negotiate it rather than having Alice choose?
> If so, how many groups might Alice be willing to propose? If it's
> only a handful, then it wouldn't be tragic in the rare case where her choice
> was unacceptable to Bob for Bob to reply with "unacceptable D-H choice"
> and Alice to cycle through her choices. Or have Bob reply with his list of
> acceptable choices.
>
> Radia
>
>
>
> From: Sheila Frankel <sheila.frankel@nist.gov>
>
>
> There is one problem that arises from adopting aggressive mode as the
> single IKE
> variant. Since "g^a mod p" is sent in message 1, we lose the capability
> to
> negotiate the Diffie-Hellman group.
>
> Sheila Frankel
> NIST
>
>
From owner-ipsec@lists.tislabs.com Tue Aug 14 10:24:14 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EHODN21969;
Tue, 14 Aug 2001 10:24:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07762
Tue, 14 Aug 2001 12:40:55 -0400 (EDT)
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: ipsec@lists.tislabs.com
In-reply-to: mcr's message of Mon, 13 Aug 2001 09:13:18 -0400.
<200108131313.f7DDDIB21122@marajade.sandelman.ottawa.on.ca>
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2
Subject: Re: Simplifying IKE
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Wed, 15 Aug 2001 01:41:22 +0900
Message-Id: <20010814164122.68A287BA@starfruit.itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>> Either way, if some packets--those with Binding Updates-- are received with
>> IPsec protection and others-- those without Binding Updates-- are not then
>> we're going to have a problem.
> If the packet has some form of authentication (I'll not prejudge by saying
>AH), and this is noted in the control structure, then the piece that
>processes the Binding Update says "okay, it was protected".
> The TCP layer (or whatever) above it didn't require that the packet was
>protected (or not), so it goes on. If the system policy required all packets
>to be authenticated, then TCP would check that.
>
> Dan McDonald? Bill Sommerfeld? Itojun?
> Does this make sense?
(not about the ipsec issue... anyway...)
The above is basically what we (itojun + Dave Johnson) thought
around 09 -> 10 mobile-ip6 spec (when we put more details on
IPsec manipulation). there were issues raised at IETF50 about policy
lookup in such cases. a point was made that there are implementations
that are not flexible enough to permit such a tweak.
now I believe that we should avoid piggybacking the binding
updates onto normal packets. if we treat them separately, we can
decide IPsec policy completely in a independent manner.
I believe it okay to use IPsec with mobile-ip6. we don't need to
invent a new authentication mechanism. another point made at IETF50
about mobile-ip6 was the lack of PKI infrastructure, which is, a
hard problem by itself and noone is going to be able ot solve this.
itojun
From owner-ipsec@lists.tislabs.com Tue Aug 14 10:47:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EHlqN22630;
Tue, 14 Aug 2001 10:47:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07820
Tue, 14 Aug 2001 13:11:09 -0400 (EDT)
Message-Id: <200108141718.f7EHISo02668@kebe.east.sun.com>
Subject: Re: Require AH?
In-Reply-To: <3B79500C.1367FCD3@storm.ca> from Sandy Harris at "Aug 14, 2001
12:21:32 pm"
To: Sandy Harris <sandy@storm.ca>
Date: Tue, 14 Aug 2001 13:18:28 -0400 (EDT)
CC: ipsec@lists.tislabs.com
From: Dan McDonald <danmcd@East.Sun.COM>
Organization: Sun Microsystems, Inc. - Solaris Internet Engineering
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> An alternative would be to require AH on all IPsec connections, giving:
>
> use none, just do normal IP
> one way to do authentication alone, AH
> one way to do encryption + authentication, AH + ESP
>
> This gets rid of that nasty fourth alternative, keeps AH for those that
> need it, and lets us drop ESP-null.
I believe this scenario was the original intent of RFCs 1825-1827. I would
have no objections to reviving this way of doing things.
> If AH is actually needed, which some people have claimed in previous
> discussions, then the last strikes me as the best choice.
>
> Of course, this was likely discussed back before authentication was
> added to ESP. Why was it rejected then?
Some HW folks didn't think you could do AH in hardware. I've heard other HW
folks (but only after the fact) say that you can indeed do AH in hardware.
ESP authentication was a knee-jerk reaction to Bellovin's analysis of
1825-1827. He stated the threats of unauthenticated CBC encryption + replay
problems. The knee-jerk reaction was to add both of these properties to ESP,
without first thinking that requiring a fixed AH with replay protection could
do the trick.
(Personally I thought that AH in hardware was not difficult, especially with
assist from the SW IPsec processing in the form of "exception vectors" that
tagged which bytes were to be treated as zero.)
Dan
From owner-ipsec@lists.tislabs.com Tue Aug 14 10:49:56 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EHntN22658;
Tue, 14 Aug 2001 10:49:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07832
Tue, 14 Aug 2001 13:13:26 -0400 (EDT)
Message-Id: <200108141718.f7EHIFu29709@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of Mon, 13 Aug 2001 09:13:18 EDT.
<200108131313.f7DDDIB21122@marajade.sandelman.ottawa.on.ca>
Date: Tue, 14 Aug 2001 19:18:15 +0200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
{Has anyone considered putting IKE message inside of a TCP option? This
doesn't help keep the session private, but if the point is to establish
keying so that a Binding Update will work, then this saves a bunch of
latency. You just can't go fix the triangle before your connection comes
up... I keep thinking that MIPv6 is the answer to multi6}
=> as the context is IPv6 I think an extension header like the destination
option header (in final position) is far better for this. But I don't
like piggybacking for heavy weight protocols (no clear pro, many cons
like ROHC confusion, complexity, SPD ambiguity, etc).
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Tue Aug 14 11:01:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EI12N22897;
Tue, 14 Aug 2001 11:01:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07808
Tue, 14 Aug 2001 13:08:30 -0400 (EDT)
Message-Id: <200108141714.f7EHEOZ00626@dharkins@lounge.orgatty.lounge.org>
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Cc: sheila.frankel@nist.gov, ipsec@lists.tislabs.com
Subject: Re: having and eating cake? agressive mode with identity hiding
In-Reply-To: Your message of "Tue, 14 Aug 2001 11:13:45 EDT."
<200108141513.LAA15508@bcn.East.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <623.997809264.1@lounge.org>
Date: Tue, 14 Aug 2001 10:14:24 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is where some deployment experience comes in handy. In real
world situations-- outside bakeoffs-- there is rarely any negotiation.
Usually both sides are already configured and prepared to speak to
each other. And in the rare cases in which they are not there are a
couple more messages to the exchange and possibly another exponentiation
in a new group, big deal. It seems better to optimize for the
99%-of-the-time case.
Dan.
On Tue, 14 Aug 2001 11:13:45 EDT you wrote
> Re: Sheila Frankel's pointing out the loss of ability to negotiate the D-H
> group.
>
> Is it that important to negotiate it rather than having Alice choose?
> If so, how many groups might Alice be willing to propose? If it's
> only a handful, then it wouldn't be tragic in the rare case where her choice
> was unacceptable to Bob for Bob to reply with "unacceptable D-H choice"
> and Alice to cycle through her choices. Or have Bob reply with his list of
> acceptable choices.
>
> Radia
>
>
>
> From: Sheila Frankel <sheila.frankel@nist.gov>
>
>
> There is one problem that arises from adopting aggressive mode as the
> single IKE
> variant. Since "g^a mod p" is sent in message 1, we lose the capability
>
> to
> negotiate the Diffie-Hellman group.
>
> Sheila Frankel
> NIST
>
>
From owner-ipsec@lists.tislabs.com Tue Aug 14 12:22:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EJM2N24763;
Tue, 14 Aug 2001 12:22:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08014
Tue, 14 Aug 2001 14:36:39 -0400 (EDT)
Date: Tue, 14 Aug 2001 10:29:58 -0700
From: Derrell Piper <ddp@cips.nokia.com>
To: Michael Thomas <mat@cisco.com>,
Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
cc: sheila.frankel@nist.gov, ipsec@lists.tislabs.com
Subject: Re: having and eating cake? agressive mode with identity hiding
Message-ID: <1799220.997784998@el-air-1.electric-loft.org>
In-Reply-To: <15225.21556.73706.140436@thomasm-u1.cisco.com>
References: <200108141513.LAA15508@bcn.East.Sun.COM>
<15225.21556.73706.140436@thomasm-u1.cisco.com>
X-Mailer: Mulberry/2.1.0b3 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Exactly!
Dan and I also met yesterday and we believe we have a four message exchange
which accomplishes this
by eliminating the first message of Main Mode (in the normal case),
reducing Phase 2 to two messages (while preserving replay protection), and
overlaying Phase 2 on top of the end of Main Mode. As you suggest, the
responder would still have the option of requiring a six message exchange
either if he did not like the opportunistic protection profile chosen by
the initiator or if he decided that he was under a possible DoS attack and
wanted to validate the cookie exchange / source peer address.
Derrell
--On Tuesday, August 14, 2001 9:39 AM -0700 Michael Thomas <mat@cisco.com>
wrote:
>
> Yes, I think that one of the optimizations that
> IKE could use is to take an optimistic approach on
> many fronts. This is, expect that what you propose
> will work (ie group 2) but allow the ability to
> reject that proposal if it's not acceptible. In
> the vast majority of cases -- assuming some
> stability in ciphersuites which seems reasonable
> at this point -- the average case will complete
> much quicker. The same can be done for DoS
> protection: if you're not under attack, sending
> the initiator off to do a return-routability test
> is fairly useless, and counterproductive. The
> protocol needs to be able support that test so
> that the recipient can defend himself if need be,
> but that should be the exceptional case.
>
> Given these two things, and then the ability to
> squish a quick mode exchange into the final cert
> exchange (using an optimistic approach too), we
> should be able to get the average initial
> main/quick mode exchange to complete in 4 or 5
> messages rather than 8 or 9.
>
> Mike
>
> Radia Perlman - Boston Center for Networking writes:
> > Re: Sheila Frankel's pointing out the loss of ability to negotiate the
> D-H > group.
> >
> > Is it that important to negotiate it rather than having Alice choose?
> > If so, how many groups might Alice be willing to propose? If it's
> > only a handful, then it wouldn't be tragic in the rare case where her
> choice > was unacceptable to Bob for Bob to reply with "unacceptable D-H
> choice" > and Alice to cycle through her choices. Or have Bob reply with
> his list of > acceptable choices.
> >
> > Radia
> >
> >
> >
> > From: Sheila Frankel <sheila.frankel@nist.gov>
> >
> >
> > There is one problem that arises from adopting aggressive mode as the
> > single IKE
> > variant. Since "g^a mod p" is sent in message 1, we lose the
> capability > to
> > negotiate the Diffie-Hellman group.
> >
> > Sheila Frankel
> > NIST
> >
> >
From owner-ipsec@lists.tislabs.com Tue Aug 14 13:53:14 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EKrEN26651;
Tue, 14 Aug 2001 13:53:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08293
Tue, 14 Aug 2001 16:05:01 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15225.34304.65698.908126@thomasm-u1.cisco.com>
Date: Tue, 14 Aug 2001 13:11:44 -0700 (PDT)
To: ipsec@lists.tislabs.com
Subject: deconstructing "simplify"
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It seems to me that it's worthwhile to come up
with a list of what "simplify" means for IPsec, as
it's pretty clear that we're not all talking about
the same thing when we tag our pet ipsec/ike
annoyance with the "simple" good housekeeping
seal approval. Here's a strawman of a taxonomy:
1) Document simplification -- lots of people would
like a easier way to read and understand the
protocols involved. Others have mentioned that
the documents are missing, vague, or misleading
about various features/modes/etc.
2) Implementation simplification -- many people
have voiced concerns that the current protocols
are either too complex implementationwise, or
provide either too many ways to implement
features, or are vague/silent as to how features
can be made interoperable.
3) Message count simplification -- many people
have expressed that the message count between
having a packet to send and sending it on a
IPsec protected SA is excessive.
4) State machine simplification -- some people
would like to see the IKE state machine far
less complicated than it currently is.
5) Option/Mode simplification -- a lot of people
have expressed an interest in reducing the
number of nobs and dials in the protocols for
both IKE and IPsec from a test-coverage
security analysis standpoint.
6) Generality simplification -- some (many?)
people would like to see IKE pay far less
attention to generality in keying than it
currently does and pay far more attention
to the kind of keying it is actually used
for, namely IPsec.
Etc. Now people can argue about the relative
ranking of these as priorities in the
simplification process, and it's pretty clear that
simplifications on one axis are going to result in
either non-simplification or complexity on another
axis, but it might be useful to keep track of what
sort of simplification we're talking about as we
start to talk about requirements.
Mike
From owner-ipsec@lists.tislabs.com Tue Aug 14 14:33:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ELXLN27762;
Tue, 14 Aug 2001 14:33:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08355
Tue, 14 Aug 2001 16:54:01 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Henry Spencer'" <henry@spsystems.net>,
"'Andrew Krywaniuk'" <andrew.krywaniuk@alcatel.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Tue, 14 Aug 2001 19:09:59 +0100
Message-Id: <000b01c12503$1514d160$0109e982@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <Pine.BSI.3.91.1010814110400.3877C-100000@spsystems.net>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> That's incorrect; "traffic analysis" is an idiom with a
> specific meaning
> in the cryptography world.
Alas, it is no longer possible to speak plain English in this technocratic
world :-)
> If the encryption scheme is vulnerable to chosen-plaintext
> attacks, it is
> already too weak to be used for protecting important data.
> Well-chosen
> encryption schemes are not vulnerable to (practical) chosen-plaintext
> attacks, and so this argument falls apart in real life.
I don't disagree with this. If you remember, this topic arose from a
previous discussion in which I was questioning the importance of having
separate SAs (i.e. keys) to protect different flows.
I merely mentioned what I felt to be the best counter-argument in order to
balance out the discussion somewhat. I agree with Scott that this attack is
certainly feasible in many environments, but we think/hope that modern
ciphers are strong enough to resist adaptive chosen plaintext attacks.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
From owner-ipsec@lists.tislabs.com Tue Aug 14 14:37:14 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ELbDN27842;
Tue, 14 Aug 2001 14:37:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08349
Tue, 14 Aug 2001 16:53:41 -0400 (EDT)
Message-ID: <20010814210053.23366.qmail@web4604.mail.yahoo.com>
Date: Tue, 14 Aug 2001 14:00:53 -0700 (PDT)
From: shiwen chen <sxc4305@yahoo.com>
Subject: VPN subnet mask
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
I am learning VPN here. Could anybody please tell me
why the subnet mask for an VPN client address is
"255.255.255.255"? Thanks a lot.
Regards,
Shiwen
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
From owner-ipsec@lists.tislabs.com Tue Aug 14 15:01:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EM14N28349;
Tue, 14 Aug 2001 15:01:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08386
Tue, 14 Aug 2001 17:14:37 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15225.38446.29432.676809@thomasm-u1.cisco.com>
Date: Tue, 14 Aug 2001 14:20:46 -0700 (PDT)
To: Henry Spencer <henry@spsystems.net>
Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>,
Hugh Daniel <hugh@road.xisp.net>, ipsec@lists.tislabs.com
Subject: RE: Wes Hardaker: opportunistic encryption deployment problems
In-Reply-To: <Pine.BSI.3.91.1010807160125.25170C-100000@spsystems.net>
References: <2F3EC696EAEED311BB2D009027C3F4F40154CA4B@vhqpostal.verisign.com>
<Pine.BSI.3.91.1010807160125.25170C-100000@spsystems.net>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Henry Spencer writes:
> On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote:
> > I would not rely on any outcome being achieved as a byproduct of
> > DNSSEC...
>
> In other words, we can't ever rely on DNS being secure? Come now.
> Admittedly, there are obstacles between here and there, but it is still
> the right solution for a number of problems.
This strikes me as saying that the only obstacle to
star travel is the speed of light...
Mike
From owner-ipsec@lists.tislabs.com Tue Aug 14 16:21:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ENLAN00334;
Tue, 14 Aug 2001 16:21:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08487
Tue, 14 Aug 2001 18:32:20 -0400 (EDT)
Message-ID: <009701c0f37d$aa484b20$c9ce1dd5@mahdavi>
From: "mahdavi" <mahdavi@sepahan.iut.ac.ir>
To: "ipsec" <ipsec@lists.tislabs.com>
Subject: implementing fully hardware version of IPSEC
Date: Wed, 13 Jun 2001 00:53:40 +0430
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0090_01C0F3A3.49B6A7E0"
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_0090_01C0F3A3.49B6A7E0
Content-Type: text/plain;
charset="windows-1256"
Content-Transfer-Encoding: quoted-printable
Hi freinds.
I am to design fully hardware version of IPSEC to gain 2.4 GBPS.=20
Now I am searching similar versions but I cant find any.=20
could you show me some line to follow up.=20
or any of you can guide me ?
any suggestion is helpful.=20
Sincerely yours=20
mahdavi=20
------=_NextPart_000_0090_01C0F3A3.49B6A7E0
Content-Type: text/html;
charset="windows-1256"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1256" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi freinds.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I am to design fully hardware version =
of IPSEC to=20
gain 2.4 GBPS. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Now I am searching similar versions but =
I cant find=20
any. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>could you show me some line to follow =
up.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>or any of you can guide me =
?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>any suggestion is helpful. =
</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Sincerely yours </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>mahdavi </FONT></DIV></BODY></HTML>
------=_NextPart_000_0090_01C0F3A3.49B6A7E0--
From owner-ipsec@lists.tislabs.com Tue Aug 14 16:23:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ENN3N00397;
Tue, 14 Aug 2001 16:23:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08496
Tue, 14 Aug 2001 18:35:52 -0400 (EDT)
Date: Tue, 14 Aug 2001 18:42:13 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Jan Vilhuber <vilhuber@cisco.com>
cc: ipsec@lists.tislabs.com
Subject: one vs. many (was Re: Simplifying IKE)
In-Reply-To: <Pine.LNX.4.21.0108091935550.5268-100000@janpc-home.cisco.com>
Message-ID: <Pine.BSI.3.91.1010814182936.11456D@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
(Slightly old mail... catching up.)
On Thu, 9 Aug 2001, Jan Vilhuber wrote:
> I say let's figure out the camps, and write a protocol that satisfies ONE of
> the camps (and later we'll write another that satisfies the other, if they
> decide there's still a need to do so).
The problem with this is that it *guarantees* that there will be no 90%
solution implemented... even if one is technically possible.
As witness the latest "having and eating cake" thread, it's imperative to
explore 90%-solution possibilities *thoroughly* -- which we have not yet
done! -- before giving up on the idea. Giving up on it, and accepting a
fragmentation of the user community, is an irrevocable step. Going from
one to two protocols, if it later becomes necessary, is much easier than
going from two to one, when the possibility later becomes obvious.
> A straw-poll should quickly show if there's a 90% that agree on something in
> this group.
What does "this group" consist of? The ones who feel motivated enough to
respond? That's not even a representative sample of the mailing list, let
alone of the IPsec user community.
> As for middle-of-the-road, I fear that it'll be so-so at everything, and not
> very good at anything at all...
Just like TCP?
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue Aug 14 16:24:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ENOWN00423;
Tue, 14 Aug 2001 16:24:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08426
Tue, 14 Aug 2001 17:44:24 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696DD@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Michael Thomas'" <mat@cisco.com>, Henry Spencer <henry@spsystems.net>
Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>,
Hugh Daniel
<hugh@road.xisp.net>, ipsec@lists.tislabs.com
Subject: RE: Wes Hardaker: opportunistic encryption deployment problems
Date: Tue, 14 Aug 2001 14:49:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C1250B.06A5ED50"
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_000_01C1250B.06A5ED50
Content-Type: text/plain;
charset="iso-8859-1"
> Henry Spencer writes:
> > On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote:
> > > I would not rely on any outcome being achieved as a byproduct of
> > > DNSSEC...
> >
> > In other words, we can't ever rely on DNS being secure? Come now.
> > Admittedly, there are obstacles between here and there,
> but it is still
> > the right solution for a number of problems.
>
> This strikes me as saying that the only obstacle to
> star travel is the speed of light...
>
> Mike
Not quite, light manages to travel from A to B independent of our
requirement for interstellar travel.
Unfortunately the requirement that people be able to use DNSSEC
as the solution to all the worlds security problems has led to a
significant and serious increase in the complexity, deployment
cost and overhead of DNSSEC.
Phill
------_=_NextPart_000_01C1250B.06A5ED50
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C1250B.06A5ED50--
From owner-ipsec@lists.tislabs.com Tue Aug 14 18:31:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1VdN03889;
Tue, 14 Aug 2001 18:31:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08776
Tue, 14 Aug 2001 20:50:27 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010412b79f6f03ed2a@[128.33.238.92]>
In-Reply-To:
<2F3EC696EAEED311BB2D009027C3F4F40154CA51@vhqpostal.verisign.com>
References:
<2F3EC696EAEED311BB2D009027C3F4F40154CA51@vhqpostal.verisign.com>
Date: Tue, 14 Aug 2001 20:14:32 -0400
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: IKE must have no Heirs
Cc: "'Dan Harkins'" <dharkins@lounge.org>, Alex Alten <Alten@home.com>,
Kory Hamzeh <kory@avatar.com>,
"Hallam-Baker, Phillip" <pbaker@verisign.com>,
"'mcnelson@mindspring.com'" <mcnelson@mindspring.com>,
ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 8:56 AM -0700 8/7/01, Hallam-Baker, Phillip wrote:
>Dan,
>
>It has been somewhat difficult for anyone in the IETF security area in the
>past dacade not to become familliar with the internal machinations of the
>IPSEC group.
>
>I would like something no more complex than SKIP that used RSA or DSA.
>
>In 1995 SKIP would have been the right move. At this point to go forward
>there has to at least be compatibility with the keying material that is
>already distributed.
SKIP was a poor choice for any long-lived SA, because SKIP forced
every packet to carry SA state information in lieu of exchanging SA
establishment messages.
Steve
From owner-ipsec@lists.tislabs.com Tue Aug 14 18:35:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1ZPN03990;
Tue, 14 Aug 2001 18:35:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08759
Tue, 14 Aug 2001 20:50:13 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p0501040fb79f65edca8d@[128.33.238.92]>
In-Reply-To: <003901c1249d$86b1a8e0$0300000a@bilbo>
References: <003901c1249d$86b1a8e0$0300000a@bilbo>
Date: Tue, 14 Aug 2001 19:36:29 -0400
To: "Sara Bitan" <sarab@cs.Technion.AC.IL>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Traffic handling and key management "divide and coquer"
Cc: <ipsec@lists.tislabs.com>
Content-Type: multipart/alternative; boundary="============_-1214285465==_ma============"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--============_-1214285465==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sara,
i think your suggestion is a reasonable one. We should realize that
before we separate the AH/ESP work from key management, we need to
establish a clearer set of requirements of what these protocols
require in the way of SA management, separate from key management.
we have yet to do that.
Steve
--============_-1214285465==_ma============
Content-Type: text/html; charset="us-ascii"
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
--></style><title>Re: Traffic handling and key management
"divide and co</title></head><body>
<div>Sara,</div>
<div><br></div>
<div>i think your suggestion is a reasonable one. We should realize
that before we separate the AH/ESP work from key management, we need
to establish a clearer set of requirements of what these protocols
require in the way of<u> SA</u> management, separate from<u> key</u>
management. we have yet to do that.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1214285465==_ma============--
From owner-ipsec@lists.tislabs.com Tue Aug 14 18:35:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1ZPN03991;
Tue, 14 Aug 2001 18:35:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08753
Tue, 14 Aug 2001 20:49:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p0501040ab79f5c4c8768@[128.33.238.92]>
In-Reply-To: <3B709706.4D051BE5@storm.ca>
References: <3B709706.4D051BE5@storm.ca>
Date: Tue, 14 Aug 2001 19:03:36 -0400
To: Sandy Harris <sandy@storm.ca>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Simplifying IKE
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 9:33 PM -0400 8/7/01, Sandy Harris wrote:
>The Leech, Schiller and Bellovin (LSB?) document mentions:
>
>> the goal: to produce a more secure, simpler, and more robust version of IKE.
>
>I thought it might be useful to inventory some proposed simplifications. Of
>course I'll toss in my own opinions while I'm at it, but my goal is less to
>get them accepted than to provoke discussion.
>
>>From the Schneier and Ferguson analysis we get:
>
>> 1: eliminate transport mode
>
>It would be possible to eliminate tunnel mode instead, and just use IP-in-IP
>over transport where required, but it seems simpler to treat transport as a
>degenerate tunnel instead. Either mode can do everything we need, so we need
>only one mode. My vote is for tunnel.
the two modes are not interchangeable, as discussed in my rebuttal to
the paper in question, a year ago. we have advocates for both, and
neither group of advocates, so far, has been willing to give up its
favorite features for the other. the simplest change would be to give
up transport, since tunnel mode can emulate transport, but one incurs
added overhead as a result. also, we now have other protocols, most
notably L2TP, specifying use of transport mode in their RFCs.
>
>> 2. eliminate the AH protocol
>> 3. modify ESP to always authenticate; only encryption should be
> optional
>
>Fine by me, but I vaguely recall some arguments that IPv6 and/or mobile
>IP actually need AH. Could anyone who needs it speak up again?
I'm sure you will hear from those folks.
>
>If it turns out there are really good reasons to keep AH, then I'd say the
>simplification is:
>
>2a: eliminate ESP authentication
are you suggesting removing the authentication option from ESP? ESP
with null encryption is more efficient than AH in most cases, and if
one needs both encryption and authentication, the combined mode use
of ESP is much more efficient. this suggests that this suggestion is
not very attractive.
>3a: require AH on all packets. No choice, no null mode. An IPsec connection
> authenticates all packets, period.
see comments above as to why this is not a great idea.
>
>> 4. modify ESP to ensure it authenticates all data used in the deciphering
> of the payload
>
>This is the only recommendation in this paper based on a direct security
>flaw, with a proposed attack to demonstrate it. There are others in the
>Simpson paper.
the proposed attack is based on assumptions about independent keying
for AH and ESP (with null auth). IKE won't do this and it is not
clear that anyone has ever done this via manual key management. it's
easy to warn against this, and retain the option for encrypt-only
ESP, which has potential efficiency benefits for situations where
upper layer protocols already provide authentication.
I'll leave comments on your IKE suggestions to others. Note that
since IKE is not the only key management protocol, e.g., KINK will be
available at some point too, changes to supported ESP/AH modes are
not really within scope for a "simplify IKE" discussion.
Steve
From owner-ipsec@lists.tislabs.com Tue Aug 14 18:37:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1boN04035;
Tue, 14 Aug 2001 18:37:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08770
Tue, 14 Aug 2001 20:50:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p0501040bb79f5ee8245c@[128.33.238.92]>
In-Reply-To:
<F86F34FDF1F9D411B7A40008C74C27B8028A29@hhdata3.cdsemea.baltimore.com>
References:
<F86F34FDF1F9D411B7A40008C74C27B8028A29@hhdata3.cdsemea.baltimore.com>
Date: Tue, 14 Aug 2001 19:09:04 -0400
To: Chris Trobridge <CTrobridge@baltimore.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Simplifying IKE
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 7:59 AM +0100 8/8/01, Chris Trobridge wrote:
>I have to admit I started in the "keep tunnelling - los transport" camp, but
>with more experience I would definitely prefer transport mode + IP-in-IP.
>This makes gateways and end-to-end cases identical. It also separates
>routing issues associated with tunnelling from IPSEC.
remember that a major difference between tunnel and transport modes
is what headers are examined for access control purposes. if one
changes to IP-in-IP tunneling above IPsec, it would be important to
retain this security facility, which means we still need to know
where to look in the stack, ...
>I'd also like to see all IPSEC traffic between two hosts carried by just one
>SA. I can't see any value in using multiple SAs between to hosts. IPSEC
>should be just providing a secure pipe between two hosts - what goes through
>it is better regulated by a firewall. There is an argument that you might
>want to use different strengths of crypto for performance reasons but there
>is generally a focus on performing one type of encryption really well rather
>than supporting multiple types.
IPsec is not designed to be just an encryption protocol. It provides
access control comparable to that of a static, packet filtering
firewall, but with per-SA authentication that a firewall, if placed
behind an IPsec device, cannot provide.
>
>I'm less keen on AH and would lose it if at all possible. Authenticated ESP
>provides authentication, integrity and anti-replay of the IP payload - what
>do you care if the IP header has been tampered with? (what is missing from
>ESP auth - just the destination IP address?). Per-hop use of SAs currently
>appears limited as keys are typically only shared by the end-points.
>
>I would like to see things like null encryption and specific algorithms not
>being MUST (or even plaintext bypass). My main reason for this is that you
>can reject these by policy anyway but that exclusion from build is required
>for products that go through tough security evaluations.
Null encryption and null authentication are artifices, because IKE
had allocated two slots for algorithms for ESP, before we allowed
modular security service use. One could do away with these
conventions in a reengineered IKE.
Steve
From owner-ipsec@lists.tislabs.com Tue Aug 14 18:37:55 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1bsN04047;
Tue, 14 Aug 2001 18:37:54 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08771
Tue, 14 Aug 2001 20:50:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p0501040cb79f60aa8e26@[128.33.238.92]>
In-Reply-To:
<2F3EC696EAEED311BB2D009027C3F4F40154CA5B@vhqpostal.verisign.com>
References:
<2F3EC696EAEED311BB2D009027C3F4F40154CA5B@vhqpostal.verisign.com>
Date: Tue, 14 Aug 2001 19:15:28 -0400
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Simplifying IKE
Cc: "'Steve.Robinson@psti.com'" <Steve.Robinson@psti.com>,
Sandy Harris <sandy@storm.ca>, ipsec@lists.tislabs.com,
owner-ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 7:41 AM -0700 8/8/01, Hallam-Baker, Phillip wrote:
> > STEVE: I agree with you on this, but in practice, unless a
>> PKI standard is
>> settled on, my boss is not going to approve of me implementing a
>> proprietary solution unless a consensus is reached in the
>> IPsec community
>> first. My gut feeling is that it isn't gonna happen unless
>> the work at the
>> NIST on PKI suddenly becomes accepted as a standard.
>
>Why not simply plug into XKMS?
>
>All IPSEC cares about is the delivery of authenticated, validated
>keys. It should not need to know if the PKI is based on X509/PKIX,
>PGP, SPKI or YAPKI.
>
IPsec cares about IDs bound to keys used for authentication. to the
extent that different PKI technologies support different name forms,
IPsec needs to be aware of this, as it affects the types of symbolic
names we support in the SPD.
A recommendation for simplification I have not yet seen is to reduce
the range of cert types that IKE supports. Everyone who does certs
probably supports X.509. Few products support PGP, SPKI, or DNSSEC,
despite these being mentioned in IKE. this would seem like an easy
simplification.
Steve
P.S. Please, Phil, no more XKMS advertisements here, OK?
From owner-ipsec@lists.tislabs.com Tue Aug 14 20:34:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F3YbN06169;
Tue, 14 Aug 2001 20:34:37 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA08994
Tue, 14 Aug 2001 22:47:00 -0400 (EDT)
From: "Lars Eggert" <larse@ISI.EDU>
To: "Stephen Kent" <kent@bbn.com>,
"Chris Trobridge" <CTrobridge@baltimore.com>, <xbone@ISI.EDU>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Tue, 14 Aug 2001 19:53:28 -0800
Message-ID: <PCELJJEJJMODEMKEBLLBKEADCAAA.larse@isi.edu>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <p0501040bb79f5ee8245c@[128.33.238.92]>
Content-Type: multipart/signed;
protocol="application/x-pkcs7-signature";
micalg=SHA1;
boundary="----=_NextPart_000_0002_01C124FA.C96C0C90"
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0002_01C124FA.C96C0C90
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
> At 7:59 AM +0100 8/8/01, Chris Trobridge wrote:
> >I have to admit I started in the "keep tunnelling - los
> transport" camp, but
> >with more experience I would definitely prefer transport mode +
IP-in-IP.
> >This makes gateways and end-to-end cases identical. It also separates
> >routing issues associated with tunnelling from IPSEC.
>
> remember that a major difference between tunnel and transport modes
> is what headers are examined for access control purposes. if one
> changes to IP-in-IP tunneling above IPsec, it would be important to
> retain this security facility, which means we still need to know
> where to look in the stack, ...
Yes, transport mode over IPIP tunnels (IIPtran) must conform to RFC2401,
section 5.2.1. And we think it can/does - from
draft-touch-ipsec-vpn-01.txt:
The primary difference is in the subsequent processing of the
incoming packet. IPsec tunnel mode does not require a separate rule
for accepting packets with the inner header; once they are accepted
during the unwrap phase, they are accepted. IIPtran requires that
unwrapped packets be further processed by an additional round, which
requires that incoming packets with these headers be accepted. As
noted in [1], IPsec processing should retain SA use for subsequent
IPsec or firewall processing. It should be possible for these
incoming packets to be IPIP decapsulated _only_ where the appropriate
SA has been used, but as a separate step.
The main difference between the two approaches is during outbound
processing: With IPsec tunnel mode, the SA determines routing (the inner
header determines the SA which prepends the outer header), while with
transport mode over IPIP, routing determines the SA (encapsulation comes
first, the SA is then determined by the outer header).
This seems like a small enough difference; however, the implications reach
far. One example is that unmodified routing algorithms work inside IIPtran
overlay networks. Another is that IIPtran decouples overlay topology from
security: Deploying IPIP tunnels without IPsec yields an insecure overlay;
IPsec can simply be turned on for existing overlay topologies by
establishing SAs.
In a nutshell, IIPtran constructs a "virtual Internet" using IPIP tunnels
(and supports most protocols/applications inside it without
modifications); and secures links in the "virtual Internet" with
transport-mode IPsec.
We are preparing an update to draft-touch-ipsec-vpn-01.txt to address
further implications of IIPtran that have been encountered recently (such
as IKE interactions, found during the KAME implementation of the ID by
Itojun-san).
Lars
--
Lars Eggert <larse@isi.edu> Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
------=_NextPart_000_0002_01C124FA.C96C0C90
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF9DCCAtgw
ggJBoAMCAQICAwMjBTANBgkqhkiG9w0BAQQFADCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE
CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAx
OTk5LjkuMTYwHhcNMDAwODI0MjAzMDA4WhcNMDEwODI0MjAzMDA4WjBUMQ8wDQYDVQQEEwZFZ2dl
cnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MRwwGgYJKoZIhvcNAQkBFg1s
YXJzZUBpc2kuZWR1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPXJ9w2zneu+G7DyBIO+vb
7+yc/wZ25hjvHtaQl3K9zBviiKk2lZgiQwY/bXhm/UquC+e0Zob6N66AAZC3SfrhW6yBwjNDpANG
2cyB1ANMCRVJDZ4tFJCRr6cA/HpIUomDv1YQQeaApAEy1l0wFi1i/+ZM5ymbuNMlWD7tbqfThQID
AQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMBgGA1Ud
EQQRMA+BDWxhcnNlQGlzaS5lZHUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY
x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQCLrl8z+NIJo+FGgD0lblfYWS1IWETnOQikVU+m
/fcZY882udywrXcd9mazQHWs3La9TtSEUj++wlCAEnJ9+QsWAwKOne5Fm8EGMYPWrjKMM7nJ8wyO
q6oGlm1GnmineVN3TV9oDnxkIHmzEJvQ5FLG9dHy1z0Mk7QkilAgtrq8gDCCAxQwggJ9oAMCAQIC
AQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsT
H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv
bTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQswCQYDVQQGEwJaQTEVMBMGA1UE
CBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0w
GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGc
I3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc
9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8C
AwEAAaM3MDUwEgYDVR0TAQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH
58ayDjANBgkqhkiG9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKl
N9idtxcoVgWL3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLk
XJeu/H6syg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAswwggLIAgEBMIGcMIGUMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAyMFMAkGBSsOAwIaBQCgggGFMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDgxNTAzNTMyOFowIwYJKoZI
hvcNAQkEMRYEFJBJvRNnvVG4gAg99NKwSi9EYnSUMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO
AwIaMAcGBSsOAwIaMAoGCCqGSIb3DQIFMAoGCCqGSIb3DQIFMIGtBgkrBgEEAYI3EAQxgZ8wgZww
gZQxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZp
bGxlMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2AgMDIwUwDQYJKoZIhvcNAQEBBQAE
gYBKKil71p/7C7hiv1DRKShfwuYmguWLOkuQcRe86+UhefYX0zoOxqB+q0p8N3hGx/sFSuIo5A+L
JUjl1+67KlQXexY3fapFR9/InyTvY5Pjf0gdidA7lXPLf/E6NyS/PSjexlQ3XrHGBPx6gzEVgX94
KuKTxZtSdJtT7DmTjjFsrwAAAAAAAA==
------=_NextPart_000_0002_01C124FA.C96C0C90--
From owner-ipsec@lists.tislabs.com Tue Aug 14 23:30:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F6U7N15726;
Tue, 14 Aug 2001 23:30:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA09180
Wed, 15 Aug 2001 01:06:55 -0400 (EDT)
Date: Wed, 15 Aug 2001 01:13:26 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: IP Security List <ipsec@lists.tislabs.com>
Subject: Re: having and eating cake? agressive mode with identity hiding
In-Reply-To: <200108141213.IAA13485@bcn.East.Sun.COM>
Message-ID: <Pine.BSI.3.91.1010815011020.16492J-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 14 Aug 2001, Radia Perlman - Boston Center for Networking wrote:
> It would be nice to have a single IKE protocol. Perhaps this slightly
> modified aggressive mode/identity hiding/public signature keys would
> be a good choice.
Sounds good to me... especially if it has the option of including the
start of an IPsec-SA negotiation in message 3.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Wed Aug 15 00:42:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F7gCN26425;
Wed, 15 Aug 2001 00:42:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA09311
Wed, 15 Aug 2001 02:43:15 -0400 (EDT)
Message-ID: <3B7A1BA8.B59B4DE3@F-Secure.com>
Date: Wed, 15 Aug 2001 09:50:16 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
CC: ipsec@lists.tislabs.com
Subject: Re: having and eating cake? agressive mode with identity hiding
References: <200108141213.IAA13485@bcn.East.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Radia Perlman - Boston Center for Networking wrote:
>
> After the IPsec meeting, some people mentioned to me that if we'd
> get rid of one mode, they'd prefer getting rid of main mode and
> keeping aggressive mode.
>
> As it turns out, in the paper from which the internet draft presented
> at the meeting was based:
> http://sec.femto.org/wetice-2001/papers/radia-paper.pdf
> it mentions that we can get identity hiding with the public signature key
> variant.
>
> It would be nice to have a single IKE protocol. Perhaps this slightly
> modified aggressive mode/identity hiding/public signature keys would
> be a good choice.
>
This protocol looks good on identity hiding point of view, but the
main 'practical' benefit of AM is that the identity is sent on
message one, allowing the responder to select the proper policy
based on reception of the first message.
Ari
> The basic idea is:
>
> message 1:
> Alice--->Bob
> g^a mod p
>
> message 2:
> Bob---->Alice
> g^b mod p, {"Bob", proof I'm Bob} encrypted with g^ab mod p
> ;the proof he's Bob consists of a signature on messages 1 and 2, e.g.
>
> message 3:
> Alice---->Bob
> {"Alice", proof I'm Alice}g^ab mod p
>
>
> I might want to add the OAKLEY-style trick where Bob can respond in message
> 2 with "I am going to want a stateless cookie, so try again, but this
> time send cookie c" That way if Bob isn't under attack, he can do the 3 message
> exchange, and if he is, he responds to cookie-less message 1's with a cookie,
> and responds to valid cookie-containing message 2's with the rest
> of the protocol.
>
> Radia
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
From owner-ipsec@lists.tislabs.com Wed Aug 15 04:38:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FBchN15552;
Wed, 15 Aug 2001 04:38:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA09741
Wed, 15 Aug 2001 06:37:07 -0400 (EDT)
Message-ID: <9D048F4A422CD411A56500B0D0209C5B02861C0A@NS-CA>
From: Jay Ratford <Jratford@netscreen.com>
To: "'shiwen chen '" <sxc4305@yahoo.com>,
"'ipsec@lists.tislabs.com '"
<ipsec@lists.tislabs.com>
Subject: RE: VPN subnet mask
Date: Wed, 15 Aug 2001 03:43:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The 32bit mask designated an "individual host" which is why it is specified
in Phase II proxied IDs
-----Original Message-----
From: shiwen chen
To: ipsec@lists.tislabs.com
Sent: 8/14/01 2:00 PM
Subject: VPN subnet mask
Hi,
I am learning VPN here. Could anybody please tell me
why the subnet mask for an VPN client address is
"255.255.255.255"? Thanks a lot.
Regards,
Shiwen
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
From owner-ipsec@lists.tislabs.com Wed Aug 15 06:01:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FD1GN19198;
Wed, 15 Aug 2001 06:01:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09868
Wed, 15 Aug 2001 08:13:25 -0400 (EDT)
Message-ID: <20010815122039.5960.qmail@web4604.mail.yahoo.com>
Date: Wed, 15 Aug 2001 05:20:39 -0700 (PDT)
From: shiwen chen <sxc4305@yahoo.com>
Subject: RE: VPN subnet mask
To: Christopher Gripp <cgripp@axcelerant.com>, ipsec@lists.tislabs.com
Cc: vpn@secruityfocus.com
In-Reply-To: <4EBB5C35607E7F48B4AE162D956666EF339182@guam.corp.axcelerant.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Thanks a lot.
I have seen three vendors' VPNs are using this
255.255.255.255 mask (including IPSec, PPTP). Remote
clients are run with Microsoft Windows 2000. So I
think it is quite a conventional way (if not standard)
for VPN configurations, isn't it?.
Suppose I have an application on remote access client,
can I use this information to detect if the local
computer is on VPN or not?
Regards,
Shiwen
--- Christopher Gripp <cgripp@axcelerant.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> That's used to explicitily define that single host.
> Without other
> info I can't tell you why it is configured that way
> on your VPN.
> What VPN are you using? What OS are you running,
> etc.
>
> Christopher S. Gripp
> Systems Engineer
> Axcelerant
>
>
> - -----Original Message-----
> From: shiwen chen [mailto:sxc4305@yahoo.com]
> Sent: Tuesday, August 14, 2001 2:01 PM
> To: ipsec@lists.tislabs.com
> Subject: VPN subnet mask
>
>
> Hi,
> I am learning VPN here. Could anybody please tell me
> why the subnet mask for an VPN client address is
> "255.255.255.255"? Thanks a lot.
>
> Regards,
> Shiwen
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute
> with Yahoo!
> Messenger
> http://phonecard.yahoo.com/
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use
> <http://www.pgp.com>
>
>
iQA/AwUBO3mu/2LRPLnfp/zREQJZrwCg/uLeFpKIdgqwSbcm9AGX20aLKPEAoJMb
> ardg+mhUBOjrnDDB5qCpfey7
> =Y3K0
> -----END PGP SIGNATURE-----
>
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
From owner-ipsec@lists.tislabs.com Wed Aug 15 06:12:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FDC9N19602;
Wed, 15 Aug 2001 06:12:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09882
Wed, 15 Aug 2001 08:21:07 -0400 (EDT)
Date: Wed, 15 Aug 2001 11:26:38 +0200
From: Pawel Krawczyk <kravietz@aba.krakow.pl>
To: ipsec@lists.tislabs.com
Subject: key derived SPI?
Message-ID: <20010815112638.C2291@aba.krakow.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.20i
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Is there anything wrong with deriving IPSec SA data like SPI from the
keying material, using one way hash? I thinking of reducing number of
parameters needed to automatically setup an IPSec SA between two hosts
without IKE. Using this trick I could end up with only password and
destination IP address needed to setup the secure channel. So the final
SPI generation scheme would be:
h0 = SHA1(source IP) [public]
h1 = SHA1(destination IP) [public]
h2 = SHA1(provided password) [secret]
h3 = SHA1(h2)
h4 = SHA1(h3)
SPI = h0 XOR h1 XOR h4
enc key = h2
auth key = h3
Result SA = ESP(SPI, src IP, dst IP, enc key, auth key)
So I use h2 as ESP encryption key, h3 as authentication key and generated
SPI to build the ESP SA. This SA is used to send small amount of data
and its lifetime is short. Use of h3 for auth is not to provide any
possible information about encryption key with authentication ciphertext.
The IP addresses are hashed only to minimize chance of SPI conflict
with many clients.
Is there any problem with this method?
--
Pawe„ Krawczyk *** home: <http://ceti.pl/~kravietz/>
security: <http://ipsec.pl/> *** fidonet: 2:486/23
From owner-ipsec@lists.tislabs.com Wed Aug 15 07:29:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FETfN21970;
Wed, 15 Aug 2001 07:29:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10134
Wed, 15 Aug 2001 09:47:34 -0400 (EDT)
Message-ID: <80B684C5E29FD211AA8000A0C9CDD9190925B301@il0015exch005u.ih.lucent.com>
From: "Kopeikin, Roy A (Roy)" <rkopeikin@lucent.com>
To: Derrell Piper <ddp@cips.nokia.com>, Michael Thomas <mat@cisco.com>,
Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Cc: sheila.frankel@nist.gov, ipsec@lists.tislabs.com
Subject: RE: having and eating cake? agressive mode with identity hiding
Date: Wed, 15 Aug 2001 08:54:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Derrell, what do you think it is going to take to get something like this
approved? This sounds like a good combination towards simplifying.
Roy
-----Original Message-----
From: Derrell Piper [mailto:ddp@cips.nokia.com]
Sent: Tuesday, August 14, 2001 12:30 PM
To: Michael Thomas; Radia Perlman - Boston Center for Networking
Cc: sheila.frankel@nist.gov; ipsec@lists.tislabs.com
Subject: Re: having and eating cake? agressive mode with identity hiding
Exactly!
Dan and I also met yesterday and we believe we have a four message exchange
which accomplishes this
by eliminating the first message of Main Mode (in the normal case),
reducing Phase 2 to two messages (while preserving replay protection), and
overlaying Phase 2 on top of the end of Main Mode. As you suggest, the
responder would still have the option of requiring a six message exchange
either if he did not like the opportunistic protection profile chosen by
the initiator or if he decided that he was under a possible DoS attack and
wanted to validate the cookie exchange / source peer address.
Derrell
--On Tuesday, August 14, 2001 9:39 AM -0700 Michael Thomas <mat@cisco.com>
wrote:
>
> Yes, I think that one of the optimizations that
> IKE could use is to take an optimistic approach on
> many fronts. This is, expect that what you propose
> will work (ie group 2) but allow the ability to
> reject that proposal if it's not acceptible. In
> the vast majority of cases -- assuming some
> stability in ciphersuites which seems reasonable
> at this point -- the average case will complete
> much quicker. The same can be done for DoS
> protection: if you're not under attack, sending
> the initiator off to do a return-routability test
> is fairly useless, and counterproductive. The
> protocol needs to be able support that test so
> that the recipient can defend himself if need be,
> but that should be the exceptional case.
>
> Given these two things, and then the ability to
> squish a quick mode exchange into the final cert
> exchange (using an optimistic approach too), we
> should be able to get the average initial
> main/quick mode exchange to complete in 4 or 5
> messages rather than 8 or 9.
>
> Mike
>
> Radia Perlman - Boston Center for Networking writes:
> > Re: Sheila Frankel's pointing out the loss of ability to negotiate the
> D-H > group.
> >
> > Is it that important to negotiate it rather than having Alice choose?
> > If so, how many groups might Alice be willing to propose? If it's
> > only a handful, then it wouldn't be tragic in the rare case where her
> choice > was unacceptable to Bob for Bob to reply with "unacceptable D-H
> choice" > and Alice to cycle through her choices. Or have Bob reply with
> his list of > acceptable choices.
> >
> > Radia
> >
> >
> >
> > From: Sheila Frankel <sheila.frankel@nist.gov>
> >
> >
> > There is one problem that arises from adopting aggressive mode as
the
> > single IKE
> > variant. Since "g^a mod p" is sent in message 1, we lose the
> capability > to
> > negotiate the Diffie-Hellman group.
> >
> > Sheila Frankel
> > NIST
> >
> >
From owner-ipsec@lists.tislabs.com Wed Aug 15 08:19:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FFJcN23980;
Wed, 15 Aug 2001 08:19:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10247
Wed, 15 Aug 2001 10:37:39 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15226.35517.701351.186328@thomasm-u1.cisco.com>
Date: Wed, 15 Aug 2001 07:44:13 -0700 (PDT)
To: Dan McDonald <danmcd@East.Sun.COM>
Cc: Sandy Harris <sandy@storm.ca>, ipsec@lists.tislabs.com
Subject: Re: Require AH?
In-Reply-To: <200108141718.f7EHISo02668@kebe.east.sun.com>
References: <3B79500C.1367FCD3@storm.ca>
<200108141718.f7EHISo02668@kebe.east.sun.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dan McDonald writes:
> Some HW folks didn't think you could do AH in hardware. I've heard other HW
> folks (but only after the fact) say that you can indeed do AH in hardware.
I have great confidence that hardware guys can
do just about anything you set them out to do.
It's only the final transistor count that tells
you whether it is worth the effort.
> ESP authentication was a knee-jerk reaction to Bellovin's analysis of
> 1825-1827. He stated the threats of unauthenticated CBC encryption + replay
> problems. The knee-jerk reaction was to add both of these properties to ESP,
> without first thinking that requiring a fixed AH with replay protection could
> do the trick.
Actually, what would make me most happy would be to
have a single IPsec extension header which does
*everything*. This helps on the code/message
compactness front, as well as simplifying the
number of SADB entries, different protocols
handling, header traversal, etc. It seems to me
that if we had modes like gzip-aes-cbc-sha1 for
ESP transforms, we could get rid of both AH and
IPCOMP.
Mike
From owner-ipsec@lists.tislabs.com Wed Aug 15 08:48:59 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FFmxN27240;
Wed, 15 Aug 2001 08:48:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10265
Wed, 15 Aug 2001 10:53:27 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696DE@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Stephen Kent'" <kent@bbn.com>,
"Hallam-Baker, Phillip"
<pbaker@verisign.com>
Cc: "'Steve.Robinson@psti.com'" <Steve.Robinson@psti.com>,
Sandy Harris
<sandy@storm.ca>, ipsec@lists.tislabs.com,
owner-ipsec@lists.tislabs.com
Subject: XKMS and NIH RE: Simplifying IKE
Date: Wed, 15 Aug 2001 07:59:57 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C1259A.F2F61790"
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_000_01C1259A.F2F61790
Content-Type: text/plain;
charset="iso-8859-1"
Steve,
You entirely manage to miss the point. You agree that part of the
complexity of IPSEC is that it is required to interface to every PKI in the
universe for political reasons. Then you make the statesmanlike suggestion
that the world standardize on the specification of the working group you
have been chairing. It may well make good technical sense. Perhaps you would
like to lend your support to Neil Kinnock's proposal to make English the
sole administrative language of the European Union whil you are at it?
As for 'advertising' the work product of another open standards
working group that is appropriate to a working group topic, has substantial
commitments from the major PKI vendors, major application vendors and major
customers - I will do it at every opportunity thank you very much, whether
the specification is one of my own invention or of somebody else.
It was the first time that I had raised XKMS on the IPSEC list. It
was not off topic, it was in fact entirely on topic. I don't think that the
majority of the IETF would agree that Not Invented Here is a good policy.
Plenty of IETF working groups make use of the work product of other working
groups outside the IETF, BEEP makes use of a W3C specification, PKIX makes
use of an ITU standard.
Perhaps you could elaborate the reasons why you do not consider XKMS
to be a suitable topic for consideration by IPSEC?
XKMS is designed to allow simplification of client implementation of
PKI. The topic on the table is simplification of IPSEC.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Tuesday, August 14, 2001 7:15 PM
> To: Hallam-Baker, Phillip
> Cc: 'Steve.Robinson@psti.com'; Sandy Harris; ipsec@lists.tislabs.com;
> owner-ipsec@lists.tislabs.com
> Subject: RE: Simplifying IKE
>
>
> At 7:41 AM -0700 8/8/01, Hallam-Baker, Phillip wrote:
> > > STEVE: I agree with you on this, but in practice, unless a
> >> PKI standard is
> >> settled on, my boss is not going to approve of me implementing a
> >> proprietary solution unless a consensus is reached in the
> >> IPsec community
> >> first. My gut feeling is that it isn't gonna happen unless
> >> the work at the
> >> NIST on PKI suddenly becomes accepted as a standard.
> >
> >Why not simply plug into XKMS?
> >
> >All IPSEC cares about is the delivery of authenticated, validated
> >keys. It should not need to know if the PKI is based on X509/PKIX,
> >PGP, SPKI or YAPKI.
> >
> IPsec cares about IDs bound to keys used for authentication. to the
> extent that different PKI technologies support different name forms,
> IPsec needs to be aware of this, as it affects the types of symbolic
> names we support in the SPD.
>
> A recommendation for simplification I have not yet seen is to reduce
> the range of cert types that IKE supports. Everyone who does certs
> probably supports X.509. Few products support PGP, SPKI, or DNSSEC,
> despite these being mentioned in IKE. this would seem like an easy
> simplification.
>
> Steve
>
> P.S. Please, Phil, no more XKMS advertisements here, OK?
>
------_=_NextPart_000_01C1259A.F2F61790
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C1259A.F2F61790--
From owner-ipsec@lists.tislabs.com Wed Aug 15 08:50:19 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FFoIN27409;
Wed, 15 Aug 2001 08:50:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10307
Wed, 15 Aug 2001 11:16:00 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696DF@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Stephen Kent'" <kent@bbn.com>,
"Hallam-Baker, Phillip"
<pbaker@verisign.com>
Cc: "'Dan Harkins'" <dharkins@lounge.org>, Alex Alten <Alten@home.com>,
Kory Hamzeh <kory@avatar.com>,
"Hallam-Baker, Phillip"
<pbaker@verisign.com>,
"'mcnelson@mindspring.com'"
<mcnelson@mindspring.com>,
ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
Date: Wed, 15 Aug 2001 08:20:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C1259D.C7A1D6D0"
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_000_01C1259D.C7A1D6D0
Content-Type: text/plain;
charset="iso-8859-1"
> SKIP was a poor choice for any long-lived SA, because SKIP forced
> every packet to carry SA state information in lieu of exchanging SA
> establishment messages.
I see no reason why that specific problem could not have been fixed.
If you have a securely established shared secret that is securely bound
to a shared context there should be no per packet state requirement.
Phill
------_=_NextPart_000_01C1259D.C7A1D6D0
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C1259D.C7A1D6D0--
From owner-ipsec@lists.tislabs.com Wed Aug 15 09:01:23 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FG1NN29270;
Wed, 15 Aug 2001 09:01:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10320
Wed, 15 Aug 2001 11:17:57 -0400 (EDT)
Date: Wed, 15 Aug 2001 11:24:24 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Michael Thomas <mat@cisco.com>
cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
In-Reply-To: <15221.37384.191416.901953@thomasm-u1.cisco.com>
Message-ID: <Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Sat, 11 Aug 2001, Michael Thomas wrote:
> > > [anonymous encryption]
> > We thought about that, but decided that some authentication was better
> > than none, especially since it would upgrade transparently...
>
> Well... How is this especially different than just
> using self-signed certificates and having a wide open policy?
The transparent upgrade to full security is important. As I said before,
there's an important difference between temporary and permanent security
holes. The nice thing about having DNSSEC verify the provenance of the
public keys is that instituting this requires no changes to the protocol
*or the protocol software*. Going from self-signed certificates to a
certificate signing chain would.
Before too very long, it *will* be necessary to secure DNS, whether that
is done by the current DNSSEC or by other means. Why duplicate that work
in each application?
> I guess what bothers me is that you are expecting to
> use DNS as a directory service for certs which it
> wasn't really intended for...
What was DNS "really intended for"? RFC 1034 (emphasis added):
- The costs of implementing such a facility dictate that it be
generally useful, and not restricted to a single application.
We should be able to use names to retrieve host addresses,
mailbox data, ***and other as yet undetermined information***.
DNS is for retrieving information about names. Using it to obtain public
keys or certificates (please distinguish between the two, they are not
synonymous) for names seems perfectly reasonable. Which is why DNS now
has KEY and CERT records.
> ...thus making an already
> complicated situation even more complicated, but
> not changing the fundamental situation (PKI are hard).
I tend to think that today's PKI are harder than necessary, partly because
they are trying to reinvent the DNS wheel and doing it badly. As with the
messes that arise in application-level encryption, much of this is
spurious, arising because we have delayed too long in securing the basic
services (IP, DNS). If DNS had been a secure source of KEY records (etc.)
all along, people would wonder why all the fuss about PKI.
> I guess that I view that there's probably an 80/20 rule
> here which is being missed: *most* people aren't going
> to go to the lengths of creating an active MITM attack
> to snoop on boring old every day conversations.
One must distinguish carefully between two different categories of people:
the users, and the attackers. It's not unreasonable to aim protocols at
80% of the users, but that means those users should be secure against very
nearly 100% of the attackers. It only takes one aggressive attacker to
put many users in jeopardy.
Most especially and particularly, there are quite a number of countries in
the world where you can be 100% sure that the government will be an
attacker, *because it already is*. And it has the cooperation, willing or
unwilling, of the ISPs... so MITM attacks will not be difficult to mount.
This is an important type of attacker.
> ...Trying to insert
> an upgrade path back to the mythical global PKI rather
> misses the point: if there were such a beast, we could
> should be able to use IKE as-is...
Actually, we *are* proposing to use IKE pretty much as-is (gross though it
is). Nothing in opportunistic encryption involves changes to IKE.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Wed Aug 15 09:32:14 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FGWEN00642;
Wed, 15 Aug 2001 09:32:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10375
Wed, 15 Aug 2001 11:48:29 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15226.39731.262640.816040@thomasm-u1.cisco.com>
Date: Wed, 15 Aug 2001 08:54:27 -0700 (PDT)
To: Henry Spencer <henry@spsystems.net>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
In-Reply-To: <Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net>
References: <15221.37384.191416.901953@thomasm-u1.cisco.com>
<Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Henry Spencer writes:
> On Sat, 11 Aug 2001, Michael Thomas wrote:
> > > > [anonymous encryption]
> > > We thought about that, but decided that some authentication was better
> > > than none, especially since it would upgrade transparently...
> >
> > Well... How is this especially different than just
> > using self-signed certificates and having a wide open policy?
>
> The transparent upgrade to full security is important. As I said before,
> there's an important difference between temporary and permanent security
> holes. The nice thing about having DNSSEC verify the provenance of the
> public keys is that instituting this requires no changes to the protocol
> *or the protocol software*. Going from self-signed certificates to a
> certificate signing chain would.
Huh? IKE requires that you be able to verify signatures
back to a trusted root. There is absolutely no difference
whether you get those certs from DNS, IKE, or
pony express. The verification process is
essentially identical. The only difference I
can see is if you want to not use certs and
instead rely on naked public keys. I'm dubious
about this as there are better thought out ways
of doing a centralized key management scheme
(namely, kerberos) which is what that amounts
to (enrollment being the hard problem).
> Before too very long, it *will* be necessary to secure DNS, whether that
> is done by the current DNSSEC or by other means. Why duplicate that work
> in each application?
The implications of secure DNS is a global
PKI. The same global PKI that doesn't exist.
I have little reason to believe that the
PKI fairy will leave one under our pillow
any time soon.
> One must distinguish carefully between two different categories of people:
> the users, and the attackers. It's not unreasonable to aim protocols at
> 80% of the users, but that means those users should be secure against very
> nearly 100% of the attackers. It only takes one aggressive attacker to
> put many users in jeopardy.
> Most especially and particularly, there are quite a number of countries in
> the world where you can be 100% sure that the government will be an
> attacker, *because it already is*. And it has the cooperation, willing or
> unwilling, of the ISPs... so MITM attacks will not be difficult to mount.
> This is an important type of attacker.
I guess I differentiate your average luser script
kiddie with attackers who really know what they're
doing. Like door locks and other common sense
security measures, you can do an adequate job of
most of the petty crimes by raising the bar to
a sufficient degree of sophistication that the
average kiddie is going to go back to making
OE bombs instead. The latter category is and has
always been far more problematic.
In any case, there is already a way to thwart MITM
attacks using IKE *today*. There is no need whatsoever
to bring DNS into the picture to do that, and indeed
DNS obscures the situation, IMO. Instead of making
a single self contained complicated system, you now
have two extremely complicated systems to analyze.
Mike
From owner-ipsec@lists.tislabs.com Wed Aug 15 10:30:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FHUfN03242;
Wed, 15 Aug 2001 10:30:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10502
Wed, 15 Aug 2001 12:48:25 -0400 (EDT)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B8028ADC@hhdata3.cdsemea.baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
Date: Wed, 15 Aug 2001 17:55:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I think the extreme position is that what IPSEC does best is:
i) Establishing keys between two known entities (IKE).
ii) Allowing those entities to pass datagram payloads securely between them
by providing encryption, authentication and anti-replay defenses.
It also provides some tunnelling (VPN) and firewall services that are
inferior to the free-standing implementations. IPSEC does not facilitate
resilient routing and you're still likely to need a firewall in addition to
IPSEC.
People have suggested and, I think, implemented stacks where the IPSEC
tunnels are treated as interfaces and hence can be accomodated by routing
protocols. This also allow a firewall (integrated in the same stack) to
make decisions based on the IPSEC tunnel.
This would allow the IPSEC, routing protocols and firewalls to concentrate
on what they do best.
Of course, there would be still a problem of configuring all this securely.
This has been discussed here before but, as usual, the discussion flared up
and died away without any sort of concensus.
As an aside, is there a 'standard' way for an application to request a
specific IPSEC policy for its traffic?
Chris
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: 15 August 2001 00:09
> To: Chris Trobridge
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Simplifying IKE
>
>
> At 7:59 AM +0100 8/8/01, Chris Trobridge wrote:
> >I have to admit I started in the "keep tunnelling - los
> transport" camp, but
> >with more experience I would definitely prefer transport
> mode + IP-in-IP.
> >This makes gateways and end-to-end cases identical. It also
> separates
> >routing issues associated with tunnelling from IPSEC.
>
> remember that a major difference between tunnel and transport modes
> is what headers are examined for access control purposes. if one
> changes to IP-in-IP tunneling above IPsec, it would be important to
> retain this security facility, which means we still need to know
> where to look in the stack, ...
>
> >I'd also like to see all IPSEC traffic between two hosts
> carried by just one
> >SA. I can't see any value in using multiple SAs between to
> hosts. IPSEC
> >should be just providing a secure pipe between two hosts -
> what goes through
> >it is better regulated by a firewall. There is an argument
> that you might
> >want to use different strengths of crypto for performance
> reasons but there
> >is generally a focus on performing one type of encryption
> really well rather
> >than supporting multiple types.
>
> IPsec is not designed to be just an encryption protocol. It provides
> access control comparable to that of a static, packet filtering
> firewall, but with per-SA authentication that a firewall, if placed
> behind an IPsec device, cannot provide.
>
> >
> >I'm less keen on AH and would lose it if at all possible.
> Authenticated ESP
> >provides authentication, integrity and anti-replay of the IP
> payload - what
> >do you care if the IP header has been tampered with? (what
> is missing from
> >ESP auth - just the destination IP address?). Per-hop use
> of SAs currently
> >appears limited as keys are typically only shared by the end-points.
> >
> >I would like to see things like null encryption and specific
> algorithms not
> >being MUST (or even plaintext bypass). My main reason for
> this is that you
> >can reject these by policy anyway but that exclusion from
> build is required
> >for products that go through tough security evaluations.
>
> Null encryption and null authentication are artifices, because IKE
> had allocated two slots for algorithms for ESP, before we allowed
> modular security service use. One could do away with these
> conventions in a reengineered IKE.
>
> Steve
>
>
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
From owner-ipsec@lists.tislabs.com Wed Aug 15 10:48:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FHmAN03902;
Wed, 15 Aug 2001 10:48:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10548
Wed, 15 Aug 2001 13:04:03 -0400 (EDT)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B8028ADD@hhdata3.cdsemea.baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: Michael Thomas <mat@cisco.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen
t problems
Date: Wed, 15 Aug 2001 18:11:15 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I think the problem is not specifically "global PKI" but "global trust
infrastructure".
It would be useful if IKE could use different trust models, including
delegation this to another protocol.
However, I think in most cases, binding up your key to an IP address
probably isn't that useful, due to ephemeral nature of IP addresses - my
impression is that this just gets worse with IPv6.
The important thing is that you can authenticate who your peer is - there's
no reason why this has to be bound up in an IP address - and that your
policy allows to communicate with them.
Chris
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: 15 August 2001 16:54
> To: Henry Spencer
> Cc: Michael Thomas; ipsec@lists.tislabs.com; FreeS/WAN Design Issues
> Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
> deployment problems
>
>
> Henry Spencer writes:
> > On Sat, 11 Aug 2001, Michael Thomas wrote:
> > > > > [anonymous encryption]
> > > > We thought about that, but decided that some
> authentication was better
> > > > than none, especially since it would upgrade transparently...
> > >
> > > Well... How is this especially different than just
> > > using self-signed certificates and having a wide open policy?
> >
> > The transparent upgrade to full security is important. As
> I said before,
> > there's an important difference between temporary and
> permanent security
> > holes. The nice thing about having DNSSEC verify the
> provenance of the
> > public keys is that instituting this requires no changes
> to the protocol
> > *or the protocol software*. Going from self-signed
> certificates to a
> > certificate signing chain would.
>
> Huh? IKE requires that you be able to verify signatures
> back to a trusted root. There is absolutely no difference
> whether you get those certs from DNS, IKE, or
> pony express. The verification process is
> essentially identical. The only difference I
> can see is if you want to not use certs and
> instead rely on naked public keys. I'm dubious
> about this as there are better thought out ways
> of doing a centralized key management scheme
> (namely, kerberos) which is what that amounts
> to (enrollment being the hard problem).
>
> > Before too very long, it *will* be necessary to secure
> DNS, whether that
> > is done by the current DNSSEC or by other means. Why
> duplicate that work
> > in each application?
>
> The implications of secure DNS is a global
> PKI. The same global PKI that doesn't exist.
> I have little reason to believe that the
> PKI fairy will leave one under our pillow
> any time soon.
>
> > One must distinguish carefully between two different
> categories of people:
> > the users, and the attackers. It's not unreasonable to
> aim protocols at
> > 80% of the users, but that means those users should be
> secure against very
> > nearly 100% of the attackers. It only takes one
> aggressive attacker to
> > put many users in jeopardy.
>
> > Most especially and particularly, there are quite a number
> of countries in
> > the world where you can be 100% sure that the government will be an
> > attacker, *because it already is*. And it has the
> cooperation, willing or
> > unwilling, of the ISPs... so MITM attacks will not be
> difficult to mount.
> > This is an important type of attacker.
>
> I guess I differentiate your average luser script
> kiddie with attackers who really know what they're
> doing. Like door locks and other common sense
> security measures, you can do an adequate job of
> most of the petty crimes by raising the bar to
> a sufficient degree of sophistication that the
> average kiddie is going to go back to making
> OE bombs instead. The latter category is and has
> always been far more problematic.
>
> In any case, there is already a way to thwart MITM
> attacks using IKE *today*. There is no need whatsoever
> to bring DNS into the picture to do that, and indeed
> DNS obscures the situation, IMO. Instead of making
> a single self contained complicated system, you now
> have two extremely complicated systems to analyze.
>
> Mike
>
>
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
From owner-ipsec@lists.tislabs.com Wed Aug 15 11:10:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FIAKN05022;
Wed, 15 Aug 2001 11:10:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10592
Wed, 15 Aug 2001 13:26:43 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15226.45614.601672.408572@thomasm-u1.cisco.com>
Date: Wed, 15 Aug 2001 10:32:30 -0700 (PDT)
To: Chris Trobridge <CTrobridge@baltimore.com>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen
t problems
In-Reply-To: <F86F34FDF1F9D411B7A40008C74C27B8028ADD@hhdata3.cdsemea.baltimore.com>
References: <F86F34FDF1F9D411B7A40008C74C27B8028ADD@hhdata3.cdsemea.baltimore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Chris Trobridge writes:
> I think the problem is not specifically "global PKI" but "global trust
> infrastructure".
Yes, my sloppy.
> It would be useful if IKE could use different trust models, including
> delegation this to another protocol.
>
> However, I think in most cases, binding up your key to an IP address
> probably isn't that useful, due to ephemeral nature of IP addresses - my
> impression is that this just gets worse with IPv6.
I agree, it not very optimal. It's quite possible that
I don't understand this very well, but do the two
use modes -- tunnel/transport -- really have the same
identity semantics? For tunnel mode, you are essentially
authenticating/authorizing an incoming interface to be
built on the security gateway. That is, a route is
established for a prefix. There really aren't any
possible consumers (normally, at least, unless you're
talking about a degenerate host-host tunnel).
I'm not as sure with transport mode. I guess I
view this as not so much affecting the routing
subsystem so much as affecting the IP datagrams
themselves; it may be implemented using the same
mechanisms as are used for tunnels, but I don't
think it *needs* to be thought of that way. In
fact, since transport is a host-host mode, it
sort of begs what the identity is used for at
all. I've brought up on the list before that
it would be nice to have the L3 credentials
available for higher layers when in transport
mode, (which I still think would be quite
useful), but I guess I don't know what the
transport identity is providing other than
a reliable way of saying, "yes, this is
mat@cisco.com". If there's not a policy module
which can take action based on that knowledge,
it seems like it's just providing a way to keep
outsiders out. Maybe this is a useful enough
service, but it seems sort of limited...
Mike
From owner-ipsec@lists.tislabs.com Wed Aug 15 13:26:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FKQvN10869;
Wed, 15 Aug 2001 13:26:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10900
Wed, 15 Aug 2001 15:35:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010402b7a0805d8c40@[128.33.238.53]>
In-Reply-To:
<2F3EC696EAEED311BB2D009027C3F4F4058696DF@vhqpostal.verisign.com>
References:
<2F3EC696EAEED311BB2D009027C3F4F4058696DF@vhqpostal.verisign.com>
Date: Wed, 15 Aug 2001 15:41:12 -0400
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: IKE must have no Heirs
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 8:20 AM -0700 8/15/01, Hallam-Baker, Phillip wrote:
> > SKIP was a poor choice for any long-lived SA, because SKIP forced
>> every packet to carry SA state information in lieu of exchanging SA
>> establishment messages.
>
>I see no reason why that specific problem could not have been fixed.
>If you have a securely established shared secret that is securely bound
>to a shared context there should be no per packet state requirement.
Phil,
You seem to be confusing the name of a protocol, and your apparent
fondness for it, with the details that define that protocol. I don't
recall your participation in IPsec WG activities during the time that
the SKIP vs. IKE war took place, so perhaps your understanding of the
history here is not so precise.
Steve
From owner-ipsec@lists.tislabs.com Wed Aug 15 14:03:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FL3qN12291;
Wed, 15 Aug 2001 14:03:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11004
Wed, 15 Aug 2001 16:24:10 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696E8@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Stephen Kent'" <kent@bbn.com>,
"Hallam-Baker, Phillip"
<pbaker@verisign.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: IKE must have no Heirs
Date: Wed, 15 Aug 2001 13:30:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C125C9.21A2B4D0"
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_000_01C125C9.21A2B4D0
Content-Type: text/plain;
charset="iso-8859-1"
Steve,
The fact that IPSEC has only gained widespread acceptance in the VPN
market and is not being employed for its intended purpose, the fact that
five years after the event the group is under an IESG injunction to get its
act together suggest to me that those who were immediately responsible for
the current situation should not be so openly contemptious and dismissive of
those who might have useful ideas on how to remedy the current situation.
I do not much care for the history of the internal politics of any
IETF group, let alone the personal campaign stories of the combatants in the
IKE vs SKIP wars. Nor for that matter am I as you suggest 'fond of SKIP',
rather I have an aversion to a specification that introduces nine separate
protocols for performing a simple key exchange.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Wednesday, August 15, 2001 3:41 PM
> To: Hallam-Baker, Phillip
> Cc: ipsec@lists.tislabs.com
> Subject: RE: IKE must have no Heirs
>
>
> At 8:20 AM -0700 8/15/01, Hallam-Baker, Phillip wrote:
> > > SKIP was a poor choice for any long-lived SA, because SKIP forced
> >> every packet to carry SA state information in lieu of
> exchanging SA
> >> establishment messages.
> >
> >I see no reason why that specific problem could not have been fixed.
> >If you have a securely established shared secret that is
> securely bound
> >to a shared context there should be no per packet state requirement.
>
> Phil,
>
> You seem to be confusing the name of a protocol, and your apparent
> fondness for it, with the details that define that protocol. I don't
> recall your participation in IPsec WG activities during the time that
> the SKIP vs. IKE war took place, so perhaps your understanding of the
> history here is not so precise.
>
> Steve
>
------_=_NextPart_000_01C125C9.21A2B4D0
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C125C9.21A2B4D0--
From owner-ipsec@lists.tislabs.com Wed Aug 15 18:33:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G1XlN21298;
Wed, 15 Aug 2001 18:33:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11271
Wed, 15 Aug 2001 20:25:12 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Sara Bitan'" <sarab@cs.Technion.AC.IL>, <ipsec@lists.tislabs.com>
Subject: RE: Traffic handling and key management "divide and coquer"
Date: Thu, 16 Aug 2001 01:20:48 +0100
Message-Id: <002b01c125e9$a0d89240$0109e982@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <003901c1249d$86b1a8e0$0300000a@bilbo>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I completely agree. I think some people have been much too quick too suggest
dumping the entire framework we have developed over several years. Can we
finally put what happened to Skip & Photuris behind us and stop
schizophrenically shedding protocols?
The IPsec WG has never been able to agree on requirements for anything. It
seems idealistic and naive to believe that we could start over with a brand
new KMP and acheive a different result. Like it or not, IKE was the
preordained result of a design by commitee,a political process. The
alternative to a committee process is a fascist process. Take your pick. I
personally don't like either committees or facism, but I'll take committees
any day of the week.
Listen to the arguments we've heard on the list recently: Let's "simplify"
IKE by reducing the number of messages, making the exchange asymmetrical,
optionally adding a cookie exchange when the responder is under DoS,
optionally piggybacking phase 2 on phase 1, optionally reducing the message
count by allowing optimistic negotiation, optionally telling the initiator
to retry the negotiation with different groups, changing phase 1 so it can't
be used transparently in MSec, changing phase 2 so it can't be easily
leveraged for KINK.
Instead of spending another 2 years arguing and developing a new protocol
that inevitably falls into the same old traps of optimization vs. simplicity
vs. features, I suggest that we do basically what Sara suggests. To steal a
comment from Ferguson/Schneier, ISAKMP is a framework for creating security
protocols; the problem with IKE is that it also seems like a framework for
creating security protocols.
Let's have one protocol which is based on IKE MM/QM + improveike for VPN
users, and a separate protocol (optimized for low-bandwidth applications)
for things like ISCSI. Make them more specific than IKE is right now, but
design them on top of ISAKMP so that those of us who need to write all of
IKE and MSec and KINK and MPLS-SEC and MAP-DOI and whatever other esoteric
usage of IPsec comes along, can at least leverage some of our code.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sara Bitan
> Sent: Tuesday, August 14, 2001 9:46 AM
> To: ipsec@lists.tislabs.com
> Subject: Traffic handling and key management "divide and coquer"
>
>
> I think that we are at a crucial point where we can make a
> change that will
> turn our work to more focused and efficient, and hopefully fruitful. I
> suggest we use a "divide and conquer" strategic.
> We should first of all separate IPsec transforms traffic
> handling (i.e. ESP
> and AH) and key management work to different WGs (if I
> understand right,
> this was raised by JI in the SAAG meeting).
> This process is already happening as we speak - MSEC and KINK
> are working on
> key management protocols that create IPsec SAs, with different
> requirements. ESP and AH will still be used for traffic handling.
> If we will do the separation, we will soon be able to tell
> the industry that
> the work on the IPsec transforms is done, which I think will
> be a great
> advantage.
>
> I think we should also allow for several key management protocols,
> preferably with one framework.
> This is the only way we will be able to cater for the
> requirements of "DSL
> geeks" as well as "billion mobile users" (quoting Jari's words).
>
> There are several actions that we need to take for this to happen:
> 1) Allow working groups other than IPsec to work on key management
> protocols, this way we could shut down the IPsec WG and keep
> on working on
> new key management protocols. As I said this is already happening.
> 2) Limit IPsec wg to only on the following IKE modifications : NAT
> traversal, SCTP support and re-keying. The new IKE version
> should be a minor
> version including only minor fixes (as outlined in the new suggested
> charter).
> 3) Re-assure ourselves that the interface between transforms and key
> management is clearly defined, and general enough to allow
> for the addition
> of new key management protocols, without having to change the
> transforms.
> 4) Have a framework protocol for key management - I think it
> should be based
> on ISAKMP. There is no need to re-invent transforms and
> proposals syntax for
> each new key management protocol.
> 5) Have different requirements for different key management
> protocols. With
> one common requirement - they should all create IPsec SAs.
> This way we could
> have one requirements document include Identity protection,
> and allow for a
> larger number of messages, and another that has no Identity Protection
> requirement, and requires a small number of message. We can
> also have one or
> several WGs in charge of the key management protocols.
>
> Sara.
>
From owner-ipsec@lists.tislabs.com Wed Aug 15 19:28:27 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2SRN22470;
Wed, 15 Aug 2001 19:28:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11411
Wed, 15 Aug 2001 21:42:04 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010403b7a09d9f2a5b@[128.33.238.53]>
In-Reply-To: <15226.45614.601672.408572@thomasm-u1.cisco.com>
References:
<F86F34FDF1F9D411B7A40008C74C27B8028ADD@hhdata3.cdsemea.baltimore.com>
<15226.45614.601672.408572@thomasm-u1.cisco.com>
Date: Wed, 15 Aug 2001 17:52:11 -0400
To: Michael Thomas <mat@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen
t problems
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:32 AM -0700 8/15/01, Michael Thomas wrote:
>Chris Trobridge writes:
> > I think the problem is not specifically "global PKI" but "global trust
> > infrastructure".
>
> Yes, my sloppy.
>
> > It would be useful if IKE could use different trust models, including
> > delegation this to another protocol.
> >
> > However, I think in most cases, binding up your key to an IP address
> > probably isn't that useful, due to ephemeral nature of IP addresses - my
> > impression is that this just gets worse with IPv6.
>
> I agree, it not very optimal. It's quite possible that
> I don't understand this very well, but do the two
> use modes -- tunnel/transport -- really have the same
> identity semantics? For tunnel mode, you are essentially
> authenticating/authorizing an incoming interface to be
> built on the security gateway. That is, a route is
> established for a prefix. There really aren't any
> possible consumers (normally, at least, unless you're
> talking about a degenerate host-host tunnel).
> I'm not as sure with transport mode. I guess I
> view this as not so much affecting the routing
> subsystem so much as affecting the IP datagrams
> themselves; it may be implemented using the same
> mechanisms as are used for tunnels, but I don't
> think it *needs* to be thought of that way. In
> fact, since transport is a host-host mode, it
> sort of begs what the identity is used for at
> all. I've brought up on the list before that
> it would be nice to have the L3 credentials
> available for higher layers when in transport
> mode, (which I still think would be quite
> useful), but I guess I don't know what the
> transport identity is providing other than
> a reliable way of saying, "yes, this is
> mat@cisco.com". If there's not a policy module
> which can take action based on that knowledge,
> it seems like it's just providing a way to keep
> outsiders out. Maybe this is a useful enough
> service, but it seems sort of limited...
>
>
> Mike
Mike,
Your understanding is not quite right. First, tunnel mode, while
required for an SG, is also applicable to two hosts communicating.
Second, IPsec supports authentication of symbolic names, not just IP
addresses, which are dynamically bound to IP addresses for the
duration of an SA. This is how we support connections from mobile
users, for example.
The access control model that underlies IPsec is that one uses some
means of authenticating a peer, e.g., via binding a signature key to
an ID, traceable to a trust anchor, and that the traffic sent from
and sent to the authenticated peer is subject to access controls
expressed in the SPD. These controls apply not only to allowed IP
addresses to/from which traffic may flow, but also protocols and port
fields. The motivation for these other selectors is the same as in
firewalls, i.e., we can control access to services based on access to
well know ports.
Once the SA is established, we look at the IP source address(es)
asserted by the peer to ensure that it does not try to spoof traffic
from other peers with whom we are communicating (especially relevant
at an SG).
Steve
From owner-ipsec@lists.tislabs.com Wed Aug 15 19:28:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2SVN22483;
Wed, 15 Aug 2001 19:28:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11454
Wed, 15 Aug 2001 21:43:10 -0400 (EDT)
Message-Id: <3.0.3.32.20010815184901.00e75050@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Wed, 15 Aug 2001 18:49:01 -0700
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>,
"'Stephen Kent'" <kent@bbn.com>,
"Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Alex Alten <Alten@home.com>
Subject: RE: IKE must have no Heirs
Cc: ipsec@lists.tislabs.com
In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058696E8@vhqpostal.verisig
n.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ahh...this takes me back to my fading memories of the Secure
SNMP War back in '96, i.e the SNMPv2 WG. :-}
- Alex
At 01:30 PM 8/15/2001 -0700, Hallam-Baker, Phillip wrote:
>Steve,
>
> The fact that IPSEC has only gained widespread acceptance in the VPN
>market and is not being employed for its intended purpose, the fact that
>five years after the event the group is under an IESG injunction to get its
>act together suggest to me that those who were immediately responsible for
>the current situation should not be so openly contemptious and dismissive of
>those who might have useful ideas on how to remedy the current situation.
>
> I do not much care for the history of the internal politics of any
>IETF group, let alone the personal campaign stories of the combatants in the
>IKE vs SKIP wars. Nor for that matter am I as you suggest 'fond of SKIP',
>rather I have an aversion to a specification that introduces nine separate
>protocols for performing a simple key exchange.
>
> Phill
>
>
>Phillip Hallam-Baker FBCS C.Eng.
>Principal Scientist
>VeriSign Inc.
>pbaker@verisign.com
>781 245 6996 x227
>
>
>> -----Original Message-----
>> From: Stephen Kent [mailto:kent@bbn.com]
>> Sent: Wednesday, August 15, 2001 3:41 PM
>> To: Hallam-Baker, Phillip
>> Cc: ipsec@lists.tislabs.com
>> Subject: RE: IKE must have no Heirs
>>
>>
>> At 8:20 AM -0700 8/15/01, Hallam-Baker, Phillip wrote:
>> > > SKIP was a poor choice for any long-lived SA, because SKIP forced
>> >> every packet to carry SA state information in lieu of
>> exchanging SA
>> >> establishment messages.
>> >
>> >I see no reason why that specific problem could not have been fixed.
>> >If you have a securely established shared secret that is
>> securely bound
>> >to a shared context there should be no per packet state requirement.
>>
>> Phil,
>>
>> You seem to be confusing the name of a protocol, and your apparent
>> fondness for it, with the details that define that protocol. I don't
>> recall your participation in IPsec WG activities during the time that
>> the SKIP vs. IKE war took place, so perhaps your understanding of the
>> history here is not so precise.
>>
>> Steve
>>
>
>
>Attachment Converted: "d:\eudora\attach\Phillip Hallam-Baker (E-mail)15.vcf"
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Wed Aug 15 19:28:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2SWN22485;
Wed, 15 Aug 2001 19:28:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11442
Wed, 15 Aug 2001 21:42:47 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p0501040ab7a0a8df6659@[128.33.238.53]>
In-Reply-To:
<F86F34FDF1F9D411B7A40008C74C27B8028ADC@hhdata3.cdsemea.baltimore.com>
References:
<F86F34FDF1F9D411B7A40008C74C27B8028ADC@hhdata3.cdsemea.baltimore.com>
Date: Wed, 15 Aug 2001 18:36:32 -0400
To: Chris Trobridge <CTrobridge@baltimore.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Simplifying IKE
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 5:55 PM +0100 8/15/01, Chris Trobridge wrote:
>I think the extreme position is that what IPSEC does best is:
>
>i) Establishing keys between two known entities (IKE).
>ii) Allowing those entities to pass datagram payloads securely between them
>by providing encryption, authentication and anti-replay defenses.
>
>It also provides some tunnelling (VPN) and firewall services that are
>inferior to the free-standing implementations. IPSEC does not facilitate
>resilient routing and you're still likely to need a firewall in addition to
>IPSEC.
we disagree. firewalls typically make access control decisions based
on unauthenticated data from packet headers. IPsec makes these
decisions based on authenticated identities and mutually enforced
constraints on these packet headers. in that regard, the access
control services are far superior to what is provided by freestanding
firewalls.
>People have suggested and, I think, implemented stacks where the IPSEC
>tunnels are treated as interfaces and hence can be accomodated by routing
>protocols. This also allow a firewall (integrated in the same stack) to
>make decisions based on the IPSEC tunnel.
one might do this, and so long as the selector features mandated in
2401 are supported, this is a compliant IPsec implementation approach.
>
>This would allow the IPSEC, routing protocols and firewalls to concentrate
>on what they do best.
since we disagree on what each does best, we obviously don't agree on
your conclusion of what constitutes an appropriate allocation of
tasks :-)
>
>Of course, there would be still a problem of configuring all this securely.
>
>This has been discussed here before but, as usual, the discussion flared up
>and died away without any sort of concensus.
>
>As an aside, is there a 'standard' way for an application to request a
>specific IPSEC policy for its traffic?
No. APIs for IPsec have not been standardized.
Steve
From owner-ipsec@lists.tislabs.com Wed Aug 15 19:28:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2SmN22510;
Wed, 15 Aug 2001 19:28:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11448
Wed, 15 Aug 2001 21:42:51 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p0501040db7a0ac202a1b@[128.33.238.53]>
In-Reply-To: <Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net>
References: <Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net>
Date: Wed, 15 Aug 2001 18:52:58 -0400
To: Henry Spencer <henry@spsystems.net>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
deployment problems
Cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Henry,
I agree that the DNS is a reasonable place to store certs, although
some DNS experts don't agree with this view.
I also agree that a PKI that exactly mirrored the DNS would be a
great feature. Unfortunately, this is not what you get from DNSSEC.
DNSSEC tries to solve a different problem, and it avoids using cert
formats, instead opting for key and sig records. Some of the problems
that DNSSEC faces re widespread deployment are a direct result of the
set of security services it attempts to provide, relative to DNS
queries. Providing certs that bind DNS names to keys would not solve
the same set of problems, but would be simpler.
We disagree on the merits of opportunistic encryption. For most
organizations, the primary threat is one of unauthorized access, not
massive passive wiretapping of Internet traffic. Thus encrypting lost
of traffic, without providing accompanying access controls, might
cause more harm (in the access control dimension) than good, e.g., by
making it harder to perform intrusion detection, trace attacks, etc.
However, to the extent that FreeS/WAN tries to address a concern to a
user community that has a different threat model, one that is more
focused on big brother than on hackers, I don't argue with your
approach.
Steve
From owner-ipsec@lists.tislabs.com Wed Aug 15 19:29:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2TCN22534;
Wed, 15 Aug 2001 19:29:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11417
Wed, 15 Aug 2001 21:42:07 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010408b7a0a0d6eba3@[128.33.238.53]>
In-Reply-To: <PCELJJEJJMODEMKEBLLBKEADCAAA.larse@isi.edu>
References: <PCELJJEJJMODEMKEBLLBKEADCAAA.larse@isi.edu>
Date: Wed, 15 Aug 2001 18:02:09 -0400
To: "Lars Eggert" <larse@ISI.EDU>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Simplifying IKE
Cc: <xbone@ISI.EDU>, <ipsec@lists.tislabs.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Lars,
If we let routing select an SA, vs. the other way around, it might
seem that we run a new risk of having a routing algorithm push
traffic over the wrong SA. To counter that we would unless we modify
the IPsec processing to check for selector appropriateness after
mapping traffic to an SA, rather than using selectors to pick the SA.
That probably would not work well unless we adopt a de-correlated SPD
model, since otherwise one would have to go back to the SPD to check
"appropriateness" for each packet. However, I am planning to use that
model for the next rev of 2401, so that might not be a problem.
Steve
From owner-ipsec@lists.tislabs.com Wed Aug 15 19:30:34 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2UXN22584;
Wed, 15 Aug 2001 19:30:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11427
Wed, 15 Aug 2001 21:42:19 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p0501040bb7a0aa66c22e@[128.33.238.53]>
In-Reply-To: <15226.35517.701351.186328@thomasm-u1.cisco.com>
References: <3B79500C.1367FCD3@storm.ca>
<200108141718.f7EHISo02668@kebe.east.sun.com>
<15226.35517.701351.186328@thomasm-u1.cisco.com>
Date: Wed, 15 Aug 2001 18:44:05 -0400
To: Michael Thomas <mat@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Require AH?
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 7:44 AM -0700 8/15/01, Michael Thomas wrote:
>Dan McDonald writes:
> > Some HW folks didn't think you could do AH in hardware. I've
>heard other HW
> > folks (but only after the fact) say that you can indeed do AH in hardware.
>
> I have great confidence that hardware guys can
> do just about anything you set them out to do.
> It's only the final transistor count that tells
> you whether it is worth the effort.
>
> > ESP authentication was a knee-jerk reaction to Bellovin's analysis of
> > 1825-1827. He stated the threats of unauthenticated CBC
>encryption + replay
> > problems. The knee-jerk reaction was to add both of these
>properties to ESP,
> > without first thinking that requiring a fixed AH with replay
>protection could
> > do the trick.
>
> Actually, what would make me most happy would be to
> have a single IPsec extension header which does
> *everything*. This helps on the code/message
> compactness front, as well as simplifying the
> number of SADB entries, different protocols
> handling, header traversal, etc. It seems to me
> that if we had modes like gzip-aes-cbc-sha1 for
> ESP transforms, we could get rid of both AH and
> IPCOMP.
>
> Mike
This has been suggested before, and rejected. In large part AH is
ugly because it tries to cover the IP header, but there are so many
fields that cannot be covered. this makes processing slower than ESP
auth only. tunnel mode of auth only ESP addresses essentially all of
the IPv4 motivations for having AH. The only open question is what
IPv6 requirements are met by AH and not by this mode.
So, if we don't find a really good reason to retain AH, there is no
good reason to create a new, different protocol to accommodate this
combination of features. Also, this sort of new protocol would be
more complex than either AH or ESP alone, which raises questions
about whether we have achieved anything. One can argue that two
protocols, each of which is relatively simple, are better than one
protocol that is more complex.
Steve
From owner-ipsec@lists.tislabs.com Wed Aug 15 19:30:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2UgN22606;
Wed, 15 Aug 2001 19:30:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11445
Wed, 15 Aug 2001 21:42:49 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010400b7a0d53571da@[128.33.238.53]>
In-Reply-To:
<F86F34FDF1F9D411B7A40008C74C27B8028ADD@hhdata3.cdsemea.baltimore.com>
References:
<F86F34FDF1F9D411B7A40008C74C27B8028ADD@hhdata3.cdsemea.baltimore.com>
Date: Wed, 15 Aug 2001 21:47:16 -0400
To: Chris Trobridge <CTrobridge@baltimore.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen
t problems
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 6:11 PM +0100 8/15/01, Chris Trobridge wrote:
>I think the problem is not specifically "global PKI" but "global trust
>infrastructure".
I think "trust" is largely an irrelevant term here. If one wants to
identify hosts by DNS name, there is an established, strict hierarchy
that we all rely on. It's authoritative. It's not a matter of trust.
>It would be useful if IKE could use different trust models, including
>delegation this to another protocol.
IKE defines very little about what one does with its varied set of
potential PKI technologies, so I don't think this is a relevant
criticism.
>However, I think in most cases, binding up your key to an IP address
>probably isn't that useful, due to ephemeral nature of IP addresses - my
>impression is that this just gets worse with IPv6.\
IP addresses are not the only choice of identifier that IKE (or
IPsec) deals with, as I noted in another message. Also, IPv6 is
hardly the primary focus of most folks today. So, for those folkks
who argue the need to be responsive to current and near term customer
needs, IPv4 should be the major focus for now.
>
>The important thing is that you can authenticate who your peer is - there's
>no reason why this has to be bound up in an IP address - and that your
>policy allows to communicate with them.
>
We agree; IPsec and IKE already allow that. But, it's not always
enough to discuss authorization merely at the granularity of IP
addresses, which is why we have other selectors in the SPD.
Steve
From owner-ipsec@lists.tislabs.com Wed Aug 15 19:32:00 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2VxN22652;
Wed, 15 Aug 2001 19:31:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11441
Wed, 15 Aug 2001 21:42:47 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p0501040eb7a0add79147@[128.33.238.53]>
In-Reply-To:
<2F3EC696EAEED311BB2D009027C3F4F4058696DE@vhqpostal.verisign.com>
References:
<2F3EC696EAEED311BB2D009027C3F4F4058696DE@vhqpostal.verisign.com>
Date: Wed, 15 Aug 2001 21:40:57 -0400
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: XKMS and NIH RE: Simplifying IKE
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Phill,
>Steve,
>
> You entirely manage to miss the point. You agree that part of the
>complexity of IPSEC is that it is required to interface to every PKI in the
>universe for political reasons. Then you make the statesmanlike suggestion
>that the world standardize on the specification of the working group you
>have been chairing. It may well make good technical sense. Perhaps you would
>like to lend your support to Neil Kinnock's proposal to make English the
>sole administrative language of the European Union whil you are at it?
There is a difference between by suggesting support for a set of IETF
standards (the WG for which I do co-chair) vs. your promoting a
VeriSign/Microsoft technology. Perhaps you find this difference too
subtle, but I feel confident others on the list can make the
distinction.
We also disagree on the issue of complexity. IPsec is not required to
interface to every PKI in the universe. (Anyway, until Vint gets the
interplanetary Internet up and running, there's not much need for
extra-global cross certification.) IKE makes syntactic accommodation
for a variety of PKI technologies, but the syntactic provisions are
just the starting point. IPsec lacks an RFC specifying the harder
details of what it really means to support ANY PKI, which is part of
why this is one of the least interoperable aspects of IKE
implementations. I'm suggesting that we consider focusing on support
of the one PKI syntax and semantics that most vendors who do support
a PKI in IKE already have selected. This seems like a simplification
consistent with the discussion we've been having. I also suggest that
we generate an RFC that does fill in the blanks that have resulted in
> As for 'advertising' the work product of another open standards
>working group that is appropriate to a working group topic, has substantial
>commitments from the major PKI vendors, major application vendors and major
>customers - I will do it at every opportunity thank you very much, whether
>the specification is one of my own invention or of somebody else.
What other open standards group? W3C? As it's name suggests, it's
more akin to an industry consortium than a standards organization.
> It was the first time that I had raised XKMS on the IPSEC list. It
>was not off topic, it was in fact entirely on topic. I don't think that the
>majority of the IETF would agree that Not Invented Here is a good policy.
>Plenty of IETF working groups make use of the work product of other working
>groups outside the IETF, BEEP makes use of a W3C specification, PKIX makes
>use of an ITU standard.
We gave you an opportunity to discuss XKMS in PKIX and the response
was not what I would call overwhelming. My guess is that you elected
to bring XKMS to W3C because you saw an easier path there, among a
group of players not know for extensive security or expertise. BTW,
don't compare W3C with the ITU, a treaty organization; it's hardly
analogous, and PKIX was chartered explicitly to profile the ITU X.509
work.
> Perhaps you could elaborate the reasons why you do not consider XKMS
>to be a suitable topic for consideration by IPSEC?
>
> XKMS is designed to allow simplification of client implementation of
>PKI. The topic on the table is simplification of IPSEC.
IPsec does not have clients. It is a peer-to-peer protocol. I recall,
from your XKMS presentation, something of a client/server flavor,
which would be appropriate for SSL, but not necessarily for IPsec.
Phill, you have never been a contributor in the IPsec area. Your
comments in recent messages illustrate ignorance of the history of WG
activities on which you now choose to comment. I don't find that
constructive. We're trying to simplify IKE. if you propose support
for XKMS as yet another PKI technology, that hardly amounts to
simplification. If you suggest it as a replacement for the other
technologies, that would call for discarding the PKI support that
most vendors (that support PKI in IKE) already implement, which also
seems questionable unless you can argue that XKMS is better in all
respects.
Steve
From owner-ipsec@lists.tislabs.com Wed Aug 15 19:45:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2j6N22929;
Wed, 15 Aug 2001 19:45:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11545
Wed, 15 Aug 2001 22:03:09 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010404b7a0da95b525@[128.33.238.57]>
In-Reply-To:
<2F3EC696EAEED311BB2D009027C3F4F4058696E8@vhqpostal.verisign.com>
References:
<2F3EC696EAEED311BB2D009027C3F4F4058696E8@vhqpostal.verisign.com>
Date: Wed, 15 Aug 2001 22:10:18 -0400
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: IKE must have no Heirs
Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>, ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 1:30 PM -0700 8/15/01, Hallam-Baker, Phillip wrote:
>Steve,
>
> The fact that IPSEC has only gained widespread acceptance in the VPN
>market and is not being employed for its intended purpose, the fact that
>five years after the event the group is under an IESG injunction to get its
>act together suggest to me that those who were immediately responsible for
>the current situation should not be so openly contemptious and dismissive of
>those who might have useful ideas on how to remedy the current situation.
>
> I do not much care for the history of the internal politics of any
>IETF group, let alone the personal campaign stories of the combatants in the
>IKE vs SKIP wars. Nor for that matter am I as you suggest 'fond of SKIP',
>rather I have an aversion to a specification that introduces nine separate
>protocols for performing a simple key exchange.
>
> Phill
>
If you're not familiar with the history, or the details of the
protocols in question, then perhaps you ought not offer comments
suggesting otherwise.
Your messages have the flavor of "you poor kerks in IPsec have made a
mess of this, perhaps because I was not here to help. now I'm here to
help."
I have no trouble being both contemptous and dismissive in your case,
because I have endured your "assistance" in PKIX for several years.
There at least you had some inkling of what was going on, but none
the less managed to produce little in the way of tangible results,
i.e., RFCs, whole offering lots of comments.
Here, where you have demonstrated even less understanding of the
subject matter, it is not at all clear how much help you can render,
other than promoting your pet technology.
Clear enough Phill?
Steve
From owner-ipsec@lists.tislabs.com Wed Aug 15 19:48:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2mdN22993;
Wed, 15 Aug 2001 19:48:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11563
Wed, 15 Aug 2001 22:06:34 -0400 (EDT)
Message-Id: <3.0.3.32.20010815191218.00e75050@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Wed, 15 Aug 2001 19:12:18 -0700
To: <andrew.krywaniuk@alcatel.com>, "'Sara Bitan'" <sarab@cs.Technion.AC.IL>,
<ipsec@lists.tislabs.com>
From: Alex Alten <Alten@home.com>
Subject: RE: Traffic handling and key management "divide and coquer"
In-Reply-To: <002b01c125e9$a0d89240$0109e982@andrewk3.ca.newbridge.com>
References: <003901c1249d$86b1a8e0$0300000a@bilbo>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 01:20 AM 8/16/2001 +0100, Andrew Krywaniuk wrote:
...
>The IPsec WG has never been able to agree on requirements for anything. It
>seems idealistic and naive to believe that we could start over with a brand
>new KMP and acheive a different result. Like it or not, IKE was the
>preordained result of a design by commitee,a political process. The
>alternative to a committee process is a fascist process. Take your pick. I
>personally don't like either committees or facism, but I'll take committees
>any day of the week.
...
There is an alternative to committes or facism, the NIST approach (as in the
AES "beauty contest"). Let's lay out the requirements, then hold a "beauty
contest", and finally vote in a winner. This way we aren't getting the
"design by committee" effect that simply does not work for a security
oriented protocol.
If you don't believe me, look what has happened to PEM, SNMPSEC, now IKE,
and possibly IPSEC itself. DNSSEC may be the only recent success, and that
was probably due to the small group involved. Our IETF WG consensus process
which works well when designing an insecure protocol standard doesn't work
properly when designing a secure protocol standard, at least not with a
large group of stongly opinionated engineers.
Let's learn from our mistakes and try an approach that seems to work,
the NIST one.
- Alex
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Thu Aug 16 01:25:23 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G8PMN23628;
Thu, 16 Aug 2001 01:25:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11996
Thu, 16 Aug 2001 03:28:08 -0400 (EDT)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B8028AE0@hhdata3.cdsemea.baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: Simplifying IKE
Date: Thu, 16 Aug 2001 08:35:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
>
> we disagree. firewalls typically make access control decisions based
> on unauthenticated data from packet headers. IPsec makes these
> decisions based on authenticated identities and mutually enforced
> constraints on these packet headers. in that regard, the access
> control services are far superior to what is provided by freestanding
> firewalls.
I was assuming you take all these things together. If tunnel SAs are
treated as interfaces by the firewall then it can enforce the IPSEC
constraints.
> >As an aside, is there a 'standard' way for an application to
> request a
> >specific IPSEC policy for its traffic?
>
> No. APIs for IPsec have not been standardized.
I think this might be one of the reasons why IPSEC hasn't taken off so
widely. I wouldn't know how to create a socket with a particular IPSEC
policy.
SSL managed to fit much better into applications and is widely used - even
if some of the fundamentals are not as strong (which also helped it...).
Chris
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
From owner-ipsec@lists.tislabs.com Thu Aug 16 01:25:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G8PSN23639;
Thu, 16 Aug 2001 01:25:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11981
Thu, 16 Aug 2001 03:19:54 -0400 (EDT)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B8028ADF@hhdata3.cdsemea.baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen
t problems
Date: Thu, 16 Aug 2001 08:27:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: Stephen Kent [mailto:kent@bbn.com]
> At 6:11 PM +0100 8/15/01, Chris Trobridge wrote:
> >I think the problem is not specifically "global PKI" but
> "global trust
> >infrastructure".
>
> I think "trust" is largely an irrelevant term here. If one wants to
> identify hosts by DNS name, there is an established, strict hierarchy
> that we all rely on. It's authoritative. It's not a matter of trust.
I think we may arguing over language here - I still see this as a
hierarchical system of trust.
> >It would be useful if IKE could use different trust models, including
> >delegation this to another protocol.
>
> IKE defines very little about what one does with its varied set of
> potential PKI technologies, so I don't think this is a relevant
> criticism.
I may be guilty of confusing what I know is being done with IKE vs what it
is capable of.
Chris
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
From owner-ipsec@lists.tislabs.com Thu Aug 16 04:59:25 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GBxPN08347;
Thu, 16 Aug 2001 04:59:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12345
Thu, 16 Aug 2001 07:19:04 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010402b7a15ccc6454@[128.33.238.106]>
In-Reply-To: <3.0.3.32.20010815191218.00e75050@mail>
References: <003901c1249d$86b1a8e0$0300000a@bilbo>
<3.0.3.32.20010815191218.00e75050@mail>
Date: Thu, 16 Aug 2001 07:20:57 -0400
To: Alex Alten <Alten@home.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Traffic handling and key management "divide and coquer"
Cc: <ipsec@lists.tislabs.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 7:12 PM -0700 8/15/01, Alex Alten wrote:
>At 01:20 AM 8/16/2001 +0100, Andrew Krywaniuk wrote:
>...
>>The IPsec WG has never been able to agree on requirements for anything. It
>>seems idealistic and naive to believe that we could start over with a brand
>>new KMP and acheive a different result. Like it or not, IKE was the
>>preordained result of a design by commitee,a political process. The
>>alternative to a committee process is a fascist process. Take your pick. I
>>personally don't like either committees or facism, but I'll take committees
>>any day of the week.
>...
>
>There is an alternative to committes or facism, the NIST approach (as in the
>AES "beauty contest"). Let's lay out the requirements, then hold a "beauty
>contest", and finally vote in a winner. This way we aren't getting the
>"design by committee" effect that simply does not work for a security
>oriented protocol.
>
>If you don't believe me, look what has happened to PEM, SNMPSEC, now IKE,
>and possibly IPSEC itself. DNSSEC may be the only recent success, and that
>was probably due to the small group involved. Our IETF WG consensus process
>which works well when designing an insecure protocol standard doesn't work
>properly when designing a secure protocol standard, at least not with a
>large group of stongly opinionated engineers.
>
>Let's learn from our mistakes and try an approach that seems to work,
>the NIST one.
>
Just a couple of observations:
NIST didn't have an open vote for AES. A small committee picked the winner.
DNSSEC is not being successful by almost any measure.
Steve
From owner-ipsec@lists.tislabs.com Thu Aug 16 07:40:25 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GEeON14545;
Thu, 16 Aug 2001 07:40:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12943
Thu, 16 Aug 2001 09:34:25 -0400 (EDT)
To: Stephen Kent <kent@bbn.com>
Cc: Henry Spencer <henry@spsystems.net>, ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
References: <Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net> <p0501040db7a0ac202a1b@[128.33.238.53]>
From: Derek Atkins <warlord@mit.edu>
Date: 16 Aug 2001 09:41:34 -0400
In-Reply-To: Stephen Kent's message of "Wed, 15 Aug 2001 18:52:58 -0400"
Message-ID: <sjmn1503ywh.fsf@rcn.ihtfp.org>
Lines: 27
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent <kent@bbn.com> writes:
> We disagree on the merits of opportunistic encryption. For most
> organizations, the primary threat is one of unauthorized access, not
> massive passive wiretapping of Internet traffic. Thus encrypting lost
> of traffic, without providing accompanying access controls, might
> cause more harm (in the access control dimension) than good, e.g., by
> making it harder to perform intrusion detection, trace attacks, etc.
> However, to the extent that FreeS/WAN tries to address a concern to a
> user community that has a different threat model, one that is more
> focused on big brother than on hackers, I don't argue with your
> approach.
This is certainly not MY memory from Cambridge '92, when the concept
of IPsec was to provide encryption technology at the network layer for
all connections on the Internet. A side effect of the goal was
endpoint authentication. Adding access control came even later.
> Steve
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Thu Aug 16 08:54:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GFsvN22238;
Thu, 16 Aug 2001 08:54:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13225
Thu, 16 Aug 2001 10:50:11 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696EE@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Stephen Kent'" <kent@bbn.com>,
"Hallam-Baker, Phillip"
<pbaker@verisign.com>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
Subject: RE: XKMS and NIH RE: Simplifying IKE
Date: Thu, 16 Aug 2001 07:57:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C12663.B68F31A0"
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_000_01C12663.B68F31A0
Content-Type: text/plain;
charset="iso-8859-1"
> There is a difference between by suggesting support for a set of IETF
> standards (the WG for which I do co-chair) vs. your promoting a
> VeriSign/Microsoft technology. Perhaps you find this difference too
> subtle, but I feel confident others on the list can make the
> distinction.
If you want to start flame wars I suggest that you try alt.flame.
The fact is that many if not most successful IETF protocols were
designed by a small group and then brought to the IETF for
standardization and change control. XKMS simply follows that tried
and tested method.
It is an open standard and has been submitted to a highly respected
standards body backed by the main PKI vendors and several major
customers.
The choice of W3C was determined by two factors, first XKMS is both
built on and designed to extend XML technology specified by W3C, the
second is that the consensus amongst the prospective members was that
W3C was the preferred forum.
I suggest that you bother to find out who is a prospective member of
the XKMS group before commenting on their security expertise.
Phill
------_=_NextPart_000_01C12663.B68F31A0
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C12663.B68F31A0--
From owner-ipsec@lists.tislabs.com Thu Aug 16 08:57:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GFvmN22809;
Thu, 16 Aug 2001 08:57:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13268
Thu, 16 Aug 2001 11:10:12 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696EF@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Stephen Kent'" <kent@bbn.com>,
"Hallam-Baker, Phillip"
<pbaker@verisign.com>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
Subject: Using XKMS to extend IPSEC PKI support and reduce complexity
Date: Thu, 16 Aug 2001 08:16:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C12666.78177F10"
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_000_01C12666.78177F10
Content-Type: text/plain;
charset="iso-8859-1"
[This is the substantive response for those who don't want to read
my responses to Steve's trolls and ad-hominem, those that do can
find them in my other post]
> Phill, you have never been a contributor in the IPsec area. Your
> comments in recent messages illustrate ignorance of the history of WG
> activities on which you now choose to comment. I don't find that
> constructive. We're trying to simplify IKE. if you propose support
> for XKMS as yet another PKI technology, that hardly amounts to
> simplification. If you suggest it as a replacement for the other
> technologies, that would call for discarding the PKI support that
> most vendors (that support PKI in IKE) already implement, which also
> seems questionable unless you can argue that XKMS is better in all
> respects.
That is not the proposal I made.
Suggesting that IPSEC rip out support for PGP and SPKI is a non-
starter. The probability of reaching consensus on the point is nil.
Even if there were the possibility of consensus I would not
support such a proposal.
XKMS provides a practical way to achieve two objectives, first to
allow IPSEC to be used with the full politically correct set of PKI.
Second and more important it means that vendors that currently
support very limited X.509 PKI can advance to provide full PKI
support without the significant increase in their code base and
configuration complexity that would entail.
At present IPSEC implementations are being used for the limited
purpose of securing VPNs. Many do not support certificate chaining,
I do not know of any that support the full PKIX stack.
I do not believe that an expensive router has any business
performing PKIX path math or public key cryptography. It is like
using a Ferrari to deliver milk.
Delegating key exchange to another box also makes sense.
Phill
------_=_NextPart_000_01C12666.78177F10
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C12666.78177F10--
From owner-ipsec@lists.tislabs.com Thu Aug 16 09:46:19 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GGkIN24227;
Thu, 16 Aug 2001 09:46:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13355
Thu, 16 Aug 2001 11:55:59 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15227.61087.646494.243710@thomasm-u1.cisco.com>
Date: Thu, 16 Aug 2001 09:02:39 -0700 (PDT)
To: Stephen Kent <kent@bbn.com>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen
t problems
In-Reply-To: <p05010403b7a09d9f2a5b@[128.33.238.53]>
References: <F86F34FDF1F9D411B7A40008C74C27B8028ADD@hhdata3.cdsemea.baltimore.com>
<15226.45614.601672.408572@thomasm-u1.cisco.com>
<p05010403b7a09d9f2a5b@[128.33.238.53]>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent writes:
> At 10:32 AM -0700 8/15/01, Michael Thomas wrote:
> Mike,
>
> Your understanding is not quite right. First, tunnel mode, while
> required for an SG, is also applicable to two hosts communicating.
> Second, IPsec supports authentication of symbolic names, not just IP
> addresses, which are dynamically bound to IP addresses for the
> duration of an SA.
My understanding is that the reality is somewhat
different. For example, I don't believe that I
can have a credential which is bound to a SPI
which spans multiple IP addresses concurrently. As
such it would only provide a single layer of
indirection. Maybe the DNS modes provide some of
this functionality, but I have doubts as to how
well supported or secure it is.
> This is how we support connections from mobile
> users, for example.
Mobile nodes use their home address, right? So
it's not an issue.
> The access control model that underlies IPsec is that one uses some
> means of authenticating a peer, e.g., via binding a signature key to
> an ID, traceable to a trust anchor, and that the traffic sent from
> and sent to the authenticated peer is subject to access controls
> expressed in the SPD. These controls apply not only to allowed IP
> addresses to/from which traffic may flow, but also protocols and port
> fields. The motivation for these other selectors is the same as in
> firewalls, i.e., we can control access to services based on access to
> well know ports.
Right... an authenticated firewall. That's pretty much
my understanding. This seems, well, of limited utility
for transport mode unless it can be tied to applications
(ie, in the same way that login names produce a mapping
to a GID/UID for file systems after login). Maybe I'm
just generally skeptical of integrated host firewalls
as being misguided, but that's probably just me.
Mike
From owner-ipsec@lists.tislabs.com Thu Aug 16 10:00:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GH0uN24575;
Thu, 16 Aug 2001 10:00:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13392
Thu, 16 Aug 2001 12:10:33 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15227.61959.609654.3723@thomasm-u1.cisco.com>
Date: Thu, 16 Aug 2001 09:17:11 -0700 (PDT)
To: Stephen Kent <kent@bbn.com>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Require AH?
In-Reply-To: <p0501040bb7a0aa66c22e@[128.33.238.53]>
References: <3B79500C.1367FCD3@storm.ca>
<200108141718.f7EHISo02668@kebe.east.sun.com>
<15226.35517.701351.186328@thomasm-u1.cisco.com>
<p0501040bb7a0aa66c22e@[128.33.238.53]>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent writes:
> At 7:44 AM -0700 8/15/01, Michael Thomas wrote:
> > Actually, what would make me most happy would be to
> > have a single IPsec extension header which does
> > *everything*. This helps on the code/message
> > compactness front, as well as simplifying the
> > number of SADB entries, different protocols
> > handling, header traversal, etc. It seems to me
> > that if we had modes like gzip-aes-cbc-sha1 for
> > ESP transforms, we could get rid of both AH and
> > IPCOMP.
> >
> > Mike
>
> This has been suggested before, and rejected. In large part AH is
> ugly because it tries to cover the IP header, but there are so many
> fields that cannot be covered. this makes processing slower than ESP
> auth only. tunnel mode of auth only ESP addresses essentially all of
> the IPv4 motivations for having AH. The only open question is what
> IPv6 requirements are met by AH and not by this mode.
>
> So, if we don't find a really good reason to retain AH, there is no
> good reason to create a new, different protocol to accommodate this
> combination of features. Also, this sort of new protocol would be
> more complex than either AH or ESP alone, which raises questions
> about whether we have achieved anything. One can argue that two
> protocols, each of which is relatively simple, are better than one
> protocol that is more complex.
There's quite a bit of complexity added by the
addition and processing of multiple headers, both
on the keying front and the kernel tasks. Interaction
between the modes/headers requires a lot of explanation in
2401, for example, and is frankly pretty confusing.
To my simple mind a single header and a single
transform of, say, compress-encrypt-hash would be
a lot more straighforward both on the understanding
and coding parts. As is right now, there are many
different ways to do the same thing, and it's possible
to get into non-sensical combinations such as compression
after encryption (even if the spec proscribes it).
Clearly, you could do such a bone headed thing with
a single spec, but right now you have to look and
understand many RFC's to grasp that proscription.
I doubt this is the only example. Also the degrees
of freedom afforded by multiple headers introduce
their own level of interoperability problems. An
implementation may very well, for example, have a
nice modular way of plugging in new crypto algorithms,
where it would be relatively simple to add a new
transform which, say, does aes/lzw. Adding IPCOMP,
however, has to be integrated into all of the
places that ESP was integrated. In my mind, that's
a false modularity since it leads to duplicated
processing (and the resultant possibility for
mistakes) with no substantive differention of
the code other than that of the gratuitous
design-by-committee kind.
Mike
From owner-ipsec@lists.tislabs.com Thu Aug 16 12:31:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GJVvN29639;
Thu, 16 Aug 2001 12:31:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13680
Thu, 16 Aug 2001 14:40:32 -0400 (EDT)
From: Steve.Robinson@psti.com
Subject: RE: Simplifying IKE
To: Stephen Kent <kent@bbn.com>
Cc: Chris Trobridge <CTrobridge@baltimore.com>, ipsec@lists.tislabs.com,
owner-ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
Message-ID: <OFF3B37AA0.8077B795-ON80256AAA.00674182@psti.com>
Date: Thu, 16 Aug 2001 14:51:43 -0400
X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at
08/16/2001 07:52:21 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent
<kent@bbn.com> To: Chris Trobridge <CTrobridge@baltimore.com>
Sent by: cc: ipsec@lists.tislabs.com
owner-ipsec@lists.t Subject: RE: Simplifying IKE
islabs.com
08/15/01 06:36 PM
>As an aside, is there a 'standard' way for an application to request a
>specific IPSEC policy for its traffic?
No. APIs for IPsec have not been standardized.
So, you wouldn't consider PF_KEY to be a standard API for use with IPsec?
I don't like it much personally, as it isn't as flexible as RFC 2401 would
allow an API to be, but still, it is there....
From owner-ipsec@lists.tislabs.com Thu Aug 16 12:35:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GJZeN29778;
Thu, 16 Aug 2001 12:35:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13802
Thu, 16 Aug 2001 14:58:52 -0400 (EDT)
X-Envelope-To: ipsec@lists.tislabs.com
To: ipsec@lists.tislabs.com
Path: not-for-mail
From: daw@mozart.cs.berkeley.edu (David Wagner)
Newsgroups: isaac.lists.ipsec
Subject: Re: Simplifying IKE
Date: 16 Aug 2001 19:02:43 GMT
Organization: University of California, Berkeley
Lines: 13
Distribution: isaac
Message-ID: <9lh5cj$hhq$1@abraham.cs.berkeley.edu>
References: <976979.997381032@el-air-2.electric-loft.org> <001801c1230f$3ca480e0$7a31788a@andrewk3.ca.newbridge.com>
NNTP-Posting-Host: mozart.cs.berkeley.edu
X-Trace: abraham.cs.berkeley.edu 997988563 17978 128.32.45.153 (16 Aug 2001 19:02:43 GMT)
X-Complaints-To: news@abraham.cs.berkeley.edu
NNTP-Posting-Date: 16 Aug 2001 19:02:43 GMT
X-Newsreader: trn 4.0-test74 (May 26, 2000)
Originator: daw@mozart.cs.berkeley.edu (David Wagner)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Andrew Krywaniuk wrote:
>I can't think of a realistic threat model that PFS solves.
Think of an IPSEC gateway that allows short-term tunnels for many laptops
in road-warrior configuration. Without PFS, if your gateway gets hacked,
the keys for every laptop that has ever used that gateway could become
compromised. With PFS, if your gateway gets hacked, only the keys for
the laptops currently using the gateway (during the time period until
the penetration is detected and repaired) are at risk.
I believe that PFS is a truly useful feature of IPSEC, and the decision
to provide PFS was well-discussed many years ago on this list, if I recall
correctly.
From owner-ipsec@lists.tislabs.com Thu Aug 16 12:43:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GJhYN29980;
Thu, 16 Aug 2001 12:43:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13830
Thu, 16 Aug 2001 15:08:34 -0400 (EDT)
Message-Id: <200108161914.f7GJEa011200@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: Steve.Robinson@psti.com
cc: Stephen Kent <kent@bbn.com>, Chris Trobridge <CTrobridge@baltimore.com>,
ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of "Thu, 16 Aug 2001 14:51:43 EDT."
<OFF3B37AA0.8077B795-ON80256AAA.00674182@psti.com>
Reply-to: sommerfeld@East.Sun.COM
Date: Thu, 16 Aug 2001 15:14:36 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> So, you wouldn't consider PF_KEY to be a standard API for use with IPsec?
> I don't like it much personally, as it isn't as flexible as RFC 2401 would
> allow an API to be, but still, it is there....
PF_KEY is not a policy API. It's an API for managing the SADB; as
such, it's useful only to the (very limited) set of people writing key
management implementations..
- Bill
From owner-ipsec@lists.tislabs.com Thu Aug 16 13:14:59 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GKEwN00681;
Thu, 16 Aug 2001 13:14:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13886
Thu, 16 Aug 2001 15:33:12 -0400 (EDT)
Message-Id: <200108161940.f7GJeZw13576@kebe.east.sun.com>
Subject: Re: Simplifying IKE
In-Reply-To: <OFF3B37AA0.8077B795-ON80256AAA.00674182@psti.com> from "Steve.Robinson@psti.com"
at "Aug 16, 2001 02:51:43 pm"
To: Steve.Robinson@psti.com
Date: Thu, 16 Aug 2001 15:40:35 -0400 (EDT)
CC: ipsec@lists.tislabs.com
From: Dan McDonald <danmcd@East.Sun.COM>
Organization: Sun Microsystems, Inc. - Solaris Internet Engineering
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> So, you wouldn't consider PF_KEY to be a standard API for use with IPsec?
> I don't like it much personally, as it isn't as flexible as RFC 2401 would
> allow an API to be, but still, it is there....
Bill already mentioned that PF_KEY is not the sort of policy API that people
have been talking about.
What people would like (I suspect) is something like my old "Simple IPsec
Socket API" or Craig Metz's later work that also includes QoS type features.
Basically, what I suspect people want would be a way to take a socket, and
say "Use IPsec for traffic on this socket," or ask "Does this socket secure
its traffic, and if so, how?"
To implement something even close to this requires a fully integrated IPsec
implementation. Examples I know of even simple IPsec socket options are in
the NRL code, Solaris 8 and beyond ("man ipsec" for docs), and the KAME code.
There may be others as well that I'm not aware of, and I'd like to hear about
them.
Dan
From owner-ipsec@lists.tislabs.com Thu Aug 16 15:24:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GMOKN02676;
Thu, 16 Aug 2001 15:24:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14106
Thu, 16 Aug 2001 17:36:15 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010401b7a1eca9f87c@[128.33.238.106]>
In-Reply-To: <sjmn1503ywh.fsf@rcn.ihtfp.org>
References: <Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net>
<p0501040db7a0ac202a1b@[128.33.238.53]> <sjmn1503ywh.fsf@rcn.ihtfp.org>
Date: Thu, 16 Aug 2001 17:42:32 -0400
To: Derek Atkins <warlord@mit.edu>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
deployment problems
Cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 9:41 AM -0400 8/16/01, Derek Atkins wrote:
>Stephen Kent <kent@bbn.com> writes:
>
>> We disagree on the merits of opportunistic encryption. For most
>> organizations, the primary threat is one of unauthorized access, not
>> massive passive wiretapping of Internet traffic. Thus encrypting lost
>> of traffic, without providing accompanying access controls, might
>> cause more harm (in the access control dimension) than good, e.g., by
>> making it harder to perform intrusion detection, trace attacks, etc.
>> However, to the extent that FreeS/WAN tries to address a concern to a
>> user community that has a different threat model, one that is more
>> focused on big brother than on hackers, I don't argue with your
>> approach.
>
>This is certainly not MY memory from Cambridge '92, when the concept
>of IPsec was to provide encryption technology at the network layer for
>all connections on the Internet. A side effect of the goal was
>endpoint authentication. Adding access control came even later.
>
Some may have come away with that impression. I certainly didn't. You
may recall that Ran Atkinson, who wrote the initial documents, noted
that he viewed IPsec ad modelled in large part on the SNDS SP3 work.
I participated in that work, and I can assure you that endpoint
authentication was an essential aspect of SP3.
I also recall that Steve Bellovin and I participated in a panel at
the National Computer Security Conference in the mid-90s, chaired by
Dorothy Denning, where the topic was "Will Encryption Thwart
Hackers." The panel was unanimous in agreeing that the answer was no,
for a variety of reasons that are still valid to day. I know of very
few folks in the (larger) Internet community who believe that the
principal threat is passive wiretapping of the Internet, vs.
unauthorized access to computing resources on organizational LANs.
Encryption of lots of Internet traffic, without accompanying
authentication and access control, does not address the latter
concern.
Steve
From owner-ipsec@lists.tislabs.com Thu Aug 16 15:24:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GMOlN02697;
Thu, 16 Aug 2001 15:24:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14122
Thu, 16 Aug 2001 17:42:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010402b7a1eeff84ed@[128.33.238.58]>
In-Reply-To:
<2F3EC696EAEED311BB2D009027C3F4F4058696EE@vhqpostal.verisign.com>
References:
<2F3EC696EAEED311BB2D009027C3F4F4058696EE@vhqpostal.verisign.com>
Date: Thu, 16 Aug 2001 17:47:31 -0400
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: XKMS and NIH RE: Simplifying IKE
Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>, ipsec@lists.tislabs.com,
owner-ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 7:57 AM -0700 8/16/01, Hallam-Baker, Phillip wrote:
> > There is a difference between by suggesting support for a set of IETF
>> standards (the WG for which I do co-chair) vs. your promoting a
>> VeriSign/Microsoft technology. Perhaps you find this difference too
>> subtle, but I feel confident others on the list can make the
>> distinction.
>
>If you want to start flame wars I suggest that you try alt.flame.
I stand by my characterization of the differences I mentioned.
>The fact is that many if not most successful IETF protocols were
>designed by a small group and then brought to the IETF for
>standardization and change control. XKMS simply follows that tried
>and tested method.
Maybe in your more limited experience, but when I look at the longer
time frame in which I've been involved, I don't come to the same
conclusion.
>It is an open standard and has been submitted to a highly respected
>standards body backed by the main PKI vendors and several major
>customers.
The IETF has traditionally not been swayed by this sort of
endorsement. You may recall that we represent ourselves in the IETF,
not our employers.
>The choice of W3C was determined by two factors, first XKMS is both
>built on and designed to extend XML technology specified by W3C, the
>second is that the consensus amongst the prospective members was that
>W3C was the preferred forum.
That's reasonable.
>I suggest that you bother to find out who is a prospective member of
>the XKMS group before commenting on their security expertise.
If you took the time to read my message, you would note that I didn't
comment on the security abilities of the XKMS developers, but rather
the W3C.
Steve
From owner-ipsec@lists.tislabs.com Thu Aug 16 15:31:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GMV2N02765;
Thu, 16 Aug 2001 15:31:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14170
Thu, 16 Aug 2001 17:55:02 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'David Wagner'" <daw@mozart.cs.berkeley.edu>, <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Thu, 16 Aug 2001 22:51:59 +0100
Message-Id: <000801c1269d$c15293e0$0109e982@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
In-Reply-To: <9lh5cj$hhq$1@abraham.cs.berkeley.edu>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Think of an IPSEC gateway that allows short-term tunnels for
> many laptops
> in road-warrior configuration. Without PFS, if your gateway
> gets hacked,
> the keys for every laptop that has ever used that gateway could become
> compromised.
Assuming that you never ever rekey phase 1 and no one ever disconnects...
> With PFS, if your gateway gets hacked, only the keys for
> the laptops currently using the gateway (during the time period until
> the penetration is detected and repaired) are at risk.
What you've just said exactly describes the security that IKE without PFS
provides.
IKE with PFS provides the additional feature that if you rekey phase 2s
faster than phase 1s then the damage will be limited to the last time you
rekeyed phase 2. That is, assuming that the attacker can't use your private
key and active phase 1&2 keys to launch an even more devastating attack.
> I believe that PFS is a truly useful feature of IPSEC, and
> the decision
> to provide PFS was well-discussed many years ago on this
> list, if I recall
> correctly.
In the context of SKIP, which didn't have a phase 1/phase 2 separation...
If the WG decides that PFS should be mandatory then I guess that is
marginally better than having to deal with the bizarre misconfiguration
problems that negotiated PFS causes. I suppose I should be supporting PFS
because it increases the cost of manufacturing an IPsec device, thus
increasing our margins. But it offends my moral sensibilities to standardize
a feature whose design goals are unsound.
I keep saying that people only want PFS because they don't really understand
the issues and they are seduced by the word "perfect" in the name. Then
people reply back to me and say that they do understand the issues and they
still believe PFS is necessary. But I still see lots of messages by people
who either don't understand that a) IKE has forward secrecy whether you use
*the PFS* feature or not, or b) doing a group 5 once an hour provides
stronger encryption than doing a group 2 once every 2 minutes.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
From owner-ipsec@lists.tislabs.com Thu Aug 16 16:01:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GN1kN03076;
Thu, 16 Aug 2001 16:01:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA14220
Thu, 16 Aug 2001 18:15:10 -0400 (EDT)
Date: Thu, 16 Aug 2001 18:21:20 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Stephen Kent <kent@bbn.com>
cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
In-Reply-To: <p05010401b7a1eca9f87c@[128.33.238.106]>
Message-ID: <Pine.BSI.3.91.1010816181922.27140B-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 16 Aug 2001, Stephen Kent wrote:
> ...unauthorized access to computing resources on organizational LANs.
> Encryption of lots of Internet traffic, without accompanying
> authentication and access control, does not address the latter concern.
And antiaircraft missiles aren't very effective against submarines, either!
Different solutions to different problems.
IPsec would not have encryption at all if passive wiretapping was not a
serious concern.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Thu Aug 16 19:30:52 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7H2UqN07101;
Thu, 16 Aug 2001 19:30:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14529
Thu, 16 Aug 2001 21:26:20 -0400 (EDT)
Message-Id: <3.0.3.32.20010816183119.00de5008@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Thu, 16 Aug 2001 18:31:19 -0700
To: Henry Spencer <henry@spsystems.net>, Stephen Kent <kent@bbn.com>
From: Alex Alten <Alten@home.com>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
deployment problems
Cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
In-Reply-To: <Pine.BSI.3.91.1010816181922.27140B-100000@spsystems.net>
References: <p05010401b7a1eca9f87c@[128.33.238.106]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 06:21 PM 8/16/2001 -0400, Henry Spencer wrote:
>On Thu, 16 Aug 2001, Stephen Kent wrote:
>> ...unauthorized access to computing resources on organizational LANs.
>> Encryption of lots of Internet traffic, without accompanying
>> authentication and access control, does not address the latter concern.
>
>And antiaircraft missiles aren't very effective against submarines, either!
>Different solutions to different problems.
>
>IPsec would not have encryption at all if passive wiretapping was not a
>serious concern.
>
You are both right. You need the encryption to properly enforce
the authentication and access control. In a trusted networked system
they are both required.
- Alex
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Fri Aug 17 06:18:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HDIGN22076;
Fri, 17 Aug 2001 06:18:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15785
Fri, 17 Aug 2001 08:31:56 -0400 (EDT)
Message-Id: <200108162023.f7GKN2d07469@marajade.sandelman.ottawa.on.ca>
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of "Tue, 14 Aug 2001 19:18:15 +0200."
<200108141718.f7EHIFu29709@givry.rennes.enst-bretagne.fr>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 16 Aug 2001 16:23:01 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Francis" == Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
MCR> {Has anyone considered putting IKE message inside of a TCP
MCR> option? This doesn't help keep the session private, but if the
MCR> point is to establish keying so that a Binding Update will work,
MCR> then this saves a bunch of latency. You just can't go fix the
MCR> triangle before your connection comes up... I keep thinking that
MCR> MIPv6 is the answer to multi6}
Francis> => as the context is IPv6 I think an extension header like the
Francis> destination option header (in final position) is far better for
Francis> this. But I don't like piggybacking for heavy weight protocols
Francis> (no clear pro, many cons like ROHC confusion, complexity, SPD
Francis> ambiguity, etc).
The reason for it to be a TCP option is so that one can make a strong
connection between the TCP sequence numbers and the IKE cookies. If the TCP
sequence numbers are considered strong enough for the connection (which is
true for a lot of connections today), then this gets you a bunch of help on
setting up the IKE. You may not need a global PKI to make it work if you can,
in this 80% situation leverage on top of what we already have.
(It does not cover the other 20% which does require a higher level of
trust)
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO3wro4qHRg3pndX9AQFDwQP8D52ltMWZX2ZUTpvkrX7GJi59zocu9A7h
IzarR0VpB5aEgZ7zjnRD37Y361XCi3PDUSR6Wp+D9ossU4YIs9y9YP9uz7simtUG
VfpTo3pirXrZcBCQ0y+idSwA8TmtJOv38wW+ihUZWNMt+P2hd2ZVOJl39AS+OsHH
kRNrn1+UCWQ=
=HImr
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Fri Aug 17 06:18:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HDIKN22086;
Fri, 17 Aug 2001 06:18:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15784
Fri, 17 Aug 2001 08:31:51 -0400 (EDT)
Message-Id: <200108162042.f7GKgwg08115@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0
In-reply-to: Your message of "13 Aug 2001 13:37:01 EDT."
<sjmd75z7tfm.fsf@rcn.ihtfp.org>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 16 Aug 2001 16:42:57 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Derek" == Derek Atkins <warlord@mit.edu> writes:
Derek> For NAT traversal, I think it is eminently ideal for the keying
Derek> and data streams to share a port.. Otherwise you need twice as
Derek> many keepalives to keep the NAT mapping happy.
Why do we have to keep the NAT mapping for the IKE stream port alive?
It isn't like the "gateway" is going to be able to initiate to the client
unless the client cooperates.
The only real thing that has to be done is to have the responder reply to
the origin port each time. We already know that the Internet dies in the
presence of an active attack (you can just drop all packets!), so I do not
see why we should worry about keeping the same port for IKE.
Derek> Speaking as the chair of KINK, I'd like to make sure that KINK
Derek> does a similar transposition. I can certainly see carrying ESP
Derek> within KINK-like UDP messages on the KINK port.
For the firewall point of view, this really sucks.
For the non-security related NAT, who cares?
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO3wwUIqHRg3pndX9AQGErAP+MdlBXt6901sQUoqK8o3cZFisDDGCqvtQ
UEwEoeckT4ujeI2RP/Y1pK7MsYoIOVzUgzo5fg2W66kGxN0r6GnxjxLsHC1z2rbG
vMlsP7QTug0QcyF/UOJQMi0Ar4fvh1y05MdknbvPBoWDtw23z9jNj6EHQW1KcNmk
3UPDijwsqNs=
=3LMi
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Fri Aug 17 06:18:24 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HDINN22099;
Fri, 17 Aug 2001 06:18:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15765
Fri, 17 Aug 2001 08:30:50 -0400 (EDT)
Message-Id: <200108162003.f7GK3mc06802@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
In-reply-to: Your message of "Sat, 11 Aug 2001 13:14:00 PDT."
<15221.37384.191416.901953@thomasm-u1.cisco.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 16 Aug 2001 16:03:47 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Michael" == Michael Thomas <mat@cisco.com> writes:
Henry> We thought about that, but decided that some authentication was better
Henry> than none, especially since it would upgrade transparently to full
Henry> authentication. It's one thing to accept security loopholes as a
Henry> temporary measure, and another to define a protocol that will always
Henry> have security loopholes.
Michael> Well... How is this especially different than just using
Michael> self-signed certificates and having a wide open policy? I don't
Michael> think there's anything protocolwise that even needs to be done
Michael> there. Clearly you can upgrade that by using rooted certs in the
Michael> future as well.
Agreed.
Nor is there anything protocol-wise that needs to be done to use DNS. The
difference is that DNS, via DNSSEC, provides a theorectical upgrade path to
get some additional authentication.
For those that do control their reverse map, the reverse map does provide a
way to point towards a gateway box. In an end-game situation where all hosts
do IPsec, this may no longer be necessary. This is the one advantage that DNS
currently has over self-signed certificates.
Michael> I guess what bothers me is that you are expecting to use DNS as
Michael> a directory service for certs which it wasn't really intended
Michael> for thus making an already complicated situation even more
I'm not sure that I agree that DNS was not meant for storing certificates.
I think that this facility has been in DNSSEC for some time now. It has not
been widely deployed yet.
Michael> I guess that I view that there's probably an 80/20 rule here
Michael> which is being missed: *most* people aren't going to go to the
Michael> lengths of creating an active MITM attack to snoop on boring old
Michael> every day conversations. Thus encrypting everything -- by
Michael> accepting MITM attacks where there is no pragmatic alternative
Michael> -- will kill off all of the passive snooping. Given the advent
So, I think that we are open to this view. We call it "anonymous encryption"
although this term has been said to be confusing.
In the draft we are attempting to document what FreeSWAN does *NOW*.
If there is interest in enhancing this, that should be the subject of a
future draft.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO3wnIYqHRg3pndX9AQEMOAQAvsYeCLjaw9s9p35xiAGnP0lg4hdugOnX
IWwwjxUswevKa/piHZLQHVH8r8iVy/iMFBTRdAIfdJq6MihKoGXjtEORvL+0k+nA
9UE0Th80Ks+PNUNs+ziXj2gY7SbB75Ebw9q2wpBSj3yz1p4eYJVJJxjmnWy630Tp
LcwwLiQAyAY=
=/dy+
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Fri Aug 17 06:18:27 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HDIQN22111;
Fri, 17 Aug 2001 06:18:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15791
Fri, 17 Aug 2001 08:32:49 -0400 (EDT)
Subject: RFC-2451
Date: Fri, 17 Aug 2001 10:54:04 +0900
MIME-Version: 1.0
Content-Type: text/plain;
charset="euc-kr"
Message-ID: <04ADDBBB4C7EBF468E3DF355B750195E0E0335@file.initech.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
Thread-Topic: RFC-2451
Thread-Index: AcEmv5dDVdH0bLEhSOe81zXwz+SpQw==
From: =?euc-kr?B?vNsgwM6xxw==?= <songa@initech.com>
To: <ipsec@lists.tislabs.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id VAA14553
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi.
While I have been reading a RFC-2451, found a some problem.
Between Page7 and Page8, a size of Initialization Vector is 8byte from
a picture.
But, a top part of Page8, "IV field MUST be same size as the block size
of the cipher algorithm being used." is written.
So, what is correct? I think that the picture is wrong.
From owner-ipsec@lists.tislabs.com Fri Aug 17 06:18:46 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HDIkN22131;
Fri, 17 Aug 2001 06:18:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15783
Fri, 17 Aug 2001 08:31:50 -0400 (EDT)
Message-Id: <200108162011.f7GKB4k07041@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Reply-To: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
cc: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
In-reply-to: Your message of "Tue, 14 Aug 2001 14:36:32 +0200."
<200108141236.f7ECaWu09104@givry.rennes.enst-bretagne.fr>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 16 Aug 2001 16:11:04 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Francis" == Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
Francis> In your previous mail you wrote:
MAT> Also: I think the MIP experience sez that we ought to consider
MAT> whether we'd want such a PKI even if it were possible.
Francis> => we leave the technical domain there... I've never seen a
Francis> rational argument about this!
But, back to a technical question.
If I have just dialed up to an ISP and been assigned an IP address, how can
I prove that I'm the legitimate owner of that IP address?
(PPPoE makes "dialup" still a part of many high speed connections now...)
If this is a cooperative ISP, they could issue me a short-lifetime
certificate attesting to this. Perhaps this should be done at the PPP layer
rather than IP as this assures link layer integrity, but that likely is not
as easy to deploy as using a standard enrolment protocol over TCP.
A note: Mobile IP does not need this at all unless your "home address" is
a dialup.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO3wo14qHRg3pndX9AQEakgQA6Eb46iqYMinzRsPkJbJjKct/1/mTVaBa
LyE+F5TjSqoUZp7qksNtS/XIK4aOZL0wBu5FqgmLX8m8QGIOcRuCjZBEPXEuppgZ
0IdoknBZEQZYzydZ8DAvBGhgxvFei/ExxNeN0NWSX9Iq2BVEEqGIa7HHBiGt2n/R
gF3uUFxptyA=
=7WQk
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Fri Aug 17 07:36:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HEamN23466;
Fri, 17 Aug 2001 07:36:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16135
Fri, 17 Aug 2001 09:49:12 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696FB@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: ipsec@lists.tislabs.com
Subject: RE: XKMS and NIH RE: Simplifying IKE
Date: Fri, 17 Aug 2001 06:54:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C12724.29385C70"
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_000_01C12724.29385C70
Content-Type: text/plain;
charset="iso-8859-1"
> If you took the time to read my message, you would note that I didn't
> comment on the security abilities of the XKMS developers, but rather
> the W3C.
Institutions don't have expertise, people do. The only difference between
the W3C process and IETF process is that in W3C process Jeff and Marcus
have effective veto power on security grounds for any protocol. In W3C
Tim Berners-Lee has veto power but he is not a security specialist.
One of the reasons I have brought XKMS to the attention of this group is
to increase the number of people who are aware of XKMS and might review
it.
Phill
------_=_NextPart_000_01C12724.29385C70
Content-Type: application/octet-stream;
name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
filename="Phillip Hallam-Baker (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:hallam@verisign.com
REV:20010214T163732Z
END:VCARD
------_=_NextPart_000_01C12724.29385C70--
From owner-ipsec@lists.tislabs.com Fri Aug 17 07:43:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HEhSN24447;
Fri, 17 Aug 2001 07:43:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16167
Fri, 17 Aug 2001 10:01:41 -0400 (EDT)
Message-ID: <153101c12726$48cb0630$b81c550a@cisco.com>
From: "Stephane Beaulieu" <stephane@cisco.com>
To: <ipsec@lists.tislabs.com>,
"Michael Richardson" <mcr@sandelman.ottawa.on.ca>
References: <200108162042.f7GKgwg08115@marajade.sandelman.ottawa.on.ca>
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0
Date: Fri, 17 Aug 2001 10:09:52 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Derek> For NAT traversal, I think it is eminently ideal for the keying
> Derek> and data streams to share a port.. Otherwise you need twice as
> Derek> many keepalives to keep the NAT mapping happy.
>
> Why do we have to keep the NAT mapping for the IKE stream port alive?
>
> It isn't like the "gateway" is going to be able to initiate to the
client
> unless the client cooperates.
The gateway might need to initiate a rekey, or even send some sort of
keepalive / DPD packet (even though none have been standardized at the
moment), or for that fact some sort of Informational message (INVALID SPI?).
>
> The only real thing that has to be done is to have the responder reply
to
> the origin port each time. We already know that the Internet dies in the
> presence of an active attack (you can just drop all packets!), so I do not
> see why we should worry about keeping the same port for IKE.
>
> Derek> Speaking as the chair of KINK, I'd like to make sure that KINK
> Derek> does a similar transposition. I can certainly see carrying ESP
> Derek> within KINK-like UDP messages on the KINK port.
>
> For the firewall point of view, this really sucks.
>
> For the non-security related NAT, who cares?
>
> ] ON HUMILITY: to err is human. To moo, bovine. |
firewalls [
> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net
architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[
> ] panic("Just another NetBSD/notebook using, kernel hacking, security
guy"); [
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
> Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
>
> iQCVAwUBO3wwUIqHRg3pndX9AQGErAP+MdlBXt6901sQUoqK8o3cZFisDDGCqvtQ
> UEwEoeckT4ujeI2RP/Y1pK7MsYoIOVzUgzo5fg2W66kGxN0r6GnxjxLsHC1z2rbG
> vMlsP7QTug0QcyF/UOJQMi0Ar4fvh1y05MdknbvPBoWDtw23z9jNj6EHQW1KcNmk
> 3UPDijwsqNs=
> =3LMi
> -----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Fri Aug 17 09:05:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HG55N01209;
Fri, 17 Aug 2001 09:05:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16300
Fri, 17 Aug 2001 11:21:40 -0400 (EDT)
Message-Id: <200108171407.f7HE7co03553@road.xisp.net>
To: ietf-sectest@lists.freeswan.org
Cc: design@lists.freeswan.org, ipsec@lists.tislabs.com
Subject: Reincarnation of an old list, IETF-sectest
Reply-To: hugh@xisp.net
Date: Fri, 17 Aug 2001 17:07:37 +0300
From: Hugh Daniel <hugh@road.bakeoff.ipsec.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
At the IKE/IPsec/etc. Bakeoff here in Helsinki today it was strongly
stated, and the community agreed, that we should have an email list
for talking about and doing testing of IKE, IPsec etc. in 'real' time
over the net between bakeoffs, and to talk about better testing
methodology's, standards etc.
I started one of these lists, <ietf-sectest@toad.com> after the San
Jose IETF just for this sort of work, but it was way too early as no
one had anything to test. So just now I restarted this list over on
lists.freeswan.org (a host in the free world where DMCA etc. is less
of an issue, maybe...).
At the time I created the first version of the list I got permission
to use the IETF- tag on the list and since I am just moving the list
to a different host I am keeping the name the same.
So the list is now called <IETF-sectest@lists.freeswan.org>, though
I did make an alias of <sectest@lists.freeswan.org> just for the
absent minded, and is open to the entire community to post to, read
the archives of etc.
There is a web page for this list with subscription interface,
archives and other functions over at:
http://lists.freeswan.org/mailman/listinfo/ietf-sectest
The list may also be subscribed to via email, find out how with this
command:
mail -s help ietf-sectest-request@lists.freeswan.org < /dev/null
Note that issues that are not IKE, IPsec etc. _testing_ related
should be discussed over on the main IPsec list over on the main IPsec
list at <ipsec@lists.tislabs.com>.
||ugh Daniel
hugh@freeswan.org
Systems Testing & Project mis-Management
The Linux FreeS/WAN Project
http://www.freeswan.org
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.
iQCVAwUBO30lH1ZpdJR7FBQRAQGTLAP/YYG2HZmbQHXM3PfMMD0FPw4GhQBPzDo1
B3w9lO6rFZYC0qB6FuhrmvVA/tUDCFgTg/5B+/5hl7jtAOeTOvYsvMxr9fIdmcRG
xV5INRAgGAULwgDlmpQ7Pu3U+DrlnLa54qCmholyYQCETJXcjLiCZVFq+8G8xxlr
AcB0OSwMabU=
=42nS
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Fri Aug 17 09:53:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HGrKN02062;
Fri, 17 Aug 2001 09:53:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16473
Fri, 17 Aug 2001 12:15:41 -0400 (EDT)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05100304b7a2f3c90e2e@[165.227.249.20]>
In-Reply-To:
<2F3EC696EAEED311BB2D009027C3F4F4058696FB@vhqpostal.verisign.com>
References:
<2F3EC696EAEED311BB2D009027C3F4F4058696FB@vhqpostal.verisign.com>
Date: Fri, 17 Aug 2001 09:22:48 -0700
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: RE: XKMS and NIH RE: Simplifying IKE
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 6:54 AM -0700 8/17/01, Hallam-Baker, Phillip wrote:
> The only difference between
>the W3C process and IETF process is that in W3C process Jeff and Marcus
>have effective veto power on security grounds for any protocol. In W3C
>Tim Berners-Lee has veto power but he is not a security specialist.
This is completely wrong on many counts.
- Jeff and Marcus only have "veto power" for WG items moving to IETF last call.
- During IESG review, every IESG member has partial veto power (you
need more than one to "veto" a draft).
- IETF WG chairs have pretty significant "veto power", more than area
directors do early in the process.
- In the W3C, there are many people (in particular, WG chairs) who
have effective veto power throughout the process.
Playing "my standards body is better than your standards body" is a
boring game, particularly when the people you are playing it with
don't know the facts.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Fri Aug 17 10:14:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HHEYN02607;
Fri, 17 Aug 2001 10:14:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16510
Fri, 17 Aug 2001 12:32:57 -0400 (EDT)
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
References: <Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net> <p0501040db7a0ac202a1b@[128.33.238.53]> <sjmn1503ywh.fsf@rcn.ihtfp.org> <p05010401b7a1eca9f87c@[128.33.238.106]>
From: Derek Atkins <warlord@mit.edu>
Date: 17 Aug 2001 12:40:07 -0400
In-Reply-To: Stephen Kent's message of "Thu, 16 Aug 2001 17:42:32 -0400"
Message-ID: <sjmu1z63ajc.fsf@rcn.ihtfp.org>
Lines: 44
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent <kent@bbn.com> writes:
> I also recall that Steve Bellovin and I participated in a panel at
> the National Computer Security Conference in the mid-90s, chaired by
> Dorothy Denning, where the topic was "Will Encryption Thwart
> Hackers." The panel was unanimous in agreeing that the answer was no,
> for a variety of reasons that are still valid to day. I know of very
> few folks in the (larger) Internet community who believe that the
> principal threat is passive wiretapping of the Internet, vs.
> unauthorized access to computing resources on organizational LANs.
> Encryption of lots of Internet traffic, without accompanying
> authentication and access control, does not address the latter
> concern.
I think that 'universal encryption' and 'universal authentication' are
two different and separable problems. Indeed, I think we've found
that universal authentication is a HARD problem, whereas 'universal
encryption' does not appear to be quite as hard (albeit with some
limited protections).
>From where I sit, I passive eavesdropping is a major issue. Is it the
only issue, hell no. However, just look at all the password-sniffing
attacks that have happened over the years. An attacker somehow gets
into an account, sets up a sniffer, and then collects other passwords
for other break-ins. If universal encryption had been deployed (even
unauthenticated DH), these sniffers would have been ineffective.
Would it have solved the authentication problems? No, of course not.
But does that mean that encryption is useless by itself? No, of
course not. It would have solved a subset of the problems, and that
by itself is a worthwhile goal.
We cannot build a panacea. No such beast exists, and looking for that
perfect solution will, in the end, cause us to have none.
> Steve
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Fri Aug 17 10:18:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HHILN02689;
Fri, 17 Aug 2001 10:18:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16529
Fri, 17 Aug 2001 12:37:42 -0400 (EDT)
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0
References: <200108162042.f7GKgwg08115@marajade.sandelman.ottawa.on.ca>
From: Derek Atkins <warlord@mit.edu>
Date: 17 Aug 2001 12:44:50 -0400
In-Reply-To: Michael Richardson's message of "Thu, 16 Aug 2001 16:42:57 -0400"
Message-ID: <sjmsneq3abh.fsf@rcn.ihtfp.org>
Lines: 34
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
> Why do we have to keep the NAT mapping for the IKE stream port alive?
Because IPsec (and IKE) are peer-to-peer protocols and not
client-server protocols? NAT forces a client-server protocol (only
the client, sitting behind the NAT, can initiate connections). What
happens if the server wants to initiate a rekey? Or needs to notify
the client IKE daemon of some importation information (e.g. "I'm going
away -- delete your SA!").
> It isn't like the "gateway" is going to be able to initiate to the client
> unless the client cooperates.
No, but while the client is connected the "gateway" may still have
something to say _during_ the conversation.
> The only real thing that has to be done is to have the responder reply to
> the origin port each time. We already know that the Internet dies in the
> presence of an active attack (you can just drop all packets!), so I do not
> see why we should worry about keeping the same port for IKE.
Yes, this should certainly be the case. One should respond to the
source port/IP that is in the received packet. But that is a
completely separate issue from over-loading IKE (or KINK) and ESP onto
the same UDP port.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Fri Aug 17 12:31:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HJVuN04978;
Fri, 17 Aug 2001 12:31:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16739
Fri, 17 Aug 2001 14:21:35 -0400 (EDT)
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0
References: <200108171738.f7HHcPC02529@marajade.sandelman.ottawa.on.ca>
From: Derek Atkins <warlord@mit.edu>
Date: 17 Aug 2001 14:15:40 -0400
In-Reply-To: Michael Richardson's message of "Fri, 17 Aug 2001 13:38:25 -0400"
Message-ID: <sjmhev63643.fsf@rcn.ihtfp.org>
Lines: 69
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
> >> It isn't like the "gateway" is going to be able to initiate to the client
> >> unless the client cooperates.
>
> Derek> No, but while the client is connected the "gateway" may still have
> Derek> something to say _during_ the conversation.
>
> So, it says it. If the NAT has timed out, it creates a new source
> port. The gateway updates its notion of where the client is if
> the ISAKMP packets decrypts properly.
Except if the NAT times out there is NO WAY for the "gateway" to send
the IKE message to the "client". Sure, if the "client" is the
initiator of the new message then we don't have a problem, but the
whole point was that the "server" may need to initiate re-key or other
notification messages while the IKE SA is alive.
> Well, the argument for overloading is that it reduces the number of keepalives.
> a) I question the need to keep the NAT mapping for the IKE port alive.
Ok, your question is acknowledged. Others believe that the "server"
IKE daemon may need to communicate with the "client" IKE daemon for
server-initiated re-key or notification messages. You may disagree
with that, but the consensus seems to be that such communication is
required.
> b) if you wish, the second keepalive should not hurt anyone.
So now you're doubling the number of "keepalive" packets? Worse, you
are now _FORCING_ keepalives on the IKE port (because IKE is only
rarely used, most of the traffic on the IKE port will be keepalives,
in your model).
At least if you overload ESP onto the same port as IKE then any 'real'
traffic will automatically act as your keepalive. That means you only
need to send out additional keepalives when you don't have any other
outgoing traffic. Similarly, you have a direct binding between IKE
and ESP.
What happens if your ESP binding disappears and IKE doesn't? Or
worse, what happens if your IKE binding disappears and ESP doesn't?
Moreover, how are you supposed to tell your peer what the ESP port
will be? If you're behind a NAT box, you have no idea what port
your peer will see.
At least if you overload onto IKE, you already know the port number.
Otherwise, the client would have to send an ESPoUDP packet to the
server on some other port but somehow tie the existing IKE negotiation
onto that other port? Gee, now THERE'S a reduction in complexity for
you -- dynamically changing port addresses.
> If having everyone behind the NAT keep two ports on the NAT alive
> kills the NAT box... well... uh... (I'm trying to make a sad face,
> but it doesn't seem to work)
Have you ever had a NAT box (that you do NOT control) fail on your in
the middle of your session? If you had, you would't be so quick to
judge. Are NATs evil? Yes. But they're an evil we have to live with
so long as "we" don't control the connectivity we're given (e.g. at a
conference).
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Fri Aug 17 12:35:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HJZnN05027;
Fri, 17 Aug 2001 12:35:49 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16832
Fri, 17 Aug 2001 14:53:27 -0400 (EDT)
Message-Id: <200108171738.f7HHcPC02529@marajade.sandelman.ottawa.on.ca>
To: Derek Atkins <warlord@mit.edu>
cc: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0
In-reply-to: Your message of "17 Aug 2001 12:44:50 EDT."
<sjmsneq3abh.fsf@rcn.ihtfp.org>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 17 Aug 2001 13:38:25 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Derek" == Derek Atkins <warlord@MIT.EDU> writes:
Derek> Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
>> Why do we have to keep the NAT mapping for the IKE stream port alive?
Derek> Because IPsec (and IKE) are peer-to-peer protocols and not
Derek> client-server protocols? NAT forces a client-server protocol (only
Derek> the client, sitting behind the NAT, can initiate connections). What
right, so let's not pretend that we need to retain the peer-to-peer ness.
Derek> happens if the server wants to initiate a rekey? Or needs to notify
Derek> the client IKE daemon of some importation information (e.g. "I'm going
Derek> away -- delete your SA!").
Fine.
>> It isn't like the "gateway" is going to be able to initiate to the client
>> unless the client cooperates.
Derek> No, but while the client is connected the "gateway" may still have
Derek> something to say _during_ the conversation.
So, it says it.
If the NAT has timed out, it creates a new source port. The gateway updates
its notion of where the client is if the ISAKMP packets decrypts properly.
>> The only real thing that has to be done is to have the responder reply to
>> the origin port each time. We already know that the Internet dies in the
>> presence of an active attack (you can just drop all packets!), so I do not
>> see why we should worry about keeping the same port for IKE.
Derek> Yes, this should certainly be the case. One should respond to the
Derek> source port/IP that is in the received packet. But that is a
Derek> completely separate issue from over-loading IKE (or KINK) and ESP onto
Derek> the same UDP port.
Well, the argument for overloading is that it reduces the number of keepalives.
a) I question the need to keep the NAT mapping for the IKE port alive.
b) if you wish, the second keepalive should not hurt anyone.
If having everyone behind the NAT keep two ports on the NAT alive kills the
NAT box... well... uh... (I'm trying to make a sad face, but it doesn't seem to work)
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO31WkIqHRg3pndX9AQEKjAP/Sw19BZiBb8WwDpYWc2CQH7qZtmWo+F9k
KKjj/rhSo4emSeMWKnACB9acSxPl8e6/HWkvDQxM2BedkC2cBsme0FiwsXTyD8++
PhRGGo+DjHCnFdzmNEqaQ3avukkwBfn1uAC8rPuvX0lI9iBcMzZlr2xSoI7u518T
M2bJQQw0OXM=
=ddTb
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Fri Aug 17 12:45:00 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HJj0N05155;
Fri, 17 Aug 2001 12:45:00 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16830
Fri, 17 Aug 2001 14:53:26 -0400 (EDT)
Message-Id: <200108171716.f7HHGWt01905@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0
In-reply-to: Your message of "Fri, 17 Aug 2001 10:09:52 EDT."
<153101c12726$48cb0630$b81c550a@cisco.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 17 Aug 2001 13:16:31 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Stephane" == Stephane Beaulieu <stephane@cisco.com> writes:
Derek> For NAT traversal, I think it is eminently ideal for the keying
Derek> and data streams to share a port.. Otherwise you need twice as
Derek> many keepalives to keep the NAT mapping happy.
>>
>> Why do we have to keep the NAT mapping for the IKE stream port alive?
>>
>> It isn't like the "gateway" is going to be able to initiate to the
Stephane> client
>> unless the client cooperates.
Stephane> The gateway might need to initiate a rekey, or even send some sort of
Stephane> keepalive / DPD packet (even though none have been standardized at the
Stephane> moment), or for that fact some sort of Informational message
Stephane> (INVALID SPI?)
The only valid reason is the rekey.
The keepalive will obviously, keep the port alive.
I just do not see the problem.
Running IPsec packets over the same port is just *UGLY*.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
From owner-ipsec@lists.tislabs.com Fri Aug 17 12:45:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HJjoN05189;
Fri, 17 Aug 2001 12:45:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16885
Fri, 17 Aug 2001 14:57:46 -0400 (EDT)
Message-Id: <200108170658.f7H6wO015624@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: andrew.krywaniuk@alcatel.com
cc: "'David Wagner'" <daw@mozart.cs.berkeley.edu>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of "Thu, 16 Aug 2001 22:51:59 BST."
<000801c1269d$c15293e0$0109e982@andrewk3.ca.newbridge.com>
Reply-to: sommerfeld@East.Sun.COM
Date: Fri, 17 Aug 2001 02:58:24 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Andrew,
You've been using sloppy terminology again ;-)
IKE always provides PFS in phase 1 with a "scope" of that PFS being
the IKE SA and all IPsec SA's derived from it; you get the benefit of
PFS for old keys once the IKE SA's shared secret is destroyed *and*
all the IPsec SA's derived from it are destroyed.
IKE optionally *also* provides PFS in phase 2 with per-IPsec-SA scope.
The value of phase-2 PFS is extremely low in typical IKE
configurations where the IPsec SA's live as long as or longer than the
IKE SA.
- Bill
From owner-ipsec@lists.tislabs.com Fri Aug 17 16:03:56 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HN3uN08463;
Fri, 17 Aug 2001 16:03:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17165
Fri, 17 Aug 2001 18:19:03 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010401b7a31e059152@[128.33.238.58]>
In-Reply-To:
<F86F34FDF1F9D411B7A40008C74C27B8028ADF@hhdata3.cdsemea.baltimore.com>
References:
<F86F34FDF1F9D411B7A40008C74C27B8028ADF@hhdata3.cdsemea.baltimore.com>
Date: Fri, 17 Aug 2001 15:20:10 -0400
To: Chris Trobridge <CTrobridge@baltimore.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen
t problems
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 8:27 AM +0100 8/16/01, Chris Trobridge wrote:
> > From: Stephen Kent [mailto:kent@bbn.com]
>> At 6:11 PM +0100 8/15/01, Chris Trobridge wrote:
>> >I think the problem is not specifically "global PKI" but
>> "global trust
>> >infrastructure".
>>
>> I think "trust" is largely an irrelevant term here. If one wants to
>> identify hosts by DNS name, there is an established, strict hierarchy
>> that we all rely on. It's authoritative. It's not a matter of trust.
>
>I think we may arguing over language here - I still see this as a
>hierarchical system of trust.
X.509 is not intrinsically hierarchic, although it is often portrayed
as such. PGP makes a point out of being non-hierarchic. DNSSEC is
clearly hierarchic, although folks are working on ways to deviate
from that. But, if one looks at the form of identifies that we are
using in IPsec, most of them are drawn from a hierarchic name space,
and that makes it more likely that a certification system will
parallel the name space and thus become hierarchic, in whole are
part. Consider DNS names, RFC822 names, IPaddresses, ...
>
>> >It would be useful if IKE could use different trust models, including
>> >delegation this to another protocol.
>>
>> IKE defines very little about what one does with its varied set of
>> potential PKI technologies, so I don't think this is a relevant
>> criticism.
>
>I may be guilty of confusing what I know is being done with IKE vs what it
>is capable of.
>
yes, that may be the source of confusion.
Steve
From owner-ipsec@lists.tislabs.com Fri Aug 17 16:03:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HN3vN08468;
Fri, 17 Aug 2001 16:03:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17140
Fri, 17 Aug 2001 18:18:06 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010406b7a308055fdc@[128.33.238.58]>
In-Reply-To: <15227.61959.609654.3723@thomasm-u1.cisco.com>
References: <3B79500C.1367FCD3@storm.ca>
<200108141718.f7EHISo02668@kebe.east.sun.com>
<15226.35517.701351.186328@thomasm-u1.cisco.com>
<p0501040bb7a0aa66c22e@[128.33.238.53]>
<15227.61959.609654.3723@thomasm-u1.cisco.com>
Date: Fri, 17 Aug 2001 13:53:37 -0400
To: Michael Thomas <mat@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Require AH?
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 9:17 AM -0700 8/16/01, Michael Thomas wrote:
>Stephen Kent writes:
> > At 7:44 AM -0700 8/15/01, Michael Thomas wrote:
> > > Actually, what would make me most happy would be to
> > > have a single IPsec extension header which does
> > > *everything*. This helps on the code/message
> > > compactness front, as well as simplifying the
> > > number of SADB entries, different protocols
> > > handling, header traversal, etc. It seems to me
> > > that if we had modes like gzip-aes-cbc-sha1 for
> > > ESP transforms, we could get rid of both AH and
> > > IPCOMP.
> > >
> > > Mike
> >
> > This has been suggested before, and rejected. In large part AH is
> > ugly because it tries to cover the IP header, but there are so many
> > fields that cannot be covered. this makes processing slower than ESP
> > auth only. tunnel mode of auth only ESP addresses essentially all of
> > the IPv4 motivations for having AH. The only open question is what
> > IPv6 requirements are met by AH and not by this mode.
> >
> > So, if we don't find a really good reason to retain AH, there is no
> > good reason to create a new, different protocol to accommodate this
> > combination of features. Also, this sort of new protocol would be
> > more complex than either AH or ESP alone, which raises questions
> > about whether we have achieved anything. One can argue that two
> > protocols, each of which is relatively simple, are better than one
> > protocol that is more complex.
>
> There's quite a bit of complexity added by the
> addition and processing of multiple headers, both
> on the keying front and the kernel tasks. Interaction
> between the modes/headers requires a lot of explanation in
> 2401, for example, and is frankly pretty confusing.
> To my simple mind a single header and a single
> transform of, say, compress-encrypt-hash would be
> a lot more straighforward both on the understanding
> and coding parts. As is right now, there are many
> different ways to do the same thing, and it's possible
> to get into non-sensical combinations such as compression
> after encryption (even if the spec proscribes it).
If we do away with AH, then this discussion is moot re AH+ESP. In the
early days of deployment, I saw folks doing both AH+ESP, but today I
think this is rarely the case, i.e., most traffic is just ESP (auth +
encrypt). As noted earlier, the most credible requirement for AH
seems to be an IPv6 mobility one. if I understand this requirement
correctly, one would have to employ different keys for encryption and
endpoint integrity/authentication vs. intermediate node
authentication, assuming a desire for normal e-t-e security as well,
and this would make for a pretty complex individual protocol and a
matching, complex key management activity.
> Clearly, you could do such a bone headed thing with
> a single spec, but right now you have to look and
> understand many RFC's to grasp that proscription.
> I doubt this is the only example. Also the degrees
> of freedom afforded by multiple headers introduce
> their own level of interoperability problems. An
> implementation may very well, for example, have a
> nice modular way of plugging in new crypto algorithms,
> where it would be relatively simple to add a new
> transform which, say, does aes/lzw. Adding IPCOMP,
> however, has to be integrated into all of the
> places that ESP was integrated. In my mind, that's
> a false modularity since it leads to duplicated
> processing (and the resultant possibility for
> mistakes) with no substantive differention of
> the code other than that of the gratuitous
> design-by-committee kind.
the decision to make compression separate from encryption was one
that this WG, and the security ADs, made a long time ago. modularity
does have a price, as you noted, but it's a price we have often
elected to accept in Internet protocols.
Steve
From owner-ipsec@lists.tislabs.com Fri Aug 17 16:06:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HN6GN08503;
Fri, 17 Aug 2001 16:06:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17152
Fri, 17 Aug 2001 18:18:30 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010400b7a2fcf2f580@[128.33.238.58]>
In-Reply-To: <Pine.BSI.3.91.1010816181922.27140B-100000@spsystems.net>
References: <Pine.BSI.3.91.1010816181922.27140B-100000@spsystems.net>
Date: Fri, 17 Aug 2001 12:59:33 -0400
To: Henry Spencer <henry@spsystems.net>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
deployment problems
Cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 6:21 PM -0400 8/16/01, Henry Spencer wrote:
>On Thu, 16 Aug 2001, Stephen Kent wrote:
>> ...unauthorized access to computing resources on organizational LANs.
>> Encryption of lots of Internet traffic, without accompanying
>> authentication and access control, does not address the latter concern.
>
>And antiaircraft missiles aren't very effective against submarines, either!
>Different solutions to different problems.
>
>IPsec would not have encryption at all if passive wiretapping was not a
>serious concern.
>
Passive wiretapping is a concern, in some contexts, and thus it is
appropriate to offer encryption as part of the IPsec suite of
security services. The difference of opinion is whether it is always
necessary or always helpful.
Most security experts agree that pervasive use of encryption via SSL
for web access does little to protect credit card numbers from being
stolen; there are much better ways to steal these values. SSL use
does address the marketing need to provide the perception of security
for users who might otherwise be reluctant to send these values
across the Internet. In the IPsec WG I assume that we will adopt
standards based on technical benefits, rather than marketing concerns.
Steve
From owner-ipsec@lists.tislabs.com Fri Aug 17 16:07:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HN7JN08534;
Fri, 17 Aug 2001 16:07:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17147
Fri, 17 Aug 2001 18:18:28 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010402b7a2fef36dd4@[128.33.238.58]>
In-Reply-To: <3.0.3.32.20010816183119.00de5008@mail>
References: <p05010401b7a1eca9f87c@[128.33.238.106]>
<3.0.3.32.20010816183119.00de5008@mail>
Date: Fri, 17 Aug 2001 13:05:18 -0400
To: Alex Alten <Alten@home.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
deployment problems
Cc: Henry Spencer <henry@spsystems.net>, ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 6:31 PM -0700 8/16/01, Alex Alten wrote:
>At 06:21 PM 8/16/2001 -0400, Henry Spencer wrote:
>>On Thu, 16 Aug 2001, Stephen Kent wrote:
>>> ...unauthorized access to computing resources on organizational LANs.
>>> Encryption of lots of Internet traffic, without accompanying
>>> authentication and access control, does not address the latter concern.
>>
>>And antiaircraft missiles aren't very effective against submarines, either!
>>Different solutions to different problems.
>>
>>IPsec would not have encryption at all if passive wiretapping was not a
>>serious concern.
>>
>
>You are both right. You need the encryption to properly enforce
>the authentication and access control. In a trusted networked system
>they are both required.
>
>- Alex
Alex,
in fact, we use the integrity algorithm to provide continuity for the
initial authentication exchange provided by IKE, not encryption.
Steve
From owner-ipsec@lists.tislabs.com Fri Aug 17 16:11:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HNBBN08661;
Fri, 17 Aug 2001 16:11:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17161
Fri, 17 Aug 2001 18:18:58 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010402b7a31f04cd10@[128.33.238.58]>
In-Reply-To:
<F86F34FDF1F9D411B7A40008C74C27B8028AE0@hhdata3.cdsemea.baltimore.com>
References:
<F86F34FDF1F9D411B7A40008C74C27B8028AE0@hhdata3.cdsemea.baltimore.com>
Date: Fri, 17 Aug 2001 15:50:46 -0400
To: Chris Trobridge <CTrobridge@baltimore.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Simplifying IKE
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 8:35 AM +0100 8/16/01, Chris Trobridge wrote:
> > -----Original Message-----
>> From: Stephen Kent [mailto:kent@bbn.com]
>>
>> we disagree. firewalls typically make access control decisions based
>> on unauthenticated data from packet headers. IPsec makes these
>> decisions based on authenticated identities and mutually enforced
>> constraints on these packet headers. in that regard, the access
>> control services are far superior to what is provided by freestanding
>> firewalls.
>
>I was assuming you take all these things together. If tunnel SAs are
>treated as interfaces by the firewall then it can enforce the IPSEC
>constraints.
yes, it can, so long as the SA tagging is maintained on received
packets after they exit IPsec processing.
> > >As an aside, is there a 'standard' way for an application to
>> request a
>> >specific IPSEC policy for its traffic?
>>
>> No. APIs for IPsec have not been standardized.
>
>I think this might be one of the reasons why IPSEC hasn't taken off so
>widely. I wouldn't know how to create a socket with a particular IPSEC
>policy.
>
>SSL managed to fit much better into applications and is widely used - even
>if some of the fundamentals are not as strong (which also helped it...).
>
SSL is implemented above TCP, and thus outside the OS, and that makes
it easier for applications to link in and use it. The prominent use
of SSL, from a deployment standpoint, also arises because it comes
for free in the two main browsers that are available in essentially
all user computers. Finally, web access that is SSL protected is a
tiny fraction of all web access, and the encryption (and one-way
authentication) it provides are often more for show than for
substance. You cite the lack of an IPsec API as a hindrance, but
what's the API provided by SSL for applications?
Steve
From owner-ipsec@lists.tislabs.com Fri Aug 17 16:13:59 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HNDwN08817;
Fri, 17 Aug 2001 16:13:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17216
Fri, 17 Aug 2001 18:38:47 -0400 (EDT)
Message-Id: <3.0.3.32.20010817154347.00b6ff30@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Fri, 17 Aug 2001 15:43:47 -0700
To: Stephen Kent <kent@bbn.com>
From: Alex Alten <Alten@home.com>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
deployment problems
Cc: Henry Spencer <henry@spsystems.net>, ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
In-Reply-To: <p05010402b7a2fef36dd4@[128.33.238.58]>
References: <3.0.3.32.20010816183119.00de5008@mail>
<p05010401b7a1eca9f87c@[128.33.238.106]>
<3.0.3.32.20010816183119.00de5008@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 01:05 PM 8/17/2001 -0400, Stephen Kent wrote:
>At 6:31 PM -0700 8/16/01, Alex Alten wrote:
>>At 06:21 PM 8/16/2001 -0400, Henry Spencer wrote:
>>>On Thu, 16 Aug 2001, Stephen Kent wrote:
>>>> ...unauthorized access to computing resources on organizational LANs.
>>>> Encryption of lots of Internet traffic, without accompanying
>>>> authentication and access control, does not address the latter concern.
>>>
>>>And antiaircraft missiles aren't very effective against submarines, either!
>>>Different solutions to different problems.
>>>
>>>IPsec would not have encryption at all if passive wiretapping was not a
>>>serious concern.
>>>
>>
>>You are both right. You need the encryption to properly enforce
>>the authentication and access control. In a trusted networked system
>>they are both required.
>>
>>- Alex
>
>Alex,
>
>in fact, we use the integrity algorithm to provide continuity for the
>initial authentication exchange provided by IKE, not encryption.
>
>Steve
>
Thank you Steve for pointing this out. I realized that I had not mentioned
integrity as soon as I had sent the email. However certainly encryption is
(almost) without exception a "must have" component of any secure network
system.
My point is that we need all of them to build a properly secure network
system,
none them can stand alone. I think even you can agree on this point.
- Alex
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Fri Aug 17 16:20:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HNKqN08945;
Fri, 17 Aug 2001 16:20:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17211
Fri, 17 Aug 2001 18:38:37 -0400 (EDT)
Message-ID: <3B7D9E8D.E5F5EFFB@F-Secure.com>
Date: Sat, 18 Aug 2001 01:45:33 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Derek Atkins <warlord@mit.edu>
CC: Michael Richardson <mcr@sandelman.ottawa.on.ca>, ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of ,
i-cookie=0
References: <200108171738.f7HHcPC02529@marajade.sandelman.ottawa.on.ca> <sjmhev63643.fsf@rcn.ihtfp.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Derek Atkins wrote:
>
> Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
>
> > >> It isn't like the "gateway" is going to be able to initiate to the client
> > >> unless the client cooperates.
> >
> > Derek> No, but while the client is connected the "gateway" may still have
> > Derek> something to say _during_ the conversation.
> >
> > So, it says it. If the NAT has timed out, it creates a new source
> > port. The gateway updates its notion of where the client is if
> > the ISAKMP packets decrypts properly.
>
> Except if the NAT times out there is NO WAY for the "gateway" to send
> the IKE message to the "client". Sure, if the "client" is the
> initiator of the new message then we don't have a problem, but the
> whole point was that the "server" may need to initiate re-key or other
> notification messages while the IKE SA is alive.
It's also relatively evil if the client is thinking it has a working phase 1 SA,
when in fact it's dead due to an expired NAT table somewhere in the network.
This can of course be solved, but the simplest way is to have that NAT mapping
not expire.
At the Helsinki bakeoff there were seven implementations of the latest drafts,
including us. Additional three had implementations of some earlier draft.
This would be a good time for someone to provide really solid arguments
against using just one port, if such arguments exist. Like, statistical
calculations of actual overhead. The firewall-argument doesn't cut it, it
cannot understand either of the traffic streams even if they are separate,
and must just allow them through.
Ari
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
From owner-ipsec@lists.tislabs.com Fri Aug 17 16:28:22 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HNSLN09073;
Fri, 17 Aug 2001 16:28:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17259
Fri, 17 Aug 2001 18:47:32 -0400 (EDT)
Message-ID: <3B7DA0A7.9405DB0E@F-Secure.com>
Date: Sat, 18 Aug 2001 01:54:31 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
CC: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Require AH?
References: <3B79500C.1367FCD3@storm.ca>
<200108141718.f7EHISo02668@kebe.east.sun.com>
<15226.35517.701351.186328@thomasm-u1.cisco.com>
<p0501040bb7a0aa66c22e@[128.33.238.53]>
<15227.61959.609654.3723@thomasm-u1.cisco.com> <p05010406b7a308055fdc@[128.33.238.58]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent wrote:
>
> If we do away with AH, then this discussion is moot re AH+ESP. In the
> early days of deployment, I saw folks doing both AH+ESP, but today I
> think this is rarely the case, i.e., most traffic is just ESP (auth +
> encrypt). As noted earlier, the most credible requirement for AH
> seems to be an IPv6 mobility one. if I understand this requirement
> correctly, one would have to employ different keys for encryption and
> endpoint integrity/authentication vs. intermediate node
> authentication, assuming a desire for normal e-t-e security as well,
> and this would make for a pretty complex individual protocol and a
> matching, complex key management activity.
I could buy AH if it just authenticated everything that is BEHIND it.
This way it could be used to protect IPv6 options if necessary, without
having to worry about NAT boxes modifying the IP address. Just put
authenticated ones behind, and unauthenticated ones in front. And forget
about IPv4 options. And arbitrary rules as to what is or is not authenticated.
Disclaimer: I don't use IPv6.
Ari
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
From owner-ipsec@lists.tislabs.com Sat Aug 18 13:22:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IKMZN02358;
Sat, 18 Aug 2001 13:22:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18337
Sat, 18 Aug 2001 15:12:12 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="ks_c_5601-1987"
Subject: RE: RFC-2451
Date: Sat, 18 Aug 2001 12:21:00 -0700
Message-ID: <4EBB5C35607E7F48B4AE162D956666EF3391B6@guam.corp.axcelerant.com>
Thread-Topic: RFC-2451
Thread-Index: AcEmv5dDVdH0bLEhSOe81zXwz+SpQwBW5b8Q
From: "Christopher Gripp" <cgripp@axcelerant.com>
To: "? ??" <songa@initech.com>, <ipsec@lists.tislabs.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA18334
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The the answer is the picture and the statement are correct and nothing
is wrong.
All the ciphers in that document use an 8 byte block size.
Christopher Gripp
Systems Engineer
Axcelerant
-----Original Message-----
From: songa@initech.com [mailto:songa@initech.com]
Sent: Thursday, August 16, 2001 6:54 PM
To: ipsec@lists.tislabs.com
Subject: RFC-2451
Hi.
While I have been reading a RFC-2451, found a some problem.
Between Page7 and Page8, a size of Initialization Vector is 8byte from
a picture.
But, a top part of Page8, "IV field MUST be same size as the block size
of the cipher algorithm being used." is written.
So, what is correct? I think that the picture is wrong.
From owner-ipsec@lists.tislabs.com Sat Aug 18 13:22:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IKMcN02370;
Sat, 18 Aug 2001 13:22:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18330
Sat, 18 Aug 2001 15:02:55 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: VPN subnet mask
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Date: Sat, 18 Aug 2001 12:11:44 -0700
Message-ID: <4EBB5C35607E7F48B4AE162D956666EF3391B5@guam.corp.axcelerant.com>
Thread-Topic: VPN subnet mask
Thread-Index: AcElhOaXoDsGxY11SC6d5PLpoD5o8QClQLHg
From: "Christopher Gripp" <cgripp@axcelerant.com>
To: "shiwen chen" <sxc4305@yahoo.com>, <ipsec@lists.tislabs.com>
Cc: <vpn@secruityfocus.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA18327
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
That would be making a large leap in assumption about the use of that
netmask being strictly limited to those applications. Which it isn't.
But if it is a controlled environment where you know that if the mask =
32bits then they are running the PPTP/IPsec client I don't see why you
wouldn't be able to utilize it.
-----Original Message-----
From: shiwen chen [mailto:sxc4305@yahoo.com]
Sent: Wednesday, August 15, 2001 5:21 AM
To: Christopher Gripp; ipsec@lists.tislabs.com
Cc: vpn@secruityfocus.com
Subject: RE: VPN subnet mask
Thanks a lot.
I have seen three vendors' VPNs are using this
255.255.255.255 mask (including IPSec, PPTP). Remote
clients are run with Microsoft Windows 2000. So I
think it is quite a conventional way (if not standard)
for VPN configurations, isn't it?.
Suppose I have an application on remote access client,
can I use this information to detect if the local
computer is on VPN or not?
Regards,
Shiwen
--- Christopher Gripp <cgripp@axcelerant.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> That's used to explicitily define that single host.
> Without other
> info I can't tell you why it is configured that way
> on your VPN.
> What VPN are you using? What OS are you running,
> etc.
>
> Christopher S. Gripp
> Systems Engineer
> Axcelerant
>
>
> - -----Original Message-----
> From: shiwen chen [mailto:sxc4305@yahoo.com]
> Sent: Tuesday, August 14, 2001 2:01 PM
> To: ipsec@lists.tislabs.com
> Subject: VPN subnet mask
>
>
> Hi,
> I am learning VPN here. Could anybody please tell me
> why the subnet mask for an VPN client address is
> "255.255.255.255"? Thanks a lot.
>
> Regards,
> Shiwen
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute
> with Yahoo!
> Messenger
> http://phonecard.yahoo.com/
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use
> <http://www.pgp.com>
>
>
iQA/AwUBO3mu/2LRPLnfp/zREQJZrwCg/uLeFpKIdgqwSbcm9AGX20aLKPEAoJMb
> ardg+mhUBOjrnDDB5qCpfey7
> =Y3K0
> -----END PGP SIGNATURE-----
>
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
From owner-ipsec@lists.tislabs.com Sat Aug 18 14:04:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IL4aN02766;
Sat, 18 Aug 2001 14:04:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA18424
Sat, 18 Aug 2001 16:21:39 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: <sommerfeld@East.Sun.COM>
Cc: "'David Wagner'" <daw@mozart.cs.berkeley.edu>, <ipsec@lists.tislabs.com>
Subject: RE: Simplifying IKE
Date: Sat, 18 Aug 2001 21:19:24 +0100
Message-Id: <001901c12823$28dad140$6831788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <200108170658.f7H6wO015624@thunk.east.sun.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Andrew,
>
> You've been using sloppy terminology again ;-)
Or rather, the IKE RFC uses sloppy terminology and I was just repeating it.
I thought it was clear from the earlier messages in this thread that I meant
PFS as defined in IKE and not PFS in general.
> IKE always provides PFS in phase 1 with a "scope" of that PFS being
> the IKE SA and all IPsec SA's derived from it; you get the benefit of
> PFS for old keys once the IKE SA's shared secret is destroyed *and*
> all the IPsec SA's derived from it are destroyed.
>
> IKE optionally *also* provides PFS in phase 2 with per-IPsec-SA scope.
>
> The value of phase-2 PFS is extremely low in typical IKE
> configurations where the IPsec SA's live as long as or longer than the
> IKE SA.
Yes, that's my point (or most of it anyway).
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
From owner-ipsec@lists.tislabs.com Mon Aug 20 04:08:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KB8kN11020;
Mon, 20 Aug 2001 04:08:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA20826
Mon, 20 Aug 2001 05:42:12 -0400 (EDT)
Message-ID: <1D82815C322BD41196EA00508B951F7B02DADBE4@MCHH265E>
From: Bungert Michael <Michael.Bungert@icn.siemens.de>
To: "'Sara Bitan'" <sarab@cs.Technion.AC.IL>
Cc: ipsec@lists.tislabs.com
Subject: AW: Traffic handling and key management "divide and coquer"
Date: Mon, 20 Aug 2001 11:47:35 +0200
X-MS-TNEF-Correlator: <1D82815C322BD41196EA00508B951F7B02DADBE4@MCHH265E>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01C1295D.23BC39C0"
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_000_01C1295D.23BC39C0
Content-Type: text/plain;
charset="windows-1255"
Hi Sara,
comments below
>
>
> I think that we are at a crucial point where we can make a
> change that will
> turn our work to more focused and efficient, and hopefully fruitful. I
> suggest we use a "divide and conquer" strategic.
> We should first of all separate IPsec transforms traffic
> handling (i.e. ESP
> and AH) and key management work to different WGs (if I
> understand right,
> this was raised by JI in the SAAG meeting).
> This process is already happening as we speak - MSEC and KINK
> are working on
> key management protocols that create IPsec SAs, with different
> requirements. ESP and AH will still be used for traffic handling.
> If we will do the separation, we will soon be able to tell
> the industry that
> the work on the IPsec transforms is done, which I think will
> be a great
> advantage.
>
> I think we should also allow for several key management protocols,
> preferably with one framework.
> This is the only way we will be able to cater for the
> requirements of "DSL
> geeks" as well as "billion mobile users" (quoting Jari's words).
Michael: I also believe that it will not be possible to define a less complex KMP that meets all the requirements of the IPsec community (IKE is so complex because it tries to do so). It seems to be reasonable to develop more focused protocols in different WGs. But, I'm also convinced that a 'default' (mandatory ?) KMP (IKE v2?) for IPsec is necessary in order to guarantee secure operation and interoperability (IPsec is useless without KMP and the security relies upon the security of the KMP). This protocol should be designed to meet only a limited basic set of requirements with security as the most important one (it should be formaly analysed). For me it is not important if this protocol is developed in the IPsec WG or in a different one. It is important that there is a default KMP for IPsec that is secure, that is suitabe for many scenarios and that is implemented by most of the IPsec products. I think that the proposed new charter is a good starting point: we will have to !
!
!
use IKE for a longer period of time and it makes sense to improve it; OTOH we should start the development of a less complex and more secure protocol. The first and most important step is a clear definition of the requirements. If application scenarios arise with new requirements new protocols can be developed by suitable WGs.
>
> There are several actions that we need to take for this to happen:
> 1) Allow working groups other than IPsec to work on key management
> protocols, this way we could shut down the IPsec WG and keep
> on working on
> new key management protocols. As I said this is already happening.
> 2) Limit IPsec wg to only on the following IKE modifications : NAT
> traversal, SCTP support and re-keying. The new IKE version
> should be a minor
> version including only minor fixes (as outlined in the new suggested
> charter).
Michael: I do not mind if the IPsec WG only adds minor changes to the current IKE or if the WG also should develop the new KMP for IPsec (see above).
> 3) Re-assure ourselves that the interface between transforms and key
> management is clearly defined, and general enough to allow
> for the addition
> of new key management protocols, without having to change the
> transforms.
Michael: I agree.
> 4) Have a framework protocol for key management - I think it
> should be based
> on ISAKMP. There is no need to re-invent transforms and
> proposals syntax for
> each new key management protocol.
Michael: I'm not sure if this really makes sense.
> 5) Have different requirements for different key management
> protocols. With
> one common requirement - they should all create IPsec SAs.
Michael: I would like to add the requirement that they should all undergo careful security analysis (formal analysis ?). I don't want to sell IPsec products that will be broken because one of the implemented KMPs was poorly designed.
> This way we could
> have one requirements document include Identity protection,
> and allow for a
> larger number of messages, and another that has no Identity Protection
> requirement, and requires a small number of message. We can
> also have one or
> several WGs in charge of the key management protocols.
>
> Sara.
Michael
------_=_NextPart_000_01C1295D.23BC39C0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64
eJ8+IisJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcIABQACwAvACMAAQBSAQEggAMADgAAANEHCAAU
AAsALwAqAAEAWQEBCYABACEAAAAxNEJEREI3NDQzOTVENTExOTcxNzAwNTA4Qjk1MUY3QgABBwEE
gAEAPAAAAEFXOiBUcmFmZmljIGhhbmRsaW5nIGFuZCBrZXkgbWFuYWdlbWVudCAiZGl2aWRlIGFu
ZCBjb3F1ZXIiAOoUAQ2ABAACAAAAAgACAAEDkAYAKA8AADAAAAADAN4/5wQAAAMAAIAIIAYAAAAA
AMAAAAAAAABGAAAAAFKFAAA/cQEAHgABgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAA
OS4wAAsADYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYA
AAAAAYUAAAAAAAALAAOACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsABIAIIAYAAAAAAMAA
AAAAAABGAAAAAA6FAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAaACCAG
AAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMACIAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAA
AgEJEAEAAADKCQAAxgkAAFwTAABMWkZ1TlTs3AMACgByY3BnMTI14jUDQ3RleAVBAQMB9wcKgAKk
A+REYXZpZE8CgA/zAFAEVk1pByFtsCBGaXgJgBElMgLjCQIAY2gKwHNldDI3BgAGwxElMwRGE8cw
IL8IVQeyAoARMwjvCfc7GC93DjERIgxgYwBQCwkBZDNGNhZgC6YgSGkGAXK8YSwK4wqECoAFoG0H
gFMCMAQgYmUXwHcdmj5DHYUf+EkgdGgLgGvFISFhBUB3ZSAKwCHxOQVAYSAFABrgBzEgcHZvC4Ah
wWgEkCHwIeFjOwORAMBrIfEgBxPhbmffIfAhlAMQGBAfpXQIcAOg7whhIdAFsCFxbyRABbAh8KkC
EGN1FCBkIgBuKIA/AREN4AiQAjAdcCiiaG9qcAEQdSYgeSgQIrBpGwAwKiAuIQAflnN1Zx0lgHMh
wyhRInEiZGlPEPEh8SixBaBucQpQcloiK5B0HVAOsGcN4C71H5ZXIfBzKdAqICiAKQBzFBAFQG9m
IgAmICuQZdcKsS4xIQBQFCBjISAdUPMAgAIQcm0EIC4RKPIgBwklUWRsC4BnIChpxC5lKvBFU1Af
liii8EFIKSAokyRwKlADgf5hJYAegidHLMABICOhI1F8V0cEIDPAMDAhEB+WdZ8osASQK/AoogUQ
Z2gpYOcmRyFABCB3YQQgHVAEAPUocWIqUEohEAuAISEh8LBTQUFHJEAJ4HQzgaopLpdUOnJwA2Bj
B5DPBCA6gQdAGDBhZCpQE/C+cCnwAwAzkTrBIeFzKfBJJGAgLQXRRUMok0v4SU5LIAciEidSM4IC
IP8fljWtPeEnoBehMhEhogUA9z7AMPc8MHMdcCXxITA3CN8flhgwLaASQDYzczQDNMX/JfMt8Uli
HuAsQi+hBbEyNrszNi6XSTAwIeFJU2QnsDs78jCVaQIgHXBMhnNv9wIgSfIBoGwlkU0RHvADIfc5
9yHwC4BkKFAuECpQIZJ/UAonU07RO/IxLzqBTQBu/mVOESFAE+AhB0lTH5ZPAu4gCcFReD7QdgBw
AZAlgP8ulyCeP+IvZAdATrAwQh8Q+0pzFCB2BJAi8UNfRGU51/894AEQW2ECYCpQRmNUYSph/xJw
B9AnYT0MOoE78gIgXkL+YV5RTJVPCSQQDrAFwEqDDzwBR08eojAhIkRTTOMfliWAZWtzLeA/szBh
+TrBImImEU3hJ8Fm8SwzuxQQLeAoLaBEYDOCSgrAzGknOpEFsGRzPPYdlPcSMBPhHvA6IQFaQx7h
CJDvW1AhhCqgSURuRGBJ8iMg/QQQaU9FAQELgCSCT1AEEe8eUQtQDsBBEE1IwCGTPIL/PnIDIDvy
ZA5S2B5SONAqoOEqUChJS0U+Ulphbub/HuAkECxSbFEuEAiQMhE28f8nsE6wPPAhAAVAFCA2MHUz
f0oBPrFOsDYAbZdbUBfAcJ8nzERIO8E3GyrwQnUpYbxJJxKAWkMtcRDwbj4QNyiAIZMigCcBAXRw
bHR2JzOwA4FkIbAFsCpQP+c1MG9icxN2Mn4hSoJTFP86gVRwPhIKwCpQO8FpYRbR+SehZ3UdQQIw
CeAwgShA/yIhKeFNtCiTI0EEkIJzZvH/ctR/hihRbpNGYghgBUBvYv8ook00giFy0hgwa6GE4SMg
/zvUhsdxpW9hddE9lkRzL0b3SgEBAACQZ1RwfEEnsTyR/2DUbnEHcCqgOzI6wDKBFCH/MBJkC0Zj
hsc6wTvyBGAr8f8HcCMgACBXsV6zM8B2EYqn/zHSB0CMcTYAKkAoYXXREpD/BbEHgGxCf9Js4ZB4
OAE6Y/+KB1Qid+QocTvFUxQ3sIDB/zuyIoA3GFRhdeNgQpCHIZP/O/EiIT5ibfJ9Em9TfzhsBP9z
cYITHXCc1yqRAaCSEzXS/ypQBPAJ8GjxbVCGNZz0kHF/T1Aegjs0kCNxqz3hUOBj/0hiIRs78j3h
bUEocVRwB+D3E+JiwpsjZ07AKIA5IQAg/zOCIyNq8EyGE/Br0iewLFL/cyJKgm5xAiAlgAXAgoFN
4P8ogHGiB3GDBG/RJGGdMgCAH09jkHEDYGvRKqA7IE/8VE9JMS83pnM743fVNkP/MCJujCiiJ9OC
BURGiZIoAb8v07BEkEsr8DCgmxRjT1D/CsFuAyqgZzJxpUfMTFE/If8zcGKhZzKfaQUQLGFGY6US
/2QLpRJESCQSiwOWhjthnlT/T1F6kh8/PUUjoiISWzYA0P9N0kTFIeFUcIuUAZAkcWMEV2ByJ7A/
FDofljE1MEHvWqNCNgnACGBwZLGawiGC/wOgUxUnsFJWNaxdSFzGOla3YVMFoK2DaIXRTQB3lx3/
NWSz0R+WTtFCP6UDW79EZf8q8EYQIQGAUBEAOlQ+b0ua2jI1MEyMwlMFdzOgJ6H/YONSpQIQWqIz
gnMiBGEGkMe3JQQgavBOQVQmRx1Qi1tRgFBsHXBTQ1RIwN8roD8wF9EokxgwLTWhS5L/sdOlEn6j
OQFnMisniqcigPuM0GzQch+W2aZ8AQpALMD/QoMqQdtjL7ESwDfROsGFwf8zcZbYpRIrpQmAJMml
gmmv/2q2TQFs0tthgzFxupfSjFP+ZGmA3ZUlRHUzO/KCITdj/3MimAJxtMqiWlIvVXfW32Z9m/wo
djFPIaxR4Wwf8DP9NTBS2EA6wCuggkIIcIURf1tQRMVQhGLBfQA+EB7RdP8h4AnwMXo1ZR+WNek6
gbRT+ypBbgRkKXQlgFRwW3IJ8P8IYDmgJ5JalB+WYwblAbUD/8tnMDDNP1yKhXen8TOCYnJ/JVZj
aDGI4X9qxgnCvO00/TUwSKgCIoBfB4n4SoI1rX9AcCEWbFHaL40i4FhO0Un/PDBvYbHDmvRs0MBn
2DELgH9bUJpC76zHGW1BWkErkHn/V8FvQOoxwnY+wFTh9x9EKP/772rEe0Fs0uzzlSY+sSoy+6sp
vO01/rU3GGQL6jI3GPc1rccfKvBXRnHLaMjiHnD/BGFHyUBhO/GfQVnmVcBFPv8q8Aw/atQnUC+C
M3AkcfRS/+UQtY6aZxhbONOmICQBXdHvKiCPGZLDOoEokjQgqH4g+6NSVFEnwCGaM3WRT8KifPu/
5UnFYoOQwRBO4nRkXsL/caWgym9hOpSnAKkA8mOLVP+87T2TyJoyuGvRXsJkC00A/3jA8ZTcw1Lx
bgABcHLSREKvghBN1DRaWphhwnZstID9qYJuLZDvEKkQ9uGqgIBBf+AR8wSU4MR3+VIFgy53UL8v
F2OPAXDzBEfFtBJzkmH/bLEyPhWxFrG68VcHWlIsB//bmL72epHfIqVS+lFxpQq/f86GWC5F8E2h
DC9qwcJ0fQFCsAAAHgBwAAEAAAA4AAAAVHJhZmZpYyBoYW5kbGluZyBhbmQga2V5IG1hbmFnZW1l
bnQgImRpdmlkZSBhbmQgY29xdWVyIgACAXEAAQAAABsAAAABwSSg4JN8xioEkJIR1bQNAAjHDfE6
AS0/xUAAAwAuAAAAAAALAAIAAQAAAB4AQhABAAAAJwAAADwwMDM5MDFjMTI0OWQkODZiMWE4ZTAk
MDMwMDAwMGFAYmlsYm8+AAADAP0/5AQAAAMACVkBAAAAQAA5AMA5vCNdKcEBAwDxPwcEAAAeADFA
AQAAAAkAAABCTTA0MTI1NAAAAAADABpAAAAAAB4AMEABAAAACQAAAEJNMDQxMjU0AAAAAAMAGUAA
AAAAAwAmAAAAAAADADYAAAAAAAMAgBD/////CwDyEAEAAAACAUcAAQAAAC8AAABjPURFO2E9REJQ
O3A9U0NOO2w9TUNISDI2NUUtMDEwODIwMDk0NzM1Wi0yNTcyAAACAfk/AQAAAEsAAAAAAAAA3KdA
yMBCEBq0uQgAKy/hggEAAAAAAAAAL089U0NOL09VPURFTUNISDIwMUUvQ049UkVDSVBJRU5UUy9D
Tj1CTTA0MTI1NAAAHgD4PwEAAAAQAAAAQnVuZ2VydCBNaWNoYWVsAB4AOEABAAAACQAAAEJNMDQx
MjU0AAAAAAIB+z8BAAAASwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1TQ04vT1U9
REVNQ0hIMjAxRS9DTj1SRUNJUElFTlRTL0NOPUJNMDQxMjU0AAAeAPo/AQAAABAAAABCdW5nZXJ0
IE1pY2hhZWwAHgA5QAEAAAAJAAAAQk0wNDEyNTQAAAAAQAAHMK5FCyFdKcEBQAAIMP4N9iddKcEB
HgA9AAEAAAAFAAAAQVc6IAAAAAAeAB0OAQAAADgAAABUcmFmZmljIGhhbmRsaW5nIGFuZCBrZXkg
bWFuYWdlbWVudCAiZGl2aWRlIGFuZCBjb3F1ZXIiAB4ANRABAAAANAAAADwxRDgyODE1QzMyMkJE
NDExOTZFQTAwNTA4Qjk1MUY3QjAyREFEQkU0QE1DSEgyNjVFPgALACkAAAAAAAsAIwAAAAAAAwAG
EGK6hscDAAcQKw0AAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISVNBUkEsQ09NTUVOVFNC
RUxPV0lUSElOS1RIQVRXRUFSRUFUQUNSVUNJQUxQT0lOVFdIRVJFV0VDQU5NQUtFQUNIQU5HRVRI
QVRXSUxMVFVSTk9VUldPUktUT01PUkVGT0NVAAAAAAIBfwABAAAANAAAADwxRDgyODE1QzMyMkJE
NDExOTZFQTAwNTA4Qjk1MUY3QjAyREFEQkU0QE1DSEgyNjVFPgB9wQ==
------_=_NextPart_000_01C1295D.23BC39C0--
From owner-ipsec@lists.tislabs.com Mon Aug 20 06:22:19 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KDMIN16787;
Mon, 20 Aug 2001 06:22:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21049
Mon, 20 Aug 2001 08:44:24 -0400 (EDT)
Message-Id: <200108191819.f7JIJF109629@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com,
design@lists.freeswan.org (FreeS/WAN Design Issues)
cc: Robert Moskowitz <rgm-sec@htt-consult.com>,
Bill Manning <bmanning@ISI.EDU>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
In-reply-to: Your message of "Wed, 08 Aug 2001 10:44:31 BST."
<5.1.0.14.2.20010808104236.01e5c210@localhost>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Sun, 19 Aug 2001 14:18:24 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Robert" == Robert Moskowitz <rgm-sec@htt-consult.com> writes:
Robert> At 02:13 AM 8/8/2001 -0700, Bill Manning wrote:
>> % We chose TXT because we simply wanted to convey a gateway address and a
>> % key, and we wanted to parse it with 10 lines of code, not 10,000.
>>
>> $DEITY help you when you grab a random TXT record... :)
Robert> What about the OPT record?
Robert> RFC 2671
Robert> Then you get IANA to assign an OPT attribute.
As Henry pointed out, they are not be stored in files:
RFC2671 says:
>4.1. One OPT pseudo-RR can be added to the additional data section of
> either a request or a response. An OPT is called a pseudo-RR
> because it pertains to a particular transport level message and not
> to any actual DNS data. OPT RRs shall never be CACHED, FORWARDED,
> OR STORED IN OR LOADED FROM MASTER FILES. The quantity of OPT
> pseudo-RRs per message shall be either zero or one, but not
> greater.
I'm not entirely clear how one could use OPT RRs given that one can not
load them, forward them or cache them. It seems to be a way to insert session
layer information. To make an analogy, more akin to IP options than OIDs.
Robert> But clearly, check out CERT first.
There are several options here:
1) ask for one IANA type between 0x100 and 0xFF00.
type "A" would be for a raw RSA key, replacing the basic TXT
record we currently use for authorization.
2) use a SPKI certificate instead.
3) use a URI-based private certificate type.
Option 1 would require that this document or a future one ask for this.
Option 2 would require introduction of new code to process SPKI into
where there was no previous need for SPKI in an implementation.
Option 3 is the simplest as we just need to establish a stable URI to
designate our usage. Probably "ftp://ftp.ietf.org/rfc/rfcXXXX.txt"
(where XXXX is the assigned number) is the most obvious one.
A variation of option 1 is to write a document asking for a KeyNote option
and include that. That would probably get more support than option 2.
Proceedurally there are two options:
1) include this request in this document. This would make the
document more than "Informational" as it would not describe an
existing system.
2) keep this and use it in a second document that might include other
changes.
The goal of this document is an Informational RFC, so I prefer #1.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO4AC5YqHRg3pndX9AQHoHQQAwpdXXnhuzD/A1MuRxrjyL2Yhawji4Kkx
I5nmWASvUQTpABH18ElZRJLFrEFuLemePwrWIcL3d4/pFS7bEvbUIw/ILYfm8b3j
Jbs5n/SC9w/SddK9/CG6r9lQCZj48b0WuQCI4a6FJAWJBGgxL2gY2JhDsbSOJ9X0
7Oo1zqAD0Wk=
=amTN
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Mon Aug 20 06:22:27 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KDMQN16802;
Mon, 20 Aug 2001 06:22:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21064
Mon, 20 Aug 2001 08:45:28 -0400 (EDT)
Message-ID: <3B808E99.457254F5@Sun.COM>
Date: Mon, 20 Aug 2001 12:14:17 +0800
From: Sayali Karanjkar <Sayali.Karanjkar@sun.com>
Reply-To: Sayali.Karanjkar@sun.com
Organization: Sun Microsystems
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: [Fwd: ipsec config problem :please help asap. really urgent]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all,
I need some help for this ipsec tunnel configuration that i am trying to
implement. this is really urgent and i hope you all will help me out
with this.
I have configured ipsec by using the command 'ipsec' at the command
prompt and
then the configuration being done at the ipsec command prompt :ipsec>
so how do i know where the ipseckey file is and how do i check it?
also the configuration needs a tunnel src address and tunnel dest
address. which
addresses are these? i have two systems which are sparc machines running
the
solaris 8 core administration package and they are connected via a
private
network. one machine is 10.1.1.1 and the other is 10.1.1.2. so these are
the two
system addresses right and then which are the tunnel addresses?
i have given the command
on system 1
ipsec> add esp spi 0x2112 src 10.1.1.1 dst 10.1.1.2\
authalg md5 authkey 123456aa123456bb123456cc123456dd \
encralg 3des encrkey 789000ee789000ff
on system 2
ipsec> add esp spi 0x2113 src 10.1.1.2 dst 10.1.1.1\
authalg md5 authkey 654321aa654321bb654321cc654321dd \
encralg 3des encrkey 000789ee000789ff
and after this the command on system 1 gave no error but the one on
system gives
error saying that one of the values entered is incorrect. return message
in
doaddup.invalid argument.
what causes this problem?
after that i tried to configure the secure tunnel..by giving the foll.
commands.
on system 1
#ifconfig ip.tun0 plumb
#ifconfig ip.tun0 10.1.1.11 10.1.1.22 \
tsrc 10.1.1.1 tdst 10.1.1.2 encr_algs 3des encr_auth_algs md5
# ifconfig ip.tun0 up
on system 2
#ifconfig ip.tun0 plumb
#ifconfig ip.tun0 10.1.1.22 10.1.1.11 \
tsrc 10.1.1.2 tdst 10.1.1.1 encr_algs 3des encr_auth_algs md5
# ifconfig ip.tun0 up
this also gives error on system 2 and no error on system 1.
what might be the problem?
i am very new to this field and have to finish this by tomorrow morning
and am
really stuck with these errors. i will be most thankful if you help me
out with
this at the earliest.
thanks in advance.
regards,
Sayali Karanjkar
From owner-ipsec@lists.tislabs.com Mon Aug 20 06:23:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KDNWN16824;
Mon, 20 Aug 2001 06:23:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21031
Mon, 20 Aug 2001 08:41:22 -0400 (EDT)
Date: Fri, 17 Aug 2001 16:39:47 -0400 (EDT)
From: "David M. Balenson" <balenson@tislabs.com>
Message-Id: <200108172039.QAA09311@clipper.gw.tislabs.com>
To: ipsec@lists.tislabs.com
Subject: CFP: Submission deadline for NDSS'02 extended to Aug 29th
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Due to the unusually large number of requests for an extension,
the submissions deadline for NDSS'02 has been extended to
Wednesday August 29, 9:00am EST (U.S. east coast time).
Paul Van Oorschot and Virgil Gligor
Co-Chairs, NDSS'02
C A L L F O R P A P E R S
Internet Society's 2002 Network and Distributed System Security Symposium (NDSS'02)
Catamaran Resort - San Diego, California
February 6-8, 2002
IMPORTANT DATES
Paper and panel submissions due August 22, 2001
Author notification October 17, 2001
Final version of papers and panels due November 20, 2001
GOAL: The symposium fosters information exchange among research scientists and practitioners of network and distributed system security services. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation (rather than theory). A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings are published by the Internet Society.
GENERAL CHAIR:
Clifford Neuman, USC Information Sciences Institute
PROGRAM CO-CHAIRS:
Paul Van Oorschot, Entrust Technologies
Virgil Gligor, University of Maryland
TUTORIAL CHAIR:
Eric Harder, National Security Agency
LOCAL ARRANGEMENTS CHAIR:
Thomas Hutton, San Diego Supercomputer Center
PUBLICATIONS CHAIR:
Mahesh Tripunitara, Purdue University
PUBLICITY CHAIR:
David Balenson, NAI Labs, Network Associates
LOGISTICS CHAIR:
Terry Weigler, Internet Society
PROGRAM COMMITTEE:
Steve Bellovin, AT&T Labs Research
Dan Boneh, Stanford University
Bill Cheswick, Lumeta Corporation
Li Gong, Sun Microsystems
Peter Gutmann, Univ. of Auckland, N.Z.
Charlie Kaufman, Iris Associates
Steve Kent, BBN Technologies
Markus Kuhn, Univ. of Cambridge, U.K.
Douglas Maughan, DARPA
Kevin McCurley, IBM Almaden Research
Gary McGraw, Cigital
Fabian Monrose, Bell Labs
Sandra Murphy, Network Associates
Radha Poovendran, Univ. of Washington
Michael Roe, Microsoft Research, U.K.
Christoph Schuba, Sun Microsystems
Clay Shields, Purdue University
Jonathan Trostle, Cisco Systems
Dan Wallach, Rice University
OUTSTANDING PAPER AWARD: There will be an Outstanding Paper award. The award will be presented at the symposium to the authors of an outstanding paper, as selected by the Program Committee.
SUBMISSIONS: Both technical papers and panel proposals are solicited. Technical papers must include a main body of at most 12 pages, with any additional details in clearly marked appendices for a combined total of at most 20 pages. Technical papers will appear in the proceedings. Panel proposals should be one page and must describe the topic, identify the panel chair, explain the panel format, and list three to four potential panelists. A description of each panel will appear in the proceedings, and may, at the discretion of the panel chair, include written position statements from the panelists.
Submissions are solicited in, but not limited to, the following areas:
* Integrating security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web.
* Intrusion avoidance, detection, and response: systems, experiences and architectures.
* Attack-resistant protocols and services.
* Network perimeter controls: firewalls, packet filters, application gateways.
* Virtual private networks.
* Public key infrastructure, key management, certification, and revocation.
* Secure electronic commerce: e.g., payment, barter, EDI, notarization, timestamping, endorsement, and licensing.
* Supporting security mechanisms and APIs; audit trails; accountability.
* Implementation, deployment and management of network security policies.
* Intellectual property protection: protocols, schemas, implementations, metering, watermarking, digital rights management.
* Fundamental services on network and distributed systems: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability.
* Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing.
* Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems.
* Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost.
* Security for collaborative applications and services: teleconferencing and video-conferencing, groupwork, etc.
Each submission must contain a separate Submission Overview specifying the submission type (paper or panel), the title or topic, author names with organizational affiliations, and must specify a contact author along with corresponding phone number, FAX number, postal address and email address.
Submissions must be received by August 22, 2001, and must be made electronically in either printable PostScript or PDF. Each submission will be acknowledged by e-mail; if acknowledgment is not received within seven days, contact a program co-chair (see above). Authors and panelists will be notified of acceptance by October 17, 2001, and given instructions for preparing the camera-ready copy. The camera-ready copy must be received by November 20, 2001.
FURTHER INFORMATION: Official dates, the final call for papers, the advance program, and registration information will be available shortly at http://www.isoc.org/ndss2002. For official submission information, visit http://www.isoc.org/ndss2002/cfp.
Internet Society
11150 Sunset Hills Road, Suite 100
Reston, VA 20191 USA
Tel: +1 703 326 9880
Fax: +1 703 326 9880
www.isoc.org
4, rue des Falaises
CH-1205 Geneva
Switzerland
Tel: +41 22 807 1444
Fax: +41 22 807 1445
www.isoc.org
From owner-ipsec@lists.tislabs.com Mon Aug 20 06:23:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KDNoN16838;
Mon, 20 Aug 2001 06:23:51 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21037
Mon, 20 Aug 2001 08:43:22 -0400 (EDT)
Message-Id: <200108172252.f7HMqTi08587@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0
In-reply-to: Your message of "Sat, 18 Aug 2001 01:45:33 +0300."
<3B7D9E8D.E5F5EFFB@F-Secure.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 17 Aug 2001 18:52:29 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Ari" == Ari Huttunen <Ari.Huttunen@F-Secure.com> writes:
Ari> Derek Atkins wrote:
>>
>> Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
>>
>> > >> It isn't like the "gateway" is going to be able to initiate to the client
>> > >> unless the client cooperates.
>> >
>> > Derek> No, but while the client is connected the "gateway" may still have
>> > Derek> something to say _during_ the conversation.
>> >
>> > So, it says it. If the NAT has timed out, it creates a new source
>> > port. The gateway updates its notion of where the client is if
>> > the ISAKMP packets decrypts properly.
>>
>> Except if the NAT times out there is NO WAY for the "gateway" to send
>> the IKE message to the "client". Sure, if the "client" is the
>> initiator of the new message then we don't have a problem, but the
>> whole point was that the "server" may need to initiate re-key or other
>> notification messages while the IKE SA is alive.
Ari> It's also relatively evil if the client is thinking it has a working phase 1 SA,
Ari> when in fact it's dead due to an expired NAT table somewhere in the network.
Ari> This can of course be solved, but the simplest way is to have that NAT mapping
Ari> not expire.
How can that happen?
When the client transmits, it will create a new NAT table entry. End of
problem.
Ari> This would be a good time for someone to provide really solid arguments
Ari> against using just one port, if such arguments exist. Like, statistical
Ari> calculations of actual overhead. The firewall-argument doesn't cut it, it
Ari> cannot understand either of the traffic streams even if they are separate,
Ari> and must just allow them through.
No you are very wrong.
There are multiple places where there are firewalls which permit *IKE* on
port 500 through. They also currently permit IP proto 51, which is can
understand through.
By putting ESP traffic on port 500, you circumvent a specific firewall policy.
We knew what the risks were with letting IKE through.
(Note, the firewall does not do NAT nor is it stateful, nor are there any
private network addresses involved)
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO32gLIqHRg3pndX9AQHmFAP+NEKPcOD7zj9u5zn7HgABuidei0w4ACUB
ynSBDmevFBh3qh+e4n+bkmOefu/J3tzYxToNn/BAEC+RQIvtetIFj66PZEs++Pvh
uS9P7TQ6FM8ujpr9PN4afLYVbPZmZmCJshpJ/ir5HNkmhPOpw840AttnQLevfV9p
nb0Re2M9vuU=
=nWpg
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Mon Aug 20 06:24:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KDO9N16853;
Mon, 20 Aug 2001 06:24:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21050
Mon, 20 Aug 2001 08:44:25 -0400 (EDT)
Message-ID: <000401c12843$3aa36070$36b12304@ffb5b>
From: "jshukla" <jshukla@earthlink.net>
To: <ipsec@lists.tislabs.com>, "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
References: <200108171738.f7HHcPC02529@marajade.sandelman.ottawa.on.ca> <sjmhev63643.fsf@rcn.ihtfp.org> <3B7D9E8D.E5F5EFFB@F-Secure.com>
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0
Date: Sat, 18 Aug 2001 17:09:31 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
----- Original Message -----
From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
>
> At the Helsinki bakeoff there were seven implementations of the latest
drafts,
> including us. Additional three had implementations of some earlier draft.
> This would be a good time for someone to provide really solid arguments
> against using just one port, if such arguments exist. Like, statistical
> calculations of actual overhead. The firewall-argument doesn't cut it, it
Have you guys considered how network based load-balancing
will work in your approach? This is a general question regarding
your approach, not using IKE port for ESP will not exactly help.
regards,
Jayant
From owner-ipsec@lists.tislabs.com Mon Aug 20 06:26:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KDQCN16887;
Mon, 20 Aug 2001 06:26:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21063
Mon, 20 Aug 2001 08:45:25 -0400 (EDT)
Message-Id: <200108191720.f7JHKoE07868@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com, design@lists.freeswan.org
cc: Wes Hardaker <wes@hardakers.net>, Hugh Daniel <hugh@road.xisp.net>
Subject: Re: opportunistic encryption deployment problems
In-reply-to: Your message of "Mon, 06 Aug 2001 07:34:54 PDT."
<sd4rrlb6k1.fsf@wanderer.hardakers.net>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Sun, 19 Aug 2001 13:19:59 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Wes" == Wes Hardaker <wes@hardakers.net> writes:
Wes> 1) your method of obtaining information is by reverse DNS lookup,
Wes> which will provide problems with people who can't control their
Wes> reverse DNS bindings. As an example, I don't have control over the
Wes> subnet mapped to my house and can not insert information into the
Wes> controlling DNS server (and can not convince them to redirect to
Wes> me).
Yes, this is a well known unresolved issue.
We may eventually have some proposals to make on this.
Note that this does not impact your ability to *initiate* opportunistic
encryption even if you do not control your reverse map. section 7.3 of the
draft says:
7.3 Use of FQDN IDs
Unfortunately, not every administrator has control over the contents
of the reverse-map. The only case where we can work around this is
where the initiator (SG-A) has no suitable reverse map. In this
case, the authorization record present in the reverse map of Alice
may refer to a FQDN instead of an IP address.
In this case, the client's TXT record gives the fully qualified
domain name (FQDN) in place of its security gateway's IP address.
The initiator should use the ID_FQDN ID-payload in phase 1. A
forward lookup for a KEY record on the FQDN must yield the
initiator's public key.
This method can also be used when the external address of SG-A is
dynamic.
Note that the client's reverse map must still exist.
[Perhaps not said here is that if Alice == SG-A, i.e. an end-node. I will
clear this text up]
Wes> 2) your method of obtaining information is by reverse DNS lookup,
Wes> which will provide problems with people behind NATs. Until IPv6
Section 8 deals with NATs.
Section 8.1 points out that if the NAT is colocated with SG-A, then the
packets appear to come from SG-A, and in fact SG-A is just acting as an
end-node. This is a common situation for people who have their single IP
address ADSL and a Linux box doing "masquerading".
This does not permit *incoming* connections to nodes behind SG-A/NAT-A, but
NAT already has this problem. Whether or not one can do OE *to* SG-A (say, to
the resident web server or smtp server) depends on whether or not SG-A can
control its reverse map.
Section 8.2 says that if you are behind a NAT (such as all the ADSL "Vibe"
customers of NBtel are), then you are screwed for IPsec anyway. If you do get
IPsec through, you likely can only do it outgoing, so you can again initiate
with FQDNs only.
Wes> (if) widely deployed, this will continue to be a growing problem.
Wes> Sure, if you can convince your NAT provider to do encryption to
Based number of installations (rather than number of people screwed by
NAT), I think that the majority of people are behind NAT boxes that they
(or their organization) owns. Maybe someone has a better statistic. This is
self-inflicted pain.
Wes> 3) The wider and wider spread use of things like web and other proxies
Wes> will provide similar problems seen in #2.
Why?
Once the packets are encrypted, they can not be determined to be port 80 or
whatever and redirected or played with. Perhaps this will result in poorer
performance, but one could certainly exempt port 80 packets from OE with an
appropriate SPD entry.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO3/1PoqHRg3pndX9AQEYbgQAykXN/H96ysAm/w414G5qtLUlbLcRlhlM
ZKxswtx2d21o0tXK7BfT+UrRx+htGKYGmRFuzyVU0NcVShY6oeyB73ht5Ll41OH9
b3KuJw48tT8C9Z0HQq6fkPf8nDFSSblP2NtPliGB5l0pzOKf4hd5JXsFyfOIDBps
J6JKpsiQ6w0=
=F+bX
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Mon Aug 20 07:10:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KEA1N17594;
Mon, 20 Aug 2001 07:10:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21255
Mon, 20 Aug 2001 09:31:48 -0400 (EDT)
Message-ID: <3B8112F6.C7237594@lmf.ericsson.se>
Date: Mon, 20 Aug 2001 16:39:02 +0300
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
CC: arne.dybdahl@ssh.com
Subject: Bakeoff summary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
An IPsec bakeoff was held last week in Espoo, Finland
(see www.bakeoff.ipsec.com). Around 100 participants
from various companies were present.
With Arne, we collected some of the experiences of the participants,
summarized them, and then held a discussion in the
meeting. The slides that show the summary can be
found from http://www.arkko.com/ipsec-bakeoff-august-2001.ppt
and http://www.arkko.com/ipsec-bakeoff-august-2001.txt.
The information tells what was it that people were testing,
what worked well, and what didn't work well. There was quite
a bit of new testing going on related to NAT traversal,
AES, and IPv6.
Unfortunately, I don't think we arranged for anyone
to take the minutes of the meeting (if anyone did
take notes, please post!). However, at least the
following was discussed:
* Deprecation of DES from the IPsec standards. There
was a consensus on this (with the exception of few
people), as long as the DES numbers from IKE would
not be reused for other purposes ;-) and the algorithms
could still be used where necessary.
* Usefulness of lifetime negotiation. Here we didn't
come to any specific conclusion as far as I could
see.
* Keepalives. Tero made the point that there are
different situations and we should find out
what the requirements are for them, likely more
than one mechanism is necessary.
Jari
From owner-ipsec@lists.tislabs.com Mon Aug 20 08:57:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KFvZN23772;
Mon, 20 Aug 2001 08:57:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21512
Mon, 20 Aug 2001 10:54:52 -0400 (EDT)
To: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Cc: ipsec@lists.tislabs.com, arne.dybdahl@ssh.com
In-reply-to: Jari.Arkko's message of Mon, 20 Aug 2001 16:39:02 +0300.
<3B8112F6.C7237594@lmf.ericsson.se>
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: Bakeoff summary
From: itojun@iijlab.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <13299.998319718.0@itojun.org>
Date: Tue, 21 Aug 2001 00:02:09 +0900
Message-ID: <13302.998319729@itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13299.998319718.1@itojun.org>
>Unfortunately, I don't think we arranged for anyone
>to take the minutes of the meeting (if anyone did
>take notes, please post!). However, at least the
>following was discussed:
mostly this is the copy of the slides, but anyway, better than nothing.
itojun
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <13299.998319718.2@itojun.org>
Return-Path: <owner-core@kame.net>
Delivered-To: itojun@coconut.itojun.org
Received: from orange.kame.net (orange.kame.net [203.178.141.194])
by coconut.itojun.org (Postfix) with ESMTP id 9EB054B20
for <itojun@coconut.itojun.org>; Fri, 17 Aug 2001 21:11:34 +0900 (JST)
Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166])
by orange.kame.net (8.11.4+3.4W/3.7W/smtpfeed 1.12) with ESMTP id f7HCBUo10578;
Fri, 17 Aug 2001 21:11:32 +0900 (JST)
Received: from itojun.org (localhost [127.0.0.1])
by starfruit.itojun.org (Postfix) with ESMTP
id 531887BA; Fri, 17 Aug 2001 20:58:26 +0900 (JST)
To: ikebone@kame.net, core@kame.net
Subject: summary of bakeoff
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Fri, 17 Aug 2001 20:58:26 +0900
Sender: itojun@itojun.org
Message-Id: <20010817115826.531887BA@starfruit.itojun.org>
X-Filter: mailagent [version 3.0 PL73] for itojun@itojun.org
what people have tested
what went well, what went not going so well
if not, spec problem or implementation problem
bakeoff organization
what's new? what's tested?
N x NAT traversal
N x AES
N x IPv6
cert management: SCEP OCSP CMP?
new DH groups
new implementations (cellphones, new vendors)
hybrid auth, xauth
hub-and-spoke VPNs
multiple trusted roots, cert chains, subordinate certs, PKCS#7
oppotunitistic encryption? two vendors
what works well?
ipsec
sha1, 3des
ike with preshared keys
ike with rsa sig certs
aes - some issues in phase 1, still
rekey
with established vendors, no problems in testing
v4 fragmentation
basic ipv6 cases
problem areas
ipsec
ipcomp - some problems?
minor fragmentation issues
diff between ike spec and ipcomp spec - encapsulation mode
rekey - a couple of problems
ike
aes key length attributes - phase 1 optional, phase 2 mandatory
slow new dh group calc cause timeouts
delete messages
some vendors do not send them - spec unclear?
if xauth phase 1.5 falls, torn down phase 1?
should not tear down ??. - in the draft.
if don't support all xauth attrs, turn down the whole thing?
retransmission and long rtt problems in some people's ike state mechanisms
cert
many smaller problems
cr warss: when to send and what to inlcude
also, is the whole chain sent or not
problems in certain fields, eg identity fqdn vs ip-addrs
cr with null cert authority - send multiple certs, some implementations can't cope with this
enrollment:scep ra/ca certificate chain - use of all cert; ca certificates might not have the key encipherment bit set
correct ordering of relative distinguished name encodings - x509 vs ldap
not much testing of revokation
certificate hierarchy and multiple ca troubles
scep - quite many (10+?).
nat traversal
packet fragmentation problems with esp-udp - implementation issue?
early phase of test.
ipv6
certs with ipv6 identities
neighbor discovery to work with ipsec
missing combinations (v6 inside v4)
many types of ipv6 addrs
source addr selection
link local adddresses
fragmentation - implementation?
some ipv6 connectivity setup problems
configuration problems
from "no" to "lots", opinion varies
specification problems
keepalives, how to solve? - no spec.
what kind of problem you are trying to solve?
if you don't have failover, you just need to have a way to recover from loss of traffic (old draft by sommerfeld)
failover solves routing problem.. ???
some interpretations on nat traversal
aes key length proposals - send or not
use of default lifetimes, if other type provided
lifetime should never been a part of the protocol - hugh
sending lifetime helps rekey sometimes
if initiate/response relationship is not bidir, need lifetime?
lifetime helps.
rekey without lifetime... you don't always want to rekey.
if you don't have lifetime, keys will stay forever and is not secure. you don't know how long sas will be alive, and you don't know how to kill it.
if the peer ignores the lifetime value, you lose.
discussion, discussion...
implementation problems
some: lifetimes, ike, proposal numbers, too many unnecessary hcecks, CRL content formats
disjoint opitons problem
not many people have AES
not many people have large DH groups
somebody wan't able to turn PFS off
different st of id types (DN vs email)
clean vs abrupt tunnel close
not many support IPv6
address-only SPD
some people require certs
certificate encodings
3des, sha1, v4 are well supported
let us remove 1des from spec. any objections?
restrictive countries. i have no choice.
deprecate it in the spec, keep the codepoint, try to discourage 1des new implementation.
some lowend devices still need des. still sometimes need to implement. may make sense to keep it
registration
generally good feedback
additional information had to be requested by some (how much power available etc)
map to the site would have been useful
general
good feedback
uphill walk from the hotel in the morning
some didn't bring all equipment, used over network - maybe good thing
less people than last time - economic, location?
where are the ca vendors?
busy people, not much time to test
good food
some time zone problems with crews back home
security guards?
network
generally good feedback
wanted to see net/vendor/implementation info before event
web site was a bit slow
network problems at start
too many steps for adding machines, interfaces, etc
we need a NAT
more realistic test environments - delay drop capacity
ipv6 worked great
ipv6 has other apps than ping6?
wlan was great
firewall would have been nice
regular phones or more mobile phones
dns setup very useful
routable address to behind the gw
NTP would be (was?) good
we keep intranet webpage for a while.
furture bakeoffs?
yes
maybe more participants if in the US
system for testing over the network?
VPNC did something like this.
test what?
whatever gets implemented
advanced cert things: enrollment, ocsp
nat traversal
dhcp
aes
opportunistic encryption
maybe "ipsec and pki" bakeoff to attract more CA vendors
new DH groups
son-of-ike
outside of the US to host?
if outside of US, no anita, too bad.
finding host is hard.
face-to-face is good.
no L2TP/...
------- =_aaaaaaaaaa0--
From owner-ipsec@lists.tislabs.com Mon Aug 20 10:15:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KHFlN25758;
Mon, 20 Aug 2001 10:15:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21691
Mon, 20 Aug 2001 12:19:27 -0400 (EDT)
Message-ID: <3B813A45.203E7849@storm.ca>
Date: Mon, 20 Aug 2001 12:26:45 -0400
From: Sandy Harris <sandy@storm.ca>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Sayali.Karanjkar@sun.com, ipsec@lists.tislabs.com
Subject: Re: [Fwd: ipsec config problem :please help asap. really urgent]
References: <3B808E99.457254F5@Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Sayali Karanjkar wrote:
> I need some help for this ipsec tunnel configuration that i am trying to
> implement. this is really urgent and i hope you all will help me out
> with this.
The ipsec@lists.tislabs.com list is not the right place to ask. It is for
discussions related to the design of the IPsec protocols, not for anything
about particular implementations.
Basically, you have to ask your vendor or other users of that software.
Some sites that might help:
A VPN mailing list with FAQ etc,:
http://kubarb.phsx.ukans.edu/~tbird/vpn.html
Questions on particular implementations are often asked there and I've
yet to see anyone complaining that they're off topic. Quite a few get
answered.
VPN Consortium:
http://www.vpnc.org/
Loads of information, though I'm not sure if any of it will be directly
relevant to your problem.
An IPsec implementation with fairly extensive documentation online:
http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/index.html
Not directly relevant, but some of the background material might be
helpful.
Link farms:
http://www.opus1.com/vpn/index.html
http://www.epm.ornl.gov/~dunigan/vpn.html
> I have ... two systems which are sparc machines running the
> solaris 8 core administration package and ...
... and you have a sun.com email address. Methinks it should be possible
for you to find help from your vendor or other users of that software.
If Sun's documentation is not sufficiently helpful, the author of the
FreeS/WAN stuff pointed to above (me :-) is available for contracts.
From owner-ipsec@lists.tislabs.com Mon Aug 20 12:15:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KJFrN28630;
Mon, 20 Aug 2001 12:15:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21961
Mon, 20 Aug 2001 14:24:54 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010407b7a7069b74b1@[128.33.84.34]>
In-Reply-To: <3.0.3.32.20010817154347.00b6ff30@mail>
References: <3.0.3.32.20010816183119.00de5008@mail>
<p05010401b7a1eca9f87c@[128.33.238.106]>
<3.0.3.32.20010816183119.00de5008@mail>
<3.0.3.32.20010817154347.00b6ff30@mail>
Date: Mon, 20 Aug 2001 14:26:46 -0400
To: Alex Alten <Alten@home.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
deployment problems
Cc: Henry Spencer <henry@spsystems.net>, ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 3:43 PM -0700 8/17/01, Alex Alten wrote:
<SNIP>
>
>Thank you Steve for pointing this out. I realized that I had not mentioned
>integrity as soon as I had sent the email. However certainly encryption is
>(almost) without exception a "must have" component of any secure network
>system.
>My point is that we need all of them to build a properly secure network
>system,
>none them can stand alone. I think even you can agree on this point.
>
>- Alex
yes, we want all of these services to be available from IPsec, but we
may not utilize all of the services on every SA. To that extent, some
of them can stand alone.
Steve
From owner-ipsec@lists.tislabs.com Mon Aug 20 13:05:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KK5cN29926;
Mon, 20 Aug 2001 13:05:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22074
Mon, 20 Aug 2001 15:14:30 -0400 (EDT)
Message-ID: <9D048F4A422CD411A56500B0D0209C5B02861C27@NS-CA>
From: Jay Ratford <Jratford@netscreen.com>
To: ipsec@lists.tislabs.com
Cc: ipsec@lists.tislabs.com
Subject: RE: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of
, i-cookie=0
Date: Mon, 20 Aug 2001 12:20:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The Firewall Mapping dying is a great concern, We found different devices
will time out the mappings between 25seconds - 2 minutes for UDP traffic.
Since in most scenereo's nobody will be able to "modify" the firewall (i.e.
Contractor working behind NAT, hotel room working behind NAT) we need to
come up with some idea intervals for the keepalive packets.
We are defaulting to 5 seconds, and only send keepalives if no traffic has
been sent for 5 seconds - so only when its needed as to not consume
bandwidth. I suggest most implementations keep this user-configurable or at
least not hard-coded somewhere.
We are also interested in testing with anyone who we havn't yet tested with,
Email me if interested.
-----Original Message-----
From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.com]
Sent: Friday, August 17, 2001 3:46 PM
To: Derek Atkins
Cc: Michael Richardson; ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits
of , i-cookie=0
Derek Atkins wrote:
>
> Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
>
> > >> It isn't like the "gateway" is going to be able to initiate to
the client
> > >> unless the client cooperates.
> >
> > Derek> No, but while the client is connected the "gateway" may still
have
> > Derek> something to say _during_ the conversation.
> >
> > So, it says it. If the NAT has timed out, it creates a new source
> > port. The gateway updates its notion of where the client is if
> > the ISAKMP packets decrypts properly.
>
> Except if the NAT times out there is NO WAY for the "gateway" to send
> the IKE message to the "client". Sure, if the "client" is the
> initiator of the new message then we don't have a problem, but the
> whole point was that the "server" may need to initiate re-key or other
> notification messages while the IKE SA is alive.
It's also relatively evil if the client is thinking it has a working phase 1
SA,
when in fact it's dead due to an expired NAT table somewhere in the network.
This can of course be solved, but the simplest way is to have that NAT
mapping
not expire.
At the Helsinki bakeoff there were seven implementations of the latest
drafts,
including us. Additional three had implementations of some earlier draft.
This would be a good time for someone to provide really solid arguments
against using just one port, if such arguments exist. Like, statistical
calculations of actual overhead. The firewall-argument doesn't cut it, it
cannot understand either of the traffic streams even if they are separate,
and must just allow them through.
Ari
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
From owner-ipsec@lists.tislabs.com Mon Aug 20 14:47:37 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KLlaN02188;
Mon, 20 Aug 2001 14:47:37 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22304
Mon, 20 Aug 2001 16:53:30 -0400 (EDT)
Message-Id: <200108202100.f7KL07022725@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: ipsec@lists.tislabs.com, design@lists.freeswan.org,
Wes Hardaker <wes@hardakers.net>, Hugh Daniel <hugh@road.xisp.net>
Subject: Re: opportunistic encryption deployment problems
In-reply-to: Your message of "Sun, 19 Aug 2001 13:19:59 EDT."
<200108191720.f7JHKoE07868@marajade.sandelman.ottawa.on.ca>
Reply-to: sommerfeld@East.Sun.COM
Date: Mon, 20 Aug 2001 17:00:06 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I very much like the concept of opportunistic use of IPsec, but I'm
deeply concerned about several aspects of the FreeS/WAN approach.
There is (at least) one significant additional opportunity for
mischief in the absence of DNSSEC: because the DNSSEC record contains
not only IPsec parameters, but also a "tunnel to" address, it provides
an additional mechanism to subvert the routing of IP datagrams.
While an attacker capable of spoofing DNS might also be able to spoof
the A record, a spoofed "A" record:
- will be visible to applications and in logs
- will be trivially visible in traditional system status tools (e.g.,
netstat output).
If we assume spotty DNSSEC deployment (almost a certainty), the
combination of a secured forward zone and an unsecured inverse zone is
extremely likely, and in this case, an unauthenticated tunnel-to
address is particularly problematic.
I'd like to suggest two changes to the proposal:
1) in the absence of a secured inverse zone, disallow use of a
tunnel-to address different from the end system's address.
Alternatively, just use transport mode..
2) Add a (necessarily unauthenticated) request-response protocol
(perhaps using IKE NOTIFY messages?) to attempt to determine whether a
destination is OE-capable, to be used if the appropriate reverse DNS
zone is insecure or does not contain OE info. This also quite
effectively deals with the very common case where the host's
administrator has no control of the contents of the inverse zone.
While it's outside the scope of a protocol specification, the spec
should recommend that, in the absence of some form of certification,
implementations should make {dnsname,address}->key mappings "sticky"
using techniques similar to those currently used by ssh.
I also think that some more thought should be given to ways to use
opportunistic encryption in conjunction with the NAT traversal drafts;
the current draft encourages using cleartext communications on the
"inside" of the NAT, which is clearly the wrong answer when there's
802.11 on the "inside" of the NAT..
- Bill
From owner-ipsec@lists.tislabs.com Mon Aug 20 22:49:45 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7L5njN11744;
Mon, 20 Aug 2001 22:49:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA23101
Tue, 21 Aug 2001 00:55:58 -0400 (EDT)
Message-ID: <018401c129fe$9bdd7b20$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: <sommerfeld@East.Sun.COM>,
"Michael Richardson" <mcr@sandelman.ottawa.on.ca>
Cc: <ipsec@lists.tislabs.com>, <design@lists.freeswan.org>,
"Wes Hardaker" <wes@hardakers.net>, "Hugh Daniel" <hugh@road.xisp.net>
References: <200108202100.f7KL07022725@thunk.east.sun.com>
Subject: Re: opportunistic encryption deployment problems
Date: Tue, 21 Aug 2001 08:03:25 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Bill Sommerfeld wrote:
> While it's outside the scope of a protocol specification, the spec
> should recommend that, in the absence of some form of certification,
> implementations should make {dnsname,address}->key mappings "sticky"
> using techniques similar to those currently used by ssh.
I very much like the idea of opportunistic encryption. However,
I'm concerned on the reliance on secure DNS as the only
authentication mechanism. While I do like how OE can be
used from small to large deployment of DNSSEC, I'm
concerned that (a) DNSSEC will eventually bring the same
trouble as a large scale PKI would [such as the worries
about people being able to control their reverse mappings
or their DNS at all], and (b) it may not be the most effective
weak authentication scheme [and it is weak until the root
gets signed].
In particular, I wonder if ssh-like leap-of-faith authentication at
the time of first contact and subsequent strong authentication
would be a better weak authentication scheme. Not much memory
is needed for this, just a mapping from a claimed identity to
a hash of the public key. Additionally, this has the benefit that
dynamic IP addresses can be accommodated as the identity
could be e.g. the user's e-mail rather than the changing IP/dns.
I believe there are vendors who are already using self-signed
certificates to do something like this.
There are also other possibilities for making unauthenticated
encryption become weak encryption. How about using server
side certificates in part, noting that many servers already have
them due to SSL? Then the other side would be authenticated
using e.g. leap-of-faith or DNSSEC. Web of trust is also a possibility,
if my friend logged on to www.cnn.com three years ago, I could trust
his initial ssh-style authentication also for my logins since he propably
got there before the evil government spies installed their active
attack equipment ;-)
Jari
From owner-ipsec@lists.tislabs.com Tue Aug 21 02:21:56 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7L9LuN10271;
Tue, 21 Aug 2001 02:21:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA23445
Tue, 21 Aug 2001 04:38:05 -0400 (EDT)
Date: Tue, 21 Aug 2001 10:45:24 +0200 (CEST)
From: Pekka Riikonen <priikone@silcnet.org>
X-X-Sender: <priikone@otaku.Xtrmntr.org>
To: Jari Arkko <jari.arkko@kolumbus.fi>
cc: <sommerfeld@East.Sun.COM>, Michael Richardson <mcr@sandelman.ottawa.on.ca>,
<ipsec@lists.tislabs.com>, <design@lists.freeswan.org>,
Wes Hardaker <wes@hardakers.net>, Hugh Daniel <hugh@road.xisp.net>
Subject: Re: opportunistic encryption deployment problems
In-Reply-To: <018401c129fe$9bdd7b20$8a1b6e0a@arenanet.fi>
Message-ID: <Pine.NEB.4.33.0108210956200.9900-100000@otaku.Xtrmntr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
: Bill Sommerfeld wrote:
:
: > While it's outside the scope of a protocol specification, the spec
: > should recommend that, in the absence of some form of certification,
: > implementations should make {dnsname,address}->key mappings "sticky"
: > using techniques similar to those currently used by ssh.
:
: I very much like the idea of opportunistic encryption. However,
: I'm concerned on the reliance on secure DNS as the only
: authentication mechanism. While I do like how OE can be
: used from small to large deployment of DNSSEC, I'm
: concerned that (a) DNSSEC will eventually bring the same
: trouble as a large scale PKI would [such as the worries
: about people being able to control their reverse mappings
: or their DNS at all], and (b) it may not be the most effective
: weak authentication scheme [and it is weak until the root
: gets signed].
:
: In particular, I wonder if ssh-like leap-of-faith authentication at
: the time of first contact and subsequent strong authentication
: would be a better weak authentication scheme. Not much memory
: is needed for this, just a mapping from a claimed identity to
: a hash of the public key. Additionally, this has the benefit that
: dynamic IP addresses can be accommodated as the identity
: could be e.g. the user's e-mail rather than the changing IP/dns.
: I believe there are vendors who are already using self-signed
: certificates to do something like this.
:
[well, I'm still supposed to be on vacation but before I leave to Lapland
I give my comments :)]
We've had this ssh-like leap-of-faith authentication as Jari suggested a
long time now in SSH Sentinel and we think it works very well. It is
especially handy when you do not have complex PKI systems in hand. While
we use it only with certificates (we negotiate IKE with remote end,
receive the certificate (show the fingerprint) and sign it with our
self-signed certificate) it would work as well with plain RSA public keys
too - in conjuction with DNS and DNSSEC systems, and with OE as well. I
too like the idea of the OE and think that the DNS approach might work,
but it is not perfect yet as we discussed with Hugh and others in the
interop. I don't much like that the OE would be added to IKE in
anyway; I think it should be a separate process, after all how the OE is
employed is very much implementation issue (and we might not actually end
up doing IKE at all).
For an implementation the authentication for example may be just using
plain DNS or maybe DNSSEC, or it might show the fingerprint of the key
when it fetches it, or it may show it and sign it with self-signed
certificate, or may it just accept all keys and cache them and sign
them. I think that the opportunisim can be interpreted so that "doing
IPSEC is fine, I think I'll try that first, and you can try it too, but if
we can't get it working I can settle to plaintext too", where the
authentication might not be the primary concern of yours. In fact, the
primary concern might be just getting the IPSEC working, after all it is
better than doing plaintext. But of course, I think if you are going to
do the authentication then you should do it well. I think the protocol
can suggest something for this. The opportunisim can also be interpreted
so that it is not different from doing IPSEC with predefined connections
except that we don't have them preset and the authentication is very
important - and plaintext is not an option.
Pekka
___________________________________________________________________________
Pekka Riikonen | Email: priikone@silcnet.org
SSH Communications Security Corp. | http://silcnet.org/~priikone
Tel. +358 (0)40 580 6673 | Snellmanninkatu 34 A 15, 70100 Kuopio
PGP KeyID A924ED4F: http://silcnet.org/~priikone/pubkey.asc
From owner-ipsec@lists.tislabs.com Tue Aug 21 03:15:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LAFfN15648;
Tue, 21 Aug 2001 03:15:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA23578
Tue, 21 Aug 2001 05:35:49 -0400 (EDT)
Message-ID: <3B822D61.655FAF61@F-Secure.com>
Date: Tue, 21 Aug 2001 12:44:01 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
CC: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of ,
i-cookie=0
References: <200108172252.f7HMqTi08587@marajade.sandelman.ottawa.on.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Michael Richardson wrote:
> Ari> It's also relatively evil if the client is thinking it has a working phase 1 SA,
> Ari> when in fact it's dead due to an expired NAT table somewhere in the network.
> Ari> This can of course be solved, but the simplest way is to have that NAT mapping
> Ari> not expire.
>
> How can that happen?
> When the client transmits, it will create a new NAT table entry. End of
> problem.
This requires that the gateway allows the client's IP address and port to vary
during a connection, and to record the latest values. It's possible, but is not
the choice made for the drafts.
>
> Ari> This would be a good time for someone to provide really solid arguments
> Ari> against using just one port, if such arguments exist. Like, statistical
> Ari> calculations of actual overhead. The firewall-argument doesn't cut it, it
> Ari> cannot understand either of the traffic streams even if they are separate,
> Ari> and must just allow them through.
>
> No you are very wrong.
>
> There are multiple places where there are firewalls which permit *IKE* on
> port 500 through. They also currently permit IP proto 51, which is can
> understand through.
> By putting ESP traffic on port 500, you circumvent a specific firewall policy.
> We knew what the risks were with letting IKE through.
Yes. If you allow encrypted traffic through a firewall, the firewall loses all
possibility to enforce any sort of policy for the packets inside the encryption.
End of story. It makes no difference whether ESP packets go inside port 500 or
by themselves.
Ari
--
Ari Huttunen phone: +358 9 2520 0700
Senior Software Engineer fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F-Secure products: Integrated Solutions for Enterprise Security
From owner-ipsec@lists.tislabs.com Tue Aug 21 05:10:55 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LCAtN21797;
Tue, 21 Aug 2001 05:10:55 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23814
Tue, 21 Aug 2001 07:23:04 -0400 (EDT)
Reply-To: <awank@future.futsoft.com>
From: "Awan Kumar" <awank@future.futsoft.com>
To: "IpsecMailingList (E-mail)" <ipsec@lists.tislabs.com>
Subject: ICMP PMTU processing relevant to IPSec.
Date: Tue, 21 Aug 2001 16:56:20 +0530
Message-Id: <000c01c12a34$1ae0f160$0702060a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi All,
I have a question related to ICMP Path MTU message processing in IPSec. I
am referring only to IPv4. Section B.3.1 of RFC 2401 states:
"However,if the ICMP message contains more information from the original
packet, then there may be enough information to immediately determine
to which host to propagate the ICMP/PMTU message and to provide that
system with the 5 fields (source address, destination address, source
port, destination port, and transport protocol) needed to determine
where to store/update the PMTU. Under such circumstances, a security
gateway MUST generate an ICMP PMTU message immediately upon receipt
of an ICMP PMTU from further down the path. "
I would be thankful if anyone could clarify the following questions:
1. RFC 792 mentions that the ICMP Error data contains IP Header + 64 bits of
original Data. Is it possible in any case to get an ICMP error message
greater than the value specified ?.
2. If yes, what is the situation in which it may be generated.
3. If no, then is it really required to support the condition mentioned
above. Can anyone tell if all the well known implementations are supporting
that.
4. If it is required to be supported, then in case of ESP, we need to
decrypt the packet. I think this packet needs to be decrypted using Outbound
SA through which it was encrypted. The key for Inbound SA will be different.
Also the full IPSec'ed packet may not be available, due to which ESP tail
may not be available to identify the next protocol of ESP. Can anybody
explain how this should be taken care. Please correct me if I am wrong
anywhere.
----------------------------
Awan Kumar Sharma
Sr. Software Engg., NEC-DF
Future Software Ltd.,
Chennai, India.
Ph: 4330 550 Extn: 437
(www.futsoft.com)
------------------------------
From owner-ipsec@lists.tislabs.com Tue Aug 21 05:47:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LClrN24857;
Tue, 21 Aug 2001 05:47:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23919
Tue, 21 Aug 2001 08:13:07 -0400 (EDT)
Date: Mon, 20 Aug 2001 21:30:14 -0700 (PDT)
From: Avram Shacham <shacham@shacham.net>
X-Sender: shacham@zev.net
To: itojun@iijlab.net
cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com
Subject: Re: Bakeoff summary
Message-ID: <Pine.BSF.4.05.10108202117370.27963-100000@zev.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
itojun,
As the attached almost-two-years-old email details, rfc2393bis is
answering RFC2407 'host-dependent default assumption when the
encapsulation attribute isn't defined', by defining the default to be
transport mode.
The change is included in the rfc2393bis I-D from the first version,
submitted in September 1999.
Regards,
avram>
itojun@iijlab.net wrote:
[...]
>
>problem areas
>
>ipsec
>ipcomp - some problems?
> minor fragmentation issues
> diff between ike spec and ipcomp spec - encapsulation mode
[...]
===
Date: Fri, 17 Sep 1999 07:12:43 -0700 (PDT)
From: Abraham Shacham <shacham@cisco.com>
To: ippcp@external.cisco.com, ipsec@lists.tislabs.com
Subject: rfc2393bis
Following the threads on ipsec and ippcp mailing lists
since the publication of RFC2393 in December 1998, and
the hallway discussion in Oslo with some of the ippcp
mailing-list members, draft-shacham-ippcp-rfc2393bis-00.txt --
(ippcp wg exists no more, therefore no draft-ietf naming) --
intends to update RFC2393 with the following clarifications:
[...]
3. Negotiations in the context of IPSec
[...]
3.3 Definition of encapsulation mode in the context of DOI,
including answering RFC2407 'host-dependent' default
assumption when the encapsulation attribute isn't defined:
Encapsulation Mode
[...]
If unspecified, the default value shall be assumed to be
unspecified (host-dependent).
[...]
351c369,372 === #3 ===
< Identifiers.
---
> Identifiers. To suggest a non-default Encapsulation Mode (such as
> Tunnel Mode), an IPComp proposal MUST include an Encapsulation Mode
> attribute. If the Encapsulation Mode is unspecified, the default
> value of Transport Mode is assumed.
From owner-ipsec@lists.tislabs.com Tue Aug 21 05:52:23 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LCqMN25026;
Tue, 21 Aug 2001 05:52:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23926
Tue, 21 Aug 2001 08:14:07 -0400 (EDT)
Date: Tue, 21 Aug 2001 09:30:15 +0200 (MEST)
From: Jakob Schlyter <jakob@crt.se>
To: Jari Arkko <jari.arkko@kolumbus.fi>
Cc: <sommerfeld@East.Sun.COM>, Michael Richardson <mcr@sandelman.ottawa.on.ca>,
<ipsec@lists.tislabs.com>, <design@lists.freeswan.org>,
Wes Hardaker <wes@hardakers.net>, Hugh Daniel <hugh@road.xisp.net>
Subject: Re: opportunistic encryption deployment problems
In-Reply-To: <018401c129fe$9bdd7b20$8a1b6e0a@arenanet.fi>
Message-ID: <Pine.BSO.4.33.0108210924280.11836-100000@fonbella.crt.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 21 Aug 2001, Jari Arkko wrote:
> While I do like how OE can be used from small to large deployment of
> DNSSEC, I'm concerned that (a) DNSSEC will eventually bring the same
> trouble as a large scale PKI would [such as the worries about people
> being able to control their reverse mappings or their DNS at all], and
> (b) it may not be the most effective weak authentication scheme [and
> it is weak until the root gets signed].
what makes DNSSEC weak just because the root is not signed? there is
nothing that stops us from signing the in-addr.arpa zone before root and
when this is done people can start trusting it immediately if they like to.
jakob
From owner-ipsec@lists.tislabs.com Tue Aug 21 06:47:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LDl8N26474;
Tue, 21 Aug 2001 06:47:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24282
Tue, 21 Aug 2001 08:58:14 -0400 (EDT)
Message-ID: <3B825C8C.25906347@lmf.ericsson.se>
Date: Tue, 21 Aug 2001 16:05:16 +0300
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jakob Schlyter <jakob@crt.se>
CC: Jari Arkko <jari.arkko@kolumbus.fi>, sommerfeld@East.Sun.COM,
Michael Richardson <mcr@sandelman.ottawa.on.ca>, ipsec@lists.tislabs.com,
design@lists.freeswan.org, Wes Hardaker <wes@hardakers.net>,
Hugh Daniel <hugh@road.xisp.net>
Subject: Re: opportunistic encryption deployment problems
References: <Pine.BSO.4.33.0108210924280.11836-100000@fonbella.crt.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Jakob writes:
>what makes DNSSEC weak just because the root is not signed? there is
>nothing that stops us from signing the in-addr.arpa zone before root and
>when this is done people can start trusting it immediately if they like >to.
Well... I'm not really on expert how secure DNS works, but
in order for the in-addr.arpa zone to be signed, doesn't
some big entity somewhere have to actually get down to
doing this? I.e., we as a group of OE interested people
can't do it by ourselves. Some big, slow, entity has to
get on board as well. Rather like someone founding the
global root CA. You're propably right in saying that
the root doesn't have to be signed, but something central
does have to happen before beyond you putting your own
key to your own DNS. Right?
Jari
From owner-ipsec@lists.tislabs.com Tue Aug 21 07:01:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LE1GN26875;
Tue, 21 Aug 2001 07:01:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24395
Tue, 21 Aug 2001 09:20:15 -0400 (EDT)
To: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Cc: Jakob Schlyter <jakob@crt.se>, Jari Arkko <jari.arkko@kolumbus.fi>,
sommerfeld@East.Sun.COM, Michael Richardson <mcr@sandelman.ottawa.on.ca>,
ipsec@lists.tislabs.com, design@lists.freeswan.org,
Wes Hardaker <wes@hardakers.net>, Hugh Daniel <hugh@road.xisp.net>
Subject: Re: opportunistic encryption deployment problems
References: <Pine.BSO.4.33.0108210924280.11836-100000@fonbella.crt.se> <3B825C8C.25906347@lmf.ericsson.se>
From: Derek Atkins <warlord@mit.edu>
Date: 21 Aug 2001 09:27:18 -0400
In-Reply-To: Jari Arkko's message of "Tue, 21 Aug 2001 16:05:16 +0300"
Message-ID: <sjmbsl91r2h.fsf@rcn.ihtfp.org>
Lines: 38
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Well, yes and no. You can go sign your own zone today. If a client
is expecting you to be a secure zone, they can notice if you're not.
So, no, the root does not need to be secured. However, you don't want
to require clients to know the keys to all zones, so that's why you
have a hierarchy; a client only needs to the know the key to the root
of the hierarchy.
But no, you can start signing zones today. Go look at tislabs.com --
they're signed :)
-derek
Jari Arkko <Jari.Arkko@lmf.ericsson.se> writes:
> Jakob writes:
>
> >what makes DNSSEC weak just because the root is not signed? there is
> >nothing that stops us from signing the in-addr.arpa zone before root and
> >when this is done people can start trusting it immediately if they like >to.
>
> Well... I'm not really on expert how secure DNS works, but
> in order for the in-addr.arpa zone to be signed, doesn't
> some big entity somewhere have to actually get down to
> doing this? I.e., we as a group of OE interested people
> can't do it by ourselves. Some big, slow, entity has to
> get on board as well. Rather like someone founding the
> global root CA. You're propably right in saying that
> the root doesn't have to be signed, but something central
> does have to happen before beyond you putting your own
> key to your own DNS. Right?
>
> Jari
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Tue Aug 21 08:04:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LF42N00891;
Tue, 21 Aug 2001 08:04:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24575
Tue, 21 Aug 2001 10:05:26 -0400 (EDT)
From: Bill Manning <bmanning@ISI.EDU>
Message-Id: <200108211412.f7LECgA26646@zed.isi.edu>
Subject: Re: opportunistic encryption deployment problems
To: jakob@crt.se (Jakob Schlyter)
Date: Tue, 21 Aug 2001 07:12:42 -0700 (PDT)
Cc: jari.arkko@kolumbus.fi (Jari Arkko), sommerfeld@East.Sun.COM,
mcr@sandelman.ottawa.on.ca (Michael Richardson), ipsec@lists.tislabs.com,
design@lists.freeswan.org, wes@hardakers.net (Wes Hardaker),
hugh@road.xisp.net (Hugh Daniel)
In-Reply-To: <Pine.BSO.4.33.0108210924280.11836-100000@fonbella.crt.se> from "Jakob Schlyter" at Aug 21, 2001 09:30:15 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
%
% On Tue, 21 Aug 2001, Jari Arkko wrote:
%
% > While I do like how OE can be used from small to large deployment of
% > DNSSEC, I'm concerned that (a) DNSSEC will eventually bring the same
% > trouble as a large scale PKI would [such as the worries about people
% > being able to control their reverse mappings or their DNS at all], and
% > (b) it may not be the most effective weak authentication scheme [and
% > it is weak until the root gets signed].
%
% what makes DNSSEC weak just because the root is not signed? there is
% nothing that stops us from signing the in-addr.arpa zone before root and
% when this is done people can start trusting it immediately if they like to.
%
% jakob
%
Ass I told Hugh in London, we have a working, signed
root, arpa, and in-addr.arpa zone available. All that
the OE folks need to do is notify the parent as to which
child zones they wish the parent to know are signed, e.g.
Hugh should tell me that:
300.168.192.in-addr.arpa is signed
and
send me the key for that signature.
Then I can sign the key for that zone and volia!
all entries in that zone can walk a fully signed
tree!
--
--bill
From owner-ipsec@lists.tislabs.com Tue Aug 21 08:10:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LFAWN01105;
Tue, 21 Aug 2001 08:10:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24595
Tue, 21 Aug 2001 10:13:44 -0400 (EDT)
To: Avram Shacham <shacham@shacham.net>
Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com
In-reply-to: shacham's message of Mon, 20 Aug 2001 21:30:14 MST.
<Pine.BSF.4.05.10108202117370.27963-100000@zev.net>
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: Bakeoff summary
From: itojun@iijlab.net
Date: Tue, 21 Aug 2001 23:21:03 +0900
Message-ID: <26072.998403663@itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>As the attached almost-two-years-old email details, rfc2393bis is
>answering RFC2407 'host-dependent default assumption when the
>encapsulation attribute isn't defined', by defining the default to be
>transport mode.
>
>The change is included in the rfc2393bis I-D from the first version,
>submitted in September 1999.
I would like to suggest 2407bis (or son-of-IKE) authors to make sure
that the part of the text will be in sync with rfc2393bis.
itojun
From owner-ipsec@lists.tislabs.com Tue Aug 21 09:03:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LG37N06739;
Tue, 21 Aug 2001 09:03:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24825
Tue, 21 Aug 2001 11:14:07 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p0501040eb7a82945bf3c@[128.33.84.34]>
In-Reply-To: <sjmu1z63ajc.fsf@rcn.ihtfp.org>
References: <Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net>
<p0501040db7a0ac202a1b@[128.33.238.53]> <sjmn1503ywh.fsf@rcn.ihtfp.org>
<p05010401b7a1eca9f87c@[128.33.238.106]> <sjmu1z63ajc.fsf@rcn.ihtfp.org>
Date: Tue, 21 Aug 2001 11:13:44 -0400
To: Derek Atkins <warlord@mit.edu>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
deployment problems
Cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 12:40 PM -0400 8/17/01, Derek Atkins wrote:
>Stephen Kent <kent@bbn.com> writes:
>
>> I also recall that Steve Bellovin and I participated in a panel at
>> the National Computer Security Conference in the mid-90s, chaired by
>> Dorothy Denning, where the topic was "Will Encryption Thwart
>> Hackers." The panel was unanimous in agreeing that the answer was no,
>> for a variety of reasons that are still valid to day. I know of very
>> few folks in the (larger) Internet community who believe that the
>> principal threat is passive wiretapping of the Internet, vs.
>> unauthorized access to computing resources on organizational LANs.
>> Encryption of lots of Internet traffic, without accompanying
>> authentication and access control, does not address the latter
>> concern.
>
>I think that 'universal encryption' and 'universal authentication' are
>two different and separable problems. Indeed, I think we've found
>that universal authentication is a HARD problem, whereas 'universal
>encryption' does not appear to be quite as hard (albeit with some
>limited protections).
>
>>From where I sit, I passive eavesdropping is a major issue. Is it the
>only issue, hell no. However, just look at all the password-sniffing
>attacks that have happened over the years. An attacker somehow gets
>into an account, sets up a sniffer, and then collects other passwords
>for other break-ins. If universal encryption had been deployed (even
>unauthenticated DH), these sniffers would have been ineffective.
Yes, but most recent attacks have not been of this flavor, and we
have a variety of alternate authentication mechanisms that can be
used when people are concerned about passive wiretapping. I'm not
opposed to using encryption, but we see lots of attacks that exploit
buffer overflows and other bugs that will not be countered by
encryption. Moreover, use of encryption does adversely affect use of
net-based IDS and one has to decide where this negative side effect
outweighs the benefits.
>Would it have solved the authentication problems? No, of course not.
>But does that mean that encryption is useless by itself? No, of
>course not. It would have solved a subset of the problems, and that
>by itself is a worthwhile goal.
Maybe. Since encryption can also interfere with our ability to detect
and track attacks, it's use is not purely beneficial. In recent
experiments sponsored by DARPA, we observed that use of encryption
with faulty authentication techniques allowed attackers to gain
unauthorized access and to hop from system to system without
detection, under cover of the encryption used on a host-to-host basis
in a LAN environment.
>We cannot build a panacea. No such beast exists, and looking for that
>perfect solution will, in the end, cause us to have none.
We agree on the principle, but may differ on where to draw the line.
Steve
From owner-ipsec@lists.tislabs.com Tue Aug 21 09:23:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LGNGN07231;
Tue, 21 Aug 2001 09:23:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24897
Tue, 21 Aug 2001 11:38:15 -0400 (EDT)
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems
References: <Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net> <p0501040db7a0ac202a1b@[128.33.238.53]> <sjmn1503ywh.fsf@rcn.ihtfp.org> <p05010401b7a1eca9f87c@[128.33.238.106]> <sjmu1z63ajc.fsf@rcn.ihtfp.org> <p0501040eb7a82945bf3c@[128.33.84.34]>
From: Derek Atkins <warlord@mit.edu>
Date: 21 Aug 2001 11:45:29 -0400
In-Reply-To: Stephen Kent's message of "Tue, 21 Aug 2001 11:13:44 -0400"
Message-ID: <sjm66bh1ko6.fsf@rcn.ihtfp.org>
Lines: 47
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent <kent@bbn.com> writes:
> Yes, but most recent attacks have not been of this flavor, and we
> have a variety of alternate authentication mechanisms that can be
> used when people are concerned about passive wiretapping. I'm not
> opposed to using encryption, but we see lots of attacks that exploit
> buffer overflows and other bugs that will not be countered by
> encryption. Moreover, use of encryption does adversely affect use of
> net-based IDS and one has to decide where this negative side effect
> outweighs the benefits.
I'm not sure how an authentication system can prevent a buffer
overflow attack, either, except you know authoritatively which host
originated the attack on you. But that might not help any, because
you don't know whether that other host started it or not. Besides,
spoofing TCP connections nowadays is pretty hard, so you can be fairly
certain of the source IP of someone attacking with a buffer overrun
(code red, anyone?). How does authentication help?
> Maybe. Since encryption can also interfere with our ability to detect
> and track attacks, it's use is not purely beneficial. In recent
> experiments sponsored by DARPA, we observed that use of encryption
> with faulty authentication techniques allowed attackers to gain
> unauthorized access and to hop from system to system without
> detection, under cover of the encryption used on a host-to-host basis
> in a LAN environment.
Perhaps this means we need better, distributed tracking tools.
Insteading of a centralized overseer, perhaps network elements need to
communicate their attack status to their peers.
> >We cannot build a panacea. No such beast exists, and looking for that
> >perfect solution will, in the end, cause us to have none.
>
> We agree on the principle, but may differ on where to draw the line.
Indeed. At least we're heading in the same general direction. :)
> Steve
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Tue Aug 21 10:00:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LH0KN08117;
Tue, 21 Aug 2001 10:00:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24958
Tue, 21 Aug 2001 12:13:54 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010410b7a8380c37f8@[128.33.84.34]>
In-Reply-To: <sjm66bh1ko6.fsf@rcn.ihtfp.org>
References: <Pine.BSI.3.91.1010815104227.27630E-100000@spsystems.net>
<p0501040db7a0ac202a1b@[128.33.238.53]> <sjmn1503ywh.fsf@rcn.ihtfp.org>
<p05010401b7a1eca9f87c@[128.33.238.106]> <sjmu1z63ajc.fsf@rcn.ihtfp.org>
<p0501040eb7a82945bf3c@[128.33.84.34]> <sjm66bh1ko6.fsf@rcn.ihtfp.org>
Date: Tue, 21 Aug 2001 12:14:30 -0400
To: Derek Atkins <warlord@mit.edu>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption
deployment problems
Cc: ipsec@lists.tislabs.com,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Derek,
>Stephen Kent <kent@bbn.com> writes:
>
>> Yes, but most recent attacks have not been of this flavor, and we
>> have a variety of alternate authentication mechanisms that can be
>> used when people are concerned about passive wiretapping. I'm not
>> opposed to using encryption, but we see lots of attacks that exploit
>> buffer overflows and other bugs that will not be countered by
>> encryption. Moreover, use of encryption does adversely affect use of
>> net-based IDS and one has to decide where this negative side effect
>> outweighs the benefits.
>
>I'm not sure how an authentication system can prevent a buffer
>overflow attack, either, except you know authoritatively which host
>originated the attack on you. But that might not help any, because
>you don't know whether that other host started it or not. Besides,
>spoofing TCP connections nowadays is pretty hard, so you can be fairly
>certain of the source IP of someone attacking with a buffer overrun
>(code red, anyone?). How does authentication help?
It helps if we know the source of the traffic that caused the
overflow, and if we use the authenticated identities to constrain
communication, i.e., for access control, then it may limit the set of
folks who can effect the overflow, a priori. But, it's not a panacea,
since we have many apps (e.g., mail) where we are willing to talk to
just about anyone ...
>
>> Maybe. Since encryption can also interfere with our ability to detect
>> and track attacks, it's use is not purely beneficial. In recent
>> experiments sponsored by DARPA, we observed that use of encryption
>> with faulty authentication techniques allowed attackers to gain
>> unauthorized access and to hop from system to system without
>> detection, under cover of the encryption used on a host-to-host basis
>> in a LAN environment.
>
>Perhaps this means we need better, distributed tracking tools.
>Insteading of a centralized overseer, perhaps network elements need to
>communicate their attack status to their peers.
There are R&D projects underway (we have one at BBN, for example)
that take this approach for tracing, but it's still a research
problem and would be a long time before any of them are deployed.
Also, net-based IDS clearly suffers in the face of encryption. Now,
I'm not saying that net-based IDS is the best or only approach to
IDS, but it is a tool that is widely used, and we must be aware of
the adverse effects of widespread encryption, especially host-to-host
in a LAN context.
> > >We cannot build a panacea. No such beast exists, and looking for that
>> >perfect solution will, in the end, cause us to have none.
>>
>> We agree on the principle, but may differ on where to draw the line.
>
>Indeed. At least we're heading in the same general direction. :)
>
yep!
Steve
From owner-ipsec@lists.tislabs.com Tue Aug 21 11:59:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LIxZN10840;
Tue, 21 Aug 2001 11:59:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25311
Tue, 21 Aug 2001 14:10:13 -0400 (EDT)
Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D706502C@rerun.lucentctc.com>
From: "Cambria, Mike" <mcambria@avaya.com>
To: ipsec@lists.tislabs.com
Subject: SPD per interface?
Date: Tue, 21 Aug 2001 14:16:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Does IPsec allow each interface to have its own SPD? That is, for a given
set of selectors, one interface can have a different policy (e.g. encryption
algorithm etc.) than a different interface.
My reading of RFC2401 leads me to believe that this is indeed possible (pg
13 bottom.)
"... an SG had multiple external interfaces, it might be
necessary to have separate SAD and SPD pairs for each interface."
Thanks,
MikeC
From owner-ipsec@lists.tislabs.com Tue Aug 21 11:59:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LIxdN10852;
Tue, 21 Aug 2001 11:59:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25328
Tue, 21 Aug 2001 14:19:34 -0400 (EDT)
Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D706502D@rerun.lucentctc.com>
From: "Cambria, Mike" <mcambria@avaya.com>
To: ipsec@lists.tislabs.com
Subject: Incoming SPD check on packet with no IPsec header?
Date: Tue, 21 Aug 2001 14:26:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In section 5.2.1 of RFC2401, should step #3 be performed (i.e. find incoming
policy in the SPD that matches the packet) even if the packet arrives with
no IPsec headers (e.g. nothing to do in steps 1 & 2)?
The beginning of section 5 (and 4.4.1) says that the SPD must be consulted
during the processing of all traffic. However, since 5.2.1 doesn't mention
to do this, I wanted to check.
Thanks,
MikeC
From owner-ipsec@lists.tislabs.com Tue Aug 21 12:18:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LJISN11903;
Tue, 21 Aug 2001 12:18:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25367
Tue, 21 Aug 2001 14:33:10 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010416b7a85aa859a0@[128.33.84.34]>
In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D706502C@rerun.lucentctc.com>
References: <3A6D367EA1EFD4118C9B00A0C9DD99D706502C@rerun.lucentctc.com>
Date: Tue, 21 Aug 2001 14:36:58 -0400
To: "Cambria, Mike" <mcambria@avaya.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: SPD per interface?
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 2:16 PM -0400 8/21/01, Cambria, Mike wrote:
>Does IPsec allow each interface to have its own SPD? That is, for a given
>set of selectors, one interface can have a different policy (e.g. encryption
>algorithm etc.) than a different interface.
>
>My reading of RFC2401 leads me to believe that this is indeed possible (pg
>13 bottom.)
>
> "... an SG had multiple external interfaces, it might be
>necessary to have separate SAD and SPD pairs for each interface."
>
yes, the SPD is nominally per-interface.
Steve
From owner-ipsec@lists.tislabs.com Tue Aug 21 12:18:45 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LJIiN11968;
Tue, 21 Aug 2001 12:18:44 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25362
Tue, 21 Aug 2001 14:33:03 -0400 (EDT)
To: "Cambria, Mike" <mcambria@avaya.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Incoming SPD check on packet with no IPsec header?
References: <3A6D367EA1EFD4118C9B00A0C9DD99D706502D@rerun.lucentctc.com>
From: Derek Atkins <warlord@mit.edu>
Date: 21 Aug 2001 14:40:24 -0400
In-Reply-To: "Cambria, Mike"'s message of "Tue, 21 Aug 2001 14:26:22 -0400"
Message-ID: <sjmvgjhz27b.fsf@rcn.ihtfp.org>
Lines: 28
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
If IPsec is enabled on the interface, then yes, all incoming packets
should get checked against the SPD. Otherwise you might let an
unprotected packet through what should be a protected interface.
Consider an example where you have a UDP protocol being protected by
IPsec; what would happen if you let a non-protected UDP packet in?
-derek
"Cambria, Mike" <mcambria@avaya.com> writes:
> In section 5.2.1 of RFC2401, should step #3 be performed (i.e. find incoming
> policy in the SPD that matches the packet) even if the packet arrives with
> no IPsec headers (e.g. nothing to do in steps 1 & 2)?
>
> The beginning of section 5 (and 4.4.1) says that the SPD must be consulted
> during the processing of all traffic. However, since 5.2.1 doesn't mention
> to do this, I wanted to check.
>
> Thanks,
> MikeC
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Tue Aug 21 12:20:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LJKfN12354;
Tue, 21 Aug 2001 12:20:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25393
Tue, 21 Aug 2001 14:43:06 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010417b7a85c3fb92c@[128.33.84.34]>
In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D706502D@rerun.lucentctc.com>
References: <3A6D367EA1EFD4118C9B00A0C9DD99D706502D@rerun.lucentctc.com>
Date: Tue, 21 Aug 2001 14:44:12 -0400
To: "Cambria, Mike" <mcambria@avaya.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Incoming SPD check on packet with no IPsec header?
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 2:26 PM -0400 8/21/01, Cambria, Mike wrote:
>In section 5.2.1 of RFC2401, should step #3 be performed (i.e. find incoming
>policy in the SPD that matches the packet) even if the packet arrives with
>no IPsec headers (e.g. nothing to do in steps 1 & 2)?
>
>The beginning of section 5 (and 4.4.1) says that the SPD must be consulted
>during the processing of all traffic. However, since 5.2.1 doesn't mention
>to do this, I wanted to check.
>
>Thanks,
>MikeC
One needs to check to see that any inbound packet without an IPsec
header is allowed to be bypassed (vs. discarded). The SPD contains
the requisite info to make this decision.
Steve
From owner-ipsec@lists.tislabs.com Tue Aug 21 13:47:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LKlmN15573;
Tue, 21 Aug 2001 13:47:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25587
Tue, 21 Aug 2001 16:07:03 -0400 (EDT)
Message-ID: <8B204D152222D51182B70001028841372024F1@postmaster.cryptek.com>
From: "Aronson, David" <daronson@cryptek.com>
To: "'Cambria, Mike'" <mcambria@avaya.com>, ipsec@lists.tislabs.com
Subject: RE: Incoming SPD check on packet with no IPsec header?
Date: Tue, 21 Aug 2001 16:18:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Cambria, Mike [mailto:mcambria@avaya.com] writes:
> In section 5.2.1 of RFC2401, should step #3 be performed
> (i.e. find incoming
> policy in the SPD that matches the packet) even if the
> packet arrives with
> no IPsec headers (e.g. nothing to do in steps 1 & 2)?
There may be a policy regarding what to do with packets that have no IPsec
header.
--
Dave Aronson, Software Engineer, +1-571-434-2039 V, +1-571-434-2001 F.
Opinions above are MINE, ALL MINE -- but for rent at reasonable rates.
Cryptek Secure Communications, 1501 Moran Rd., Sterling, VA 20166 USA.
SW ENGINEERS, EES: see http://www.cryptek.com and send me your resume.
From owner-ipsec@lists.tislabs.com Tue Aug 21 13:53:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LKrAN15697;
Tue, 21 Aug 2001 13:53:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25641
Tue, 21 Aug 2001 16:15:55 -0400 (EDT)
Message-Id: <4.3.2.7.1.20010821131514.00cc5de0@golf.cpgdesign.analog.com>
X-Sender: ramana@golf.cpgdesign.analog.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 21 Aug 2001 13:19:26 -0700
To: "Cambria, Mike" <mcambria@avaya.com>, ipsec@lists.tislabs.com
From: Ramana Yarlagadda <ramana@chiplogic.com>
Subject: Re: Incoming SPD check on packet with no IPsec header?
In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D706502D@rerun.lucentctc.com
>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Yes, you have to.
Let's say for A-B , discard on one end (Sg1). And if the other end has
a policy , A-b bypass.
Then with out checking the polciy on SG1, you will accept that which
is not correct.
-ramana
At 02:26 PM 8/21/01 -0400, Cambria, Mike wrote:
>In section 5.2.1 of RFC2401, should step #3 be performed (i.e. find incoming
>policy in the SPD that matches the packet) even if the packet arrives with
>no IPsec headers (e.g. nothing to do in steps 1 & 2)?
>
>The beginning of section 5 (and 4.4.1) says that the SPD must be consulted
>during the processing of all traffic. However, since 5.2.1 doesn't mention
>to do this, I wanted to check.
>
>Thanks,
>MikeC
From owner-ipsec@lists.tislabs.com Tue Aug 21 13:53:34 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LKrXN15713;
Tue, 21 Aug 2001 13:53:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25598
Tue, 21 Aug 2001 16:08:37 -0400 (EDT)
Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7065030@rerun.lucentctc.com>
From: "Cambria, Mike" <mcambria@avaya.com>
To: "'Derek Atkins'" <warlord@mit.edu>, "'Stephen Kent'" <kent@bbn.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: Incoming SPD check on packet with no IPsec header?
Date: Tue, 21 Aug 2001 16:15:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Just for completeness ...
The result of all this (moving on to step #4 in section 5.2.1) is the packet
should be discarded (& logged).
MikeC
-----Original Message-----
From: Derek Atkins [mailto:warlord@MIT.EDU]
Sent: Tuesday, August 21, 2001 2:40 PM
To: Cambria, Mike
Cc: ipsec@lists.tislabs.com
Subject: Re: Incoming SPD check on packet with no IPsec header?
If IPsec is enabled on the interface, then yes, all incoming packets
should get checked against the SPD. Otherwise you might let an
unprotected packet through what should be a protected interface.
Consider an example where you have a UDP protocol being protected by
IPsec; what would happen if you let a non-protected UDP packet in?
-derek
"Cambria, Mike" <mcambria@avaya.com> writes:
> In section 5.2.1 of RFC2401, should step #3 be performed (i.e. find
incoming
> policy in the SPD that matches the packet) even if the packet arrives with
> no IPsec headers (e.g. nothing to do in steps 1 & 2)?
>
> The beginning of section 5 (and 4.4.1) says that the SPD must be consulted
> during the processing of all traffic. However, since 5.2.1 doesn't
mention
> to do this, I wanted to check.
>
> Thanks,
> MikeC
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Wed Aug 22 06:33:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MDXcN10668;
Wed, 22 Aug 2001 06:33:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26933
Wed, 22 Aug 2001 08:25:45 -0400 (EDT)
From: Ghislaine Labouret <Ghislaine.Labouret@hsc.fr>
To: ipsec@lists.tislabs.com
Subject: Re: Bakeoff summary
Date: Wed, 22 Aug 2001 11:21:00 +0200
Organization: HSC (Herve Schauer Consultants)
References: <3B8112F6.C7237594@lmf.ericsson.se> <13302.998319729@itojun.org>
In-Reply-To: <13302.998319729@itojun.org>
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: <20010822092009.B557510F50@itesec.hsc.fr>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 21 Aug 2001 00:02:09 +0900, itojun@iijlab.net wrote:
> oppotunitistic encryption? two vendors
For those who might be wondering, those are FreeS/WAN (1.91) and
OpenBSD's isakmpd (2.9-current).
--
Ghislaine Labouret, Network security consultant
Hervé Schauer Consultants (HSC) - http://www.hsc.fr/
Phone (+33)-141-409-700 - Fax (+33)-141-409-709
From owner-ipsec@lists.tislabs.com Thu Aug 23 06:40:54 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NDerD20022;
Thu, 23 Aug 2001 06:40:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00300
Thu, 23 Aug 2001 08:11:53 -0400 (EDT)
Date: Thu, 23 Aug 2001 00:04:38 +0300 (EEST)
Message-Id: <200108222104.f7ML4cs15675@ryijy.hel.fi.ssh.com>
X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to <kivinen@ssh.fi> using -f
From: Tero Kivinen <kivinen@ssh.fi>
To: mcr@sandelman.ottawa.on.ca (Michael Richardson)
CC: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie
Organization: SSH Communications Security Oy
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="iso-8859-1"
X-Edit-Time: 9 min
X-Total-Time: 10 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
mcr@sandelman.ottawa.on.ca (Michael Richardson) writes:
> There are multiple places where there are firewalls which permit
> *IKE* on port 500 through. They also currently permit IP proto 51,
> which is can understand through. By putting ESP traffic on port 500,
> you circumvent a specific firewall policy. We knew what the risks
> were with letting IKE through.
>
> (Note, the firewall does not do NAT nor is it stateful, nor are there any
> private network addresses involved)
If there is no NAT involved in the firewall, then the NAT-T will not
be enabled, and you will be using just normal IKE and ESP traffic.
There is NO REASON to use NAT-T unless you have NAT between the two
hosts. The NAT-T NAT discovery will automatically detect if there is
NAT between and enable using of NAT-T only and only if there is NAT
between and the NAT-T is supported by both ends.
Having IKE and ESP on the same port is UGLY, I agree, but so is NAT
anyways. When there is NAT involved there is no clean beautiful
solution available :-)
Anyways puting the IKE and ESP on the same port has some advantages:
1) Only one keepalive needed, and we only need keepalives
while there is no IKE and ESP traffic.
2) It is simple, and much easier to implement.
3) IKE SA mapping through the NAT stays up as long as the IKE
SA/IPsec SAs, which means that the rekeying, deletes,
notifications etc can use same mechanism they are using the
IKE normally, no need to specify some special mechanism to
wake up original initiator who is behind NAT to create the
IKE SA mapping again so original responder can do rekey,
send delete or something like that.
4) We only need to configure one port for those firewalls
which also do NAT to pass. If the firewall want to inspect
the data he can just check the first 8 bytes if the
traffic, and if it is zeros, then assume that this is ESP
traffic and act accordingly.
5) Did I already mention it is simple and easy to implement :-)
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
From owner-ipsec@lists.tislabs.com Thu Aug 23 06:41:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NDf7D20043;
Thu, 23 Aug 2001 06:41:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28958
Thu, 23 Aug 2001 07:47:23 -0400 (EDT)
Message-ID: <3B8547DB.AB6D0FC1@inrialpes.fr>
Date: Thu, 23 Aug 2001 20:13:47 +0200
From: Pars MUTAF <pars.mutaf@inrialpes.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: ipsec@lists.tislabs.com
Subject: question on SPI
References: <3A6D367EA1EFD4118C9B00A0C9DD99D706502C@rerun.lucentctc.com> <p05010416b7a85aa859a0@[128.33.84.34]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all;
How a host picks the SPIs when establishing SAs?
(i.e., randomly? consecutively?)
Any limitation, suggestion (or documentation)
on that?
Help please! Thank you...
Regards,
pars
From owner-ipsec@lists.tislabs.com Thu Aug 23 06:55:56 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NDtuD20365;
Thu, 23 Aug 2001 06:55:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29055
Thu, 23 Aug 2001 07:51:13 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010402b7a968be5ccb@[128.33.84.35]>
In-Reply-To: <15227.61087.646494.243710@thomasm-u1.cisco.com>
References:
<F86F34FDF1F9D411B7A40008C74C27B8028ADD@hhdata3.cdsemea.baltimore.com>
<15226.45614.601672.408572@thomasm-u1.cisco.com>
<p05010403b7a09d9f2a5b@[128.33.238.53]>
<15227.61087.646494.243710@thomasm-u1.cisco.com>
Date: Wed, 22 Aug 2001 09:52:39 -0400
To: Michael Thomas <mat@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen
t problems
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 9:02 AM -0700 8/16/01, Michael Thomas wrote:
>Stephen Kent writes:
> > At 10:32 AM -0700 8/15/01, Michael Thomas wrote:
> > Mike,
> >
> > Your understanding is not quite right. First, tunnel mode, while
> > required for an SG, is also applicable to two hosts communicating.
> > Second, IPsec supports authentication of symbolic names, not just IP
> > addresses, which are dynamically bound to IP addresses for the
> > duration of an SA.
>
> My understanding is that the reality is somewhat
> different. For example, I don't believe that I
> can have a credential which is bound to a SPI
> which spans multiple IP addresses concurrently. As
> such it would only provide a single layer of
> indirection. Maybe the DNS modes provide some of
> this functionality, but I have doubts as to how
> well supported or secure it is.
>
> > This is how we support connections from mobile
> > users, for example.
>
> Mobile nodes use their home address, right? So
> it's not an issue.
some vendors have adopted that approach, but it is not a requirement
and IPsec is prepared to deal with the more general case.
>
> > The access control model that underlies IPsec is that one uses some
> > means of authenticating a peer, e.g., via binding a signature key to
> > an ID, traceable to a trust anchor, and that the traffic sent from
> > and sent to the authenticated peer is subject to access controls
> > expressed in the SPD. These controls apply not only to allowed IP
> > addresses to/from which traffic may flow, but also protocols and port
> > fields. The motivation for these other selectors is the same as in
> > firewalls, i.e., we can control access to services based on access to
> > well know ports.
>
> Right... an authenticated firewall. That's pretty much
> my understanding. This seems, well, of limited utility
> for transport mode unless it can be tied to applications
> (ie, in the same way that login names produce a mapping
> to a GID/UID for file systems after login). Maybe I'm
> just generally skeptical of integrated host firewalls
> as being misguided, but that's probably just me.
>
In the context of a host it would be nice to have a standard API for
applications to request IPsec services, this requires changes to the
apps. the alternative is to configure the SPD to automatically
provide the services, which is attractive as a centrally managed
approach to security as well. there is no transport vs. tunnel mode
distinction here, unless you're making the assumption that a host
would only use transport mode. (this would be OK for host/host SAs,
but it's not necessary and it doesn't work for host/SG SAs.)
Steve
From owner-ipsec@lists.tislabs.com Thu Aug 23 08:56:25 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NFuOD28758;
Thu, 23 Aug 2001 08:56:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00730
Thu, 23 Aug 2001 10:57:50 -0400 (EDT)
Date: Thu, 23 Aug 2001 11:04:29 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Pars MUTAF <pars.mutaf@inrialpes.fr>
cc: IP Security List <ipsec@lists.tislabs.com>
Subject: Re: question on SPI
In-Reply-To: <3B8547DB.AB6D0FC1@inrialpes.fr>
Message-ID: <Pine.BSI.3.91.1010823110149.24089A-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 23 Aug 2001, Pars MUTAF wrote:
> How a host picks the SPIs when establishing SAs?
> (i.e., randomly? consecutively?)
However the (receiving) host wishes. Many implementations pick them
randomly, which has minor advantages in making it harder to mount a
denial-of-service attack. But they could be sequential, or they could be
indices into a table internal to the receiving host.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Thu Aug 23 13:12:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NKCAD04062;
Thu, 23 Aug 2001 13:12:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01301
Thu, 23 Aug 2001 15:11:39 -0400 (EDT)
Message-Id: <200108231835.f7NIZt701356@marajade.sandelman.ottawa.on.ca>
To: Tero Kivinen <kivinen@ssh.fi>
cc: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie
In-reply-to: Your message of "Thu, 23 Aug 2001 00:04:38 +0300."
<200108222104.f7ML4cs15675@ryijy.hel.fi.ssh.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 23 Aug 2001 14:35:54 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Tero" == Tero Kivinen <kivinen@ssh.fi> writes:
Tero> mcr@sandelman.ottawa.on.ca (Michael Richardson) writes:
>> There are multiple places where there are firewalls which permit
>> *IKE* on port 500 through. They also currently permit IP proto 51,
>> which is can understand through. By putting ESP traffic on port 500,
>> you circumvent a specific firewall policy. We knew what the risks
>> were with letting IKE through.
>>
>> (Note, the firewall does not do NAT nor is it stateful, nor are there any
>> private network addresses involved)
Tero> If there is no NAT involved in the firewall, then the NAT-T will not
Tero> be enabled, and you will be using just normal IKE and ESP traffic.
True.
But, the security evaluation of what you permit through the firewall has
now changed because standard products now make UDP port 500 a tunneling port.
Tero> Having IKE and ESP on the same port is UGLY, I agree, but so is NAT
Tero> anyways. When there is NAT involved there is no clean beautiful
Tero> solution available :-)
You are complicated the non-NAT case in order to support the NAT case.
At least use a different port than 500.
Tero> Anyways puting the IKE and ESP on the same port has some advantages:
Tero> 1) Only one keepalive needed, and we only need keepalives
Tero> while there is no IKE and ESP traffic.
I disagree with the need to keep the IKE port alive.
Tero> 2) It is simple, and much easier to implement.
For bump-in-the-stack implementations where you get to inspect every packet
anyway, it might be, but for other people it is much harder to implement.
It is possible, for instance, to implement IPsec using "tun0" and a
usermode-process plus some IP-protocol bound sockets since IKE processing is
just normal UDP. Now it is not normal UDP.
Now, if I want to do this, I must put my IKE daemon in the fast path.
Tero> 3) IKE SA mapping through the NAT stays up as long as the IKE
Tero> SA/IPsec SAs, which means that the rekeying, deletes,
Tero> notifications etc can use same mechanism they are using the
Tero> IKE normally, no need to specify some special mechanism to
Tero> wake up original initiator who is behind NAT to create the
Tero> IKE SA mapping again so original responder can do rekey,
Tero> send delete or something like that.
In the situations where you really want to do this from the gateway to the
road warrior, I do not buy that not having IKE keepalives is too expensive.
Tero> 4) We only need to configure one port for those firewalls
Tero> which also do NAT to pass. If the firewall want to inspect
Tero> the data he can just check the first 8 bytes if the
Tero> traffic, and if it is zeros, then assume that this is ESP
Tero> traffic and act accordingly.
This is a security issue to me.
Tero> 5) Did I already mention it is simple and easy to implement :-)
I do not buy that.
In order to support this in a BSD protocol stack I must write a kernel
thread (or "nfsd"-like kernel process) that waits on UDP port 500 socket, and
*if* the zeros are not present, must push the packet into a *different* port
500 so that my regular IKE can receive this.
Again:
1) use a different UDP port for IPsec traffic.
2) if you won't do this, at least do not use port 500.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO4VNB4qHRg3pndX9AQH17QQAqJ0qZp0vNEcaGHlS4qRqBiWZfXXSk8RJ
QRY2k4sD07dEXcrjWBaANEZxe9YSJfCOOgT2M0M3aTTBBgwlKMSUnXLLYs4Ov6yN
cX1VZpmOa8BNs8MhsrUBO6HJ6VLNMBicRsJxwiJdK4w+K3Ny1e9PpBUKy3ts6pvj
Nt7O63lcSpM=
=jMOd
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Thu Aug 23 16:22:04 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NNM3D20059;
Thu, 23 Aug 2001 16:22:04 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01651
Thu, 23 Aug 2001 18:34:07 -0400 (EDT)
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: Tero Kivinen <kivinen@ssh.fi>, ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie
References: <200108231835.f7NIZt701356@marajade.sandelman.ottawa.on.ca>
From: Derek Atkins <warlord@mit.edu>
Date: 23 Aug 2001 18:41:27 -0400
In-Reply-To: Michael Richardson's message of "Thu, 23 Aug 2001 14:35:54 -0400"
Message-ID: <sjm7kvuz9ew.fsf@rcn.ihtfp.org>
Lines: 38
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
> True.
> But, the security evaluation of what you permit through the firewall has
> now changed because standard products now make UDP port 500 a tunneling port.
And if you let through UDP/500 w/o IPPROTO 50, you're in just as much
trouble (and even being obnoxious). I would say this makes it easier
with a NAT gateway -- if you want to allow IPsec, you open UDP/500.
If not, then you don't. This way you don't need to keep track of TWO
things and make sure they match. In anything, this is simplifying
life!
> You are complicated the non-NAT case in order to support the NAT case.
> At least use a different port than 500.
How is this complicating the non-NAT case? In the case of non-NAT,
you get regular IKE. How is this complicated?
> I disagree with the need to keep the IKE port alive.
Then you are confused about why there is IKE phase-I state.
> In order to support this in a BSD protocol stack I must write a kernel
> thread (or "nfsd"-like kernel process) that waits on UDP port 500 socket, and
> *if* the zeros are not present, must push the packet into a *different* port
> 500 so that my regular IKE can receive this.
Or you could have your IKE daemon parse it and then pass the packet
back down into the kernel. There are many ways of doing this.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Thu Aug 23 16:41:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NNflD20404;
Thu, 23 Aug 2001 16:41:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01706
Thu, 23 Aug 2001 19:01:39 -0400 (EDT)
Message-Id: <200108232308.f7NN8I009289@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: Tero Kivinen <kivinen@ssh.fi>, ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie
In-reply-to: Your message of "Thu, 23 Aug 2001 14:35:54 EDT."
<200108231835.f7NIZt701356@marajade.sandelman.ottawa.on.ca>
Reply-to: sommerfeld@East.Sun.COM
Date: Thu, 23 Aug 2001 19:08:18 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> In order to support this in a BSD protocol stack I must write a kernel
> thread (or "nfsd"-like kernel process) that waits on UDP port 500 socket, and
> *if* the zeros are not present, must push the packet into a *different* port
> 500 so that my regular IKE can receive this.
I can think of several other alternatives to this (this is in the
context of NetBSD; your milage may vary):
1) you could register a so_upcall handler which picks off the ESP
traffic and leaves the IKE traffic present (with no need for a second
socket). This will probably work ok but will involve spuriously
waking up your ike daemon..
2) you could "fix" the so_upcall interface so it can be used
efficiently for this purpose.
3) you could do what AFS did on BSD platforms, and jam a shim layer
between IP and UDP, and pick off the packet before udp_input().
Crude, but effective, and avoids the spurious wakeups.
4) register a pfil hook to decapsulate UDP 500+zeros packets into a
"normal" ESP packet; like #2, except that it uses documented
interfaces, and probably also uses less stack depth.
- Bill
From owner-ipsec@lists.tislabs.com Thu Aug 23 21:06:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O46PD10606;
Thu, 23 Aug 2001 21:06:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02036
Thu, 23 Aug 2001 23:04:09 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0
Content-Class: urn:content-classes:message
Subject: Ipsec load balancing devices - UDP-ESP impact
Date: Thu, 23 Aug 2001 20:10:45 -0700
Message-ID: <2E33960095B58E40A4D3345AB9F65EC1013F8438@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Ipsec load balancing devices - UDP-ESP impact
thread-index: AcEpeDu7LbJhbV9sRyitHiInLHM9BwCzlBsg
From: "William Dixon" <wdixon@windows.microsoft.com>
To: "jshukla" <jshukla@earthlink.net>, <ipsec@lists.tislabs.com>,
"Ari Huttunen" <Ari.Huttunen@F-Secure.com>
X-OriginalArrivalTime: 24 Aug 2001 03:10:46.0023 (UTC) FILETIME=[5E0D8170:01C12C4A]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Jayant, I've checked around on the popular load balancing product web
sites. But the details are often not avail, or buried in technical docs
that require a customer account to access.
Does anyone know of any products that do NAT or "VLAN" translation and
specifically provide mapping support for IPSec "sessions", that is,
devices that aren't already IPSec gateways and terminating IPSec before
they do NAT ?
I'd like to know if they do something more than maintain source IP-based
mappings, like cookie-pair-SPI tracking or something.
In any case, combining IKE & ESP in the same UDP port 500 encapsulation
makes the take easier by having to track only one UDP src/dst pair - vs.
IPSec ESP inbound and outbound SPIs, in addition to the IKE traffic, or
in addition to another critically related UDP src/dst port pair carrying
ESP.
Wm
William Dixon
Program Manager - Network Security, IPSec
Windows Networking
-----Original Message-----
From: jshukla [mailto:jshukla@earthlink.net]
Sent: Saturday, August 18, 2001 5:10 PM
To: ipsec@lists.tislabs.com; Ari Huttunen
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits
of , i-cookie=0
----- Original Message -----
From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
>
> At the Helsinki bakeoff there were seven implementations of the latest
drafts,
> including us. Additional three had implementations of some earlier
> draft. This would be a good time for someone to provide really solid
> arguments against using just one port, if such arguments exist. Like,
> statistical calculations of actual overhead. The firewall-argument
> doesn't cut it, it
Have you guys considered how network based load-balancing
will work in your approach? This is a general question regarding your
approach, not using IKE port for ESP will not exactly help.
regards,
Jayant
From owner-ipsec@lists.tislabs.com Fri Aug 24 05:50:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OCooD05794;
Fri, 24 Aug 2001 05:50:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02667
Fri, 24 Aug 2001 07:51:24 -0400 (EDT)
Date: Fri, 24 Aug 2001 14:51:40 +0300
To: ipsec@lists.tislabs.com
Subject: Re: SPD per interface?
Message-ID: <20010824145140.B2453@terrapin>
Mail-Followup-To: ipsec@lists.tislabs.com
References: <3A6D367EA1EFD4118C9B00A0C9DD99D706502C@rerun.lucentctc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <3A6D367EA1EFD4118C9B00A0C9DD99D706502C@rerun.lucentctc.com>
User-Agent: Mutt/1.3.20i
From: alexey.vyskubov@nokia.com (Alexey Vyskubov)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Does IPsec allow each interface to have its own SPD? That is, for a
[SKIP]
> My reading of RFC2401 leads me to believe that this is indeed possible
> (pg 13 bottom.)
It's not possible, it's required. Page 14, end of the second paragraph,
RFC2401:
"In addition, a nominally separate SPD must be provided for each
IPsec-enabled interface."
> "... an SG had multiple external interfaces, it might be
> necessary to have separate SAD and SPD pairs for each interface."
--
Alexey
From owner-ipsec@lists.tislabs.com Fri Aug 24 06:29:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7ODTgD10107;
Fri, 24 Aug 2001 06:29:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02809
Fri, 24 Aug 2001 08:44:26 -0400 (EDT)
Message-ID: <3B864DE3.3FE689EA@F-Secure.com>
Date: Fri, 24 Aug 2001 15:51:47 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tero Kivinen <kivinen@ssh.fi>
CC: Michael Richardson <mcr@sandelman.ottawa.on.ca>, ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of ,
i-cookie
References: <200108222104.f7ML4cs15675@ryijy.hel.fi.ssh.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Tero Kivinen wrote:
> If there is no NAT involved in the firewall, then the NAT-T will not
> be enabled, and you will be using just normal IKE and ESP traffic.
> There is NO REASON to use NAT-T unless you have NAT between the two
> hosts. The NAT-T NAT discovery will automatically detect if there is
> NAT between and enable using of NAT-T only and only if there is NAT
> between and the NAT-T is supported by both ends.
I disagree somewhat. The current drafts do not clearly forbid proposing
only ESPUDP encapsulation in QM when there is no NAT detected. There is
also no mentioning what the responder should do in such a case.
This was discussed earlier (off ipsec-list) and at that time it was
to be allowed, with the understanding that this results in ESPUDP usage without
there being a NAT. The intent of such a thing is indeed to go through
improperly configured firewalls.
Please show me one real case where someone wants IKE to go through
a firewall but not ESP?
Ari
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
From owner-ipsec@lists.tislabs.com Fri Aug 24 09:19:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OGJ9D23714;
Fri, 24 Aug 2001 09:19:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03213
Fri, 24 Aug 2001 11:25:59 -0400 (EDT)
Message-ID: <9D048F4A422CD411A56500B0D0209C5B02861C88@NS-CA>
From: Jay Ratford <Jratford@netscreen.com>
To: "'William Dixon'" <wdixon@windows.microsoft.com>,
jshukla
<jshukla@earthlink.net>, ipsec@lists.tislabs.com,
Ari Huttunen
<Ari.Huttunen@F-Secure.com>
Subject: RE: Ipsec load balancing devices - UDP-ESP impact
Date: Fri, 24 Aug 2001 08:32:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Alteon (now Nortel) devices perform NAT and NAPT, but not in default
configurations. They also have a "VPN Load-Balancing" solution to load
balance your VPN Gateway's - It does keep some kind of state, specifically
how i'm not sure.
-----Original Message-----
From: William Dixon [mailto:wdixon@windows.microsoft.com]
Sent: Thursday, August 23, 2001 8:11 PM
To: jshukla; ipsec@lists.tislabs.com; Ari Huttunen
Subject: Ipsec load balancing devices - UDP-ESP impact
Jayant, I've checked around on the popular load balancing product web
sites. But the details are often not avail, or buried in technical docs
that require a customer account to access.
Does anyone know of any products that do NAT or "VLAN" translation and
specifically provide mapping support for IPSec "sessions", that is,
devices that aren't already IPSec gateways and terminating IPSec before
they do NAT ?
I'd like to know if they do something more than maintain source IP-based
mappings, like cookie-pair-SPI tracking or something.
In any case, combining IKE & ESP in the same UDP port 500 encapsulation
makes the take easier by having to track only one UDP src/dst pair - vs.
IPSec ESP inbound and outbound SPIs, in addition to the IKE traffic, or
in addition to another critically related UDP src/dst port pair carrying
ESP.
Wm
William Dixon
Program Manager - Network Security, IPSec
Windows Networking
-----Original Message-----
From: jshukla [mailto:jshukla@earthlink.net]
Sent: Saturday, August 18, 2001 5:10 PM
To: ipsec@lists.tislabs.com; Ari Huttunen
Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits
of , i-cookie=0
----- Original Message -----
From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
>
> At the Helsinki bakeoff there were seven implementations of the latest
drafts,
> including us. Additional three had implementations of some earlier
> draft. This would be a good time for someone to provide really solid
> arguments against using just one port, if such arguments exist. Like,
> statistical calculations of actual overhead. The firewall-argument
> doesn't cut it, it
Have you guys considered how network based load-balancing
will work in your approach? This is a general question regarding your
approach, not using IKE port for ESP will not exactly help.
regards,
Jayant
From owner-ipsec@lists.tislabs.com Fri Aug 24 09:28:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OGSrD23994;
Fri, 24 Aug 2001 09:28:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03243
Fri, 24 Aug 2001 11:46:56 -0400 (EDT)
Message-ID: <958D701256C5D411953200508BE3761802556943@zrtpd0jb.us.nortel.com>
From: "Wilson Leung" <leungw@nortelnetworks.com>
To: ipsec@lists.tislabs.com
Subject: RE: Simplifying Son of IKE
Date: Fri, 24 Aug 2001 11:53:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C12CB4.F296A960"
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_01C12CB4.F296A960
Content-Type: text/plain;
charset="iso-8859-1"
IETF Ipsec Community:
In the opinion of the Nortel Network's Portfolio Integration Network
Security Group, the recent push to fully embrace the "son of IKE"
replacement for IPSec and IKE by the IETF Standards community is a rushed
judgment meant to fix a problem that does not necessarily exist. The
Network Security Group understands, but does not fully agree, with popular
proposition that IPSec and IKE are too complicated to modify further. For
those that have used and implemented both of these protocols, we are
comfortable with implementation and operational results. The proposed "son
of IKE's" lack of backwards compatibility to IPSec and IKE add further
resistance to abandoning these two protocols. Far better if a replacement
is indeed required, in our opinion, to identify and delete or modify those
segments of IPSec and IKE that are deemed to be confusing or of limited
implementation flexibility. In our opinion, it is wiser to simplify rather
than reject and redo.
Regards,
Wilson Leung
Wilson Leung, CISSP
Senior Security Consultant
Nortel Networks - NGN Security Solutions Team
301-570-0966 ESN (451)
240-604-4235 Cell
------_=_NextPart_001_01C12CB4.F296A960
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: Simplifying Son of IKE</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>IETF Ipsec Community:</FONT>
</P>
<P><FONT SIZE=3D2>In the opinion of the Nortel Network's Portfolio =
Integration Network Security Group, the recent push to fully embrace =
the "son of IKE" replacement for IPSec and IKE by the IETF =
Standards community is a rushed judgment meant to fix a problem that =
does not necessarily exist. The Network Security Group =
understands, but does not fully agree, with popular proposition that =
IPSec and IKE are too complicated to modify further. For those =
that have used and implemented both of these protocols, we are =
comfortable with implementation and operational results. The =
proposed "son of IKE's" lack of backwards compatibility to =
IPSec and IKE add further resistance to abandoning these two =
protocols. Far better if a replacement is indeed required, in our =
opinion, to identify and delete or modify those segments of IPSec and =
IKE that are deemed to be confusing or of limited implementation =
flexibility. In our opinion, it is wiser to simplify rather than =
reject and redo. </FONT></P>
<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Wilson Leung</FONT>
</P>
<P><FONT SIZE=3D2>Wilson Leung, CISSP</FONT>
<BR><FONT SIZE=3D2>Senior Security Consultant</FONT>
<BR><FONT SIZE=3D2>Nortel Networks - NGN Security Solutions Team</FONT>
<BR><FONT SIZE=3D2>301-570-0966 ESN (451)</FONT>
<BR><FONT SIZE=3D2>240-604-4235 Cell</FONT>
</P>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C12CB4.F296A960--
From owner-ipsec@lists.tislabs.com Fri Aug 24 10:46:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OHkJD27256;
Fri, 24 Aug 2001 10:46:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03424
Fri, 24 Aug 2001 12:48:54 -0400 (EDT)
Message-ID: <9D048F4A422CD411A56500B0D0209C5B02861C8B@NS-CA>
From: Jay Ratford <Jratford@netscreen.com>
To: "'jshukla'" <jshukla@earthlink.net>,
"'William Dixon'"
<wdixon@windows.microsoft.com>, ipsec@lists.tislabs.com,
Ari Huttunen
<Ari.Huttunen@F-Secure.com>
Subject: RE: Ipsec load balancing devices - UDP-ESP impact
Date: Fri, 24 Aug 2001 09:54:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It doesn't support fail-over, unless your using something like our device
which maintains "state" between two active vpn gateways. As far as I know
where the only vendors doing this: Fully Meshed, Active Active with
session&sa mirroring between 2 active devices for statefull failover.
-----Original Message-----
From: jshukla [mailto:jshukla@earthlink.net]
Sent: Friday, August 24, 2001 9:21 AM
To: Jay Ratford; 'William Dixon'; ipsec@lists.tislabs.com; Ari Huttunen
Subject: Re: Ipsec load balancing devices - UDP-ESP impact
how does the load balancing work when one of
the VPN gateways dies?
regards,
Jayant
----- Original Message -----
From: "Jay Ratford" <Jratford@netscreen.com>
To: "'William Dixon'" <wdixon@windows.microsoft.com>; "jshukla"
<jshukla@earthlink.net>; <ipsec@lists.tislabs.com>; "Ari Huttunen"
<Ari.Huttunen@F-Secure.com>
Sent: Friday, August 24, 2001 8:32 AM
Subject: RE: Ipsec load balancing devices - UDP-ESP impact
> Alteon (now Nortel) devices perform NAT and NAPT, but not in default
> configurations. They also have a "VPN Load-Balancing" solution to load
> balance your VPN Gateway's - It does keep some kind of state, specifically
> how i'm not sure.
>
>
>
> -----Original Message-----
> From: William Dixon [mailto:wdixon@windows.microsoft.com]
> Sent: Thursday, August 23, 2001 8:11 PM
> To: jshukla; ipsec@lists.tislabs.com; Ari Huttunen
> Subject: Ipsec load balancing devices - UDP-ESP impact
>
>
> Jayant, I've checked around on the popular load balancing product web
> sites. But the details are often not avail, or buried in technical docs
> that require a customer account to access.
>
> Does anyone know of any products that do NAT or "VLAN" translation and
> specifically provide mapping support for IPSec "sessions", that is,
> devices that aren't already IPSec gateways and terminating IPSec before
> they do NAT ?
>
> I'd like to know if they do something more than maintain source IP-based
> mappings, like cookie-pair-SPI tracking or something.
>
> In any case, combining IKE & ESP in the same UDP port 500 encapsulation
> makes the take easier by having to track only one UDP src/dst pair - vs.
> IPSec ESP inbound and outbound SPIs, in addition to the IKE traffic, or
> in addition to another critically related UDP src/dst port pair carrying
> ESP.
>
> Wm
> William Dixon
> Program Manager - Network Security, IPSec
> Windows Networking
>
> -----Original Message-----
> From: jshukla [mailto:jshukla@earthlink.net]
> Sent: Saturday, August 18, 2001 5:10 PM
> To: ipsec@lists.tislabs.com; Ari Huttunen
> Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits
> of , i-cookie=0
>
>
>
> ----- Original Message -----
> From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
> >
> > At the Helsinki bakeoff there were seven implementations of the latest
> drafts,
> > including us. Additional three had implementations of some earlier
> > draft. This would be a good time for someone to provide really solid
> > arguments against using just one port, if such arguments exist. Like,
> > statistical calculations of actual overhead. The firewall-argument
> > doesn't cut it, it
>
> Have you guys considered how network based load-balancing
> will work in your approach? This is a general question regarding your
> approach, not using IKE port for ESP will not exactly help.
>
> regards,
> Jayant
From owner-ipsec@lists.tislabs.com Fri Aug 24 10:46:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OHkJD27257;
Fri, 24 Aug 2001 10:46:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03471
Fri, 24 Aug 2001 13:03:26 -0400 (EDT)
Message-ID: <8DCFE693DDFFD111AC4100A0C9B8DB9405DF1FD6@hdsmsx33.hd.intel.com>
From: "Eissa, Mohamed" <mohamed.eissa@intel.com>
To: ipsec@lists.tislabs.com
Subject: IKE and certificate chains
Date: Fri, 24 Aug 2001 10:10:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
Regarding the certificate chains within the IKE certificate payload, looks
like there are two ways to achieve this. First, the certificate encoding
field is set to "X509 Certificate" and multiple certificate payloads carry
the chain, one certificate per payload. Second, the certificate encoded
field is set to "PKCS#7 wrapper" and one payload will be used to carry the
whole chain.
Did I understood this correctly, please correct me if I am wrong; and I
would like also to know which was is getting wide acceptance and why.
Regards,
Mohamed Eissa
From owner-ipsec@lists.tislabs.com Fri Aug 24 11:57:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OIvqD00364;
Fri, 24 Aug 2001 11:57:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03569
Fri, 24 Aug 2001 14:05:19 -0400 (EDT)
Message-Id: <200108241810.f7OIAUF00677@dharkins@lounge.orgatty.lounge.org>
To: "Wilson Leung" <leungw@nortelnetworks.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying Son of IKE
In-Reply-To: Your message of "Fri, 24 Aug 2001 11:53:41 EDT."
<958D701256C5D411953200508BE3761802556943@zrtpd0jb.us.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <674.998676630.1@lounge.org>
Date: Fri, 24 Aug 2001 11:10:30 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I think that Nortel Network's Portfolio Integration Network Security
Group misunderstands the scope of the work (and the separation of the
base protocols from key management). None of the son-of-ike work will in
anyway impact "backwards compatibility to IPsec". AH and ESP do not know
or care whether the SAs they are using were established by IKE,
son-of-ike, JFK, LBJ or W.
Dan.
On Fri, 24 Aug 2001 11:53:41 EDT you wrote
>
> IETF Ipsec Community:
>
> In the opinion of the Nortel Network's Portfolio Integration Network
> Security Group, the recent push to fully embrace the "son of IKE"
> replacement for IPSec and IKE by the IETF Standards community is a rushed
> judgment meant to fix a problem that does not necessarily exist. The
> Network Security Group understands, but does not fully agree, with popular
> proposition that IPSec and IKE are too complicated to modify further. For
> those that have used and implemented both of these protocols, we are
> comfortable with implementation and operational results. The proposed "son
> of IKE's" lack of backwards compatibility to IPSec and IKE add further
> resistance to abandoning these two protocols. Far better if a replacement
> is indeed required, in our opinion, to identify and delete or modify those
> segments of IPSec and IKE that are deemed to be confusing or of limited
> implementation flexibility. In our opinion, it is wiser to simplify rather
> than reject and redo.
>
> Regards,
> Wilson Leung
>
> Wilson Leung, CISSP
> Senior Security Consultant
> Nortel Networks - NGN Security Solutions Team
> 301-570-0966 ESN (451)
> 240-604-4235 Cell
>
>
>
> ------_=_NextPart_001_01C12CB4.F296A960
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 5.5.2654.89">
> <TITLE>RE: Simplifying Son of IKE</TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=3D2>IETF Ipsec Community:</FONT>
> </P>
>
> <P><FONT SIZE=3D2>In the opinion of the Nortel Network's Portfolio =
> Integration Network Security Group, the recent push to fully embrace =
> the "son of IKE" replacement for IPSec and IKE by the IETF =
> Standards community is a rushed judgment meant to fix a problem that =
> does not necessarily exist. The Network Security Group =
> understands, but does not fully agree, with popular proposition that =
> IPSec and IKE are too complicated to modify further. For those =
> that have used and implemented both of these protocols, we are =
> comfortable with implementation and operational results. The =
> proposed "son of IKE's" lack of backwards compatibility to =
> IPSec and IKE add further resistance to abandoning these two =
> protocols. Far better if a replacement is indeed required, in our =
> opinion, to identify and delete or modify those segments of IPSec and =
> IKE that are deemed to be confusing or of limited implementation =
> flexibility. In our opinion, it is wiser to simplify rather than =
> reject and redo. </FONT></P>
>
> <P><FONT SIZE=3D2>Regards,</FONT>
> <BR><FONT SIZE=3D2>Wilson Leung</FONT>
> </P>
>
> <P><FONT SIZE=3D2>Wilson Leung, CISSP</FONT>
> <BR><FONT SIZE=3D2>Senior Security Consultant</FONT>
> <BR><FONT SIZE=3D2>Nortel Networks - NGN Security Solutions Team</FONT>
> <BR><FONT SIZE=3D2>301-570-0966 ESN (451)</FONT>
> <BR><FONT SIZE=3D2>240-604-4235 Cell</FONT>
> </P>
> <BR>
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C12CB4.F296A960--
From owner-ipsec@lists.tislabs.com Fri Aug 24 13:26:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OKQGD06530;
Fri, 24 Aug 2001 13:26:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03771
Fri, 24 Aug 2001 15:39:51 -0400 (EDT)
Message-ID: <000601c12cb8$f169c550$bfb02304@ffb5b>
From: "jshukla" <jshukla@earthlink.net>
To: "Jay Ratford" <Jratford@netscreen.com>,
"'William Dixon'" <wdixon@windows.microsoft.com>, <ipsec@lists.tislabs.com>,
"Ari Huttunen" <Ari.Huttunen@F-Secure.com>
References: <9D048F4A422CD411A56500B0D0209C5B02861C88@NS-CA>
Subject: Re: Ipsec load balancing devices - UDP-ESP impact
Date: Fri, 24 Aug 2001 09:20:59 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
how does the load balancing work when one of
the VPN gateways dies?
regards,
Jayant
----- Original Message -----
From: "Jay Ratford" <Jratford@netscreen.com>
To: "'William Dixon'" <wdixon@windows.microsoft.com>; "jshukla"
<jshukla@earthlink.net>; <ipsec@lists.tislabs.com>; "Ari Huttunen"
<Ari.Huttunen@F-Secure.com>
Sent: Friday, August 24, 2001 8:32 AM
Subject: RE: Ipsec load balancing devices - UDP-ESP impact
> Alteon (now Nortel) devices perform NAT and NAPT, but not in default
> configurations. They also have a "VPN Load-Balancing" solution to load
> balance your VPN Gateway's - It does keep some kind of state, specifically
> how i'm not sure.
>
>
>
> -----Original Message-----
> From: William Dixon [mailto:wdixon@windows.microsoft.com]
> Sent: Thursday, August 23, 2001 8:11 PM
> To: jshukla; ipsec@lists.tislabs.com; Ari Huttunen
> Subject: Ipsec load balancing devices - UDP-ESP impact
>
>
> Jayant, I've checked around on the popular load balancing product web
> sites. But the details are often not avail, or buried in technical docs
> that require a customer account to access.
>
> Does anyone know of any products that do NAT or "VLAN" translation and
> specifically provide mapping support for IPSec "sessions", that is,
> devices that aren't already IPSec gateways and terminating IPSec before
> they do NAT ?
>
> I'd like to know if they do something more than maintain source IP-based
> mappings, like cookie-pair-SPI tracking or something.
>
> In any case, combining IKE & ESP in the same UDP port 500 encapsulation
> makes the take easier by having to track only one UDP src/dst pair - vs.
> IPSec ESP inbound and outbound SPIs, in addition to the IKE traffic, or
> in addition to another critically related UDP src/dst port pair carrying
> ESP.
>
> Wm
> William Dixon
> Program Manager - Network Security, IPSec
> Windows Networking
>
> -----Original Message-----
> From: jshukla [mailto:jshukla@earthlink.net]
> Sent: Saturday, August 18, 2001 5:10 PM
> To: ipsec@lists.tislabs.com; Ari Huttunen
> Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits
> of , i-cookie=0
>
>
>
> ----- Original Message -----
> From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
> >
> > At the Helsinki bakeoff there were seven implementations of the latest
> drafts,
> > including us. Additional three had implementations of some earlier
> > draft. This would be a good time for someone to provide really solid
> > arguments against using just one port, if such arguments exist. Like,
> > statistical calculations of actual overhead. The firewall-argument
> > doesn't cut it, it
>
> Have you guys considered how network based load-balancing
> will work in your approach? This is a general question regarding your
> approach, not using IKE port for ESP will not exactly help.
>
> regards,
> Jayant
From owner-ipsec@lists.tislabs.com Fri Aug 24 13:28:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OKSdD06611;
Fri, 24 Aug 2001 13:28:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03805
Fri, 24 Aug 2001 15:53:02 -0400 (EDT)
Message-Id: <200108241959.f7OJwtF00872@dharkins@lounge.orgatty.lounge.org>
To: Jay Ratford <Jratford@netscreen.com>
Cc: "'jshukla'" <jshukla@earthlink.net>,
"'William Dixon'" <wdixon@windows.microsoft.com>, ipsec@lists.tislabs.com,
Ari Huttunen <Ari.Huttunen@F-Secure.com>
Subject: Re: Ipsec load balancing devices - UDP-ESP impact
In-Reply-To: Your message of "Fri, 24 Aug 2001 09:54:51 PDT."
<9D048F4A422CD411A56500B0D0209C5B02861C8B@NS-CA>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <869.998683135.1@lounge.org>
Date: Fri, 24 Aug 2001 12:58:55 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Actually you're not. There's another vendor out there that does
dynamic load balancing and active session failover of IPsec and IKE SAs--
fully meshed if so configured-- as well as PPTP and L2TP tunnels and BGP,
OSPF, and RIP. (It was a great day when I failed the box who was currently
assigned the workload of sucking down a full Internet routing table via
BGP and watched the entire session-- including all the routing state and
the TCP state-- failover to another node without a hitch). It's subsecond
failover too and beat the crap out of the competition in a trade rag's
head-to-head comparison. And it's not just between "2 active devices",
the size of the cluster can be 2, 3, 4 or more and adding nodes gives you
a non-linear increase in performance (that eventually tapers off).
This vendor has had this capability for around three years. I won't
mention who it is because for some strange reason they don't advertise
this expertise.
Dan.
On Fri, 24 Aug 2001 09:54:51 PDT you wrote
> It doesn't support fail-over, unless your using something like our device
> which maintains "state" between two active vpn gateways. As far as I know
> where the only vendors doing this: Fully Meshed, Active Active with
> session&sa mirroring between 2 active devices for statefull failover.
>
> -----Original Message-----
> From: jshukla [mailto:jshukla@earthlink.net]
> Sent: Friday, August 24, 2001 9:21 AM
> To: Jay Ratford; 'William Dixon'; ipsec@lists.tislabs.com; Ari Huttunen
> Subject: Re: Ipsec load balancing devices - UDP-ESP impact
>
>
> how does the load balancing work when one of
> the VPN gateways dies?
>
> regards,
> Jayant
>
> ----- Original Message -----
> From: "Jay Ratford" <Jratford@netscreen.com>
> To: "'William Dixon'" <wdixon@windows.microsoft.com>; "jshukla"
> <jshukla@earthlink.net>; <ipsec@lists.tislabs.com>; "Ari Huttunen"
> <Ari.Huttunen@F-Secure.com>
> Sent: Friday, August 24, 2001 8:32 AM
> Subject: RE: Ipsec load balancing devices - UDP-ESP impact
>
>
> > Alteon (now Nortel) devices perform NAT and NAPT, but not in default
> > configurations. They also have a "VPN Load-Balancing" solution to load
> > balance your VPN Gateway's - It does keep some kind of state, specifically
> > how i'm not sure.
> >
> >
> >
> > -----Original Message-----
> > From: William Dixon [mailto:wdixon@windows.microsoft.com]
> > Sent: Thursday, August 23, 2001 8:11 PM
> > To: jshukla; ipsec@lists.tislabs.com; Ari Huttunen
> > Subject: Ipsec load balancing devices - UDP-ESP impact
> >
> >
> > Jayant, I've checked around on the popular load balancing product web
> > sites. But the details are often not avail, or buried in technical docs
> > that require a customer account to access.
> >
> > Does anyone know of any products that do NAT or "VLAN" translation and
> > specifically provide mapping support for IPSec "sessions", that is,
> > devices that aren't already IPSec gateways and terminating IPSec before
> > they do NAT ?
> >
> > I'd like to know if they do something more than maintain source IP-based
> > mappings, like cookie-pair-SPI tracking or something.
> >
> > In any case, combining IKE & ESP in the same UDP port 500 encapsulation
> > makes the take easier by having to track only one UDP src/dst pair - vs.
> > IPSec ESP inbound and outbound SPIs, in addition to the IKE traffic, or
> > in addition to another critically related UDP src/dst port pair carrying
> > ESP.
> >
> > Wm
> > William Dixon
> > Program Manager - Network Security, IPSec
> > Windows Networking
> >
> > -----Original Message-----
> > From: jshukla [mailto:jshukla@earthlink.net]
> > Sent: Saturday, August 18, 2001 5:10 PM
> > To: ipsec@lists.tislabs.com; Ari Huttunen
> > Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits
> > of , i-cookie=0
> >
> >
> >
> > ----- Original Message -----
> > From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
> > >
> > > At the Helsinki bakeoff there were seven implementations of the latest
> > drafts,
> > > including us. Additional three had implementations of some earlier
> > > draft. This would be a good time for someone to provide really solid
> > > arguments against using just one port, if such arguments exist. Like,
> > > statistical calculations of actual overhead. The firewall-argument
> > > doesn't cut it, it
> >
> > Have you guys considered how network based load-balancing
> > will work in your approach? This is a general question regarding your
> > approach, not using IKE port for ESP will not exactly help.
> >
> > regards,
> > Jayant
From owner-ipsec@lists.tislabs.com Fri Aug 24 13:49:33 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OKnXD06918;
Fri, 24 Aug 2001 13:49:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03867
Fri, 24 Aug 2001 16:10:55 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Subject: RE: Ipsec load balancing devices - UDP-ESP impact
Date: Fri, 24 Aug 2001 13:15:51 -0700
Message-ID: <2E33960095B58E40A4D3345AB9F65EC1025337BB@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Ipsec load balancing devices - UDP-ESP impact
Thread-Index: AcEs12rhhOexguHEQy6OcFzhTkLOqQAAfEFg
From: "William Dixon" <wdixon@windows.microsoft.com>
To: "Dan Harkins" <dharkins@lounge.org>,
"Jay Ratford" <Jratford@netscreen.com>
Cc: "jshukla" <jshukla@earthlink.net>, <ipsec@lists.tislabs.com>,
"Ari Huttunen" <Ari.Huttunen@F-Secure.com>
X-OriginalArrivalTime: 24 Aug 2001 20:15:52.0382 (UTC) FILETIME=[92B315E0:01C12CD9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA03864
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I'm aware of the Crytocluster capabilities - great stuff. Which is why
my original question for the thread was when the devices aren't
terminating the IPSec SAs, rather in the middle looking at a packet
stream, and doing NAT.
-----Original Message-----
From: Dan Harkins [mailto:dharkins@lounge.org]
Sent: Friday, August 24, 2001 12:59 PM
To: Jay Ratford
Cc: 'jshukla'; William Dixon; ipsec@lists.tislabs.com; Ari Huttunen
Subject: Re: Ipsec load balancing devices - UDP-ESP impact
Actually you're not. There's another vendor out there that does
dynamic load balancing and active session failover of IPsec and IKE
SAs-- fully meshed if so configured-- as well as PPTP and L2TP tunnels
and BGP,
OSPF, and RIP. (It was a great day when I failed the box who was
currently assigned the workload of sucking down a full Internet routing
table via BGP and watched the entire session-- including all the routing
state and the TCP state-- failover to another node without a hitch).
It's subsecond failover too and beat the crap out of the competition in
a trade rag's head-to-head comparison. And it's not just between "2
active devices", the size of the cluster can be 2, 3, 4 or more and
adding nodes gives you a non-linear increase in performance (that
eventually tapers off).
This vendor has had this capability for around three years. I won't
mention who it is because for some strange reason they don't advertise
this expertise.
Dan.
On Fri, 24 Aug 2001 09:54:51 PDT you wrote
> It doesn't support fail-over, unless your using something like our
> device which maintains "state" between two active vpn gateways. As far
> as I know where the only vendors doing this: Fully Meshed, Active
> Active with session&sa mirroring between 2 active devices for
> statefull failover.
>
> -----Original Message-----
> From: jshukla [mailto:jshukla@earthlink.net]
> Sent: Friday, August 24, 2001 9:21 AM
> To: Jay Ratford; 'William Dixon'; ipsec@lists.tislabs.com; Ari
> Huttunen
> Subject: Re: Ipsec load balancing devices - UDP-ESP impact
>
>
> how does the load balancing work when one of
> the VPN gateways dies?
>
> regards,
> Jayant
>
> ----- Original Message -----
> From: "Jay Ratford" <Jratford@netscreen.com>
> To: "'William Dixon'" <wdixon@windows.microsoft.com>; "jshukla"
> <jshukla@earthlink.net>; <ipsec@lists.tislabs.com>; "Ari Huttunen"
> <Ari.Huttunen@F-Secure.com>
> Sent: Friday, August 24, 2001 8:32 AM
> Subject: RE: Ipsec load balancing devices - UDP-ESP impact
>
>
> > Alteon (now Nortel) devices perform NAT and NAPT, but not in default
> > configurations. They also have a "VPN Load-Balancing" solution to
> > load balance your VPN Gateway's - It does keep some kind of state,
> > specifically how i'm not sure.
> >
> >
> >
> > -----Original Message-----
> > From: William Dixon [mailto:wdixon@windows.microsoft.com]
> > Sent: Thursday, August 23, 2001 8:11 PM
> > To: jshukla; ipsec@lists.tislabs.com; Ari Huttunen
> > Subject: Ipsec load balancing devices - UDP-ESP impact
> >
> >
> > Jayant, I've checked around on the popular load balancing product
> > web sites. But the details are often not avail, or buried in
> > technical docs that require a customer account to access.
> >
> > Does anyone know of any products that do NAT or "VLAN" translation
> > and specifically provide mapping support for IPSec "sessions", that
> > is, devices that aren't already IPSec gateways and terminating IPSec
> > before they do NAT ?
> >
> > I'd like to know if they do something more than maintain source
> > IP-based mappings, like cookie-pair-SPI tracking or something.
> >
> > In any case, combining IKE & ESP in the same UDP port 500
> > encapsulation makes the take easier by having to track only one UDP
> > src/dst pair - vs. IPSec ESP inbound and outbound SPIs, in addition
> > to the IKE traffic, or in addition to another critically related UDP
> > src/dst port pair carrying ESP.
> >
> > Wm
> > William Dixon
> > Program Manager - Network Security, IPSec
> > Windows Networking
> >
> > -----Original Message-----
> > From: jshukla [mailto:jshukla@earthlink.net]
> > Sent: Saturday, August 18, 2001 5:10 PM
> > To: ipsec@lists.tislabs.com; Ari Huttunen
> > Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap,
> > 32bits of , i-cookie=0
> >
> >
> >
> > ----- Original Message -----
> > From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
> > >
> > > At the Helsinki bakeoff there were seven implementations of the
> > > latest
> > drafts,
> > > including us. Additional three had implementations of some earlier
> > > draft. This would be a good time for someone to provide really
> > > solid arguments against using just one port, if such arguments
> > > exist. Like, statistical calculations of actual overhead. The
> > > firewall-argument doesn't cut it, it
> >
> > Have you guys considered how network based load-balancing will work
> > in your approach? This is a general question regarding your
> > approach, not using IKE port for ESP will not exactly help.
> >
> > regards,
> > Jayant
From owner-ipsec@lists.tislabs.com Fri Aug 24 13:57:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OKvLD07020;
Fri, 24 Aug 2001 13:57:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03898
Fri, 24 Aug 2001 16:16:51 -0400 (EDT)
X-mProtect: Fri, 24 Aug 2001 13:23:44 -0700 Nokia Silicon Valley Messaging Protection
Message-ID: <3B86B7CF.847A8ADF@iprg.nokia.com>
Date: Fri, 24 Aug 2001 13:23:43 -0700
From: Marc Solsona-Palomar <marc@iprg.nokia.com>
Organization: Nokia NIC
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Harkins <dharkins@lounge.org>
CC: Jay Ratford <Jratford@netscreen.com>, "'jshukla'" <jshukla@earthlink.net>,
"'William Dixon'" <wdixon@windows.microsoft.com>, ipsec@lists.tislabs.com,
Ari Huttunen <Ari.Huttunen@F-Secure.com>
Subject: Re: Ipsec load balancing devices - UDP-ESP impact
References: <200108241959.f7OJwtF00872@dharkins@lounge.orgatty.lounge.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
You can have a look at Nokia VPN products, you'll see clustering, fail over and
such. I know we shouldn't be using IETF groups for advertising, but I'm answering
a question guys!
http://www.nokia.com/vpn/nokiavpn.html
marc.
Dan Harkins wrote:
> Actually you're not. There's another vendor out there that does
> dynamic load balancing and active session failover of IPsec and IKE SAs--
> fully meshed if so configured-- as well as PPTP and L2TP tunnels and BGP,
> OSPF, and RIP. (It was a great day when I failed the box who was currently
> assigned the workload of sucking down a full Internet routing table via
> BGP and watched the entire session-- including all the routing state and
> the TCP state-- failover to another node without a hitch). It's subsecond
> failover too and beat the crap out of the competition in a trade rag's
> head-to-head comparison. And it's not just between "2 active devices",
> the size of the cluster can be 2, 3, 4 or more and adding nodes gives you
> a non-linear increase in performance (that eventually tapers off).
>
> This vendor has had this capability for around three years. I won't
> mention who it is because for some strange reason they don't advertise
> this expertise.
>
> Dan.
>
> On Fri, 24 Aug 2001 09:54:51 PDT you wrote
> > It doesn't support fail-over, unless your using something like our device
> > which maintains "state" between two active vpn gateways. As far as I know
> > where the only vendors doing this: Fully Meshed, Active Active with
> > session&sa mirroring between 2 active devices for statefull failover.
> >
> > -----Original Message-----
> > From: jshukla [mailto:jshukla@earthlink.net]
> > Sent: Friday, August 24, 2001 9:21 AM
> > To: Jay Ratford; 'William Dixon'; ipsec@lists.tislabs.com; Ari Huttunen
> > Subject: Re: Ipsec load balancing devices - UDP-ESP impact
> >
> >
> > how does the load balancing work when one of
> > the VPN gateways dies?
> >
> > regards,
> > Jayant
> >
> > ----- Original Message -----
> > From: "Jay Ratford" <Jratford@netscreen.com>
> > To: "'William Dixon'" <wdixon@windows.microsoft.com>; "jshukla"
> > <jshukla@earthlink.net>; <ipsec@lists.tislabs.com>; "Ari Huttunen"
> > <Ari.Huttunen@F-Secure.com>
> > Sent: Friday, August 24, 2001 8:32 AM
> > Subject: RE: Ipsec load balancing devices - UDP-ESP impact
> >
> >
> > > Alteon (now Nortel) devices perform NAT and NAPT, but not in default
> > > configurations. They also have a "VPN Load-Balancing" solution to load
> > > balance your VPN Gateway's - It does keep some kind of state, specifically
> > > how i'm not sure.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: William Dixon [mailto:wdixon@windows.microsoft.com]
> > > Sent: Thursday, August 23, 2001 8:11 PM
> > > To: jshukla; ipsec@lists.tislabs.com; Ari Huttunen
> > > Subject: Ipsec load balancing devices - UDP-ESP impact
> > >
> > >
> > > Jayant, I've checked around on the popular load balancing product web
> > > sites. But the details are often not avail, or buried in technical docs
> > > that require a customer account to access.
> > >
> > > Does anyone know of any products that do NAT or "VLAN" translation and
> > > specifically provide mapping support for IPSec "sessions", that is,
> > > devices that aren't already IPSec gateways and terminating IPSec before
> > > they do NAT ?
> > >
> > > I'd like to know if they do something more than maintain source IP-based
> > > mappings, like cookie-pair-SPI tracking or something.
> > >
> > > In any case, combining IKE & ESP in the same UDP port 500 encapsulation
> > > makes the take easier by having to track only one UDP src/dst pair - vs.
> > > IPSec ESP inbound and outbound SPIs, in addition to the IKE traffic, or
> > > in addition to another critically related UDP src/dst port pair carrying
> > > ESP.
> > >
> > > Wm
> > > William Dixon
> > > Program Manager - Network Security, IPSec
> > > Windows Networking
> > >
> > > -----Original Message-----
> > > From: jshukla [mailto:jshukla@earthlink.net]
> > > Sent: Saturday, August 18, 2001 5:10 PM
> > > To: ipsec@lists.tislabs.com; Ari Huttunen
> > > Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits
> > > of , i-cookie=0
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
> > > >
> > > > At the Helsinki bakeoff there were seven implementations of the latest
> > > drafts,
> > > > including us. Additional three had implementations of some earlier
> > > > draft. This would be a good time for someone to provide really solid
> > > > arguments against using just one port, if such arguments exist. Like,
> > > > statistical calculations of actual overhead. The firewall-argument
> > > > doesn't cut it, it
> > >
> > > Have you guys considered how network based load-balancing
> > > will work in your approach? This is a general question regarding your
> > > approach, not using IKE port for ESP will not exactly help.
> > >
> > > regards,
> > > Jayant
From owner-ipsec@lists.tislabs.com Sun Aug 26 02:08:18 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7Q98HD16466;
Sun, 26 Aug 2001 02:08:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05916
Sun, 26 Aug 2001 03:59:18 -0400 (EDT)
Message-ID: <765C241A3031D3119F050008C7E9C2CC095A5B11@SI2061EXCH001U>
From: "Chen, Jun (Jun)" <cjun@lucent.com>
To: ipsec@lists.tislabs.com
Subject: Preshared key bound to peer IP address in main mode
Date: Sun, 26 Aug 2001 16:06:23 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all
I am new to IPSec. I don't understand the following statement in
RFC2409 IKE (page 16)
"When using pre-shared key authentication with Main Mode the key can only be
identified by the
IP address of the peers since HASH_I must be computed before the initiator
has process IDir"
I would highly appreciate if some can give a guide for this. It really make
me confuse.
With Best Regards,
Chen Jun
> Lucent Technologies Singapore Pte Ltd
> Customer Technical Support (CTS)
> 750D Chai Chee Rd, #06-01 (Lift Lobby 1)
> Technopark @ Chai Chee
> Singapore 469004
Tel: +65 - 240 8741
Fax: +65 - 240 8522
Email: cjun@lucent.com
From owner-ipsec@lists.tislabs.com Sun Aug 26 23:33:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7R6XSD29707;
Sun, 26 Aug 2001 23:33:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07314
Mon, 27 Aug 2001 01:36:15 -0400 (EDT)
From: "Henrik Grankvist" <henrik.grankvist@aerotechtelub.se>
To: "Ipsec" <ipsec@lists.tislabs.com>
Subject: IPSec client...
Date: Mon, 27 Aug 2001 07:42:43 +0200
Message-ID: <NFBBLCDABMACHEODNKBJMEMACBAA.henrik.grankvist@aerotechtelub.se>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello!
I want to find out if Windows NT4.0 has any IPSec client built in, that can
be
used with appliances such as Cisco routers in 1700 or 2600 series...
I know that win2000 has a standard IPSec client but I wonder if the
same applies to WinNT4.0 or does NT only support PPTP ??
Regards,
Henrik
Student at the University of Växjö, Sweden.
From owner-ipsec@lists.tislabs.com Mon Aug 27 04:44:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RBimD27551;
Mon, 27 Aug 2001 04:44:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07731
Mon, 27 Aug 2001 06:44:05 -0400 (EDT)
Message-Id: <200108271050.GAA10273@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: ipsec@lists.tislabs.com, design@lists.freeswan.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-richardson-ipsec-opportunistic-01.txt
Date: Mon, 27 Aug 2001 06:50:06 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : A method for doing opportunistic encryption with IKE
Author(s) : M. Richardson, D. Redelmeier, H. Spencer
Filename : draft-richardson-ipsec-opportunistic-01.txt
Pages : 32
Date : 24-Aug-01
This document discusses a method used by the Linux FreeS/WAN project
to opportunistically encrypt traffic between peers without specific
pre-arrangement. It describes the infrastructure necessary to
support this configuration. Opportunistic Encryption (OE) provides
major simplifications of typical configurations, as it scales
linearly rather than quadratically in the number of systems involved.
There are naturally some risks, which are described.
| This document is offered up as an Informational RFC.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-richardson-ipsec-opportunistic-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-richardson-ipsec-opportunistic-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010824141409.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-richardson-ipsec-opportunistic-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-richardson-ipsec-opportunistic-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010824141409.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Mon Aug 27 05:59:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RCxDD01953;
Mon, 27 Aug 2001 05:59:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07837
Mon, 27 Aug 2001 08:15:04 -0400 (EDT)
Message-ID: <000601c12d86$06119e10$3cb12304@ffb5b>
From: "jshukla" <jshukla@earthlink.net>
To: "Marc Solsona-Palomar" <marc@iprg.nokia.com>,
"Dan Harkins" <dharkins@lounge.org>
Cc: "Jay Ratford" <Jratford@netscreen.com>,
"'William Dixon'" <wdixon@windows.microsoft.com>, <ipsec@lists.tislabs.com>,
"Ari Huttunen" <Ari.Huttunen@F-Secure.com>
References: <200108241959.f7OJwtF00872@dharkins@lounge.orgatty.lounge.org> <3B86B7CF.847A8ADF@iprg.nokia.com>
Subject: Re: Ipsec load balancing devices - UDP-ESP impact
Date: Sat, 25 Aug 2001 09:50:17 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Your solution is based on sharing SAs and
session keys between node, right?! I thought
that was a big no no.
Secondly, what I gather from the one paragraph
blurb that I found on IP-clustering on your web
site is that it is a layer-2 solution. You use
Ethernet multicast, unicast, and forwarding.
In unicast same Ethernet address is used by
all ports according to the article. That means
all nodes get the same packet. The situation
is same in multicast and all nodes receive all
packets. So every node is processing the
packet?! Doesn't seem like this is what one
should be doing.
The last case, is forwarding. Here only one
node gets the packet. This is real load balancing.
However, a layer 2 solution is something that
I find hard to digest.
Another question, when you have to debug/maintain
a node, won't you have to disconnect it from the cluster
as all nodes are sharing the same IP address?
In case I have misunderstood your solution,
please accept my apologies.
regards,
Jayant
p.s.: we have an all IP layer based load balancing
solution for IPsec coming up.
----- Original Message -----
From: "Marc Solsona-Palomar" <marc@iprg.nokia.com>
To: "Dan Harkins" <dharkins@lounge.org>
Cc: "Jay Ratford" <Jratford@netscreen.com>; "'jshukla'"
<jshukla@earthlink.net>; "'William Dixon'" <wdixon@windows.microsoft.com>;
<ipsec@lists.tislabs.com>; "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
Sent: Friday, August 24, 2001 1:23 PM
Subject: Re: Ipsec load balancing devices - UDP-ESP impact
>
> You can have a look at Nokia VPN products, you'll see clustering, fail
over and
> such. I know we shouldn't be using IETF groups for advertising, but I'm
answering
> a question guys!
>
> http://www.nokia.com/vpn/nokiavpn.html
>
> marc.
>
> Dan Harkins wrote:
>
> > Actually you're not. There's another vendor out there that does
> > dynamic load balancing and active session failover of IPsec and IKE
SAs--
> > fully meshed if so configured-- as well as PPTP and L2TP tunnels and
BGP,
> > OSPF, and RIP. (It was a great day when I failed the box who was
currently
> > assigned the workload of sucking down a full Internet routing table via
> > BGP and watched the entire session-- including all the routing state and
> > the TCP state-- failover to another node without a hitch). It's
subsecond
> > failover too and beat the crap out of the competition in a trade rag's
> > head-to-head comparison. And it's not just between "2 active devices",
> > the size of the cluster can be 2, 3, 4 or more and adding nodes gives
you
> > a non-linear increase in performance (that eventually tapers off).
> >
> > This vendor has had this capability for around three years. I won't
> > mention who it is because for some strange reason they don't advertise
> > this expertise.
> >
> > Dan.
> >
> > On Fri, 24 Aug 2001 09:54:51 PDT you wrote
> > > It doesn't support fail-over, unless your using something like our
device
> > > which maintains "state" between two active vpn gateways. As far as I
know
> > > where the only vendors doing this: Fully Meshed, Active Active with
> > > session&sa mirroring between 2 active devices for statefull failover.
> > >
> > > -----Original Message-----
> > > From: jshukla [mailto:jshukla@earthlink.net]
> > > Sent: Friday, August 24, 2001 9:21 AM
> > > To: Jay Ratford; 'William Dixon'; ipsec@lists.tislabs.com; Ari
Huttunen
> > > Subject: Re: Ipsec load balancing devices - UDP-ESP impact
> > >
> > >
> > > how does the load balancing work when one of
> > > the VPN gateways dies?
> > >
> > > regards,
> > > Jayant
> > >
> > > ----- Original Message -----
> > > From: "Jay Ratford" <Jratford@netscreen.com>
> > > To: "'William Dixon'" <wdixon@windows.microsoft.com>; "jshukla"
> > > <jshukla@earthlink.net>; <ipsec@lists.tislabs.com>; "Ari Huttunen"
> > > <Ari.Huttunen@F-Secure.com>
> > > Sent: Friday, August 24, 2001 8:32 AM
> > > Subject: RE: Ipsec load balancing devices - UDP-ESP impact
> > >
> > >
> > > > Alteon (now Nortel) devices perform NAT and NAPT, but not in default
> > > > configurations. They also have a "VPN Load-Balancing" solution to
load
> > > > balance your VPN Gateway's - It does keep some kind of state,
specifically
> > > > how i'm not sure.
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: William Dixon [mailto:wdixon@windows.microsoft.com]
> > > > Sent: Thursday, August 23, 2001 8:11 PM
> > > > To: jshukla; ipsec@lists.tislabs.com; Ari Huttunen
> > > > Subject: Ipsec load balancing devices - UDP-ESP impact
> > > >
> > > >
> > > > Jayant, I've checked around on the popular load balancing product
web
> > > > sites. But the details are often not avail, or buried in technical
docs
> > > > that require a customer account to access.
> > > >
> > > > Does anyone know of any products that do NAT or "VLAN" translation
and
> > > > specifically provide mapping support for IPSec "sessions", that is,
> > > > devices that aren't already IPSec gateways and terminating IPSec
before
> > > > they do NAT ?
> > > >
> > > > I'd like to know if they do something more than maintain source
IP-based
> > > > mappings, like cookie-pair-SPI tracking or something.
> > > >
> > > > In any case, combining IKE & ESP in the same UDP port 500
encapsulation
> > > > makes the take easier by having to track only one UDP src/dst pair -
vs.
> > > > IPSec ESP inbound and outbound SPIs, in addition to the IKE traffic,
or
> > > > in addition to another critically related UDP src/dst port pair
carrying
> > > > ESP.
> > > >
> > > > Wm
> > > > William Dixon
> > > > Program Manager - Network Security, IPSec
> > > > Windows Networking
> > > >
> > > > -----Original Message-----
> > > > From: jshukla [mailto:jshukla@earthlink.net]
> > > > Sent: Saturday, August 18, 2001 5:10 PM
> > > > To: ipsec@lists.tislabs.com; Ari Huttunen
> > > > Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap,
32bits
> > > > of , i-cookie=0
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
> > > > >
> > > > > At the Helsinki bakeoff there were seven implementations of the
latest
> > > > drafts,
> > > > > including us. Additional three had implementations of some earlier
> > > > > draft. This would be a good time for someone to provide really
solid
> > > > > arguments against using just one port, if such arguments exist.
Like,
> > > > > statistical calculations of actual overhead. The firewall-argument
> > > > > doesn't cut it, it
> > > >
> > > > Have you guys considered how network based load-balancing
> > > > will work in your approach? This is a general question regarding
your
> > > > approach, not using IKE port for ESP will not exactly help.
> > > >
> > > > regards,
> > > > Jayant
>
From owner-ipsec@lists.tislabs.com Mon Aug 27 07:21:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7REL1D14610;
Mon, 27 Aug 2001 07:21:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08212
Mon, 27 Aug 2001 09:34:29 -0400 (EDT)
Message-ID: <B8C72DA21548524180BE5AB32D65F6C208F232@sottmxs09.entrust.com>
From: Greg Carter <greg.carter@entrust.com>
To: "'Eissa, Mohamed'" <mohamed.eissa@intel.com>, ipsec@lists.tislabs.com
Subject: RE: IKE and certificate chains
Date: Mon, 27 Aug 2001 09:41:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C12EFD.F47CAEA0"
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_01C12EFD.F47CAEA0
Content-Type: text/plain;
charset="iso-8859-1"
Hello,
Yes you are correct. The single cert per payload seems to be the most used,
at least when I doing interop testing (a while back now). The reason for
this is that the PKCS#7 wrapping adds no new information, is only additional
overhead and adds yet another format that the IPSEC device would need to
understand. PKCS#7 does not mandate any particular order of the certificate
chain, so there is no advantage to using it.
Greg Carter
Entrust Technologies - http://www.entrust.com
-----Original Message-----
From: Eissa, Mohamed [mailto:mohamed.eissa@intel.com]
Sent: Friday, August 24, 2001 1:11 PM
To: ipsec@lists.tislabs.com
Subject: IKE and certificate chains
Hi,
Regarding the certificate chains within the IKE certificate payload, looks
like there are two ways to achieve this. First, the certificate encoding
field is set to "X509 Certificate" and multiple certificate payloads carry
the chain, one certificate per payload. Second, the certificate encoded
field is set to "PKCS#7 wrapper" and one payload will be used to carry the
whole chain.
------_=_NextPart_001_01C12EFD.F47CAEA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: IKE and certificate chains</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Hello,</FONT>
</P>
<P><FONT SIZE=3D2>Yes you are correct. The single cert per =
payload seems to be the most used, at least when I doing interop =
testing (a while back now). The reason for this is that the =
PKCS#7 wrapping adds no new information, is only additional overhead =
and adds yet another format that the IPSEC device would need to =
understand. PKCS#7 does not mandate any particular order of the =
certificate chain, so there is no advantage to using it.</FONT></P>
<P><FONT SIZE=3D2>Greg Carter</FONT>
<BR><FONT SIZE=3D2>Entrust Technologies - <A =
HREF=3D"http://www.entrust.com" =
TARGET=3D"_blank">http://www.entrust.com</A></FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Eissa, Mohamed [<A =
HREF=3D"mailto:mohamed.eissa@intel.com">mailto:mohamed.eissa@intel.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, August 24, 2001 1:11 PM</FONT>
<BR><FONT SIZE=3D2>To: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>Subject: IKE and certificate chains</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Hi,</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Regarding the certificate chains within the IKE =
certificate payload, looks</FONT>
<BR><FONT SIZE=3D2>like there are two ways to achieve this. First, the =
certificate encoding</FONT>
<BR><FONT SIZE=3D2>field is set to "X509 Certificate" and =
multiple certificate payloads carry</FONT>
<BR><FONT SIZE=3D2>the chain, one certificate per payload. Second, the =
certificate encoded</FONT>
<BR><FONT SIZE=3D2>field is set to "PKCS#7 wrapper" and one =
payload will be used to carry the</FONT>
<BR><FONT SIZE=3D2>whole chain.</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C12EFD.F47CAEA0--
From owner-ipsec@lists.tislabs.com Mon Aug 27 07:46:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7REkKD15161;
Mon, 27 Aug 2001 07:46:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08298
Mon, 27 Aug 2001 10:07:43 -0400 (EDT)
To: "Chen, Jun (Jun)" <cjun@lucent.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Preshared key bound to peer IP address in main mode
References: <765C241A3031D3119F050008C7E9C2CC095A5B11@SI2061EXCH001U>
From: Derek Atkins <warlord@mit.edu>
Date: 27 Aug 2001 10:14:47 -0400
In-Reply-To: "Chen, Jun's message of "Sun, 26 Aug 2001 16:06:23 +0800"
Message-ID: <sjmbsl1y4h4.fsf@rcn.ihtfp.org>
Lines: 42
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
When using pre-shared keys with Main Mode, the only ID you can
use is IP Address.
-derek
"Chen, Jun (Jun)" <cjun@lucent.com> writes:
> Hi all
> I am new to IPSec. I don't understand the following statement in
> RFC2409 IKE (page 16)
>
> "When using pre-shared key authentication with Main Mode the key can only be
> identified by the
> IP address of the peers since HASH_I must be computed before the initiator
> has process IDir"
>
> I would highly appreciate if some can give a guide for this. It really make
> me confuse.
>
> With Best Regards,
>
> Chen Jun
>
>
> > Lucent Technologies Singapore Pte Ltd
> > Customer Technical Support (CTS)
> > 750D Chai Chee Rd, #06-01 (Lift Lobby 1)
> > Technopark @ Chai Chee
> > Singapore 469004
> Tel: +65 - 240 8741
> Fax: +65 - 240 8522
> Email: cjun@lucent.com
>
>
>
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Mon Aug 27 08:22:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RFMSD16081;
Mon, 27 Aug 2001 08:22:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08364
Mon, 27 Aug 2001 10:34:38 -0400 (EDT)
content-class: urn:content-classes:message
Subject: RE: Ipsec load balancing devices - UDP-ESP impact
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Date: Mon, 27 Aug 2001 10:41:38 -0400
Message-ID: <AF2378CBE7016247BC0FD5261F1EEB21068B1B@EXCHANGE01.domain.ecutel.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: Ipsec load balancing devices - UDP-ESP impact
Thread-Index: AcEu+OnQ1992vuwIRFmWwM45aWFIXgAFMGRw
From: "Qiang Zhang" <qzhang@ecutel.com>
To: "jshukla" <jshukla@earthlink.net>,
"Marc Solsona-Palomar" <marc@iprg.nokia.com>,
"Dan Harkins" <dharkins@lounge.org>
Cc: "Jay Ratford" <Jratford@netscreen.com>,
"William Dixon" <wdixon@windows.microsoft.com>, <ipsec@lists.tislabs.com>,
"Ari Huttunen" <Ari.Huttunen@F-Secure.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA08361
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Jayrant,
Am quite interested in your layer3 solution, do you have any tech info
available? But so far I consider L2 solution a better approach, some
comments in below...
Qiang
-----Original Message-----
From: jshukla [mailto:jshukla@earthlink.net]
Sent: Saturday, August 25, 2001 11:50 AM
To: Marc Solsona-Palomar; Dan Harkins
Cc: Jay Ratford; 'William Dixon'; ipsec@lists.tislabs.com; Ari Huttunen
Subject: Re: Ipsec load balancing devices - UDP-ESP impact
Your solution is based on sharing SAs and
session keys between node, right?! I thought
that was a big no no.
=>the participating nodes in the cluster can remain as a close set,
though sharing
keys/SAs can potentially expose it to any security threat, it is not
necessary
true I think. would you further detail on the threat models on the
cluster?
Secondly, what I gather from the one paragraph
blurb that I found on IP-clustering on your web
site is that it is a layer-2 solution. You use
Ethernet multicast, unicast, and forwarding.
In unicast same Ethernet address is used by
all ports according to the article. That means
all nodes get the same packet. The situation
is same in multicast and all nodes receive all
packets. So every node is processing the
packet?! Doesn't seem like this is what one
should be doing.
=>This architecture can have a few benefits, i.e. same IP identity for
all nodes,
"hot swap" so there is no interrupt, easier convergence if there is
failure.
Every node is processing the packet to some extent, but based on a good
port/filtering
rules, early drop can be deployed, similiar in handling a DoS attack :)
The last case, is forwarding. Here only one
node gets the packet. This is real load balancing.
However, a layer 2 solution is something that
I find hard to digest.
=> Why not if it has advantage, do you have any technical info regarding
the layer 3 approach? I am quite interested as well
Another question, when you have to debug/maintain
a node, won't you have to disconnect it from the cluster
as all nodes are sharing the same IP address?
=>This is not true, i guess the cluster should be able to allow you
disconnect any one of
the node and still have the sessions be offloaded to available others
----- Original Message -----
From: "Marc Solsona-Palomar" <marc@iprg.nokia.com>
To: "Dan Harkins" <dharkins@lounge.org>
Cc: "Jay Ratford" <Jratford@netscreen.com>; "'jshukla'"
<jshukla@earthlink.net>; "'William Dixon'"
<wdixon@windows.microsoft.com>;
<ipsec@lists.tislabs.com>; "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
Sent: Friday, August 24, 2001 1:23 PM
Subject: Re: Ipsec load balancing devices - UDP-ESP impact
>
> You can have a look at Nokia VPN products, you'll see clustering,
fail
over and
> such. I know we shouldn't be using IETF groups for advertising, but
I'm
answering
> a question guys!
>
> http://www.nokia.com/vpn/nokiavpn.html
>
> marc.
>
> Dan Harkins wrote:
>
> > Actually you're not. There's another vendor out there that does
> > dynamic load balancing and active session failover of IPsec and IKE
SAs--
> > fully meshed if so configured-- as well as PPTP and L2TP tunnels
and
BGP,
> > OSPF, and RIP. (It was a great day when I failed the box who was
currently
> > assigned the workload of sucking down a full Internet routing table
via
> > BGP and watched the entire session-- including all the routing
state and
> > the TCP state-- failover to another node without a hitch). It's
subsecond
> > failover too and beat the crap out of the competition in a trade
rag's
> > head-to-head comparison. And it's not just between "2 active
devices",
> > the size of the cluster can be 2, 3, 4 or more and adding nodes
gives
you
> > a non-linear increase in performance (that eventually tapers off).
> >
> > This vendor has had this capability for around three years. I
won't
> > mention who it is because for some strange reason they don't
advertise
> > this expertise.
> >
> > Dan.
> >
> > On Fri, 24 Aug 2001 09:54:51 PDT you wrote
> > > It doesn't support fail-over, unless your using something like
our
device
> > > which maintains "state" between two active vpn gateways. As far
as I
know
> > > where the only vendors doing this: Fully Meshed, Active Active
with
> > > session&sa mirroring between 2 active devices for statefull
failover.
> > >
> > > -----Original Message-----
> > > From: jshukla [mailto:jshukla@earthlink.net]
> > > Sent: Friday, August 24, 2001 9:21 AM
> > > To: Jay Ratford; 'William Dixon'; ipsec@lists.tislabs.com; Ari
Huttunen
> > > Subject: Re: Ipsec load balancing devices - UDP-ESP impact
> > >
> > >
> > > how does the load balancing work when one of
> > > the VPN gateways dies?
> > >
> > > regards,
> > > Jayant
> > >
> > > ----- Original Message -----
> > > From: "Jay Ratford" <Jratford@netscreen.com>
> > > To: "'William Dixon'" <wdixon@windows.microsoft.com>; "jshukla"
> > > <jshukla@earthlink.net>; <ipsec@lists.tislabs.com>; "Ari
Huttunen"
> > > <Ari.Huttunen@F-Secure.com>
> > > Sent: Friday, August 24, 2001 8:32 AM
> > > Subject: RE: Ipsec load balancing devices - UDP-ESP impact
> > >
> > >
> > > > Alteon (now Nortel) devices perform NAT and NAPT, but not in
default
> > > > configurations. They also have a "VPN Load-Balancing" solution
to
load
> > > > balance your VPN Gateway's - It does keep some kind of state,
specifically
> > > > how i'm not sure.
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: William Dixon [mailto:wdixon@windows.microsoft.com]
> > > > Sent: Thursday, August 23, 2001 8:11 PM
> > > > To: jshukla; ipsec@lists.tislabs.com; Ari Huttunen
> > > > Subject: Ipsec load balancing devices - UDP-ESP impact
> > > >
> > > >
> > > > Jayant, I've checked around on the popular load balancing
product
web
> > > > sites. But the details are often not avail, or buried in
technical
docs
> > > > that require a customer account to access.
> > > >
> > > > Does anyone know of any products that do NAT or "VLAN"
translation
and
> > > > specifically provide mapping support for IPSec "sessions", that
is,
> > > > devices that aren't already IPSec gateways and terminating
IPSec
before
> > > > they do NAT ?
> > > >
> > > > I'd like to know if they do something more than maintain source
IP-based
> > > > mappings, like cookie-pair-SPI tracking or something.
> > > >
> > > > In any case, combining IKE & ESP in the same UDP port 500
encapsulation
> > > > makes the take easier by having to track only one UDP src/dst
pair -
vs.
> > > > IPSec ESP inbound and outbound SPIs, in addition to the IKE
traffic,
or
> > > > in addition to another critically related UDP src/dst port pair
carrying
> > > > ESP.
> > > >
> > > > Wm
> > > > William Dixon
> > > > Program Manager - Network Security, IPSec
> > > > Windows Networking
> > > >
> > > > -----Original Message-----
> > > > From: jshukla [mailto:jshukla@earthlink.net]
> > > > Sent: Saturday, August 18, 2001 5:10 PM
> > > > To: ipsec@lists.tislabs.com; Ari Huttunen
> > > > Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap,
32bits
> > > > of , i-cookie=0
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
> > > > >
> > > > > At the Helsinki bakeoff there were seven implementations of
the
latest
> > > > drafts,
> > > > > including us. Additional three had implementations of some
earlier
> > > > > draft. This would be a good time for someone to provide
really
solid
> > > > > arguments against using just one port, if such arguments
exist.
Like,
> > > > > statistical calculations of actual overhead. The
firewall-argument
> > > > > doesn't cut it, it
> > > >
> > > > Have you guys considered how network based load-balancing
> > > > will work in your approach? This is a general question
regarding
your
> > > > approach, not using IKE port for ESP will not exactly help.
> > > >
> > > > regards,
> > > > Jayant
>
From owner-ipsec@lists.tislabs.com Mon Aug 27 10:36:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RHa4D22892;
Mon, 27 Aug 2001 10:36:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08496
Mon, 27 Aug 2001 12:40:07 -0400 (EDT)
Message-Id: <200108271607.f7RG71A28252@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: modp drafts
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 27 Aug 2001 12:07:01 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
draft-ietf-ipsec-ike-modp-groups-01.txt expired last May.
Is there something that kept is from progressing?
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
From owner-ipsec@lists.tislabs.com Mon Aug 27 10:49:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RHnVD23131;
Mon, 27 Aug 2001 10:49:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08539
Mon, 27 Aug 2001 12:59:15 -0400 (EDT)
Message-ID: <3B8A7D14.DD3BFDFD@cips.nokia.com>
Date: Mon, 27 Aug 2001 10:02:12 -0700
From: mckenna <mckenna@cips.nokia.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: jshukla <jshukla@earthlink.net>
CC: Marc Solsona-Palomar <marc@iprg.nokia.com>,
Dan Harkins <dharkins@lounge.org>, Jay Ratford <Jratford@netscreen.com>,
"'William Dixon'" <wdixon@windows.microsoft.com>, ipsec@lists.tislabs.com,
Ari Huttunen <Ari.Huttunen@F-Secure.com>
Subject: Re: Ipsec load balancing devices - UDP-ESP impact
References: <200108241959.f7OJwtF00872@dharkins@lounge.orgatty.lounge.org> <3B86B7CF.847A8ADF@iprg.nokia.com> <000601c12d86$06119e10$3cb12304@ffb5b>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
My apologies if this has already been answered. Comments in line below.
---Dave
jshukla wrote:
>
> Your solution is based on sharing SAs and
> session keys between node, right?! I thought
> that was a big no no.
Yes all nodes in a cluster will share the keys. Why is this a no no?
The cluster, regardless of the number of nodes, acts as one tunnel
endpoint to the outside world. To maintain the traffic and not force a
costly rekey requires that the session keys be shared. Of course,
precautions must be made to share them amongst themselves securely.
>
> Secondly, what I gather from the one paragraph
> blurb that I found on IP-clustering on your web
> site is that it is a layer-2 solution. You use
> Ethernet multicast, unicast, and forwarding.
> In unicast same Ethernet address is used by
> all ports according to the article. That means
> all nodes get the same packet. The situation
> is same in multicast and all nodes receive all
> packets. So every node is processing the
> packet?! Doesn't seem like this is what one
> should be doing.
Probably those web pages are inadequate. Every node sees every packet
in unicast or multicast mode. The one node that needs to process the
particular packet sends it up the stack. The other nodes silently drop
it. There is a dynamic algorithm to distribute this changing load
amongst cluster members. The ability to drop a packet is done fairly
quickly compared to encryption/decryption and doesn't create much load
on a member. Thus, these modes are in most circumstances faster than
forwarding mode and transparent to other IP devices.
I would consider our failover and load balancing a layer 3 solution.
All nodes share a layer 3 address and IPSec peers deal with that
address. The different modes deal with internal cluster business and is
not a concern of any external device, except the connecting switch.
>
> The last case, is forwarding. Here only one
> node gets the packet. This is real load balancing.
> However, a layer 2 solution is something that
> I find hard to digest.
>
> Another question, when you have to debug/maintain
> a node, won't you have to disconnect it from the cluster
> as all nodes are sharing the same IP address?
Each node has a unique individual set of IPs (for each interface) and a
common set common cluster IPs (an external an internal IP). One can do
most debugging without disconnecting the node from the cluster.
>
> In case I have misunderstood your solution,
> please accept my apologies.
>
> regards,
> Jayant
>
> p.s.: we have an all IP layer based load balancing
> solution for IPsec coming up.
>
> ----- Original Message -----
> From: "Marc Solsona-Palomar" <marc@iprg.nokia.com>
> To: "Dan Harkins" <dharkins@lounge.org>
> Cc: "Jay Ratford" <Jratford@netscreen.com>; "'jshukla'"
> <jshukla@earthlink.net>; "'William Dixon'" <wdixon@windows.microsoft.com>;
> <ipsec@lists.tislabs.com>; "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
> Sent: Friday, August 24, 2001 1:23 PM
> Subject: Re: Ipsec load balancing devices - UDP-ESP impact
>
> >
> > You can have a look at Nokia VPN products, you'll see clustering, fail
> over and
> > such. I know we shouldn't be using IETF groups for advertising, but I'm
> answering
> > a question guys!
> >
> > http://www.nokia.com/vpn/nokiavpn.html
> >
> > marc.
> >
> > Dan Harkins wrote:
> >
> > > Actually you're not. There's another vendor out there that does
> > > dynamic load balancing and active session failover of IPsec and IKE
> SAs--
> > > fully meshed if so configured-- as well as PPTP and L2TP tunnels and
> BGP,
> > > OSPF, and RIP. (It was a great day when I failed the box who was
> currently
> > > assigned the workload of sucking down a full Internet routing table via
> > > BGP and watched the entire session-- including all the routing state and
> > > the TCP state-- failover to another node without a hitch). It's
> subsecond
> > > failover too and beat the crap out of the competition in a trade rag's
> > > head-to-head comparison. And it's not just between "2 active devices",
> > > the size of the cluster can be 2, 3, 4 or more and adding nodes gives
> you
> > > a non-linear increase in performance (that eventually tapers off).
> > >
> > > This vendor has had this capability for around three years. I won't
> > > mention who it is because for some strange reason they don't advertise
> > > this expertise.
> > >
> > > Dan.
> > >
> > > On Fri, 24 Aug 2001 09:54:51 PDT you wrote
> > > > It doesn't support fail-over, unless your using something like our
> device
> > > > which maintains "state" between two active vpn gateways. As far as I
> know
> > > > where the only vendors doing this: Fully Meshed, Active Active with
> > > > session&sa mirroring between 2 active devices for statefull failover.
> > > >
> > > > -----Original Message-----
> > > > From: jshukla [mailto:jshukla@earthlink.net]
> > > > Sent: Friday, August 24, 2001 9:21 AM
> > > > To: Jay Ratford; 'William Dixon'; ipsec@lists.tislabs.com; Ari
> Huttunen
> > > > Subject: Re: Ipsec load balancing devices - UDP-ESP impact
> > > >
> > > >
> > > > how does the load balancing work when one of
> > > > the VPN gateways dies?
> > > >
> > > > regards,
> > > > Jayant
> > > >
> > > > ----- Original Message -----
> > > > From: "Jay Ratford" <Jratford@netscreen.com>
> > > > To: "'William Dixon'" <wdixon@windows.microsoft.com>; "jshukla"
> > > > <jshukla@earthlink.net>; <ipsec@lists.tislabs.com>; "Ari Huttunen"
> > > > <Ari.Huttunen@F-Secure.com>
> > > > Sent: Friday, August 24, 2001 8:32 AM
> > > > Subject: RE: Ipsec load balancing devices - UDP-ESP impact
> > > >
> > > >
> > > > > Alteon (now Nortel) devices perform NAT and NAPT, but not in default
> > > > > configurations. They also have a "VPN Load-Balancing" solution to
> load
> > > > > balance your VPN Gateway's - It does keep some kind of state,
> specifically
> > > > > how i'm not sure.
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: William Dixon [mailto:wdixon@windows.microsoft.com]
> > > > > Sent: Thursday, August 23, 2001 8:11 PM
> > > > > To: jshukla; ipsec@lists.tislabs.com; Ari Huttunen
> > > > > Subject: Ipsec load balancing devices - UDP-ESP impact
> > > > >
> > > > >
> > > > > Jayant, I've checked around on the popular load balancing product
> web
> > > > > sites. But the details are often not avail, or buried in technical
> docs
> > > > > that require a customer account to access.
> > > > >
> > > > > Does anyone know of any products that do NAT or "VLAN" translation
> and
> > > > > specifically provide mapping support for IPSec "sessions", that is,
> > > > > devices that aren't already IPSec gateways and terminating IPSec
> before
> > > > > they do NAT ?
> > > > >
> > > > > I'd like to know if they do something more than maintain source
> IP-based
> > > > > mappings, like cookie-pair-SPI tracking or something.
> > > > >
> > > > > In any case, combining IKE & ESP in the same UDP port 500
> encapsulation
> > > > > makes the take easier by having to track only one UDP src/dst pair -
> vs.
> > > > > IPSec ESP inbound and outbound SPIs, in addition to the IKE traffic,
> or
> > > > > in addition to another critically related UDP src/dst port pair
> carrying
> > > > > ESP.
> > > > >
> > > > > Wm
> > > > > William Dixon
> > > > > Program Manager - Network Security, IPSec
> > > > > Windows Networking
> > > > >
> > > > > -----Original Message-----
> > > > > From: jshukla [mailto:jshukla@earthlink.net]
> > > > > Sent: Saturday, August 18, 2001 5:10 PM
> > > > > To: ipsec@lists.tislabs.com; Ari Huttunen
> > > > > Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap,
> 32bits
> > > > > of , i-cookie=0
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
> > > > > >
> > > > > > At the Helsinki bakeoff there were seven implementations of the
> latest
> > > > > drafts,
> > > > > > including us. Additional three had implementations of some earlier
> > > > > > draft. This would be a good time for someone to provide really
> solid
> > > > > > arguments against using just one port, if such arguments exist.
> Like,
> > > > > > statistical calculations of actual overhead. The firewall-argument
> > > > > > doesn't cut it, it
> > > > >
> > > > > Have you guys considered how network based load-balancing
> > > > > will work in your approach? This is a general question regarding
> your
> > > > > approach, not using IKE port for ESP will not exactly help.
> > > > >
> > > > > regards,
> > > > > Jayant
> >
From owner-ipsec@lists.tislabs.com Mon Aug 27 16:00:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RN07D29437;
Mon, 27 Aug 2001 16:00:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09144
Mon, 27 Aug 2001 18:06:45 -0400 (EDT)
Message-ID: <3B8AC637.EC27CCF0@austin.ibm.com>
Date: Mon, 27 Aug 2001 17:14:15 -0500
From: JianHua Feng <jhfeng@austin.ibm.com>
Reply-To: jhfeng@austin.ibm.com
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
CC: jari.arkko@ericsson.com
Subject: Re: Notify SPI field specifications
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Since I cannot find the clear answer to Jari's question from ipsec mail
list archives, and we got the same problem with several other vendors in
Finland bakeoff, I'd like ask the same question again:
Which SPI, notification sender's inbound SPI or outbound SPI, should be
put in
RESPONDER-LIFETIME notify's SPI field ?
Thanks
Jianhua
On Thu, Jan 27, 2000 at 03:42:02PM +0200, jari.arkko@ericsson.com wrote:
>
> Hi. In the San Diego bakeoff I was studying the RFCs with somebody
> and we noticed some strange descriptions for the Notify SPI field.
> Here's what RFC 2408 says in section "3.14 Notification Payload":
>
> > o SPI (variable length) - Security Parameter Index. The receiving
> > entity's SPI. The use of the SPI field is described in section
>
> And RFC 2407 says in section "4.6.3.1 RESPONDER-LIFETIME":
>
> > o SPI - set to the two ISAKMP cookies or to the sender's inbound
> > IPSEC SP
>
> I find the latter description quite clear. But the one in RFC 2408
> is quite unclear and possibly even contradictory to it. In the RFC 2408
> description, what is "receiving entity"? Is it the one receiving the
> notification? If so, then which SPI does it have? The incoming? If so,
> the RFC 2408 proposes the use of Notification-Receivers-Inbound-SPI
> i.e. Notification-Senders-Outbound-SPI which is not the same as
> Notification-Senders-Inbound-SPI in RFC 2407...
>
> Even if I'm to ignore the SPI value for phase 1, the specifications
> also disagree, I think, upon the value that should be put to the SPI
> field for phase 1. Again from the same sections in these two RFCs:
>
> RFC 2408:
> > The Protocol Identifier, in this case, is
> > ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP
> > Header identifies the ISAKMP SA.
>
> RFC 2407:
> > o SPI - set to the two ISAKMP cookies or to the sender's inbound
> > IPSEC SPI
>
> That is, RFC 2408 proposes zero and RFC 2407 the cookies.
>
> Also, I found it quite funny for RFC 2407 to say in the description of
> the SPI Size field that "If the SPI Size is non-zero, the content of
> the SPI field MUST be ignored.". If the SPI Size is zero, I am expected
> to check the SPI field! If I understood this right, the specification
> should have said perhaps "The SPI Size and SPI fields MUST be ignored
> for phase 1."
>
> Jari Arkko
> Ericsson
>
>
From owner-ipsec@lists.tislabs.com Mon Aug 27 18:25:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7S1PbD03030;
Mon, 27 Aug 2001 18:25:37 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09430
Mon, 27 Aug 2001 20:45:18 -0400 (EDT)
Message-Id: <200108280051.f7S0pBV01461@dharkins@lounge.orgatty.lounge.org>
To: jhfeng@austin.ibm.com
Cc: ipsec@lists.tislabs.com, jari.arkko@ericsson.com
Subject: Re: Notify SPI field specifications
In-Reply-To: Your message of "Mon, 27 Aug 2001 17:14:15 CDT."
<3B8AC637.EC27CCF0@austin.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1458.998959871.1@lounge.org>
Date: Mon, 27 Aug 2001 17:51:11 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
If you're sending it then it is the one from your "SPI space", the one
you came up with, your inbound SPI. These sorts of RFC2407/8/9 discrepancies
are just the sort of thing that will be cleaned up by combining all the
documents into one. If you're receiving it then it is the one from your
peer's "SPI space", the one he came up with, your outbound SPI.
The thing about "the content of the SPI field MUST be ignored" is from
RFC2408 not RFC2407 and that was the mandated covert channel that we
all wanted to change but couldn't because the documents were in last call
for a year and then we were prohibited from changing them because they
were so confusing.
Dan.
"I personally think it is very dangerous to organize
referendums when you're not sure to win them"
-- Louis Michel, President of the European Union
On Mon, 27 Aug 2001 17:14:15 CDT you wrote
> Since I cannot find the clear answer to Jari's question from ipsec mail
> list archives, and we got the same problem with several other vendors in
> Finland bakeoff, I'd like ask the same question again:
>
> Which SPI, notification sender's inbound SPI or outbound SPI, should be
> put in
> RESPONDER-LIFETIME notify's SPI field ?
>
> Thanks
> Jianhua
>
> On Thu, Jan 27, 2000 at 03:42:02PM +0200, jari.arkko@ericsson.com wrote:
> >
> > Hi. In the San Diego bakeoff I was studying the RFCs with somebody
> > and we noticed some strange descriptions for the Notify SPI field.
> > Here's what RFC 2408 says in section "3.14 Notification Payload":
> >
> > > o SPI (variable length) - Security Parameter Index. The receiving
> > > entity's SPI. The use of the SPI field is described in section
> >
> > And RFC 2407 says in section "4.6.3.1 RESPONDER-LIFETIME":
> >
> > > o SPI - set to the two ISAKMP cookies or to the sender's inbound
> > > IPSEC SP
> >
> > I find the latter description quite clear. But the one in RFC 2408
> > is quite unclear and possibly even contradictory to it. In the RFC 2408
> > description, what is "receiving entity"? Is it the one receiving the
> > notification? If so, then which SPI does it have? The incoming? If so,
> > the RFC 2408 proposes the use of Notification-Receivers-Inbound-SPI
> > i.e. Notification-Senders-Outbound-SPI which is not the same as
> > Notification-Senders-Inbound-SPI in RFC 2407...
> >
> > Even if I'm to ignore the SPI value for phase 1, the specifications
> > also disagree, I think, upon the value that should be put to the SPI
> > field for phase 1. Again from the same sections in these two RFCs:
> >
> > RFC 2408:
> > > The Protocol Identifier, in this case, is
> > > ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP
> > > Header identifies the ISAKMP SA.
> >
> > RFC 2407:
> > > o SPI - set to the two ISAKMP cookies or to the sender's inbound
> > > IPSEC SPI
> >
> > That is, RFC 2408 proposes zero and RFC 2407 the cookies.
> >
> > Also, I found it quite funny for RFC 2407 to say in the description of
> > the SPI Size field that "If the SPI Size is non-zero, the content of
> > the SPI field MUST be ignored.". If the SPI Size is zero, I am expected
> > to check the SPI field! If I understood this right, the specification
> > should have said perhaps "The SPI Size and SPI fields MUST be ignored
> > for phase 1."
> >
> > Jari Arkko
> > Ericsson
> >
> >
From owner-ipsec@lists.tislabs.com Mon Aug 27 19:18:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7S2IAD08770;
Mon, 27 Aug 2001 19:18:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA09587
Mon, 27 Aug 2001 21:37:31 -0400 (EDT)
Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F36BB@NS-CA>
From: Michael Choung Shieh <mshieh@netscreen.com>
To: "'Dan Harkins'" <dharkins@lounge.org>, jhfeng@austin.ibm.com
Cc: ipsec@lists.tislabs.com, jari.arkko@ericsson.com
Subject: RE: Notify SPI field specifications
Date: Mon, 27 Aug 2001 18:43:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Is it the consensus? In RFC2408 it says "The receiving entity's SPI" which
implies the receiver's inbound SPI. From my experience in bake-off, many
vendors have implemented notify payload based on "receiver's inbound SPI".
--------------------------------------------
Michael Shieh
--------------------------------------------
-----Original Message-----
From: Dan Harkins [mailto:dharkins@lounge.org]
Sent: Monday, August 27, 2001 5:51 PM
To: jhfeng@austin.ibm.com
Cc: ipsec@lists.tislabs.com; jari.arkko@ericsson.com
Subject: Re: Notify SPI field specifications
If you're sending it then it is the one from your "SPI space", the one
you came up with, your inbound SPI. These sorts of RFC2407/8/9 discrepancies
are just the sort of thing that will be cleaned up by combining all the
documents into one. If you're receiving it then it is the one from your
peer's "SPI space", the one he came up with, your outbound SPI.
The thing about "the content of the SPI field MUST be ignored" is from
RFC2408 not RFC2407 and that was the mandated covert channel that we
all wanted to change but couldn't because the documents were in last call
for a year and then we were prohibited from changing them because they
were so confusing.
Dan.
"I personally think it is very dangerous to organize
referendums when you're not sure to win them"
-- Louis Michel, President of the European Union
On Mon, 27 Aug 2001 17:14:15 CDT you wrote
> Since I cannot find the clear answer to Jari's question from ipsec mail
> list archives, and we got the same problem with several other vendors in
> Finland bakeoff, I'd like ask the same question again:
>
> Which SPI, notification sender's inbound SPI or outbound SPI, should be
> put in
> RESPONDER-LIFETIME notify's SPI field ?
>
> Thanks
> Jianhua
>
> On Thu, Jan 27, 2000 at 03:42:02PM +0200, jari.arkko@ericsson.com wrote:
> >
> > Hi. In the San Diego bakeoff I was studying the RFCs with somebody
> > and we noticed some strange descriptions for the Notify SPI field.
> > Here's what RFC 2408 says in section "3.14 Notification Payload":
> >
> > > o SPI (variable length) - Security Parameter Index. The receiving
> > > entity's SPI. The use of the SPI field is described in section
> >
> > And RFC 2407 says in section "4.6.3.1 RESPONDER-LIFETIME":
> >
> > > o SPI - set to the two ISAKMP cookies or to the sender's inbound
> > > IPSEC SP
> >
> > I find the latter description quite clear. But the one in RFC 2408
> > is quite unclear and possibly even contradictory to it. In the RFC 2408
> > description, what is "receiving entity"? Is it the one receiving the
> > notification? If so, then which SPI does it have? The incoming? If so,
> > the RFC 2408 proposes the use of Notification-Receivers-Inbound-SPI
> > i.e. Notification-Senders-Outbound-SPI which is not the same as
> > Notification-Senders-Inbound-SPI in RFC 2407...
> >
> > Even if I'm to ignore the SPI value for phase 1, the specifications
> > also disagree, I think, upon the value that should be put to the SPI
> > field for phase 1. Again from the same sections in these two RFCs:
> >
> > RFC 2408:
> > > The Protocol Identifier, in this case, is
> > > ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP
> > > Header identifies the ISAKMP SA.
> >
> > RFC 2407:
> > > o SPI - set to the two ISAKMP cookies or to the sender's inbound
> > > IPSEC SPI
> >
> > That is, RFC 2408 proposes zero and RFC 2407 the cookies.
> >
> > Also, I found it quite funny for RFC 2407 to say in the description of
> > the SPI Size field that "If the SPI Size is non-zero, the content of
> > the SPI field MUST be ignored.". If the SPI Size is zero, I am expected
> > to check the SPI field! If I understood this right, the specification
> > should have said perhaps "The SPI Size and SPI fields MUST be ignored
> > for phase 1."
> >
> > Jari Arkko
> > Ericsson
> >
> >
From owner-ipsec@lists.tislabs.com Tue Aug 28 00:57:24 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7S7vND21552;
Tue, 28 Aug 2001 00:57:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12574
Tue, 28 Aug 2001 02:47:29 -0400 (EDT)
Message-Id: <200108280653.f7S6rNU00549@dharkins@lounge.orgatty.lounge.org>
To: Michael Choung Shieh <mshieh@netscreen.com>
Cc: jhfeng@austin.ibm.com, ipsec@lists.tislabs.com, jari.arkko@ericsson.com
Subject: Re: Notify SPI field specifications
In-Reply-To: Your message of "Mon, 27 Aug 2001 18:43:44 PDT."
<9D048F4A422CD411A56500B0D0209C5B028F36BB@NS-CA>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <546.998981603.1@lounge.org>
Date: Mon, 27 Aug 2001 23:53:23 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
RFC2408 is the generic language/transport. It does not define how to
use things that are specific to a particular service like IPsec and, in
fact, says, "The DOI will also determine which SPIs (i.e. initiator's
or responder's) are sent during communication." If the DOI field of the
notify message is 1 then RFC2407 dictates how to construct the message.
Let me state again that it is just these sorts of things that will be
solved by having a single document to describe key management. The generic
language/transport (RFC2408) with a generic key exchange (RFC2409) on top
with a specific service (RFC2407) on top of that does not work. Things
that are required for the service have to be defined in the language or
key exchange. The commit bit is another example. The entire layering is
artificial and the source of this sort of confusion. That is being rectified.
Dan.
"I personally think it is very dangerous to organize
referendums when you're not sure to win them"
-- Louis Michel, President of the European Union
On Mon, 27 Aug 2001 18:43:44 PDT you wrote
>
> Is it the consensus? In RFC2408 it says "The receiving entity's SPI" which
> implies the receiver's inbound SPI. From my experience in bake-off, many
> vendors have implemented notify payload based on "receiver's inbound SPI".
>
> --------------------------------------------
> Michael Shieh
> --------------------------------------------
>
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Monday, August 27, 2001 5:51 PM
> To: jhfeng@austin.ibm.com
> Cc: ipsec@lists.tislabs.com; jari.arkko@ericsson.com
> Subject: Re: Notify SPI field specifications
>
>
> If you're sending it then it is the one from your "SPI space", the one
> you came up with, your inbound SPI. These sorts of RFC2407/8/9 discrepancies
> are just the sort of thing that will be cleaned up by combining all the
> documents into one. If you're receiving it then it is the one from your
> peer's "SPI space", the one he came up with, your outbound SPI.
>
> The thing about "the content of the SPI field MUST be ignored" is from
> RFC2408 not RFC2407 and that was the mandated covert channel that we
> all wanted to change but couldn't because the documents were in last call
> for a year and then we were prohibited from changing them because they
> were so confusing.
>
> Dan.
>
> "I personally think it is very dangerous to organize
> referendums when you're not sure to win them"
> -- Louis Michel, President of the European Union
>
> On Mon, 27 Aug 2001 17:14:15 CDT you wrote
> > Since I cannot find the clear answer to Jari's question from ipsec mail
> > list archives, and we got the same problem with several other vendors in
> > Finland bakeoff, I'd like ask the same question again:
> >
> > Which SPI, notification sender's inbound SPI or outbound SPI, should be
> > put in
> > RESPONDER-LIFETIME notify's SPI field ?
> >
> > Thanks
> > Jianhua
> >
> > On Thu, Jan 27, 2000 at 03:42:02PM +0200, jari.arkko@ericsson.com wrote:
> > >
> > > Hi. In the San Diego bakeoff I was studying the RFCs with somebody
> > > and we noticed some strange descriptions for the Notify SPI field.
> > > Here's what RFC 2408 says in section "3.14 Notification Payload":
> > >
> > > > o SPI (variable length) - Security Parameter Index. The receiving
> > > > entity's SPI. The use of the SPI field is described in section
> > >
> > > And RFC 2407 says in section "4.6.3.1 RESPONDER-LIFETIME":
> > >
> > > > o SPI - set to the two ISAKMP cookies or to the sender's inbound
> > > > IPSEC SP
> > >
> > > I find the latter description quite clear. But the one in RFC 2408
> > > is quite unclear and possibly even contradictory to it. In the RFC 2408
> > > description, what is "receiving entity"? Is it the one receiving the
> > > notification? If so, then which SPI does it have? The incoming? If so,
> > > the RFC 2408 proposes the use of Notification-Receivers-Inbound-SPI
> > > i.e. Notification-Senders-Outbound-SPI which is not the same as
> > > Notification-Senders-Inbound-SPI in RFC 2407...
> > >
> > > Even if I'm to ignore the SPI value for phase 1, the specifications
> > > also disagree, I think, upon the value that should be put to the SPI
> > > field for phase 1. Again from the same sections in these two RFCs:
> > >
> > > RFC 2408:
> > > > The Protocol Identifier, in this case, is
> > > > ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP
> > > > Header identifies the ISAKMP SA.
> > >
> > > RFC 2407:
> > > > o SPI - set to the two ISAKMP cookies or to the sender's inbound
> > > > IPSEC SPI
> > >
> > > That is, RFC 2408 proposes zero and RFC 2407 the cookies.
> > >
> > > Also, I found it quite funny for RFC 2407 to say in the description of
> > > the SPI Size field that "If the SPI Size is non-zero, the content of
> > > the SPI field MUST be ignored.". If the SPI Size is zero, I am expected
> > > to check the SPI field! If I understood this right, the specification
> > > should have said perhaps "The SPI Size and SPI fields MUST be ignored
> > > for phase 1."
> > >
> > > Jari Arkko
> > > Ericsson
> > >
> > >
From owner-ipsec@lists.tislabs.com Tue Aug 28 04:28:41 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SBSfD14004;
Tue, 28 Aug 2001 04:28:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12943
Tue, 28 Aug 2001 06:37:18 -0400 (EDT)
Message-ID: <3B8B760E.A2D1FDB1@ks.ericsson.se>
Date: Tue, 28 Aug 2001 12:44:30 +0200
From: Anders Ellstrom <einanel@ks.ericsson.se>
Reply-To: anders.ellstrom@ks.ericsson.se
Organization: Ericsson
X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Litterature for SIP and security
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 GAA12940
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello.
Im looking for a good book on session intiation protocol
in combination of security aspects.
Is there anyone who knows a good title. ?
Best regards
Anders Ellström
From owner-ipsec@lists.tislabs.com Tue Aug 28 05:41:56 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SCftD18482;
Tue, 28 Aug 2001 05:41:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA13090
Tue, 28 Aug 2001 07:44:57 -0400 (EDT)
Message-ID: <E546760DDA87D411882700508BAF16CE306F6A@ukwtpmsx3>
From: ANTIGEN_UKWTPMSX3 <ANTIGEN_UKWTPMSX3@crowncastle.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>,
"'design@lists.freeswan.org'" <design@lists.freeswan.org>
Subject: Antigen forwarded attachment
Date: Tue, 28 Aug 2001 08:46:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed ; boundary="----_=_NextPart_000_01C12F95.9C763670"
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_000_01C12F95.9C763670
Content-Type: text/plain
Enclosed is your original file attachment from the message "I-D
ACTION:draft-richardson-ipsec-opportunistic-01.txt"
sent to you by Internet-Drafts@ietf.org (Internet-Drafts@ietf.org).
************************
NOTICE TO USERS
The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed and may also be privileged.
If you are not the addressee of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever, or take any action in reliance on its contents.
If you have received this e-mail in error please e-mail the author by replying to this message and delete the material from your computer.
While reasonable precautions have been taken to ensure no viruses are present in this e-mail, you are responsible for carrying out your own virus checks and Crown Castle International does not accept responsibility for any loss or damage thereby arising.
The views of the author may not necessarily reflect those of Crown Castle International. At present the integrity of e-mail across the Internet cannot be guaranteed and messages sent via this medium are potentially at risk.
All liability is excluded to the extent permitted by law for any claims arising as a result of the use of this medium to transmit information by or to Crown Castle International.
Visit Crown Castle International web site on: http://www.crowncastle.com
------_=_NextPart_000_01C12F95.9C763670
Content-Type: message/external-body;
site="internet-drafts";
dir="draft-richardson-ipsec-opportunistic-01.txt";
mode="ftp.ietf.org";
access-type="anon-ftp"
------_=_NextPart_000_01C12F95.9C763670--
From owner-ipsec@lists.tislabs.com Tue Aug 28 07:41:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SEfqD23998;
Tue, 28 Aug 2001 07:41:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13438
Tue, 28 Aug 2001 09:53:21 -0400 (EDT)
Subject: More MODP Diffie-Hellman groups for IKE
To: ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF92C62CC9.0A31E81B-ON86256AB6.004874BA@rchland.ibm.com>
From: "Jason Palmatier" <palmatie@us.ibm.com>
Date: Tue, 28 Aug 2001 09:58:31 -0400
X-MIMETrack: Serialize by Router on d27ml103/27/M/IBM(Release 5.0.8 |June 18, 2001) at
08/28/2001 08:58:36 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Have numbers been assigned to the additional MODP groups described in
draft-ietf-ipsec-ike-modp-groups-01.txt ? The bakeoff notes seemed to
indicate some testing was carried out using new larger groups and timeouts
occured from the extra computation. Were these the MODP groups described
in the above draft? If so, what numbers were used to negotiate them or
were they negotiated in a different manner? Any help would be appreciated.
Jason Palmatier
IBM iSeries eServer
Endicott, NY
email: palmatie@us.ibm.com
From owner-ipsec@lists.tislabs.com Tue Aug 28 08:46:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SFkZD29374;
Tue, 28 Aug 2001 08:46:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13674
Tue, 28 Aug 2001 10:57:28 -0400 (EDT)
Message-ID: <3B8BB318.F210FC74@F-Secure.com>
Date: Tue, 28 Aug 2001 18:04:56 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jason Palmatier <palmatie@us.ibm.com>
CC: ipsec@lists.tislabs.com
Subject: IKEv2 stuff.. Re: More MODP Diffie-Hellman groups for IKE
References: <OF92C62CC9.0A31E81B-ON86256AB6.004874BA@rchland.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
40000 + number of bits in the group.
It would be nice to have officially assigned numbers, though.
Especially since you cannot negotiate this by having a VID, since
they are used in the first message.
The same restriction applies to the.. dare I say it?.. here goes..
X-Auth authentication type. There's no way to negotiate it's usage
by using a VID. Our new software version sends this automatically,
and a couple of vendors whose software refused any connection when
they received an attribute they didn't understand, agreed to change
their software that it skips a transform it doesn't fully understand
and tries to match the next transform.
The current RFCs do not state what to do when something like this
happens.. i.e. an unknown attribute is received in a transform payload.
Ari
Jason Palmatier wrote:
>
> Have numbers been assigned to the additional MODP groups described in
> draft-ietf-ipsec-ike-modp-groups-01.txt ? The bakeoff notes seemed to
> indicate some testing was carried out using new larger groups and timeouts
> occured from the extra computation. Were these the MODP groups described
> in the above draft? If so, what numbers were used to negotiate them or
> were they negotiated in a different manner? Any help would be appreciated.
>
> Jason Palmatier
> IBM iSeries eServer
> Endicott, NY
> email: palmatie@us.ibm.com
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
From owner-ipsec@lists.tislabs.com Tue Aug 28 09:08:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SG83D01894;
Tue, 28 Aug 2001 09:08:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13745
Tue, 28 Aug 2001 11:27:42 -0400 (EDT)
Message-Id: <3.0.5.32.20010828163934.037de100@smtp.datafellows.com>
X-Sender: joern@smtp.datafellows.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 28 Aug 2001 16:39:34 +0200
To: "Jason Palmatier" <palmatie@us.ibm.com>
From: Joern Sierwald <joern.sierwald@F-Secure.com>
Subject: Re: More MODP Diffie-Hellman groups for IKE
Cc: ipsec@lists.tislabs.com
In-Reply-To: <OF92C62CC9.0A31E81B-ON86256AB6.004874BA@rchland.ibm.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 KAA13591
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 09:58 28.08.01 -0400, Jason Palmatier wrote:
>Have numbers been assigned to the additional MODP groups described in
>draft-ietf-ipsec-ike-modp-groups-01.txt ? The bakeoff notes seemed to
>indicate some testing was carried out using new larger groups and timeouts
>occured from the extra computation. Were these the MODP groups described
>in the above draft? If so, what numbers were used to negotiate them or
>were they negotiated in a different manner? Any help would be appreciated.
>
>Jason Palmatier
>IBM iSeries eServer
>Endicott, NY
>email: palmatie@us.ibm.com
>
>
We used numbers 40000+modulussize at the interops.
42048, 43072, 44096
These will be changed when the RFC is out.
Jörn
From owner-ipsec@lists.tislabs.com Tue Aug 28 09:28:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SGSGD02415;
Tue, 28 Aug 2001 09:28:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13812
Tue, 28 Aug 2001 11:47:46 -0400 (EDT)
Date: Tue, 28 Aug 2001 11:54:39 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: IP Security List <ipsec@lists.tislabs.com>
Subject: Re: More MODP Diffie-Hellman groups for IKE
In-Reply-To: <3.0.5.32.20010828163934.037de100@smtp.datafellows.com>
Message-ID: <Pine.BSI.3.91.1010828115302.19077A-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 28 Aug 2001, Joern Sierwald wrote:
> >Have numbers been assigned to the additional MODP groups...
>
> We used numbers 40000+modulussize at the interops.
> 42048, 43072, 44096
> These will be changed when the RFC is out.
Well, those numbers will remain usable -- they're in the private-use part
of the number space -- but of course, once there are standard numbers, the
standard ones are preferable.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue Aug 28 10:28:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SHSBD03862;
Tue, 28 Aug 2001 10:28:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13956
Tue, 28 Aug 2001 12:40:34 -0400 (EDT)
Reply-To: <ttang@clickarray.com>
From: "Tom Tang" <ttang@clickarray.com>
To: <anders.ellstrom@ks.ericsson.se>, <ipsec@lists.tislabs.com>
Subject: RE: Litterature for SIP and security
Date: Tue, 28 Aug 2001 09:47:33 -0700
Message-ID: <000a01c12fe1$2298c970$43e7020a@corp.clickarray.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <3B8B760E.A2D1FDB1@ks.ericsson.se>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Anders,
For note, there is a SIP security mailing list
managed by Brian Rosen at http://www.softarmor.com/sipwg/teams/sipsec/
All discussions are more at a framework level, not really in the
context of IPSec.
Cheers,
- Tom Tang
-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Anders Ellstrom
Sent: Tuesday, August 28, 2001 3:45 AM
To: ipsec@lists.tislabs.com
Subject: Litterature for SIP and security
Hello.
Im looking for a good book on session intiation protocol
in combination of security aspects.
Is there anyone who knows a good title. ?
Best regards
Anders Ellström
From owner-ipsec@lists.tislabs.com Tue Aug 28 11:21:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SIL6D04892;
Tue, 28 Aug 2001 11:21:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14171
Tue, 28 Aug 2001 13:34:13 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Ari Huttunen'" <Ari.Huttunen@F-Secure.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: IKEv2 stuff.. Re: More MODP Diffie-Hellman groups for IKE
Date: Tue, 28 Aug 2001 13:39:31 +0100
Message-Id: <002201c12fbe$9ef2ab80$1e72788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <3B8BB318.F210FC74@F-Secure.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I have also been making the assumption that if you send a VID in the first
message then it is acceptable to send private attributes in the SA
proposals.
I think implementations that fail automatically when they recieve an unknown
attribute are just broken. It's not just private attributes that they'll
choke on. What happens to their already deployed products when someone
proposes AES?
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ari Huttunen
> Sent: Tuesday, August 28, 2001 4:05 PM
> To: Jason Palmatier
> Cc: ipsec@lists.tislabs.com
> Subject: IKEv2 stuff.. Re: More MODP Diffie-Hellman groups for IKE
>
>
> 40000 + number of bits in the group.
>
> It would be nice to have officially assigned numbers, though.
> Especially since you cannot negotiate this by having a VID, since
> they are used in the first message.
>
> The same restriction applies to the.. dare I say it?.. here goes..
> X-Auth authentication type. There's no way to negotiate it's usage
> by using a VID. Our new software version sends this automatically,
> and a couple of vendors whose software refused any connection when
> they received an attribute they didn't understand, agreed to change
> their software that it skips a transform it doesn't fully understand
> and tries to match the next transform.
>
> The current RFCs do not state what to do when something like this
> happens.. i.e. an unknown attribute is received in a
> transform payload.
>
> Ari
>
> Jason Palmatier wrote:
> >
> > Have numbers been assigned to the additional MODP groups
> described in
> > draft-ietf-ipsec-ike-modp-groups-01.txt ? The bakeoff
> notes seemed to
> > indicate some testing was carried out using new larger
> groups and timeouts
> > occured from the extra computation. Were these the MODP
> groups described
> > in the above draft? If so, what numbers were used to
> negotiate them or
> > were they negotiated in a different manner? Any help would
> be appreciated.
> >
> > Jason Palmatier
> > IBM iSeries eServer
> > Endicott, NY
> > email: palmatie@us.ibm.com
>
> --
> Ari Huttunen phone: +358 9 2520 0700
> Software Architect fax : +358 9 2520 5001
>
> F-Secure Corporation http://www.F-Secure.com
>
> F(ully)-Secure products: Securing the Mobile Enterprise
>
From owner-ipsec@lists.tislabs.com Tue Aug 28 12:07:19 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SJ7ID05909;
Tue, 28 Aug 2001 12:07:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14252
Tue, 28 Aug 2001 14:18:04 -0400 (EDT)
X-Authentication-Warning: redshift.mimosa.com: hugh owned process doing -bs
Date: Tue, 28 Aug 2001 14:26:18 -0400 (EDT)
From: "D. Hugh Redelmeier" <hugh@mimosa.com>
Reply-To: <hugh@mimosa.com>
To: Bill Manning <bmanning@ISI.EDU>
cc: Henry Spencer <henry@spsystems.net>, Hugh Daniel <hugh@road.xisp.net>,
<ipsec@lists.tislabs.com>,
FreeS/WAN Design Issues <design@lists.freeswan.org>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment
problems
In-Reply-To: <200108080913.f789DNM20119@zed.isi.edu>
Message-ID: <Pine.LNX.4.33.0108281422280.1460-100000@redshift.mimosa.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
| From: Bill Manning <bmanning@ISI.EDU>
| % We chose TXT because we simply wanted to convey a gateway address and a
| % key, and we wanted to parse it with 10 lines of code, not 10,000.
|
| $DEITY help you when you grab a random TXT record... :)
Why would you have random TXT records in your reverse domain,
especially ones starting with "X-IPsec-Gateway("?
Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253
From owner-ipsec@lists.tislabs.com Tue Aug 28 15:47:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SMlqD09662;
Tue, 28 Aug 2001 15:47:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14607
Tue, 28 Aug 2001 17:54:20 -0400 (EDT)
From: Bill Manning <bmanning@ISI.EDU>
Message-Id: <200108282201.f7SM1oN14523@zed.isi.edu>
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment
To: hugh@mimosa.com
Date: Tue, 28 Aug 2001 15:01:49 -0700 (PDT)
Cc: bmanning@ISI.EDU (Bill Manning), henry@spsystems.net (Henry Spencer),
hugh@road.xisp.net (Hugh Daniel), ipsec@lists.tislabs.com,
design@lists.freeswan.org (FreeS/WAN Design Issues)
In-Reply-To: <Pine.LNX.4.33.0108281422280.1460-100000@redshift.mimosa.com> from "D. Hugh Redelmeier" at Aug 28, 2001 02:26:18 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
%
% | From: Bill Manning <bmanning@ISI.EDU>
%
% | % We chose TXT because we simply wanted to convey a gateway address and a
% | % key, and we wanted to parse it with 10 lines of code, not 10,000.
% |
% | $DEITY help you when you grab a random TXT record... :)
%
% Why would you have random TXT records in your reverse domain,
% especially ones starting with "X-IPsec-Gateway("?
%
% Hugh Redelmeier
% hugh@mimosa.com voice: +1 416 482-8253
%
'cause I want to confuse your software?
--
--bill
From owner-ipsec@lists.tislabs.com Tue Aug 28 17:32:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7T0WlD11458;
Tue, 28 Aug 2001 17:32:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA14725
Tue, 28 Aug 2001 19:50:21 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Dan Harkins'" <dharkins@lounge.org>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Notify SPI field specifications
Date: Tue, 28 Aug 2001 19:50:19 +0100
Message-Id: <002f01c12ff3$50d26a50$1e72788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <200108280653.f7S6rNU00549@dharkins@lounge.orgatty.lounge.org>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Let me state again that it is just these sorts of things
> that will be
> solved by having a single document to describe key
> management. The generic
> language/transport (RFC2408) with a generic key exchange
> (RFC2409) on top
> with a specific service (RFC2407) on top of that does not work. Things
> that are required for the service have to be defined in the
> language or
> key exchange. The commit bit is another example. The entire
> layering is
> artificial and the source of this sort of confusion. That is
> being rectified.
Or so we keep hearing...
Merging the documents is not a magic wand you can wave in order to make the
documents clearer; you actually have to write the text clearly and
unambiguously.
Perhaps the problem is that RFC2409 didn't need to be a generic key
exchange. Isn't it possible that only one of the 3 documents is confusing?
Criticizing your own document due to circumstances beyond your control seems
like passing the buck.
I keep hearing, without substantiation, that having a DOI has greatly
complicated IKE. However, I have noticed that 4 other groups have exploited
this feature to create keying protocols with much reduced effort, and all
without any extra work by me.
> "I personally think it is very dangerous to organize
> referendums when you're not sure to win them"
> -- Louis Michel, President of the European Union
You can aways hold another referendum next year, and keep holding them once
every few years until you win.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
From owner-ipsec@lists.tislabs.com Wed Aug 29 01:23:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7T8NRD09777;
Wed, 29 Aug 2001 01:23:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15536
Wed, 29 Aug 2001 03:14:32 -0400 (EDT)
Message-ID: <004501c1305a$19141160$1bce1dd5@mscece.iut.ac.ir>
From: "mahdavi" <mahdavi@sepahan.iut.ac.ir>
To: "Cambria, Mike" <mcambria@avaya.com>, <ipsec@lists.tislabs.com>
References: <3A6D367EA1EFD4118C9B00A0C9DD99D706502D@rerun.lucentctc.com>
Subject: Re: Incoming SPD check on packet with no IPsec header?
Date: Wed, 29 Aug 2001 11:41:33 +0430
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Yes.
you have to check spd for all incomming packet. include non ipsec packets.
perhaps you want not to receive some packets.
----- Original Message -----
From: "Cambria, Mike" <mcambria@avaya.com>
To: <ipsec@lists.tislabs.com>
Sent: Tuesday, August 21, 2001 10:56 PM
Subject: Incoming SPD check on packet with no IPsec header?
>
> In section 5.2.1 of RFC2401, should step #3 be performed (i.e. find
incoming
> policy in the SPD that matches the packet) even if the packet arrives with
> no IPsec headers (e.g. nothing to do in steps 1 & 2)?
>
> The beginning of section 5 (and 4.4.1) says that the SPD must be consulted
> during the processing of all traffic. However, since 5.2.1 doesn't
mention
> to do this, I wanted to check.
>
> Thanks,
> MikeC
From owner-ipsec@lists.tislabs.com Wed Aug 29 01:31:31 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7T8VUD10768;
Wed, 29 Aug 2001 01:31:30 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15615
Wed, 29 Aug 2001 03:43:31 -0400 (EDT)
Message-ID: <012a01c1305e$7d965db0$1bce1dd5@mscece.iut.ac.ir>
From: "mahdavi" <mahdavi@sepahan.iut.ac.ir>
To: <ipsec@lists.tislabs.com>
Subject: inbound vs outbound?
Date: Wed, 29 Aug 2001 12:14:53 +0430
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0127_01C13084.357F8350"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0127_01C13084.357F8350
Content-Type: text/plain;
charset="windows-1256"
Content-Transfer-Encoding: quoted-printable
Hi.=20
In a security gateway how you can distinguish between an Inbound packet =
and outbound packet?
Is this correct ?=20
"every packet is outbound else its destination IP is IP of this machine =
(this security gateway) .=20
------=_NextPart_000_0127_01C13084.357F8350
Content-Type: text/html;
charset="windows-1256"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1256" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi. </FONT></DIV>
<DIV><FONT face=3D"Arial (Arabic)" size=3D2>In a security gateway how =
you can=20
distinguish between an Inbound packet and outbound packet?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3D"Arial (Arabic)" size=3D2>Is this correct ? =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>"every packet is outbound else its =
destination IP=20
is IP of this machine (this security gateway) . </FONT></DIV>
<DIV> </DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0127_01C13084.357F8350--
From owner-ipsec@lists.tislabs.com Wed Aug 29 02:17:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7T9HAD14864;
Wed, 29 Aug 2001 02:17:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15550
Wed, 29 Aug 2001 03:22:49 -0400 (EDT)
Message-ID: <008401c1305a$f9b01160$1bce1dd5@mscece.iut.ac.ir>
From: "mahdavi" <mahdavi@sepahan.iut.ac.ir>
To: "Pars MUTAF" <pars.mutaf@inrialpes.fr>
Cc: <ipsec@lists.tislabs.com>
References: <3A6D367EA1EFD4118C9B00A0C9DD99D706502C@rerun.lucentctc.com> <p05010416b7a85aa859a0@[128.33.84.34]> <3B8547DB.AB6D0FC1@inrialpes.fr>
Subject: Re: question on SPI
Date: Wed, 29 Aug 2001 11:49:37 +0430
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
you can generate it every way you want . but random is better. just behalf
ipsec must agree with it and also it must not be used for another SA.
----- Original Message -----
From: "Pars MUTAF" <pars.mutaf@inrialpes.fr>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, August 23, 2001 10:43 PM
Subject: question on SPI
>
> Hi all;
>
> How a host picks the SPIs when establishing SAs?
> (i.e., randomly? consecutively?)
>
> Any limitation, suggestion (or documentation)
> on that?
>
> Help please! Thank you...
>
> Regards,
> pars
>
From owner-ipsec@lists.tislabs.com Wed Aug 29 08:48:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TFmmD04683;
Wed, 29 Aug 2001 08:48:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16431
Wed, 29 Aug 2001 10:22:02 -0400 (EDT)
Message-ID: <8894CA1F87A5D411BD24009027EE7838128276@ROC-76-204.nai.com>
From: "Mason, David" <David_Mason@nai.com>
To: "'mahdavi'" <mahdavi@sepahan.iut.ac.ir>,
Pars MUTAF
<pars.mutaf@inrialpes.fr>
Cc: ipsec@lists.tislabs.com
Subject: RE: question on SPI
Date: Wed, 29 Aug 2001 07:27:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It was suggested a while back that the lower SPIs be reserved for manual
SAs. I don't believe this is in the RFCs anywhere, but I would suggest not
using small SPIs for IKE generated IPsec SAs. The RFCs do state that you
should not use 0-255.
-dave
-----Original Message-----
From: mahdavi [mailto:mahdavi@sepahan.iut.ac.ir]
Sent: Wednesday, August 29, 2001 3:20 AM
To: Pars MUTAF
Cc: ipsec@lists.tislabs.com
Subject: Re: question on SPI
you can generate it every way you want . but random is better. just behalf
ipsec must agree with it and also it must not be used for another SA.
----- Original Message -----
From: "Pars MUTAF" <pars.mutaf@inrialpes.fr>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, August 23, 2001 10:43 PM
Subject: question on SPI
>
> Hi all;
>
> How a host picks the SPIs when establishing SAs?
> (i.e., randomly? consecutively?)
>
> Any limitation, suggestion (or documentation)
> on that?
>
> Help please! Thank you...
>
> Regards,
> pars
>
From owner-ipsec@lists.tislabs.com Wed Aug 29 09:43:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TGhGD07338;
Wed, 29 Aug 2001 09:43:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16456
Wed, 29 Aug 2001 10:30:18 -0400 (EDT)
To: Bill Manning <bmanning@ISI.EDU>
Cc: hugh@mimosa.com, henry@spsystems.net (Henry Spencer),
hugh@road.xisp.net (Hugh Daniel), ipsec@lists.tislabs.com,
design@lists.freeswan.org (FreeS/WAN Design Issues)
Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment
References: <200108282201.f7SM1oN14523@zed.isi.edu>
From: Derek Atkins <warlord@mit.edu>
Date: 29 Aug 2001 10:37:37 -0400
In-Reply-To: Bill Manning's message of "Tue, 28 Aug 2001 15:01:49 -0700 (PDT)"
Message-ID: <sjmg0abvsni.fsf@rcn.ihtfp.org>
Lines: 22
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Bill Manning <bmanning@ISI.EDU> writes:
> 'cause I want to confuse your software?
If one is going to trust DNS (or even DNSSec) and the DNS zone
administrator wants to foil you, there is nothing you can do. Even if
you go ahead and use KEY or CERT records, you (they DNS admin) could
put in bad/fake data. There is nothing to protect users against
attackers who are their own DNS admins.
However, that doesn't mean the approach isn't valid. It just means
it doesn't protect against this particular threat.
> --bill
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Wed Aug 29 10:57:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7THv1D08735;
Wed, 29 Aug 2001 10:57:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16875
Wed, 29 Aug 2001 12:55:46 -0400 (EDT)
Message-ID: <4652644B98DFF34696801F8F3070D3FE04B5F7@D2CSPEXM001.smartpipes.com>
From: "Jain, Gautam" <GJain@smartpipes.com>
To: ipsec@lists.tislabs.com
Subject: monitoring ipsec tunnels...
Date: Wed, 29 Aug 2001 17:02:47 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Do there exist any products that monitors IPsec tunnels or is there interest
at all in monitoring IPsec tunnels...
There seems to exist ( to name a few ) parameters that seem to be of
interest from monitoring perspective..
A snapshot of an SA on a device ( talking ipsec ) at any give point will
give stats of things like
IPsec send, receive, compression, decompression errors ( Are these device
specific or standard based )
The names are self explanatory, however...
1) what causes these errors ?
2) how can you get rid of them ? ( is it a temporary behavior say during
IPsec renegotiating tunnels ? )
3) what behavioral aspect of the device do these errors represent ?
4) Are they of any concern as far as the overall operation of a tunnel is
concerned ?
Any help is appreciated.
gautam
From owner-ipsec@lists.tislabs.com Wed Aug 29 11:09:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TI9WD08950;
Wed, 29 Aug 2001 11:09:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16987
Wed, 29 Aug 2001 13:24:46 -0400 (EDT)
Message-Id: <200108291730.f7THUfq00632@dharkins@lounge.orgatty.lounge.org>
To: andrew.krywaniuk@alcatel.com
Cc: ipsec@lists.tislabs.com
Subject: Re: Notify SPI field specifications
In-Reply-To: Your message of "Tue, 28 Aug 2001 19:50:19 BST."
<002f01c12ff3$50d26a50$1e72788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <629.999106241.1@lounge.org>
Date: Wed, 29 Aug 2001 10:30:41 -0700
From: Dan Harkins <dharkins@lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 28 Aug 2001 19:50:19 BST you wrote
>
> Merging the documents is not a magic wand you can wave in order to make the
> documents clearer; you actually have to write the text clearly and
> unambiguously.
I never said it was a magic wand. I said it would clean up just the sort
of confusion that started this thread: one document saying one thing and
another saying something different. If there is one document then that
problem doesn't happen.
> Perhaps the problem is that RFC2409 didn't need to be a generic key
> exchange. Isn't it possible that only one of the 3 documents is confusing?
> Criticizing your own document due to circumstances beyond your control seems
> like passing the buck.
No it didn't and no I don't think so. You may be able to explain the true
meaning of the Commit Bit by just reading RFC2408 but no one else can.
And I don't think anyone can justify the seemingly mandated covert channel
in RFC2408.
We have payloads being defined in one document and redefined in another.
We have overly generic descriptions of things simply because there is this
artificial layering of the documents. That will all go away.
> I keep hearing, without substantiation, that having a DOI has greatly
> complicated IKE. However, I have noticed that 4 other groups have exploited
> this feature to create keying protocols with much reduced effort, and all
> without any extra work by me.
The artificial layering has creatly complicated the key management protocol
for IPsec. It is completely unnecessary. The problem that the DOI adds is
not only one of added genericicity (the attempt to be vague enough to
satisfy all sorts of possible key management protocols) but it encourages
people to overload one single port with all sorts of security protocols.
That is A Bad Thing.
Which 4 keying protocols have been created with the DOI concept? KINK? No.
GDOI? Sort of but not really. OSPF DOI? That died. RIP DOI? That died too.
> > "I personally think it is very dangerous to organize
> > referendums when you're not sure to win them"
> > -- Louis Michel, President of the European Union
>
> You can aways hold another referendum next year, and keep holding them once
> every few years until you win.
You of all people should not be making fun of someone's sig. I've left your
pompous one below for comparison.
> Andrew
> -------------------------------------------
> Upon closer inspection, I saw that the line
> dividing black from white was in fact a shade
> of grey. As I drew nearer still, the grey area
> grew larger. And then I was enlightened.
Dan.
"I personally think it is very dangerous to organize
referendums when you're not sure to win them"
-- Louis Michel, President of the European Union
From owner-ipsec@lists.tislabs.com Wed Aug 29 11:55:46 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TItjD09539;
Wed, 29 Aug 2001 11:55:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17173
Wed, 29 Aug 2001 14:12:26 -0400 (EDT)
Message-Id: <200108291636.f7TGasa02503@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com,
design@lists.freeswan.org (FreeS/WAN Design Issues)
Subject: opportunistic encryption and DNSSEC
In-reply-to: Your message of "29 Aug 2001 10:37:37 EDT."
<sjmg0abvsni.fsf@rcn.ihtfp.org>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 29 Aug 2001 12:36:54 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
(I'm changing the subject line to help mail sorting...)
>>>>> "Derek" == Derek Atkins <warlord@MIT.EDU> writes:
Derek> Bill Manning <bmanning@ISI.EDU> writes:
>> 'cause I want to confuse your software?
Derek> If one is going to trust DNS (or even DNSSec) and the DNS zone
Derek> administrator wants to foil you, there is nothing you can do. Even if
Derek> you go ahead and use KEY or CERT records, you (they DNS admin) could
Derek> put in bad/fake data. There is nothing to protect users against
Derek> attackers who are their own DNS admins.
Derek is absolute right.
DNS(sec) is in general used for *authentication*.
The X-IPsec-Server record is a form authorization. If you wish to authorize
strange things that it your business. It would be nice to go towards a more
clear form of authorization.
(Recall RGM's "TX" record for instance)
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO40aJYqHRg3pndX9AQECdAP/b5x4b4tiGKI10B6cLJVZEnzhMhqCO1vr
qDSIv4xL1xMtZL8+BAexOjI2DqzFg9NDg/J+TFelsjMd4mwRxhaF2LCX3GPop6SC
vPP2POq/UC8JjlObLjMI0QBH//G0cZ1mHdhVo8g4uBcXjV8veOdyH7O2GVMRuzaN
27EyqL32izg=
=V69G
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Wed Aug 29 22:38:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7U5cPD21515;
Wed, 29 Aug 2001 22:38:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA18341
Thu, 30 Aug 2001 00:40:32 -0400 (EDT)
Date: Thu, 30 Aug 2001 10:18:37 +0530 (IST)
From: Puja Puri <puja.puri@cdac.ernet.in>
To: mahdavi <mahdavi@sepahan.iut.ac.ir>
cc: ipsec@lists.tislabs.com
Subject: Re: inbound vs outbound?
In-Reply-To: <012a01c1305e$7d965db0$1bce1dd5@mscece.iut.ac.ir>
Message-ID: <Pine.GSO.4.10.10108301015260.12559-100000@mailhub.cdac.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I beg to defer from this point of view "that every packet that is not
destined for my machine is outbound". I feel that the packets that are
originating from ur machine are outbound and the remaining packets
recieved by ur machine are inbound irrespective of whether they r destined
for ur machine or they r forwarded(in which case they also become
outbound).
Puja Puri
Member of Technical Staff
Networking and Internet Software Group
C-DAC
Pune
On Wed, 29 Aug 2001, mahdavi wrote:
> Hi.
> In a security gateway how you can distinguish between an Inbound packet and outbound packet?
>
> Is this correct ?
> "every packet is outbound else its destination IP is IP of this machine (this security gateway) .
>
>
>
From owner-ipsec@lists.tislabs.com Thu Aug 30 00:05:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7U75YD04420;
Thu, 30 Aug 2001 00:05:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18507
Thu, 30 Aug 2001 02:16:17 -0400 (EDT)
Message-ID: <006f01c1311c$b4b09040$ae0510ac@roc.com>
Reply-To: "lokesh" <lokeshnb@intotoinc.com>
From: "lokesh" <lokeshnb@intotoinc.com>
To: <ipsec@lists.tislabs.com>
Subject: Stream Ciphers in ESP- IPsec Stack?
Date: Thu, 30 Aug 2001 11:56:26 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_006C_01C1314A.CC8B32A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_006C_01C1314A.CC8B32A0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi all,
Is there any latest document/information regarding use of=20
Stream ciphers like ARC-4 or RC4 in ESP of IPsec/Firewall Stack?.
people seem to call ESP using Stream ciphers as SC/ESP.
in that case, is there going to be change in ESP packet format or =
packet processing ?=20
I happen to refer some internet drafts like=20
<draft-caronni-esp--stream-01.txt> and <draft-mcgrew-ipsec-scesp-02.txt> =
second draft proposes no change in ESP packet format but gives no idea =
about how to handle packets which come out of order and how to provide =
Anti-Replay-Service, while former does give implementation details of =
Antireplay service but there is a change in ESP packet format as there =
is no pad length field present.
I'm looking for a complete document which addresses all these =
implementation details, is there one?
Are there any products which have implemented stream ciphers like ARC4 =
or RC4 in IPsec stack?=20
if so, can you give details there of ?
help in this regard is highly appreciated.
thanks
Lokesh
------=_NextPart_000_006C_01C1314A.CC8B32A0
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Is there any latest =
document/information regarding=20
use of </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Stream ciphers like ARC-4 or RC4 in ESP =
of=20
IPsec/Firewall Stack?.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>people seem to call ESP using Stream =
ciphers as=20
SC/ESP.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>in that case, is there going to =
be change in=20
ESP packet format or packet processing ? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I happen to refer some internet drafts =
like=20
</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2><draft-caronni-esp--stream-01.txt> and=20
<draft-mcgrew-ipsec-scesp-02.txt> second draft proposes =
no=20
change in ESP packet format but gives no idea about how to handle =
packets which=20
come out of order and how to provide Anti-Replay-Service, while former =
does give=20
implementation details of Antireplay service but there is a change in =
ESP packet=20
format as there is no pad length field present.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I'm looking for a complete document =
which addresses=20
all these implementation details, is there one?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Are there any products which have =
implemented=20
stream ciphers like ARC4 or RC4 in IPsec stack? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>if so, can you give details there of =
?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>help in this regard is highly=20
appreciated.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Lokesh</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_006C_01C1314A.CC8B32A0--
From owner-ipsec@lists.tislabs.com Thu Aug 30 07:07:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UE72D03349;
Thu, 30 Aug 2001 07:07:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19233
Thu, 30 Aug 2001 09:01:57 -0400 (EDT)
Message-ID: <009a01c13139$a142efe0$0601a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <ipsec@lists.tislabs.com>
Subject: IPsec interoperability demonstration platform
Date: Thu, 30 Aug 2001 11:53:32 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0097_01C1314A.64703260"
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_0097_01C1314A.64703260
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
During the 2000 edition of the IPsec Summit, HSC showcased a very =
successfull interoperability platform, demonstrating with several =
vendors that some VPN functions could interoperate at the gateway level. =
During the 2001 edition of the conference next October the experience =
will be renewed but with very important technical extensions.=20
The demonstration platform will perform :=20
A) VPN interoperability (gateway to gateway)
B) Certificate based authentication (PKI compliance)=20
C) Hybrid IPv4/IPv6 based network=20
The demonstration platform, developped and managed by HSC, is still =
welcoming vendors wishing to demonstrate that their IPsec systems are =
able to interoperate at the gateway level. Vendors wishing to connect =
clients on a distant access mode are also welcome.
The demonstrartion network will also integrate a certificate authority =
component (PKI)=20
Above all, the network will be able to implement IPv4 and IPv6 tunnels.
More details at:
http://www.upperside.fr/ipsec2001/ipsec01intro.htm
------=_NextPart_000_0097_01C1314A.64703260
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
During the 2000 edition of the = IPsec Summit,=20 HSC showcased a very successfull interoperability platform, = demonstrating with=20 several vendors that some VPN functions could interoperate at the = gateway=20 level.=20
During the 2001 edition of the = conference next=20 October the experience will be renewed but with very important technical = extensions.
The demonstration platform will perform :
A) VPN = interoperability (gateway to gateway)
B) Certificate based = authentication=20 (PKI compliance)
C) Hybrid IPv4/IPv6 based network =
The demonstration platform, developped and managed by HSC, = is still=20 welcoming vendors wishing to demonstrate that their IPsec systems are = able to=20 interoperate at the gateway level. Vendors wishing to connect clients on = a=20 distant access mode are also welcome.
The=20 demonstrartion network will also integrate a certificate authority = component=20 (PKI)
Above all, the network will be = able to=20 implement IPv4 and IPv6 tunnels.
More details at:
<3d.htm>http://www.up= perside.fr/ipsec2001/ipsec01intro.<3d.htm>htm
<= /DIV>
------=_NextPart_000_0097_01C1314A.64703260--
From owner-ipsec@lists.tislabs.com Thu Aug 30 07:24:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UEORD03704;
Thu, 30 Aug 2001 07:24:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19326
Thu, 30 Aug 2001 09:32:42 -0400 (EDT)
Message-ID: <10C8636AE359D4119118009027AE99870B292127@FMSMSX34>
From: "Walker, Jesse" <jesse.walker@intel.com>
To: "'lokesh'" <lokeshnb@intotoinc.com>, ipsec@lists.tislabs.com
Subject: RE: Stream Ciphers in ESP- IPsec Stack?
Date: Thu, 30 Aug 2001 06:39:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C13159.326E14D0"
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_01C13159.326E14D0
Content-Type: text/plain;
charset="Windows-1252"
Lokesh,
If you must use a stream cipher, perhaps you should consider a stream cipher
like SEAL or a block cipher in counter mode rather than RC4. RC4 does not
have the random access property--i.e., the packet can't simply carry some
marker to tell the receiver where to efficiently resume the cipher in case
packets are lost or arrive out of order--so for practical purposes its key
schedule has to be restarted on every packet. This causes all sorts of
trouble you'd really rather not deal with. RC4 is a good choice if you have
a reliable medium, but seems problematic for datagram environments. I would
never use it in IPsec.
-- Jesse
-----Original Message-----
From: lokesh [mailto:lokeshnb@intotoinc.com]
Sent: Wednesday, August 29, 2001 11:26 PM
To: ipsec@lists.tislabs.com
Subject: Stream Ciphers in ESP- IPsec Stack?
Hi all,
Is there any latest document/information regarding use of
Stream ciphers like ARC-4 or RC4 in ESP of IPsec/Firewall Stack?.
people seem to call ESP using Stream ciphers as SC/ESP.
in that case, is there going to be change in ESP packet format or packet
processing ?
I happen to refer some internet drafts like
<draft-caronni-esp--stream-01.txt> and <draft-mcgrew-ipsec-scesp-02.txt>
second draft proposes no change in ESP packet format but gives no idea about
how to handle packets which come out of order and how to provide
Anti-Replay-Service, while former does give implementation details of
Antireplay service but there is a change in ESP packet format as there is no
pad length field present.
I'm looking for a complete document which addresses all these implementation
details, is there one?
Are there any products which have implemented stream ciphers like ARC4 or
RC4 in IPsec stack?
if so, can you give details there of ?
help in this regard is highly appreciated.
thanks
Lokesh
------_=_NextPart_001_01C13159.326E14D0
Content-Type: text/html;
charset="Windows-1252"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Windows-1252">
<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=996343213-30082001>Lokesh,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=996343213-30082001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=996343213-30082001>If you
must use a stream cipher, perhaps you should consider a stream cipher like SEAL
or a block cipher in counter mode rather than RC4. RC4 does not have the random
access property--i.e., the packet can't simply carry some marker to tell the
receiver where to efficiently resume the cipher in case packets are lost or
arrive out of order--so for practical purposes its key schedule has to be
restarted on every packet. This causes all sorts of trouble you'd really rather
not deal with. RC4 is a good choice if you have a reliable medium,
but seems problematic for datagram environments. I would never use it in
IPsec.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=996343213-30082001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=996343213-30082001>--
Jesse</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> lokesh
[mailto:lokeshnb@intotoinc.com]<BR><B>Sent:</B> Wednesday, August 29, 2001
11:26 PM<BR><B>To:</B> ipsec@lists.tislabs.com<BR><B>Subject:</B> Stream
Ciphers in ESP- IPsec Stack?<BR><BR></DIV></FONT>
<DIV><FONT face=Arial size=2>Hi all,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Is there any latest document/information
regarding use of </FONT></DIV>
<DIV><FONT face=Arial size=2>Stream ciphers like ARC-4 or RC4 in ESP of
IPsec/Firewall Stack?.</FONT></DIV>
<DIV><FONT face=Arial size=2>people seem to call ESP using Stream ciphers as
SC/ESP.</FONT></DIV>
<DIV><FONT face=Arial size=2>in that case, is there going to be change
in ESP packet format or packet processing ? </FONT></DIV>
<DIV><FONT face=Arial size=2>I happen to refer some internet drafts like
</FONT></DIV>
<DIV><FONT face=Arial size=2><draft-caronni-esp--stream-01.txt> and
<draft-mcgrew-ipsec-scesp-02.txt> second draft proposes no
change in ESP packet format but gives no idea about how to handle packets
which come out of order and how to provide Anti-Replay-Service, while former
does give implementation details of Antireplay service but there is a change
in ESP packet format as there is no pad length field present.</FONT></DIV>
<DIV><FONT face=Arial size=2>I'm looking for a complete document which
addresses all these implementation details, is there one?</FONT></DIV>
<DIV><FONT face=Arial size=2>Are there any products which have implemented
stream ciphers like ARC4 or RC4 in IPsec stack? </FONT></DIV>
<DIV><FONT face=Arial size=2>if so, can you give details there of
?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>help in this regard is highly
appreciated.</FONT></DIV>
<DIV><FONT face=Arial size=2>thanks</FONT></DIV>
<DIV><FONT face=Arial size=2>Lokesh</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C13159.326E14D0--
From owner-ipsec@lists.tislabs.com Thu Aug 30 07:29:55 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UETtD03805;
Thu, 30 Aug 2001 07:29:55 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19347
Thu, 30 Aug 2001 09:45:24 -0400 (EDT)
To: "lokesh" <lokeshnb@intotoinc.com>
Cc: <ipsec@lists.tislabs.com>
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
References: <006f01c1311c$b4b09040$ae0510ac@roc.com>
From: Derek Atkins <warlord@mit.edu>
Date: 30 Aug 2001 09:52:49 -0400
In-Reply-To: "lokesh"'s message of "Thu, 30 Aug 2001 11:56:26 +0530"
Message-ID: <sjmsne9vemm.fsf@rcn.ihtfp.org>
Lines: 99
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Using stream ciphers in ESP is just dangerous. There are too many
ways to just get it wrong. Look at the problems it caused in 802.11's
WEP for a clear example how you should not do it.
-derek
"lokesh" <lokeshnb@intotoinc.com> writes:
> Hi all,
>
> Is there any latest document/information regarding use of=20
> Stream ciphers like ARC-4 or RC4 in ESP of IPsec/Firewall Stack?.
> people seem to call ESP using Stream ciphers as SC/ESP.
> in that case, is there going to be change in ESP packet format or =
> packet processing ?=20
> I happen to refer some internet drafts like=20
> <draft-caronni-esp--stream-01.txt> and <draft-mcgrew-ipsec-scesp-02.txt> =
> second draft proposes no change in ESP packet format but gives no idea =
> about how to handle packets which come out of order and how to provide =
> Anti-Replay-Service, while former does give implementation details of =
> Antireplay service but there is a change in ESP packet format as there =
> is no pad length field present.
> I'm looking for a complete document which addresses all these =
> implementation details, is there one?
> Are there any products which have implemented stream ciphers like ARC4 =
> or RC4 in IPsec stack?=20
> if so, can you give details there of ?
>
> help in this regard is highly appreciated.
> thanks
> Lokesh
>
>
>
> ------=_NextPart_000_006C_01C1314A.CC8B32A0
> Content-Type: text/html;
> charset="Windows-1252"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META content=3D"text/html; charset=3Dwindows-1252" =
> http-equiv=3DContent-Type>
> <META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
> <DIV> </DIV>
> <DIV><FONT face=3DArial size=3D2>Is there any latest =
> document/information regarding=20
> use of </FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>Stream ciphers like ARC-4 or RC4 in ESP =
> of=20
> IPsec/Firewall Stack?.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>people seem to call ESP using Stream =
> ciphers as=20
> SC/ESP.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>in that case, is there going to =
> be change in=20
> ESP packet format or packet processing ? </FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>I happen to refer some internet drafts =
> like=20
> </FONT></DIV>
> <DIV><FONT face=3DArial =
> size=3D2><draft-caronni-esp--stream-01.txt> and=20
> <draft-mcgrew-ipsec-scesp-02.txt> second draft proposes =
> no=20
> change in ESP packet format but gives no idea about how to handle =
> packets which=20
> come out of order and how to provide Anti-Replay-Service, while former =
> does give=20
> implementation details of Antireplay service but there is a change in =
> ESP packet=20
> format as there is no pad length field present.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>I'm looking for a complete document =
> which addresses=20
> all these implementation details, is there one?</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>Are there any products which have =
> implemented=20
> stream ciphers like ARC4 or RC4 in IPsec stack? </FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>if so, can you give details there of =
> ?</FONT></DIV>
> <DIV> </DIV>
> <DIV><FONT face=3DArial size=3D2>help in this regard is highly=20
> appreciated.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>thanks</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>Lokesh</FONT></DIV>
> <DIV> </DIV>
> <DIV> </DIV></BODY></HTML>
>
> ------=_NextPart_000_006C_01C1314A.CC8B32A0--
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Thu Aug 30 09:23:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UGNmD12247;
Thu, 30 Aug 2001 09:23:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19582
Thu, 30 Aug 2001 11:31:23 -0400 (EDT)
Message-Id: <3.0.3.32.20010830084621.00e90630@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Thu, 30 Aug 2001 08:46:21 -0700
To: Derek Atkins <warlord@mit.edu>, "lokesh" <lokeshnb@intotoinc.com>
From: Alex Alten <Alten@home.com>
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
Cc: <ipsec@lists.tislabs.com>
In-Reply-To: <sjmsne9vemm.fsf@rcn.ihtfp.org>
References: <"lokesh"'s message of "Thu, 30 Aug 2001 11:56:26 +0530">
<006f01c1311c$b4b09040$ae0510ac@roc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
That's not true. Just because the WEP implementation was wrong
doesn't mean a stream cipher is too dangerous. Depending on the
design stream ciphers can fit nicely into implementations of
protocols or disk i/o drivers. However, I would not use RC4
(aka ARC4), I've heard that its key setup machinery is broken.
- Alex
At 09:52 AM 8/30/2001 -0400, Derek Atkins wrote:
>Using stream ciphers in ESP is just dangerous. There are too many
>ways to just get it wrong. Look at the problems it caused in 802.11's
>WEP for a clear example how you should not do it.
>
>-derek
>
>"lokesh" <lokeshnb@intotoinc.com> writes:
>
>> Hi all,
>>
>> Is there any latest document/information regarding use of=20
>> Stream ciphers like ARC-4 or RC4 in ESP of IPsec/Firewall Stack?.
>> people seem to call ESP using Stream ciphers as SC/ESP.
>> in that case, is there going to be change in ESP packet format or =
>> packet processing ?=20
>> I happen to refer some internet drafts like=20
>> <draft-caronni-esp--stream-01.txt> and <draft-mcgrew-ipsec-scesp-02.txt> =
>> second draft proposes no change in ESP packet format but gives no idea =
>> about how to handle packets which come out of order and how to provide =
>> Anti-Replay-Service, while former does give implementation details of =
>> Antireplay service but there is a change in ESP packet format as there =
>> is no pad length field present.
>> I'm looking for a complete document which addresses all these =
>> implementation details, is there one?
>> Are there any products which have implemented stream ciphers like ARC4 =
>> or RC4 in IPsec stack?=20
>> if so, can you give details there of ?
>>
>> help in this regard is highly appreciated.
>> thanks
>> Lokesh
>>
>>
>>
>> ------=_NextPart_000_006C_01C1314A.CC8B32A0
>> Content-Type: text/html;
>> charset="Windows-1252"
>> Content-Transfer-Encoding: quoted-printable
>>
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
>> <HTML><HEAD>
>> <META content=3D"text/html; charset=3Dwindows-1252" =
>> http-equiv=3DContent-Type>
>> <META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
>> <STYLE></STYLE>
>> </HEAD>
>> <BODY bgColor=3D#ffffff>
>> <DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
>> <DIV> </DIV>
>> <DIV><FONT face=3DArial size=3D2>Is there any latest =
>> document/information regarding=20
>> use of </FONT></DIV>
>> <DIV><FONT face=3DArial size=3D2>Stream ciphers like ARC-4 or RC4 in ESP =
>> of=20
>> IPsec/Firewall Stack?.</FONT></DIV>
>> <DIV><FONT face=3DArial size=3D2>people seem to call ESP using Stream =
>> ciphers as=20
>> SC/ESP.</FONT></DIV>
>> <DIV><FONT face=3DArial size=3D2>in that case, is there going to =
>> be change in=20
>> ESP packet format or packet processing ? </FONT></DIV>
>> <DIV><FONT face=3DArial size=3D2>I happen to refer some internet drafts =
>> like=20
>> </FONT></DIV>
>> <DIV><FONT face=3DArial =
>> size=3D2><draft-caronni-esp--stream-01.txt> and=20
>> <draft-mcgrew-ipsec-scesp-02.txt> second draft proposes =
>> no=20
>> change in ESP packet format but gives no idea about how to handle =
>> packets which=20
>> come out of order and how to provide Anti-Replay-Service, while former =
>> does give=20
>> implementation details of Antireplay service but there is a change in =
>> ESP packet=20
>> format as there is no pad length field present.</FONT></DIV>
>> <DIV><FONT face=3DArial size=3D2>I'm looking for a complete document =
>> which addresses=20
>> all these implementation details, is there one?</FONT></DIV>
>> <DIV><FONT face=3DArial size=3D2>Are there any products which have =
>> implemented=20
>> stream ciphers like ARC4 or RC4 in IPsec stack? </FONT></DIV>
>> <DIV><FONT face=3DArial size=3D2>if so, can you give details there of =
>> ?</FONT></DIV>
>> <DIV> </DIV>
>> <DIV><FONT face=3DArial size=3D2>help in this regard is highly=20
>> appreciated.</FONT></DIV>
>> <DIV><FONT face=3DArial size=3D2>thanks</FONT></DIV>
>> <DIV><FONT face=3DArial size=3D2>Lokesh</FONT></DIV>
>> <DIV> </DIV>
>> <DIV> </DIV></BODY></HTML>
>>
>> ------=_NextPart_000_006C_01C1314A.CC8B32A0--
>>
>
>--
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Thu Aug 30 09:30:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UGUPD12349;
Thu, 30 Aug 2001 09:30:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19604
Thu, 30 Aug 2001 11:40:06 -0400 (EDT)
To: Alex Alten <Alten@home.com>
Cc: "lokesh" <lokeshnb@intotoinc.com>, <ipsec@lists.tislabs.com>
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
References: <"lokesh"'s message of "Thu, 30 Aug 2001 11:56:26 +0530"> <006f01c1311c$b4b09040$ae0510ac@roc.com> <3.0.3.32.20010830084621.00e90630@mail>
From: Derek Atkins <warlord@mit.edu>
Date: 30 Aug 2001 11:47:32 -0400
In-Reply-To: Alex Alten's message of "Thu, 30 Aug 2001 08:46:21 -0700"
Message-ID: <sjmk7zlv9bf.fsf@rcn.ihtfp.org>
Lines: 139
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Last I checked, "disk i/o drivers" is not ESP. Note that I
specifically said "using stream ciphers in ESP." I would hope that
this statement would clearly limit my intent to IPsec, not other
potential uses of stream ciphers, no?
I would appreciate it if you could refrain from putting words in my
mouth or trying to expand the meaning of my words beyond what I
actually said. I have nothing against stream ciphers, but I would
prefer they be used only in tasks for which their benefits (and
drawbacks) match the engineering problem at hand.
Thanks,
-derek
Alex Alten <Alten@Home.Com> writes:
> That's not true. Just because the WEP implementation was wrong
> doesn't mean a stream cipher is too dangerous. Depending on the
> design stream ciphers can fit nicely into implementations of
> protocols or disk i/o drivers. However, I would not use RC4
> (aka ARC4), I've heard that its key setup machinery is broken.
>
> - Alex
>
> At 09:52 AM 8/30/2001 -0400, Derek Atkins wrote:
> >Using stream ciphers in ESP is just dangerous. There are too many
> >ways to just get it wrong. Look at the problems it caused in 802.11's
> >WEP for a clear example how you should not do it.
> >
> >-derek
> >
> >"lokesh" <lokeshnb@intotoinc.com> writes:
> >
> >> Hi all,
> >>
> >> Is there any latest document/information regarding use of=20
> >> Stream ciphers like ARC-4 or RC4 in ESP of IPsec/Firewall Stack?.
> >> people seem to call ESP using Stream ciphers as SC/ESP.
> >> in that case, is there going to be change in ESP packet format or =
> >> packet processing ?=20
> >> I happen to refer some internet drafts like=20
> >> <draft-caronni-esp--stream-01.txt> and <draft-mcgrew-ipsec-scesp-02.txt> =
> >> second draft proposes no change in ESP packet format but gives no idea =
> >> about how to handle packets which come out of order and how to provide =
> >> Anti-Replay-Service, while former does give implementation details of =
> >> Antireplay service but there is a change in ESP packet format as there =
> >> is no pad length field present.
> >> I'm looking for a complete document which addresses all these =
> >> implementation details, is there one?
> >> Are there any products which have implemented stream ciphers like ARC4 =
> >> or RC4 in IPsec stack?=20
> >> if so, can you give details there of ?
> >>
> >> help in this regard is highly appreciated.
> >> thanks
> >> Lokesh
> >>
> >>
> >>
> >> ------=_NextPart_000_006C_01C1314A.CC8B32A0
> >> Content-Type: text/html;
> >> charset="Windows-1252"
> >> Content-Transfer-Encoding: quoted-printable
> >>
> >> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> >> <HTML><HEAD>
> >> <META content=3D"text/html; charset=3Dwindows-1252" =
> >> http-equiv=3DContent-Type>
> >> <META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
> >> <STYLE></STYLE>
> >> </HEAD>
> >> <BODY bgColor=3D#ffffff>
> >> <DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
> >> <DIV> </DIV>
> >> <DIV><FONT face=3DArial size=3D2>Is there any latest =
> >> document/information regarding=20
> >> use of </FONT></DIV>
> >> <DIV><FONT face=3DArial size=3D2>Stream ciphers like ARC-4 or RC4 in ESP =
> >> of=20
> >> IPsec/Firewall Stack?.</FONT></DIV>
> >> <DIV><FONT face=3DArial size=3D2>people seem to call ESP using Stream =
> >> ciphers as=20
> >> SC/ESP.</FONT></DIV>
> >> <DIV><FONT face=3DArial size=3D2>in that case, is there going to =
> >> be change in=20
> >> ESP packet format or packet processing ? </FONT></DIV>
> >> <DIV><FONT face=3DArial size=3D2>I happen to refer some internet drafts =
> >> like=20
> >> </FONT></DIV>
> >> <DIV><FONT face=3DArial =
> >> size=3D2><draft-caronni-esp--stream-01.txt> and=20
> >> <draft-mcgrew-ipsec-scesp-02.txt> second draft proposes =
> >> no=20
> >> change in ESP packet format but gives no idea about how to handle =
> >> packets which=20
> >> come out of order and how to provide Anti-Replay-Service, while former =
> >> does give=20
> >> implementation details of Antireplay service but there is a change in =
> >> ESP packet=20
> >> format as there is no pad length field present.</FONT></DIV>
> >> <DIV><FONT face=3DArial size=3D2>I'm looking for a complete document =
> >> which addresses=20
> >> all these implementation details, is there one?</FONT></DIV>
> >> <DIV><FONT face=3DArial size=3D2>Are there any products which have =
> >> implemented=20
> >> stream ciphers like ARC4 or RC4 in IPsec stack? </FONT></DIV>
> >> <DIV><FONT face=3DArial size=3D2>if so, can you give details there of =
> >> ?</FONT></DIV>
> >> <DIV> </DIV>
> >> <DIV><FONT face=3DArial size=3D2>help in this regard is highly=20
> >> appreciated.</FONT></DIV>
> >> <DIV><FONT face=3DArial size=3D2>thanks</FONT></DIV>
> >> <DIV><FONT face=3DArial size=3D2>Lokesh</FONT></DIV>
> >> <DIV> </DIV>
> >> <DIV> </DIV></BODY></HTML>
> >>
> >> ------=_NextPart_000_006C_01C1314A.CC8B32A0--
> >>
> >
> >--
> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > Member, MIT Student Information Processing Board (SIPB)
> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> > warlord@MIT.EDU PGP key available
> >
> --
>
> Alex Alten
>
> Alten@Home.Com
>
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Thu Aug 30 15:47:04 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UMl3D18657;
Thu, 30 Aug 2001 15:47:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20395
Thu, 30 Aug 2001 17:39:00 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010830174408.01ec6e58@localhost>
X-Sender: rgm-sec@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 30 Aug 2001 17:47:17 -0400
To: "lokesh" <lokeshnb@intotoinc.com>, <ipsec@lists.tislabs.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
In-Reply-To: <006f01c1311c$b4b09040$ae0510ac@roc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 11:56 AM 8/30/2001 +0530, lokesh wrote:
>Is there any latest document/information regarding use of
>Stream ciphers like ARC-4 or RC4 in ESP of IPsec/Firewall Stack?.
RFC 2451 defines how to use RC5 as an ESP transform.
There is an ESP transform for RC4, and there was an Internet Draft for
ARC4. However it died a quite death. Rodney Thayer did the work for it,
but it did not get any backing.
So I think that RC5 is the only streaming cipher that you will find out
there as a few vendors did EVERY cipher in the spec...
Robert Moskowitz
ICSA
Security Interest EMail: rgm-sec@htt-consult.com
From owner-ipsec@lists.tislabs.com Thu Aug 30 15:47:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UMlAD18675;
Thu, 30 Aug 2001 15:47:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20447
Thu, 30 Aug 2001 17:55:45 -0400 (EDT)
From: ji@research.att.com
Date: Thu, 30 Aug 2001 18:03:18 -0400 (EDT)
Message-Id: <200108302203.SAA04735@bual.research.att.com>
To: ipsec@lists.tislabs.com, lokeshnb@intotoinc.com, rgm-sec@htt-consult.com
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> o I think that RC5 is the only streaming cipher that you will find out
RC5 is a block cipher.
From owner-ipsec@lists.tislabs.com Thu Aug 30 16:55:41 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UNteD19633;
Thu, 30 Aug 2001 16:55:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20522
Thu, 30 Aug 2001 19:02:35 -0400 (EDT)
Message-Id: <4.3.2.7.0.20010830175849.01e55db8@STPNTMX03.sctc.com>
X-Sender: smith@STPNTMX03.sctc.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 30 Aug 2001 18:05:53 -0500
To: "lokesh" <lokeshnb@intotoinc.com>, <ipsec@lists.tislabs.com>
From: Rick Smith at Secure Computing <rick_smith@securecomputing.com>
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
In-Reply-To: <006f01c1311c$b4b09040$ae0510ac@roc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 01:26 AM 8/30/2001, lokesh wrote:
>Hi all,
>
>Is there any latest document/information regarding use of
>Stream ciphers like ARC-4 or RC4 in ESP of IPsec/Firewall Stack?.
The Borderware firewall had a proprietary-ish RC4 transform: I don't think
anyone ever published an I-D or anything describing it. I think it was
dropped entirely when the implementation moved to the newer RFCs. It was
brittle in practice. I seem to recall that when we got involved with it at
SCC, we couldn't see a practical way to make it more robust.
Rick.
smith@securecomputing.com roseville, minnesota
"Authentication" coming in October http://www.visi.com/crypto/
From owner-ipsec@lists.tislabs.com Fri Aug 31 04:51:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VBpnD05744;
Fri, 31 Aug 2001 04:51:49 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA21602
Fri, 31 Aug 2001 06:52:17 -0400 (EDT)
Message-Id: <200108311058.GAA27844@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-02.txt
Date: Fri, 31 Aug 2001 06:58:30 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : More MODP Diffie-Hellman groups for IKE
Author(s) : T. Kivinen, M. Kojo
Filename : draft-ietf-ipsec-ike-modp-groups-02.txt
Pages : 6
Date : 30-Aug-01
This document defines new MODP groups for the IKE [RFC-2409] protocol.
It documents the well know and used 1536 bit group 5, and also defines
new 2048, 3072, 4096, and 8192 bit Diffie-Hellman groups. The selection
of the primes for theses groups follows the criteria established by
Richard Schroeppel as described in [RFC-2412].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-ike-modp-groups-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-02.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: <20010830111544.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ike-modp-groups-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010830111544.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Fri Aug 31 04:55:46 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VBtjD06322;
Fri, 31 Aug 2001 04:55:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21643
Fri, 31 Aug 2001 07:15:31 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010831072155.00ac5778@localhost>
X-Sender: rgm-sec@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 31 Aug 2001 07:22:32 -0400
To: ji@research.att.com, ipsec@lists.tislabs.com, lokeshnb@intotoinc.com
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
In-Reply-To: <200108302203.SAA04735@bual.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 06:03 PM 8/30/2001 -0400, ji@research.att.com wrote:
> > o I think that RC5 is the only streaming cipher that you will find out
>
>RC5 is a block cipher.
this is what I get for responding at the hour I did.
I retract and apologize to all!!!!!!
Robert Moskowitz
ICSA
Security Interest EMail: rgm-sec@htt-consult.com
From owner-ipsec@lists.tislabs.com Fri Aug 31 05:27:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VCReD08673;
Fri, 31 Aug 2001 05:27:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21726
Fri, 31 Aug 2001 07:48:30 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010831075339.01e0fc50@localhost>
X-Sender: rgm-sec@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 31 Aug 2001 07:54:59 -0400
To: ji@research.att.com, ipsec@lists.tislabs.com, lokeshnb@intotoinc.com
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
In-Reply-To: <5.1.0.14.2.20010831072155.00ac5778@localhost>
References: <200108302203.SAA04735@bual.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 07:22 AM 8/31/2001 -0400, Robert Moskowitz wrote:
>At 06:03 PM 8/30/2001 -0400, ji@research.att.com wrote:
>> > o I think that RC5 is the only streaming cipher that you will find out
>>
>>RC5 is a block cipher.
>
>
>this is what I get for responding at the hour I did.
>
>I retract and apologize to all!!!!!!
BTW, based on discussions at IEEE 802.11i, I am working on an AES counter
mode ID. As well as an AES-OCB ID.
Anyone else interested in these?
Robert Moskowitz
TruSecure Corporation
Security Interest EMail: rgm-sec@htt-consult.com
From owner-ipsec@lists.tislabs.com Fri Aug 31 06:20:54 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VDKrD11688;
Fri, 31 Aug 2001 06:20:54 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21822
Fri, 31 Aug 2001 08:37:21 -0400 (EDT)
From: chris stillson <stillson@difilippo.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15246.47755.268116.583853@gargle.gargle.HOWL>
Date: Thu, 30 Aug 2001 15:13:31 -0700
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Cc: "lokesh" <lokeshnb@intotoinc.com>, <ipsec@lists.tislabs.com>
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
In-Reply-To: <5.1.0.14.2.20010830174408.01ec6e58@localhost>
References: <006f01c1311c$b4b09040$ae0510ac@roc.com>
<5.1.0.14.2.20010830174408.01ec6e58@localhost>
X-Mailer: VM 6.92 under 21.1 (patch 3) "Acadia" XEmacs Lucid
X-Face: ;>?o+t66!z`OvpX.6T'j.4l4Gi+L*?8ZnU3L[G/^R,ELl3.Stln=12L+t|hsa*<{/D<{OS(ybD%5<p1k'KWu~2`ggA_L%P.80xTxo5E[(Co7E2b{4tMN[z59GT8woI?%`|<N_#Hbbq=g?Czs;CGv`KH(`'4?OWT.ENXkD6]nt=k)b9pb!Mx<0OJ!l&'SK_@/F]L3-KPn`RvR*Na'T;w;}uk2y`
Reply-to: Chris.Stillson@sun.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Robert Moskowitz writes:
> So I think that RC5 is the only streaming cipher that you will find out
> there as a few vendors did EVERY cipher in the spec...
RC5 is a block cipher.
chris stillson
IPSEC crypto monkey
x82477
Note: Preceding comments written by an engineer. There is nothing
to read into them. He really has no hidden motives or agendas.
1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action
5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration
--Please inform author if he has forgotten about any of these
From owner-ipsec@lists.tislabs.com Fri Aug 31 08:02:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VF2CD16433;
Fri, 31 Aug 2001 08:02:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22044
Fri, 31 Aug 2001 10:15:42 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010400b7b54da934b2@[128.33.84.34]>
In-Reply-To: <5.1.0.14.2.20010831075339.01e0fc50@localhost>
References: <200108302203.SAA04735@bual.research.att.com>
<5.1.0.14.2.20010831075339.01e0fc50@localhost>
Date: Fri, 31 Aug 2001 10:21:15 -0400
To: Robert Moskowitz <rgm-sec@htt-consult.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
Cc: ji@research.att.com, ipsec@lists.tislabs.com, lokeshnb@intotoinc.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 7:54 AM -0400 8/31/01, Robert Moskowitz wrote:
>At 07:22 AM 8/31/2001 -0400, Robert Moskowitz wrote:
>>At 06:03 PM 8/30/2001 -0400, ji@research.att.com wrote:
>>> > o I think that RC5 is the only streaming cipher that you will find out
>>>
>>>RC5 is a block cipher.
>>
>>
>>this is what I get for responding at the hour I did.
>>
>>I retract and apologize to all!!!!!!
>
>BTW, based on discussions at IEEE 802.11i, I am working on an AES
>counter mode ID. As well as an AES-OCB ID.
>
>Anyone else interested in these?
yes, Bob, I am interested in a split counter mode, based on
discussions several folks have been having offlist, and based on my
presentation at the last IETF meeting.
Steve
From owner-ipsec@lists.tislabs.com Fri Aug 31 08:06:43 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VF6gD16490;
Fri, 31 Aug 2001 08:06:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22060
Fri, 31 Aug 2001 10:24:28 -0400 (EDT)
Message-ID: <3B8FA158.3A820DB9@cisco.com>
Date: Fri, 31 Aug 2001 07:38:16 -0700
From: "David A. McGrew" <mcgrew@cisco.com>
Reply-To: @cisco.com
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Derek Atkins <warlord@mit.edu>
CC: lokesh <lokeshnb@intotoinc.com>, ipsec@lists.tislabs.com
Subject: Re: Stream Ciphers in ESP- IPsec Stack?
References: <006f01c1311c$b4b09040$ae0510ac@roc.com> <sjmsne9vemm.fsf@rcn.ihtfp.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Derek,
Derek Atkins wrote:
>
> Using stream ciphers in ESP is just dangerous. There are too many
> ways to just get it wrong. Look at the problems it caused in 802.11's
> WEP for a clear example how you should not do it.
draft-mcgrew-ipsec-scesp-02.txt describes how to do it right, and also
references some suitable keystream generators. Are you aware of any
problems in that spec? If so, I would be grateful if you would pass
them on.
thanks,
David
>
> -derek
>
> "lokesh" <lokeshnb@intotoinc.com> writes:
>
> > Hi all,
> >
> > Is there any latest document/information regarding use of=20
> > Stream ciphers like ARC-4 or RC4 in ESP of IPsec/Firewall Stack?.
> > people seem to call ESP using Stream ciphers as SC/ESP.
> > in that case, is there going to be change in ESP packet format or =
> > packet processing ?=20
> > I happen to refer some internet drafts like=20
> > <draft-caronni-esp--stream-01.txt> and <draft-mcgrew-ipsec-scesp-02.txt> =
> > second draft proposes no change in ESP packet format but gives no idea =
> > about how to handle packets which come out of order and how to provide =
> > Anti-Replay-Service, while former does give implementation details of =
> > Antireplay service but there is a change in ESP packet format as there =
> > is no pad length field present.
> > I'm looking for a complete document which addresses all these =
> > implementation details, is there one?
> > Are there any products which have implemented stream ciphers like ARC4 =
> > or RC4 in IPsec stack?=20
> > if so, can you give details there of ?
> >
> > help in this regard is highly appreciated.
> > thanks
> > Lokesh
> >
> >
> >
> > ------=_NextPart_000_006C_01C1314A.CC8B32A0
> > Content-Type: text/html;
> > charset="Windows-1252"
> > Content-Transfer-Encoding: quoted-printable
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> > <HTML><HEAD>
> > <META content=3D"text/html; charset=3Dwindows-1252" =
> > http-equiv=3DContent-Type>
> > <META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
> > <STYLE></STYLE>
> > </HEAD>
> > <BODY bgColor=3D#ffffff>
> > <DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
> > <DIV> </DIV>
> > <DIV><FONT face=3DArial size=3D2>Is there any latest =
> > document/information regarding=20
> > use of </FONT></DIV>
> > <DIV><FONT face=3DArial size=3D2>Stream ciphers like ARC-4 or RC4 in ESP =
> > of=20
> > IPsec/Firewall Stack?.</FONT></DIV>
> > <DIV><FONT face=3DArial size=3D2>people seem to call ESP using Stream =
> > ciphers as=20
> > SC/ESP.</FONT></DIV>
> > <DIV><FONT face=3DArial size=3D2>in that case, is there going to =
> > be change in=20
> > ESP packet format or packet processing ? </FONT></DIV>
> > <DIV><FONT face=3DArial size=3D2>I happen to refer some internet drafts =
> > like=20
> > </FONT></DIV>
> > <DIV><FONT face=3DArial =
> > size=3D2><draft-caronni-esp--stream-01.txt> and=20
> > <draft-mcgrew-ipsec-scesp-02.txt> second draft proposes =
> > no=20
> > change in ESP packet format but gives no idea about how to handle =
> > packets which=20
> > come out of order and how to provide Anti-Replay-Service, while former =
> > does give=20
> > implementation details of Antireplay service but there is a change in =
> > ESP packet=20
> > format as there is no pad length field present.</FONT></DIV>
> > <DIV><FONT face=3DArial size=3D2>I'm looking for a complete document =
> > which addresses=20
> > all these implementation details, is there one?</FONT></DIV>
> > <DIV><FONT face=3DArial size=3D2>Are there any products which have =
> > implemented=20
> > stream ciphers like ARC4 or RC4 in IPsec stack? </FONT></DIV>
> > <DIV><FONT face=3DArial size=3D2>if so, can you give details there of =
> > ?</FONT></DIV>
> > <DIV> </DIV>
> > <DIV><FONT face=3DArial size=3D2>help in this regard is highly=20
> > appreciated.</FONT></DIV>
> > <DIV><FONT face=3DArial size=3D2>thanks</FONT></DIV>
> > <DIV><FONT face=3DArial size=3D2>Lokesh</FONT></DIV>
> > <DIV> </DIV>
> > <DIV> </DIV></BODY></HTML>
> >
> > ------=_NextPart_000_006C_01C1314A.CC8B32A0--
> >
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available