From owner-ipsec@lists.tislabs.com Thu May 2 06:35:25 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g42DZPa23779;
Thu, 2 May 2002 06:35:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24453
Thu, 2 May 2002 08:37:53 -0400 (EDT)
Message-Id: <200205021217.IAA17132@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;;;;@tislabs.com;;;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-revised-identity-00.txt
Date: Thu, 02 May 2002 08:17:48 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : Revised Use of Identity in Successors to IKE
Author(s) : P. Hoffman
Filename : draft-ietf-ipsec-revised-identity-00.txt
Pages :
Date : 01-May-02
There is an opportunity in successor-to-IKE to fix two major problems
that have plagued IKEv1: a misunderstanding about what is identity, and
having to send certificates every time because you don't know if the
other party already has your certificate. This proposal covers both
topics at once because it turns out that they are related.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-revised-identity-00.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-revised-identity-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-revised-identity-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: <20020501141313.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-revised-identity-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-revised-identity-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20020501141313.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Thu May 2 06:42:22 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g42DgMa23996;
Thu, 2 May 2002 06:42:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24454
Thu, 2 May 2002 08:37:53 -0400 (EDT)
Message-Id: <200205021217.IAA17116@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;;;;@tislabs.com;;;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-soi-features-00.txt
Date: Thu, 02 May 2002 08:17:43 -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 : Features of Proposed Successors to IKE
Author(s) : P. Hoffman
Filename : draft-ietf-ipsec-soi-features-00.txt
Pages :
Date : 01-May-02
This document describes many features of the proposals for the successor
to IKEv1. The purpose of the document is to help the IPsec Working Group
decide which features they want for the next protocol. The document
focuses on how those features are instantiated in two proposals, IKEv2
and JFK, but other ideas for features and options are also included.
Most of the material in this document comes from many of the authors of
the JFK and IKEv2 proposals.
This document is meant to help the Working Group choose which features
it finds important for the successor to IKE. It should be short-lived
and is not expected to become an RFC.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-soi-features-00.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-soi-features-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-soi-features-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: <20020501141303.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-soi-features-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-soi-features-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20020501141303.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Thu May 2 23:26:36 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g436QZa26139;
Thu, 2 May 2002 23:26:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA26724
Fri, 3 May 2002 01:29:53 -0400 (EDT)
Message-Id: <5.1.0.14.0.20020503105853.009f8b80@172.16.1.10>
X-Sender: lokeshnb@172.16.1.10
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 03 May 2002 11:05:52 +0530
To: ipsec@lists.tislabs.com
From: Lokesh <lokeshnb@intotoinc.com>
Subject: NAT-Traversal
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all,
I think NAT - Traversal fails if user configures IKE with Main mode and
Authentication method as
Preshared keys.
Since user don't know if there is a NAT enroute, he might configure IKE
with main mode and preshared keys, and now, if IKE tries to do
NAT-traversal or IKE detects NAT, How to proceed?
Thanks
Lokesh
From owner-ipsec@lists.tislabs.com Fri May 3 11:40:38 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Ieca17670;
Fri, 3 May 2002 11:40:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28457
Fri, 3 May 2002 13:42:25 -0400 (EDT)
Message-ID: <004501c1f2cb$9f261300$1cf22b42@mv.lucent.com>
From: "David W. Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Subject: Ikev2 IKE-SA rekey collision
Date: Fri, 3 May 2002 12:54:23 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying:
If there is a collision where both sides attempt to
rekey an IKE-SA at the same time, which one ends up
owning the child-SAs?
It is possible to avoid this condition all together by
simply using some value within the messages to determine
who will "win" the rekey. For example, the side whose
nonce has the greater value. Alternatively, one could
use the initiator of the current IKE-SA to determine
who "wins" the rekey.
David
From owner-ipsec@lists.tislabs.com Fri May 3 11:40:44 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Ieia17687;
Fri, 3 May 2002 11:40:44 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28499
Fri, 3 May 2002 13:52:30 -0400 (EDT)
Message-ID: <005201c1f2cd$2074d670$1cf22b42@mv.lucent.com>
From: "David W. Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Subject: Ikev2 Traffic Selector payload
Date: Fri, 3 May 2002 13:05:34 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Regarding draft-ietf-ipsec-ikev2-02.txt section 2.9:
"The Responder is allowed to narrow the choices
by selecting a subset of the traffic..."
How do we avoid the situation where the reduced set
does not encompass the selectors of the original packet
on the initiator which started the negotiation?
David
From owner-ipsec@lists.tislabs.com Fri May 3 14:30:49 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g43LUma23078;
Fri, 3 May 2002 14:30:49 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28960
Fri, 3 May 2002 16:41:59 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05100319b8f8a6a23307@[128.89.88.34]>
In-Reply-To: <OFCEF14CC1.BF19DE52-ONC1256BAB.00451B3A@net.alcatel.be>
References: <OFCEF14CC1.BF19DE52-ONC1256BAB.00451B3A@net.alcatel.be>
Date: Fri, 3 May 2002 16:44:03 -0400
To: annelies.van_moffaert@alcatel.be
From: Stephen Kent <kent@bbn.com>
Subject: Re: Please send me your GSEC presenation slides
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 2:51 PM +0200 4/30/02, annelies.van_moffaert@alcatel.be wrote:
>Hi Steven and all,
>
>I read the new IP Authentication Header I-D and I have a small question or
>remark about the multicast SAs. I saw that these are identified by the
>destination IP address
>and the SPI value and optionally, the protocol ID.
>I'm not sure whether this rules out all possible ambiguity for SSM. For SSM
>the IP destination address does not need to be unique (if I remember
>correctly). A group session is in SSM identified by the pair (Source IP,
>Destination IP) and it is possible that 2 different sources choose the same
>SSM group address as Destination IP address. The group controller of each
>will pick independently an SPI number. It's of course very unlikely but I
>think that it is then strictly speaking possible to have the same (SPI,
>Destination IP) pair for 2 different SSM sessions. In this case the
>receiver cannot differentiate between two different SAs since they have the
>same identification pair (Destion IP, SPI). Is this correct or did I
>overlook something?
>
>Kind regards,
> Lies
Lies,
I am not familiar with the spec for SSM, but from an IP perspective
it is not generally feasible to have two distinct multicast groups
with the same IP layer address, as then there would be ambiguity in
terms of routing.
Steve
From owner-ipsec@lists.tislabs.com Fri May 3 18:10:00 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4419xa27964;
Fri, 3 May 2002 18:09:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29456
Fri, 3 May 2002 20:16:35 -0400 (EDT)
Message-Id: <200205040028.UAA29790@bcn.East.Sun.COM>
Date: Fri, 3 May 2002 20:28:58 -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: Ikev2 Traffic Selector payload
To: ipsec@lists.tislabs.com, dfaucher@lucent.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: TX0tmci7U966qsSu1mYpEQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>From my reading of the policy database, this wouldn't happen. Bob might
narrow the choices in one of two cases:
a) his policy excludes the range of the original packet, in which
case Alice can't forward this packet to Bob no matter what she does, or
b) his policy says only a single source/destination pair allowed on any SA,
in which case he responds with notification #34-single-pair-required
Radia
****************
From: "David W. Faucher" <dfaucher@lucent.com>
Regarding draft-ietf-ipsec-ikev2-02.txt section 2.9:
"The Responder is allowed to narrow the choices
by selecting a subset of the traffic..."
How do we avoid the situation where the reduced set
does not encompass the selectors of the original packet
on the initiator which started the negotiation?
David
From owner-ipsec@lists.tislabs.com Fri May 3 18:24:01 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g441O1a28367;
Fri, 3 May 2002 18:24:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29407
Fri, 3 May 2002 20:09:29 -0400 (EDT)
Message-Id: <200205040021.UAA29773@bcn.East.Sun.COM>
Date: Fri, 3 May 2002 20:21:42 -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: Ikev2 IKE-SA rekey collision
To: ipsec@lists.tislabs.com, dfaucher@lucent.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: myObu6Xixd2doljyLG3Pzw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Actually, one could have the same problem you point out, on establishment of
the original IKE-SA. The spec does say that one should randomize
the rekeying time to minimize the likelihood of duplicate
SA's resulting from rekeying. I think your suggestion
would work...if you notice you have duplicate SAs, then drop
the one with the larger initiator nonce. With that rule, it also
works if there's a collision on the initial IKE-SA (where there
isn't a unique initiator, since each of the duplicate SAs would be initiated
by one end).
Radia
David Faucher said:
Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying:
If there is a collision where both sides attempt to
rekey an IKE-SA at the same time, which one ends up
owning the child-SAs?
It is possible to avoid this condition all together by
simply using some value within the messages to determine
who will "win" the rekey. For example, the side whose
nonce has the greater value. Alternatively, one could
use the initiator of the current IKE-SA to determine
who "wins" the rekey.
David
From owner-ipsec@lists.tislabs.com Fri May 3 22:51:10 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g445pAa02842;
Fri, 3 May 2002 22:51:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA29899
Sat, 4 May 2002 00:57:56 -0400 (EDT)
Message-ID: <001401c1f32a$01f194b0$b1323ac3@trustworks.com>
From: "Valery Smyslov" <svan@trustworks.com>
To: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>,
<ipsec@lists.tislabs.com>, <dfaucher@lucent.com>
References: <200205040028.UAA29790@bcn.East.Sun.COM>
Subject: Re: Ikev2 Traffic Selector payload
Date: Sat, 4 May 2002 09:10:26 +0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
----- Original Message -----
From: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>
To: <ipsec@lists.tislabs.com>; <dfaucher@lucent.com>
Sent: Saturday, May 04, 2002 4:28 AM
Subject: Re: Ikev2 Traffic Selector payload
> From my reading of the policy database, this wouldn't happen. Bob might
> narrow the choices in one of two cases:
> a) his policy excludes the range of the original packet, in which
> case Alice can't forward this packet to Bob no matter what she does, or
What if initiator's proposal consists of one range, while responder's
SPD requires this range to be splitted into two (or more) each protected
by separate SA? For example:
Initiator's SPD: 1.1.1.1-1.1.1.100
Responder's SPD: 1.1.1.1-1.1.1.50 & 1.1.1.51-1.1.1.100
In this case responder cannot narrow initiator's proposal
because he/she doesn't know actual packet selector.
> b) his policy says only a single source/destination pair allowed on any
SA,
> in which case he responds with notification #34-single-pair-required
I think this is not very efficient way to require new negotiation (possibly
including
new DH computation) for this case.
I think the better way would be to require for initiator to always include
actual packet selector in his/her proposal. The simplest way to do it
(without any changes in the protocol format) would be to simply state in the
document,
that the very first TS in initiator's TS payload MUST be selector of the
packet that triggered this negotiation. This TS either MUST be encompassed
in the (possibly narrowed) responder's TS payload or responder MUST
return an error notification NO-PROPOSAL-CHOSEN.
This actual packet TS will help responder to correctly choose (narrow) its
TS.
The cost is that initiator's message will be greater by 12 bytes (one
TS with single address). I think it is tolerable.
Regards,
Valery Smyslov.
> Radia
> ****************
> From: "David W. Faucher" <dfaucher@lucent.com>
>
> Regarding draft-ietf-ipsec-ikev2-02.txt section 2.9:
>
> "The Responder is allowed to narrow the choices
> by selecting a subset of the traffic..."
>
> How do we avoid the situation where the reduced set
> does not encompass the selectors of the original packet
> on the initiator which started the negotiation?
>
> David
>
>
>
From owner-ipsec@lists.tislabs.com Sat May 4 12:54:16 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g44JsFa21096;
Sat, 4 May 2002 12:54:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01254
Sat, 4 May 2002 14:58:37 -0400 (EDT)
Date: Sat, 4 May 2002 12:10:38 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
cc: <ipsec@lists.tislabs.com>, <dfaucher@lucent.com>
Subject: Re: Ikev2 IKE-SA rekey collision
In-Reply-To: <200205040021.UAA29773@bcn.East.Sun.COM>
Message-ID: <Pine.LNX.4.33.0205041209110.23939-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 Fri, 3 May 2002, Radia Perlman - Boston Center for Networking wrote:
> Actually, one could have the same problem you point out, on establishment of
> the original IKE-SA. The spec does say that one should randomize
> the rekeying time to minimize the likelihood of duplicate
> SA's resulting from rekeying. I think your suggestion
> would work...
I'm all for writing something like this into the spec. While it
trivial to do and implement, it's impossible to retrofit without
standard-support, since iut'll wind up being non-interoperable, if
everyone does it differently (one picks the larger nonce, the other
the smaller nonce, and you wind up with nothing).
Any objections to writing this into the standard?
jan
>if you notice you have duplicate SAs, then drop
> the one with the larger initiator nonce. With that rule, it also
> works if there's a collision on the initial IKE-SA (where there
> isn't a unique initiator, since each of the duplicate SAs would be initiated
> by one end).
>
> Radia
>
> David Faucher said:
> Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying:
>
> If there is a collision where both sides attempt to
> rekey an IKE-SA at the same time, which one ends up
> owning the child-SAs?
>
> It is possible to avoid this condition all together by
> simply using some value within the messages to determine
> who will "win" the rekey. For example, the side whose
> nonce has the greater value. Alternatively, one could
> use the initiator of the current IKE-SA to determine
> who "wins" the rekey.
>
> David
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
http://www.eff.org/cafe
From owner-ipsec@lists.tislabs.com Sat May 4 18:45:14 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g451jDa29501;
Sat, 4 May 2002 18:45:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01837
Sat, 4 May 2002 20:51:00 -0400 (EDT)
Message-Id: <4.3.2.7.1.20020504175712.00ad7f00@golf.cpgdesign.analog.com>
X-Sender: ramana@golf.cpgdesign.analog.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 04 May 2002 18:01:26 -0700
To: Jan Vilhuber <vilhuber@cisco.com>,
Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
From: Ramana Yarlagadda <ramana.yarlagadda@analog.com>
Subject: Re: Ikev2 IKE-SA rekey collision
Cc: <ipsec@lists.tislabs.com>, <dfaucher@lucent.com>
In-Reply-To: <Pine.LNX.4.33.0205041209110.23939-100000@janpc-home.cisco.
com>
References: <200205040021.UAA29773@bcn.East.Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
> > Actually, one could have the same problem you point out, on
> establishment of
> > the original IKE-SA. The spec does say that one should randomize
> > the rekeying time to minimize the likelihood of duplicate
> > SA's resulting from rekeying. I think your suggestion
> > would work...
>
>I'm all for writing something like this into the spec. While it
>trivial to do and implement, it's impossible to retrofit without
>standard-support, since iut'll wind up being non-interoperable, if
>everyone does it differently (one picks the larger nonce, the other
>the smaller nonce, and you wind up with nothing).
>
>Any objections to writing this into the standard?
>
I think it is a good idea to make it standard. otherwise the re-keying
is a major interoperable issue, if we try to avoid duplicate SAs. These
duplicate SAs have some effect from the memory requirements point
of view.
> >if you notice you have duplicate SAs, then drop
> > the one with the larger initiator nonce. With that rule, it also
> > works if there's a collision on the initial IKE-SA (where there
> > isn't a unique initiator, since each of the duplicate SAs would be
> initiated
> > by one end).
> >
> >
> > David Faucher said:
> > Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying:
> >
> > If there is a collision where both sides attempt to
> > rekey an IKE-SA at the same time, which one ends up
> > owning the child-SAs?
> >
> > It is possible to avoid this condition all together by
> > simply using some value within the messages to determine
> > who will "win" the rekey. For example, the side whose
> > nonce has the greater value. Alternatively, one could
> > use the initiator of the current IKE-SA to determine
> > who "wins" the rekey.
> >
> > David
> >
> >
>
> --
>Jan Vilhuber vilhuber@cisco.com
>Cisco Systems, San Jose (408) 527-0847
>
>http://www.eff.org/cafe
From owner-ipsec@lists.tislabs.com Sun May 5 09:11:11 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g45GB9L19274;
Sun, 5 May 2002 09:11:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02881
Sun, 5 May 2002 10:51:22 -0400 (EDT)
Message-ID: <3CD4CB14.EF621859@frohwein.xs4all.nl>
Date: Sun, 05 May 2002 08:03:00 +0200
From: rob frohwein <rob@frohwein.xs4all.nl>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: PF_KEY socket code examples
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi ,
Does anyone maybe has some code examples that demonstrate
how to specify and read SPDs and SAa via socket( ....,PFKEY) ??
greetings
Rob Frohwein
From owner-ipsec@lists.tislabs.com Sun May 5 19:38:43 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g462chL01148;
Sun, 5 May 2002 19:38:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03947
Sun, 5 May 2002 21:38:12 -0400 (EDT)
Message-Id: <200205060144.JAA12727@cwcsun41.cwc.nus.edu.sg>
Content-Type: text/plain;
charset="utf-8"
From: Parijat Mishra <parijat@cwc.nus.edu.sg>
Reply-To: parijat@cwc.nus.edu.sg
Organization: CWC
To: rob frohwein <rob@frohwein.xs4all.nl>, ipsec@lists.tislabs.com
Subject: Re: PF_KEY socket code examples
Date: Mon, 6 May 2002 09:45:51 +0800
X-Mailer: KMail [version 1.3.2]
References: <3CD4CB14.EF621859@frohwein.xs4all.nl>
In-Reply-To: <3CD4CB14.EF621859@frohwein.xs4all.nl>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Sunday 05 May 2002 14:03, rob frohwein wrote:
> Does anyone maybe has some code examples that demonstrate
> how to specify and read SPDs and SAa via socket( ....,PFKEY) ??
The PFKEY interface as specified in RFC2367 only allows one to
read/write to the SADB, not SPD. However, some IPSec implementations
have created extensions to allow the specification of SPD entries as
well.
In any case, good starting points would be the FreeS/WAN project
(www.freeswan.org) and the IPSec implementation withing the USAGI
project (www.linux-ipv6.org). Both contain extensions to the base
PFKEY interface to deal with SPDs, SA groups and stuff, and differ
from each other. Another place should be the KAME project's
implementation -- but I am not a BSD user and do not know much about
it.
--
Sincerely,
Parijat Mishra
R & D Engineer,
Institute for Communications Research
Tel: (65)68709353
From owner-ipsec@lists.tislabs.com Mon May 6 06:34:47 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g46DYkL16348;
Mon, 6 May 2002 06:34:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05482
Mon, 6 May 2002 08:39:10 -0400 (EDT)
Message-ID: <001301c1f4fc$d60c70c0$1cf22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>,
<ipsec@lists.tislabs.com>
References: <200205040021.UAA29773@bcn.East.Sun.COM>
Subject: Re: Ikev2 IKE-SA rekey collision
Date: Mon, 6 May 2002 07:52:08 -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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I had thought about collisions on initial establishment but
came to the conclusion that this is not a problem and may even
be desired.
- collision on initial establishment don't have the problems
of a rekey collision because there are no child-SAs present.
- two endpoints may choose to have logically separate IKE-SAs
for different identities.
David
----- Original Message -----
From: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@Sun.COM>
To: <ipsec@lists.tislabs.com>; <dfaucher@lucent.com>
Sent: Friday, May 03, 2002 7:21 PM
Subject: Re: Ikev2 IKE-SA rekey collision
| Actually, one could have the same problem you point out, on establishment
of
| the original IKE-SA. The spec does say that one should randomize
| the rekeying time to minimize the likelihood of duplicate
| SA's resulting from rekeying. I think your suggestion
| would work...if you notice you have duplicate SAs, then drop
| the one with the larger initiator nonce. With that rule, it also
| works if there's a collision on the initial IKE-SA (where there
| isn't a unique initiator, since each of the duplicate SAs would be
initiated
| by one end).
|
| Radia
|
| David Faucher said:
| Regarding draft-ietf-ipsec-ikev2-02.tx IKE-SA rekeying:
|
| If there is a collision where both sides attempt to
| rekey an IKE-SA at the same time, which one ends up
| owning the child-SAs?
|
| It is possible to avoid this condition all together by
| simply using some value within the messages to determine
| who will "win" the rekey. For example, the side whose
| nonce has the greater value. Alternatively, one could
| use the initiator of the current IKE-SA to determine
| who "wins" the rekey.
|
| David
|
|
From owner-ipsec@lists.tislabs.com Mon May 6 06:42:27 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g46DgQL16543;
Mon, 6 May 2002 06:42:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05553
Mon, 6 May 2002 08:51:14 -0400 (EDT)
Message-ID: <004601c1f4fe$694e3c50$1cf22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: "Valery Smyslov" <svan@trustworks.com>,
"Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>,
<ipsec@lists.tislabs.com>
References: <200205040028.UAA29790@bcn.East.Sun.COM> <001401c1f32a$01f194b0$b1323ac3@trustworks.com>
Subject: Re: Ikev2 Traffic Selector payload
Date: Mon, 6 May 2002 08:03:24 -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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I agree with this, 12 bytes is a small price to pay
for better interoperability.
----- Original Message -----
From: "Valery Smyslov" <svan@trustworks.com>
To: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>;
<ipsec@lists.tislabs.com>; <dfaucher@lucent.com>
Sent: Saturday, May 04, 2002 12:10 AM
Subject: Re: Ikev2 Traffic Selector payload
| ----- Original Message -----
| From: "Radia Perlman - Boston Center for Networking"
<Radia.Perlman@sun.com>
| To: <ipsec@lists.tislabs.com>; <dfaucher@lucent.com>
| Sent: Saturday, May 04, 2002 4:28 AM
| Subject: Re: Ikev2 Traffic Selector payload
|
|
| > From my reading of the policy database, this wouldn't happen. Bob might
| > narrow the choices in one of two cases:
| > a) his policy excludes the range of the original packet, in which
| > case Alice can't forward this packet to Bob no matter what she does, or
|
| What if initiator's proposal consists of one range, while responder's
| SPD requires this range to be splitted into two (or more) each protected
| by separate SA? For example:
|
| Initiator's SPD: 1.1.1.1-1.1.1.100
| Responder's SPD: 1.1.1.1-1.1.1.50 & 1.1.1.51-1.1.1.100
|
| In this case responder cannot narrow initiator's proposal
| because he/she doesn't know actual packet selector.
|
| > b) his policy says only a single source/destination pair allowed on any
| SA,
| > in which case he responds with notification #34-single-pair-required
|
| I think this is not very efficient way to require new negotiation
(possibly
| including
| new DH computation) for this case.
|
| I think the better way would be to require for initiator to always include
| actual packet selector in his/her proposal. The simplest way to do it
| (without any changes in the protocol format) would be to simply state in
the
| document,
| that the very first TS in initiator's TS payload MUST be selector of the
| packet that triggered this negotiation. This TS either MUST be encompassed
| in the (possibly narrowed) responder's TS payload or responder MUST
| return an error notification NO-PROPOSAL-CHOSEN.
|
| This actual packet TS will help responder to correctly choose (narrow) its
| TS.
| The cost is that initiator's message will be greater by 12 bytes (one
| TS with single address). I think it is tolerable.
|
| Regards,
| Valery Smyslov.
|
|
| > Radia
| > ****************
| > From: "David W. Faucher" <dfaucher@lucent.com>
| >
| > Regarding draft-ietf-ipsec-ikev2-02.txt section 2.9:
| >
| > "The Responder is allowed to narrow the choices
| > by selecting a subset of the traffic..."
| >
| > How do we avoid the situation where the reduced set
| > does not encompass the selectors of the original packet
| > on the initiator which started the negotiation?
| >
| > David
| >
| >
| >
|
From owner-ipsec@lists.tislabs.com Mon May 6 08:47:33 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g46FlWL20152;
Mon, 6 May 2002 08:47:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05946
Mon, 6 May 2002 10:57:40 -0400 (EDT)
From: "Jayant Shukla" <jshukla@trlokom.com>
To: "'Lokesh'" <lokeshnb@intotoinc.com>, <ipsec@lists.tislabs.com>
Subject: RE: NAT-Traversal
Date: Mon, 6 May 2002 08:06:37 -0700
Message-ID: <012a01c1f50f$9e9f7750$0100a8c0@trlhpc1>
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, Build 10.0.2627
Importance: Normal
In-Reply-To: <5.1.0.14.0.20020503105853.009f8b80@172.16.1.10>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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 Lokesh
> Hi all,
> I think NAT - Traversal fails if user configures IKE with Main mode
and
> Authentication method as
> Preshared keys.
Yes it is a known problem with NAT-T and it cannot be fixed because the
IP addresses are sent after the authentication is done. There is an
issue with certificates as well because of the IKE packet fragmentation.
My personal opinion is that the NAT-T solution should be abandoned as it
is flawed. Over the last two years several problems have been pointed
out and the NAT-T ID keeps changing. A short while ago it was heavily
criticized (after it made it to last call) and has since been modified
(again)! Even so, the latest draft has several problems.
> How to proceed?
We have a working and tested solution that overcomes the pre-shared key
problem as well as the certificate problem. We are going to show our
solution at N+I 2002, 7th -9th May.
Nobody seems to notice, but NAT traversal can be achieved without
modifying IKE and without tunneling IPsec data through the IKE port. Not
relying on IKE for NAT Traversal makes it a much more general solution
and can be used elsewhere as well.
Plus, there are several other advantages like true end-to-end security
and there is no need for nested tunnels. The same solution can be
applied to IP and mobile IP networks. Try that with NAT-T!
Regards,
Jayant
Booth # 7981, N+I Las Vegas 2002
www.trlokom.com
From owner-ipsec@lists.tislabs.com Mon May 6 09:46:15 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g46GkFL21629;
Mon, 6 May 2002 09:46:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06153
Mon, 6 May 2002 12:03:03 -0400 (EDT)
Message-Id: <200205061628.SAA19666@malraux.matranet.com>
Date: Mon, 06 May 2002 18:15:09 +0200
From: Laurent Fabre <fabre@matranet.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010924
X-Accept-Language: en-us
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: IKE and Legacy A.S
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
I'm currently studying the support of legacy authentication system
for our products. During my researches i came accross the following drafts :
- draft-zegman-ike-hybrid-auth
- draft-beaulieu-ike-xauth
- draft-ietf-ipsra-pic
Hopefully these are the only proposals for legacy AS support,
only the third seems to be revelant as the two others are out-of-date,
if not please correct me.
Did anyone try to use PIC/EAP in his IKE implementation and would
give feedback ?
Best regards,
--
#--------------------------------------------#
# Laurent Fabre #
# fabre@matranet.com # /\ ASCII ribbon
# EADS, Matranet Product Group # \/ campaign
# # /\ against
# # / \ HTML email
# #
#--------------------------------------------#
From owner-ipsec@lists.tislabs.com Mon May 6 11:04:52 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g46I4qL23814;
Mon, 6 May 2002 11:04:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06435
Mon, 6 May 2002 13:09:20 -0400 (EDT)
Date: Mon, 6 May 2002 10:31:12 -0700 (PDT)
From: Srinivasa Addepalli <srao@intotoinc.com>
To: Laurent Fabre <fabre@matranet.com>
cc: ipsec@lists.tislabs.com
Subject: Re: IKE and Legacy A.S
In-Reply-To: <200205061628.SAA19666@malraux.matranet.com>
Message-ID: <Pine.LNX.4.21.0205061029240.4788-100000@intotoinc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
ISAKMP configuration method and XAUTH drafts are implemented
by good number of vendors to provide remote access and legacy
authentication. You can find these standards in www.vpnc.org.
Srini
On Mon, 6 May 2002, Laurent Fabre wrote:
>
> Hi,
>
> I'm currently studying the support of legacy authentication system
> for our products. During my researches i came accross the following drafts :
>
> - draft-zegman-ike-hybrid-auth
> - draft-beaulieu-ike-xauth
> - draft-ietf-ipsra-pic
>
> Hopefully these are the only proposals for legacy AS support,
> only the third seems to be revelant as the two others are out-of-date,
> if not please correct me.
>
> Did anyone try to use PIC/EAP in his IKE implementation and would
> give feedback ?
>
> Best regards,
>
>
--
Srinivasa Rao Addepalli
Intoto Inc.
3160, De La Cruz Blvd #100
Santa Clara, CA
USA
Ph: 408-844-0480 x317
From owner-ipsec@lists.tislabs.com Mon May 6 12:00:49 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g46J0mL25223;
Mon, 6 May 2002 12:00:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06653
Mon, 6 May 2002 14:16:48 -0400 (EDT)
Message-Id: <200205061815.g46IF7P17052@trpz.com>
To: Laurent Fabre <fabre@matranet.com>
cc: ipsec@lists.tislabs.com
Subject: Re: IKE and Legacy A.S
In-Reply-To: Your message of "Mon, 06 May 2002 18:15:09 +0200."
<200205061628.SAA19666@malraux.matranet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <832.1020708702.1@tibernian.com>
Date: Mon, 06 May 2002 11:11:42 -0700
From: Dan Harkins <dharkins@tibernian.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
There's another which is also out-of-date, CRACK. The expired draft
follows. It's been implemented in the SymbianOS.
The CRACK exchange is very similar to the PIC exchange, in fact if
you put them down on paper payload for payload, message for message,
you'd see they are almost identical. The difference is that CRACK is
politically incorrect while PIC is politically correct. But to pay the
price for political correctness you must go to the trouble of doing
a mutually authenticated Diffie-Hellman exchange, then throw away all
that authenticated and shared secret state, and do another mutually
authenticated Diffie-Hellman exchange. CRACK just uses the first set
of mutually authenticated secret state to form an IKE SA.
Back when we were discussing protocol costs I posted this:
Protocol Initiator Responder Latency
------------------------------------------------
PIC+IKE 1 signature 2 signatures 6.5-9 RTT + 1-2 RTs to legacy server
2 verifies 1 verify
2 DH agree 2 DH agree
That's 22 messages worst case (DoS protection, token for legacy authentication
is out-of-sync) or 14 messages best case. I haven't heard stories from the
field about use of PIC but I'd be surprised if people are willing to pay
that price just to use a legacy authentication method, especially if there
are more efficient ways-- albeit one's that are frowned upon by those weilding
political clubs^H^H^H^H^Hclout.
I like PIC, especially its use of EAP instead of the roll-your-own method
CRACK does. It's a nice way to get a certificate for a client and wean a
corporation off token cards and onto a CA. It's just not particularly well
suited for people that want to use an existing legacy infrastructure for
authentication and who have no intention of going to client certificates any
time soon.
Dan.
On Mon, 06 May 2002 18:15:09 +0200 you wrote
>
> Hi,
>
> I'm currently studying the support of legacy authentication system
> for our products. During my researches i came accross the following drafts :
>
> - draft-zegman-ike-hybrid-auth
> - draft-beaulieu-ike-xauth
> - draft-ietf-ipsra-pic
>
> Hopefully these are the only proposals for legacy AS support,
> only the third seems to be revelant as the two others are out-of-date,
> if not please correct me.
>
> Did anyone try to use PIC/EAP in his IKE implementation and would
> give feedback ?
>
> Best regards,
>
> --
> #--------------------------------------------#
> # Laurent Fabre #
> # fabre@matranet.com # /\ ASCII ribbon
> # EADS, Matranet Product Group # \/ campaign
> # # /\ against
> # # / \ HTML email
> # #
> #--------------------------------------------#
>
---------------------------- snip snip ---------------------------------
Network Working Group D Harkins, D Piper
INTERNET-DRAFT Nokia
draft-ieft-ipsra-crack-01.txt July 14, 2000
IKE Challenge/Response for Authenticated Cryptographic Keys (Revised)
<draft-ietf-ipsra-crack-01.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and working groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet Draft, please check the
"1id-abstracts.txt" listing contained in the Internet Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Australia), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Table of Contents
1. Abstract......................................................2
2. Terms and Definitions.........................................2
2.1 Requirements Terminology and Notation.........................2
2.2 IKE Exchange Integration......................................2
2.3 IKE Authentication Method Definition..........................3
2.4 The Challenge/Response Payload (CHRE).........................3
2.5 LAM Types.....................................................4
2.6 LAM Attributes................................................5
3. The Protocol..................................................6
3.1 IKE Challenge/Response Abstract Representation................7
3.2 IKE Challenge/Response Failures...............................8
4. Legacy Authentication Method (LAM) Profiles...................9
4.1 LAM Profiles: Password........................................10
4.2 LAM Profiles: One-Time Password...............................11
4.3 LAM Profiles: Challenge/Response..............................12
4.4 LAM Profiles: SecurID.........................................15
Harkins, Piper Expires in 6 months [Page 1]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
4.5 LAM Profile Matrix............................................17
5. The IKE Challenge/Response Vendor ID Signature................17
6. Security Considerations.......................................18
Acknowledgments...................................................18
References........................................................18
Authors' Address..................................................19
1. Abstract
This memo describes a new IKE authentication method ([HC98]) which
provides for mutual authentication when one side is using a legacy-
based secret-key authentication technique such as RADIUS, SecurID, or
OTP and the other side is using public-key authentication, with
optional digital certificates.
The generic protocol described herein is an open-ended IKE Main Mode
exchange ([HC98]). The result of this exchange is a mutually
authenticated IKE security association ([HC98]). The keys that are
derived from this SA are also authenticated and thereby convey this
state to any SA's created from it for any other security service,
such as IPSec [Pip98].
2. Terms and Definitions
2.1 Requirements Terminology and Notation
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described
in [Bra96].
The notation of this memo is similar to [HC98]. Like [HC98] it uses
payloads defined in [MSST98]. The notation for the new payload is:
CHRE is the newly defined "challenge/response payload"
To prevent confusion in the protocol diagrams (e.g. between the
Diffie-Hellman public values), the client's payloads are sometimes
post-fixed with "i", for "initiator", and the gateway's payloads are
sometimes post-fixed with "r", for "responder".
2.2 IKE Exchange Integration
This protocol is motivated by mobile IPSec-enabled clients who desire
to use legacy authentication techniques instead of digital
certificates. Therefore the parties to this exchange are a "client"
and a "gateway". The client is always the initiator of this exchange
and is assumed to be coming from an IP address that cannot be known a
priori by the gateway.
Harkins, Piper Expires in 6 months [Page 2]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
The protocol described in this memo is an IKE exchange using a newly
defined IKE authentication method. All other attributes and their
status from [HC98] are unaffected. Unless otherwise overridden by a
specific requirement in this memo, all requirements in [HC98] exist
in this memo.
2.3 IKE Authentication Method Definition
The following new IKE authentication method value is defined for
CRACK from the IKE private-use space (see Section 6):
Authentication Mode Value
------------------- -----
IKE_A_CRACK 128
2.4 The Challenge/Response Payload (CHRE)
This draft requires a new payload to carry new information unique to
this exchange. The Challenge/Response payload is used to convey a
challenge from the gateway to the client and is used by the client to
respond to a challenge from the gateway. The Challenge/Response
payload contains attributes denoting specific information conveyed
from the client to the gateway and back. The actual legacy
authentication method will determine the contents of this payload at
the various points in the exchange.
This payload consists of the ISAKMP generic header ([MSST98]) and a
payload-specific body whose length is not fixed. The "Payload
Length" in the generic header includes the length of the header
itself. All fields labeled "RESERVED" MUST be filled with zero (0)
prior to sending and each party to the exchange MUST verify that
value on all payloads it is sent.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LAM Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ generic challenge/response blob ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The payload type for this payload is 128, which is taken from the
ISAKMP private use space (see Section 6). The body of this payload
may also contain attributes used to convey authentication information
(see Section 4.2).
Harkins, Piper Expires in 6 months [Page 3]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
The LAM Type field denotes the legacy authentication method (see
Section 5) associated with the exchange. The LAM Type must be set in
all CHRE payloads in an exchange. The LAM Type is selected by the
initiator (client) and MUST be set in every CHRE payload to the same
value throughout the exchange.
2.5 LAM Types
Different legacy authentication methods are denoted by unique LAM
type identifiers in the Challenge/Response payloads. The legacy
authentication methods defined for this protocol are as follows:
LAM Type Identifier Value
------------------- -----------
CRACK_PASSWORD 1
CRACK_OTP 2
CRACK_CHALLENGE_RESPONSE 3
CRACK_SECURID 4
<reserved> 5-32767
<private use> 32768-65535
If the gateway is not configured to support the requested LAM type while
processing the client's first CHRE payload, the gateway MUST terminate
the exchange and MUST respond with an ISAKMP Notify (PROPOSAL-NOT-
CHOSEN).
A conformant gateway MUST support at least one of the specified LAM
Types. A gateway MAY support more than one LAM Type and it's assumed
that the choice of which LAM Types are supported is implementation
specific and determined from local policy configuration, perhaps on a
per-user basis based on the content of the first CHRE payload and its
associated attributes.
CRACK_PASSWORD specifies a simple username/password mechanism. It's
used for any simple host-based password or one-way hash mechanism.
It also useful for proxy-based password authentication schemes, like
TACACS and RADIUS.
CRACK_OTP specifies that a one-time password mechanism. It's useful
for the S/KEY [Hal95] and OTP [HM96] schemes.
CRACK_CHALLENGE_RESPONSE specifies a token-based challenge/response
mechanism. It's useful for a wide variety of cryptographic tokens,
typically based on DES.
CRACK_SECURID specifies a SecurID mechanism. It's useful for the RSA
SecurID system. The CRACK_SECURID closely resembles
CRACK_CHALLENGE_RESPONSE.
Harkins, Piper Expires in 6 months [Page 4]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
2.6 LAM Attributes
The Challenge/Response payload contains attributes used to convey
information between the client and the gateway authenticating the
client. These are standard [MSST98] attribute payloads associated
with the Challenge/Response payloads. The following LAM attributes
are valid:
Attribute Value Type
---------- ------- ------
CRACK_T_USERNAME 16390 variable
CRACK_T_SECRET 16391 variable
CRACK_T_DOMAIN 16392 variable
CRACK_T_PIN 16393 variable
CRACK_T_CHALLENGE 16394 variable
CRACK_T_MESSAGE 16395 variable
CRACK_T_FIN 16396 basic
CRACK_T_USERNAME specifies the client user identity that's requesting
authentication. The syntax and format of CRACK_T_USERNAME is
specific to each LAM type.
CRACK_T_SECRET specifies secret information the client sends in an
attempt to authenticate, for instance a password or passcode. The
syntax and format of CRACK_T_SECRET is specific to each LAM type.
CRACK_T_DOMAIN specifies the domain or realm the client is requesting
authentication credentials within. The syntax and format of
CRACK_T_DOMAIN is specific to each LAM type.
CRACK_T_PIN specifies the client's PIN. The syntax and format of
CRACK_PIN is specific to each LAM type.
CRACK_T_CHALLENGE specifies any challenge the gateway may choose to
issue to the client. The syntax and format of CRACK_T_CHALLENGE is
specific to each LAM type.
CRACK_T_MESSAGE specifies an ASCII string to be displayed to the user
upon receipt of the corresponding CHRE payload. CRACK_T_MESSAGE is
valid for all LAM types. Upon receipt, the contents of
CRACK_T_MESSAGES SHOULD be displayed to the client user, typically
along with the CHRE challenge.
CRACK_T_FIN specifies the server's response to the authentication
exchange at all critical decision points specific to each LAM type.
The following table defines the values for CRACK_T_FIN:
Harkins, Piper Expires in 6 months [Page 5]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
Finish Types Value
------------ -----
RESERVED 0
CRACK_FIN_SUCCESS 1
CRACK_FIN_MORE 2
CRACK_FIN_SUCCESS indicates the gateway has successfully
authenticated the client. This value successfully terminates the
CRACK exchange. This value is legal for all LAM types.
CRACK_FIN_MORE indicates the gateway requires an additional round-
trip to authentication the client. This is only legal for LAM
types which define its use. It MUST NOT be used unless defined in
the corresponding LAM profile.
3. The Protocol
This protocol uses digital signatures and proof of possession of a
legacy secret to bind each party to the exchange as well as to the
keying material that results from the exchange. This trust is
acquired differently for the client and the gateway. The client
trusts the gateway's public key either because it came from a
certificate which is signed by a trusted certification authority or
because the client trusts it by some out-of-band mechanism (for
instance it is loaded into his policy store prior to hitting the
road). The gateway trusts the client because the client has
successfully authenticated himself using a legacy authentication
method through a secure channel.
The reader should note that the channel in which the client's legacy
proof is transmitted is secure from a man-in-the-middle attack due to
the fact that the Diffie-Hellman public values and the attributes
from the accepted offer, among other things, are signed. As in
[HC98], the signature uses a pseudo-random function (prf), which is
either negotiated in the initial SA payload or is the HMAC version
[KBC96] of a hash function, over state from the exchange and keyed
with "SKEYID".
The "SKEYID*" secret state is generated according to the rules for
digital signature authentication of [HC98]. In other words.
SKEYID = prf(Ni_b | Nr_b, g^xy)
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
The data portion of the pseudo-random function consists of the
clients's Diffie-Hellman public value concatenated with the gateway's
Harkins, Piper Expires in 6 months [Page 6]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
Diffie-Hellman public value concatenated with the client's cookie
(from the [MSST98] header) concatenated with the gateway's cookie
concatenated with the body of the client's initial SA offer.
Graphically, the signature is over:
digest = prf (SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b)
Generally the pseudo-random function is the [KBC96] version of the
negotiated hash function but this can be overridden if the signature
algorithm is tied to a particular hash function (e.g. [DSS]) in which
case the pseudo-random function will the the [KBC96] version of the
hash function tied to the signature method.
The data being signed includes any padding prepended to the body of
the payloads (for alignment to the length of the prime modulus) but
does not include the ISAKMP header from any payload. The client MUST
verify the signature. If the signature is not valid the exchange MUST
be terminated by the client.
First, we describe the protocol abstractly using the aforementioned
notation and then separate profiles are defined for each of the
various LAM types.
3.1 IKE Challenge/Response Abstract Representation
The IKE Challenge/Response protocol is abstractly defined as follows:
Main Mode using CRACK is defined as
Client (I) Gateway (R)
----------- -----------
HDR, SAi, --->
<--- HDR, SAr
HDR, KEi, Ni,
[, CERTREQ] --->
<--- HDR, [CERT, ] KEr,
Nr, SIG
HDR*, CHRE --->
<--- HDR*, CHRE
[ HDR*, CHRE --->
<--- HDR*, CHRE ]
Harkins, Piper Expires in 6 months [Page 7]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
Aggressive Mode using CRACK is defined as
Client (I) Gateway (R)
----------- -----------
HDR, SAi, KEi, Ni
[, CERTREQ] --->
<--- HDR, SAr, [CERT, ] KEr,
Nr, SIG
HDR*, CHRE --->
<--- HDR*, CHRE
[ HDR*, CHRE --->
<--- HDR*, CHRE ]
Where SIG is a digital signature of the aforementioned information.
Any ambiguity about which key was used can be dispelled by optionally
sending a certificate payload which indicates the public key that
should be used to verify the signature.
Note that the number of messages in an exchange is not fixed. The
gateway can respond with any number of challenges (CHRE payloads) to
which the client responds with responses (also CHRE payloads) for
each. When the gateway has successfully authenticated the client, it
responds with a CHRE payload with an associated attribute list
containing (at least) the CRACK_T_FIN attribute with the value of
CRACK_FIN_SUCCESS. Depending on the LAM Type, the gateway may respond
with CRACK_FIN_MORE, indicating that the exchange needs to continue
for an additional round.
3.2 IKE Challenge/Response Failures
CRACK requires the gateway to send ISAKMP Notify payloads under
certain circumstances detailed in this section and elsewhere in this
draft. These Notify payloads use the same format for the
Notification Payload ([MSST98]) and differ only in the "Notification
Data" field.
The Notification Payload MUST have the following format:
o Payload length - set to the value 28 + "Notification Data"
o DOI - set to the value zero (0) (ISAKMP)
o Protocol ID - set to the value one (1) (PROTO_ISAKMP)
o SPI Size - set to the value 16
o Notify Message Type - set to the value 24
o SPI - set to the ISAKMP initiator and responder cookies
If the contents of the CHRE payload(s) that the client sends fail to
satisfy the legacy authentication method, the gateway MUST terminate
the connection and MUST respond with an ISAKMP (AUTHENTICATION-
Harkins, Piper Expires in 6 months [Page 8]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
FAILED) [MSST98].
AUTHENTICATION-FAILED MUST include the following "Notification Data":
o LAM Type (two octets) - set to the associated LAM Type
o RESERVED (two octets) - MUST be zero (0) (alignment)
In addition AUTHENTICATION-FAILED SHOULD contain the following
"Notification Data" when applicable:
o Status (variable length) - implementation-specific
authentication failure status
If LAM Type, signature algorithm, or corresonding public-key
requested by a CERTREQ cannot be located, the gateway MUST terminate
the connection and MUST respond with an ISAKMP Notify (PROPOSAL-NOT-
CHOSEN) [MSST98].
PROPOSAL-NOT-CHOSEN MUST include the following "Notification Data":
o LAM Type (two octets) - set to the LAM Type the server requires
for the client; MAY be different than the LAM Type specified in
the first CHRE payloads if the server required a different LAM
Type than was offered
o RESERVED (two octets) - MUST be zero (0) (alignment)
In addition PROPOSAL-NOT-CHOSEN SHOULD contain the following
"Notification Data" when applicable:
o Status (variable length) - authentication failure status
Because these Notify messages are only sent under the security of the
Phase 1 shared secret and only after the gateway has proven its
identity to the client, the client can trust the authenticity of
these messages and MUST terminate the exchange upon receipt of any of
these Notify messages.
4. Legacy Authentication Method (LAM) Profiles
Each defined LAM type uses the CHRE payload and LAM attributes in a
different manner. This section profiles the acceptable use of each
for the defined LAM types and details the list of acceptable
attributes for each profile.
The Challenge/Response profile examples include the exchange of
CERTREQ and CERT payloads which may be used when the client does not
have access to the server's public-key or has access to multiple
server keys. In other examples, the CERTREQ and CERT payloads are
Harkins, Piper Expires in 6 months [Page 9]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
omitted for simplicity, but these MAY be used with any of the defined
profiles, according to the additional requirements in Section 3.1.
4.1 LAM Profiles: Password
The Password profile supports legacy operating system (OS)
authentication along with proxy-based password authentication
protocols, like RADIUS or TACACS+.
It is assumed in this example that the client has the gateway's
public key, either through a certificate or a trusted raw public key,
prior to initiation of the exchange. This example is given using Main
Mode.
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, --->
<--- HDR2, SAr,
HDR1, KEi, Ni --->
<--- HDR2, KEr, Ni, SIG
HDR3*, CHRE1 --->
<--- HDR4*, CHRE2
For Password, the CHRE payloads are used as follows:
HDR3*, CHRE1 --->
The CHRE1 payload contains the client's username as a
CRACK_T_USERNAME attribute and a password as a CRACK_T_SECRET
attribute. The format of the client password is dictated by the
corresponding host OS or proxy authentication server and may be
either plaintext or binary.
<--- HDR4*, CHRE2
The CHRE2 payload contains a CRACK_T_FIN attribute with the value of
CRACK_FIN_SUCCESS.
The following attributes are defined for Password:
CRACK_T_USERNAME (client -> gateway, required)
CRACK_T_USERNAME is sent in the client's first CHRE payload and MUST
contain the client's username which is used as an index key by
the host OS or proxy password authentication server.
CRACK_T_SECRET (client -> gateway, required)
Harkins, Piper Expires in 6 months [Page 10]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
CRACK_T_SECRET is sent in the client's first CHRE payload and MUST
contain the client's password.
CRACK_T_DOMAIN (client -> gateway, optional)
CRACK_T_DOMAIN is sent in the client's second message and MAY be
used to specify the authentication domain that the client is
requesting authentication within.
CRACK_T_FIN (gateway -> client, required)
CRACK_T_FIN is used to successfully terminate the exchange.
4.2 LAM Profiles: One-Time Password
The OTP profile supports both the S/KEY and OTP one-time password
schemes.
It is assumed in this example that the client has the gateway's
public key, either through a certificate or a trusted raw public key,
prior to initiation of the exchange. The example is given using
Aggressive Mode.
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni --->
<--- HDR2, SAr, KEr, Nr, SIG
HDR3*, CHRE1 --->
<--- HDR4*, CHRE2
HDR5*, CHRE3 --->
<--- HDR6*, CHRE4
For OTP, the CHRE payloads are used as follows:
HDR3*, CHRE1 --->
The CHRE1 payload contains only any associated attributes
such as a username.
<--- HDR4*, CHRE2
The CHRE2 payload contains the OTP server's challenge
text which MUST be displayed to the client user.
HDR5*, CHRE3 --->
The CHRE3 payload contains the client's one-time password
response.
Harkins, Piper Expires in 6 months [Page 11]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
<--- HDR6*, CHRE4
The CHRE4 payload contains a CRACK_T_FIN attribute with the value
of CRACK_FIN_SUCCESS.
The following attributes are defined for OTP:
CRACK_T_USERNAME (client -> gateway, required)
CRACK_T_USERNAME is sent in the client's first CHRE payload and MUST
contain the client's username which is used as an index key by
the OTP server.
CRACK_T_CHALLENGE (gateway -> client, required)
CRACK_T_CHALLENGE is sent in the gateway's first CHRE payload
and MUST contain the OTP challenge to be issued to the client.
CRACK_T_SECRET (client -> gateway, required)
CRACK_T_SECRET is sent in the client's second CHRE payload and
contains the client's one-time password.
CRACK_T_MESSAGE (gateway -> client, optional)
CRACK_T_MESSAGE is optionally sent in any server message and MAY
by used by the server to provide optional text to be displayed
to the user along with any associated challenge text.
CRACK_T_FIN (gateway -> client, required)
CRACK_T_FIN is used to successfully terminate the exchange.
4.3 LAM Profiles: Challenge/Response
The Challenge/Response profile supports various token cards that
follow a standard challenge/response exchange. The client's token
card information (the response) depends on the gateway's request (the
challenge).
It is assumed in this example that the client does not have the
gateway's public key and requires a certificate issued by a trusted
Certification Authority. Note that in this case, identity protection
of the gateway is lost. Whether a certificate is requested and sent
or not, the client's identity is never open to a passive attack (i.e.
the client retains identity protection regardless).
The following example shows an exchange where a full
Harkins, Piper Expires in 6 months [Page 12]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
challenge/response exchange is followed:
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni,
CERTREQ --->
<--- HDR2, SAr, CERT, KEr,
Nr, SIG
HDR3*, CHRE1 --->
<--- HDR4*, CHRE2
HDR5*, CHRE3 --->
<--- HDR6*, CHRE4
If more challenges were required to authenticate this client, message
six would be another CHRE payload containing a challenge to the
client. This would force a message seven which would be another CHRE
payload. This can be repeated until the gateway authenticates the
client (or authentication fails, see below).
Alternatively, some challenge-response tokens cache their last
computed result and do not require a challenge from the gateway
unless they get out of sync (perhaps due to intrusion detection). In
this case, the gateway may be able to authenticate the client in the
second message and would return, assuming success a CHRE2 containing
CRACK_T_FIN attribute with the value of CRACK_T_FIN_SUCCESS. There
would also be no fifth nor sixth message.
The following example shows an exchange where the client can pre-
compute his expected response:
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni,
CERTREQ --->
<--- HDR2, SAr, CERT, KEr,
Nr, SIG
HDR3*, CHRE1 --->
<--- HDR4*, CHRE2
For Challenge/Response, the CHRE payloads are used as follows:
HDR3*, CHRE1 --->
When the client is using a token that can compute the
next expected response without requiring a challenge,
the CHRE1 payload contains the client's username and
expected response. When the client does not
have an expected response, or has chosen not to use
Harkins, Piper Expires in 6 months [Page 13]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
the current one for whatever reason, the CHRE payload
contains only the client's username.
<--- HDR4*, CHRE2
The CHRE2 payload contains the gateway's challenge
text which MUST be displayed to the client user unless
the client has presented an expected response (as
above) in which case this is identical to CHRE4 below.
HDR5*, CHRE3 --->
The CHRE3 payload, when used, contains the client's
response to the gateway challenge.
<--- HDR6*, CHRE4
The CHRE4 payload contains a CRACK_T_FIN attribute with the
value of CRACK_FIN_SUCCESS.
The following attributes are defined for Challenge/Response:
CRACK_T_USERNAME (client -> gateway, required)
CRACK_T_USERNAME is sent in the client's second message and MUST
contain the client's username which is used as an index key for
authentication by the server.
CRACK_T_SECRET (client -> gateway, required)
CRACK_T_SECRET contains the client's response and is sent in the
client's second message if an anticipated challenge is used, and
in the client's third message if the client is responding to
a gateway challenge.
CRACK_T_PIN (client -> gateway, optional)
CRACK_PIN is optionally sent in any client message and MAY by
used if the authentication protocol also requires the client
to provide a PIN.
CRACK_T_MESSAGE (gateway -> client, optional)
CRACK_MESSAGE is optionally sent in any server message and MAY
by used by the server to provide optional text to be displayed
to the user along with any associated challenge text.
Harkins, Piper Expires in 6 months [Page 14]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
CRACK_T_FIN (gateway -> client, required)
CRACK_T_FIN is used to successfully terminate the exchange.
4.4 LAM Profiles: SecurID
The SecurID profile supports the RSA SecurID protocol. With SecurID
the client will be passing the output of the SecurID card as the body
of the first CHRE payload (in the second message it sends) and its
identity as an associated CRACK_T_USERNAME attribute. Assuming the
client and gateway are in sync (i.e. they are not in "Next Code"
mode) there is a single CHRE payload.
It is assumed in this example that the client has the gateway's
public key, either through a certificate or a trusted raw public key,
prior to initiation of the exchange.
The following example shows a simple SecurID authentication using
aggressive mode:
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni --->
<--- HDR2, SAr, KEr,
Nr, SIG1
HDR3*, CHRE1 --->
<--- HDR4*, CHRE2
For simple SecurID, the CHRE payloads are used as follows:
HDR3*, CHRE1 --->
The CHRE1 payload contains the client's username and the current
Passcode displayed by the client's SecurID token.
<--- HDR4*, CHRE2
The CHRE2 payload contains a CRACK_T_FIN attribute with the value
of CRACK_FIN_SUCCESS.
When the client and gateway clocks are slightly out of sync, the gateway
will respond with an additional challenge payload to which the client
MUST respond with another reponse payload. This is known as "Next Code"
mode.
The following example shows a SecurID authentication where "Next Code"
mode is required:
Harkins, Piper Expires in 6 months [Page 15]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni --->
<--- HDR2, SAr, KEr,
Nr, SIG
HDR3*, CHRE1 --->
<--- HDR4*, CHRE2
HDR5*, CHRE3 --->
<--- HDR6*, CHRE4
For SecurID with "Next Code", the CHRE payloads are used as follows:
HDR3*, CHRE1 --->
The CHRE1 payload contains the client's username and the current
Passcode displayed by the client's SecurID token.
<--- HDR4*, CHRE2
The CHRE2 payload contains a CRACK_T_FIN attribute with the value
of CRACK_FIN_MORE.
HDR5*, CHRE3 --->
The CHRE3 payload contains the client's next Passcode
displayed by the client's SecurID token.
<--- HDR6*, CHRE4
The CHRE4 payload contains a CRACK_T_FIN attribute with the value
of CRACK_FIN_SUCCESS.
The following attributes are defined for SecurID:
CRACK_T_USERNAME (client -> gateway, required)
CRACK_T_USERNAME is sent in the client's second message and MUST
contain the client's username which is used as an index key by
the ACE server.
CRACK_T_PIN (client -> gateway, optional)
CRACK_T_PIN is sent in the client's second message and MAY be
used when the SecurID card is not a PINPAD card.
CRACK_T_MESSAGE (gateway -> client, optional)
CRACK_T_MESSAGE is optionally sent in any server message and MAY
Harkins, Piper Expires in 6 months [Page 16]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
by used by the server to provide optional text to be displayed
to the user along with any associated challenge text.
CRACK_T_FIN (gateway -> client, required)
CRACK_T_FIN is used to successfully terminate the exchange and
to request the client continue under "Next Code" mode.
4.5 LAM Profile Matrix
Each of the LAM's supported by IKE Challenge/Response fall into one
of the defined LAM profiles. This section details the classification
for those methods, including all of the types defined for the
experimental XAUTH protocol [PB99].
Password
DIAMETER
LDAP
NDS (Netware Directory Services)
NT Domain
RADIUS
TACACS
TACACS+
UNIX Login
OTP
OTP
S/KEY
Challenge/Response
AXENT Defender
CheckPoint ActivCard
CRYPTOCard CRYPTOCard
Digital Pathways SNK
LeeMah InfoCard
Secure Computing SafeWord (Enigma Logic DES Gold)
SecurID
RSA SecurID
5. The IKE Challenge/Response Vendor ID Signature
This memo describes a protocol that lives on top of [MSST98] and as a
companion to [HC98]. These standards-track protocols reserve some of
their "magic number" space for private use by mutually consenting
parties. It is from this number space that this memo obtains some of
the "magic numbers" it needs (payload types, exchange value,
attributes). As part of the "mutually consenting parties" part of
Harkins, Piper Expires in 6 months [Page 17]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
the requirement implementors of this protocol are encouraged to use a
Vendor ID payload to announce willingness to engage in this protocol.
The contents of the Vendor ID payload will be the following
hexadecimal string: 0x13f11823f966fa91900f024ba66a86b, which is the
result of an MD5 hash of "IKE Challenge/Response for Authenticated
Cryptographic Keys (Revised)" without the quotation marks. An [HC98]
implementation that implements this protocol that obtains a Vendor ID
payload with this string in the body of the payload can assume that
the sender of the Vendor ID payload has likewise implemented this
protocol and is therefore a "mutually consenting party".
If this protocol is advanced to standards-track status IANA will
assign new "magic numbers" out of the appropriate number spaces (the
"magic numbers" will no longer be from the private use ranges) and
the requirement to use a Vendor ID payload will go away.
6. Security Considerations
The channel that results from the exchange of the first two messages
is secured because the gateway signs his Diffie-Hellman public value
and it is the resulting SKEYID state (see [HC98]) that protects the
channel. The channel is secured from the client's perspective because
he knows that the gateway was the actual source of the Diffie-Hellman
public value and is an active party to the exchange. The channel is
secured from the gateway's perspective because the client has proved
proof-of-possession of a long-term shared secret and would not have
sent his sensitive information if a man-in-the-middle was detected by
the client.
While this seems to be a weak form of assurance, the exchange could
only be foiled by an intentionally malfunctioning client and if that
is the case then all bets are off regardless of the method of
authentication. (If Alice and Bob establish IPSec SA's in the
traditional fashion, using a [HC98] exchange nothing could stop Alice
from sending all the sensitive information Bob conveys to her to
Eve.) Also note that this technique is used in other popular on-line
certificate enrollment schemes ([MLSW99]).
As noted, this whole scheme can fail if the client is intentionally
malicious. Also, if the token card and knowledge of how to generate
valid credentials is conveyed to a third-party this scheme would fail
(but not due to any protocol failure).
The number of messages in this protocol is dictated by the type of
legacy authentication method employed. Since this protocol is open-
ended, a host implementation may wish to limit the number of CHRE
round-trips using locally defined policy.
Harkins, Piper Expires in 6 months [Page 18]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
Acknowledgments
The authors would like to thank the sales and marketing staff of all
companies who said, "Just give us something that uses token cards!"
We would like to recognize Roy Pereira and Stephane Beaulieu, authors
of [PB99], which was borrowed from liberally in creation of this
memo.
References
[Bra96] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[CR98] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol",
draft-calhoun-diameter-02.txt, March 1998, a work in
progress.
[DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard",
FIPS 186, May 1994.
[Hal95] N. Haller, "The S/KEY One-Time Password System", RFC1760,
February 1995.
[HC98] D. Harkins, D. Carrel, "The Internet Key Exchange",
RFC2409, November 1998.
[HM96] N. Haller, C. Metz, "A One-Time Password System", RFC1938,
May 1996.
[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[MLSW99] M. Myers, X. Liu, J. Schaad, and J. Weinstein, "Certificate
Management Messages over CMS", draft-ietf-pkix-cmc-05.txt,
a work in progress.
[MSST98] D. Maughan, M. Schertler, M. Schneider, J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC2408, November 1998.
[PB99] R. Pereira, S. Beaulieu, "Extended Authentication within
ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-05.txt,
September, 1999, a work in progress.
[Pip98] Piper, D., "The Internet IP Security Domain Of
Interpretation for ISAKMP", RFC 2407, November 1998.
Harkins, Piper Expires in 6 months [Page 19]
INTERNET DRAFT IKE Challenge/Response July 14, 2000
[PKCS1] B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2", September 1998.
[RASW97] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC2138,
April 1997.
[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems",
Communications of the ACM, v. 21, n. 2, February 1978.
Authors' Address
Dan Harkins <dharkins@cips.nokia.com>
Derrell Piper <ddp@cips.nokia.com>
Nokia Corporation
1538 Pacific Ave
Santa Cruz, CA 95060-9311
United States of America
Harkins, Piper Expires in 6 months [Page 20]
From owner-ipsec@lists.tislabs.com Tue May 7 03:27:03 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g47AR3L14976;
Tue, 7 May 2002 03:27:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA08948
Tue, 7 May 2002 05:21:39 -0400 (EDT)
Message-Id: <scd74b39.057@prv-mail25.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta
Date: Tue, 07 May 2002 03:34:10 -0600
From: "Umasankar Mukkara" <mumasankar@novell.com>
To: <ipsec@lists.tislabs.com>
Subject: NAT-T ipaddress conflict
Mime-Version: 1.0
Content-Type: text/plain; charset=Windows-874
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA08945
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
NAT-Traversal and UDP-Encapsulation drafts do not suggest a way to deal
with IP address conflict behind two different NATs. The recent draft
"draft-ietf-ipsec-udp-encaps-02.txt" also says that that the
implementations should devise their own way to solve this problem. (in
section 5.2 — Tunnel Mode Conflict)
Are there any references available suggesting a solution to this issue?
I read that NAT functionality built-in into the ipsec stack on the VPN
GW solves this problem. Could somebody provide an overview (or already
available stuff on the web)
TIA,
Umasankar.
From owner-ipsec@lists.tislabs.com Tue May 7 08:10:09 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g47FA8L27045;
Tue, 7 May 2002 08:10:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09890
Tue, 7 May 2002 10:23:04 -0400 (EDT)
Message-ID: <E76F715C0429D5118F2100508BB9EDEE036FE96B@hrtades7.atea.be>
From: Goeman Stefan <Stefan.Goeman@siemens.atea.be>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: data origin authentication
Date: Tue, 7 May 2002 16:29:53 +0200
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
Hello All,
In rfc 2406 "IP Encapsulating Security Payload", and also in
draft-ietf-ipsec-esp-v3-02.txt,
I read: "EPS is used to provide confidentiality, data origin authentication,
connectionless integrity,
an anti-replay service (a form of partial sequence integrity), and limited
traffic flow confidentiality.
The set of services provided depends on options selected at the time of
Security Association (SA)
establishment and on the location of the implementation in a network
topology."
I have been reading more carefully through the rfc (not through the draft
yet). I is correct to say
that if ESP is used in transport mode, there is no data origin
authentication? I would say this because
the IP header, containing the source IP address is not authenticated.
Or am I missing something here?
Greetings,
Stefan.
From owner-ipsec@lists.tislabs.com Tue May 7 09:04:14 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g47G4DL29850;
Tue, 7 May 2002 09:04:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10157
Tue, 7 May 2002 11:20:37 -0400 (EDT)
Date: Tue, 7 May 2002 11:33:03 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Goeman Stefan <Stefan.Goeman@siemens.atea.be>
cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Re: data origin authentication
In-Reply-To: <E76F715C0429D5118F2100508BB9EDEE036FE96B@hrtades7.atea.be>
Message-ID: <Pine.BSI.3.91.1020507112839.10419C-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 May 2002, Goeman Stefan wrote:
> ...I is correct to say
> that if ESP is used in transport mode, there is no data origin
> authentication? I would say this because
> the IP header, containing the source IP address is not authenticated.
Not really correct. Yes, the header may be tampered with... but the
origin of the *data* (the packet contents) is still certain, because only
someone knowing the authentication key can generate a packet which will
pass authentication.
The header is just the means by which the data is conveyed to the
destination. Usually, one cares about authenticating the contents, not
the header.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue May 7 09:21:54 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g47GLrL00614;
Tue, 7 May 2002 09:21:54 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10211
Tue, 7 May 2002 11:40:43 -0400 (EDT)
Message-Id: <5.1.0.14.0.20020507171226.03c24ec0@dfintra.f-secure.com>
X-Sender: joern@dfintra.f-secure.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 07 May 2002 17:20:49 +0200
To: ipsec@lists.tislabs.com
From: Joern Sierwald <joern@f-secure.com>
Subject: Re: data origin authentication
In-Reply-To: <E76F715C0429D5118F2100508BB9EDEE036FE96B@hrtades7.atea.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA10092
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 16:29 07.05.2002 +0200, you wrote:
>Hello All,
>
>In rfc 2406 "IP Encapsulating Security Payload", and also in
>draft-ietf-ipsec-esp-v3-02.txt,
>I read: "EPS is used to provide confidentiality, data origin authentication,
>connectionless integrity,
>an anti-replay service (a form of partial sequence integrity), and limited
>traffic flow confidentiality.
>The set of services provided depends on options selected at the time of
>Security Association (SA)
>establishment and on the location of the implementation in a network
>topology."
>
>I have been reading more carefully through the rfc (not through the draft
>yet). I is correct to say
>that if ESP is used in transport mode, there is no data origin
>authentication? I would say this because
>the IP header, containing the source IP address is not authenticated.
>Or am I missing something here?
>
>
>Greetings,
>
>Stefan.
I guess you are missing something. You receive an ESP packet. By looking up
<dst IP address, protocol (ESP), SPI> you find the IPsec SA.
Now, since you negotiated the SA for transport mode, the SA data will
contain the
remote IP address. The SA entry states "<dst addr 1.2.3.4 (that's us), ESP,
SPI 0x61782395>, that
should come from 5.6.7.8". And if it doesn't, you can discard the packet.
Or, to explain it in another way:
Transport mode: src IP address is the same for all packets. Easy to check.
Tunnel mode: src IP addresses (inner header) can vary. Therefore is must be
authenticated.
Jörn
From owner-ipsec@lists.tislabs.com Tue May 7 09:22:54 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g47GMsL00659;
Tue, 7 May 2002 09:22:54 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10239
Tue, 7 May 2002 11:43:45 -0400 (EDT)
Message-Id: <200205071553.g47FrWKw027550@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@east.sun.com>
To: Goeman Stefan <Stefan.Goeman@siemens.atea.be>
cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Re: data origin authentication
In-Reply-To: Your message of "Tue, 07 May 2002 16:29:53 +0200."
<E76F715C0429D5118F2100508BB9EDEE036FE96B@hrtades7.atea.be>
Reply-to: sommerfeld@east.sun.com
Date: Tue, 07 May 2002 11:53:31 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> I have been reading more carefully through the rfc (not through the draft
> yet). I is correct to say
> that if ESP is used in transport mode, there is no data origin
> authentication?
No. It's underspecified.
> I would say this because the IP header, containing the source IP
> address is not authenticated. Or am I missing something here?
Implementations often allow a specific source address to be bound to
the SA in transport mode -- if the packet's source doesn't match the
SA source, the packet is dropped. (PF_KEY provides exactly this
mechanism).
memcmp() with a known quantity is a stronger integrity check than
hmac-sha1. ;-)
- Bill
From owner-ipsec@lists.tislabs.com Tue May 7 10:14:49 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g47HEmL03446;
Tue, 7 May 2002 10:14:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10473
Tue, 7 May 2002 12:34:11 -0400 (EDT)
Message-ID: <E76F715C0429D5118F2100508BB9EDEE036FE96C@hrtades7.atea.be>
From: Goeman Stefan <Stefan.Goeman@siemens.atea.be>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: RE: data origin authentication
Date: Tue, 7 May 2002 18:41:40 +0200
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
Hello All,
(As you all might guess, I am quite new to this stuff).
See my question(s) below
> -----Original Message-----
> From: Henry Spencer [mailto:henry@spsystems.net]
> Sent: dinsdag 7 mei 2002 17:33
> To: Goeman Stefan
> Cc: 'ipsec@lists.tislabs.com'
> Subject: Re: data origin authentication
>
>
> On Tue, 7 May 2002, Goeman Stefan wrote:
> > ...I is correct to say
> > that if ESP is used in transport mode, there is no data origin
> > authentication? I would say this because
> > the IP header, containing the source IP address is not
> authenticated.
>
> Not really correct. Yes, the header may be tampered with... but the
> origin of the *data* (the packet contents) is still certain,
> because only
> someone knowing the authentication key can generate a packet
> which will
> pass authentication.
>
> The header is just the means by which the data is conveyed to the
> destination. Usually, one cares about authenticating the
> contents, not
> the header.
>
>
> Henry Spencer
>
> henry@spsystems.net
>
If you don't really need to authenticate the header to obtain data origin
authentication, why does AH (rfc 2402) authenticates also the IP header,
and not only the IP payload?
Anyway, thanks for answering all my (stupid?) questions.
Greetings,
Stefan.
From owner-ipsec@lists.tislabs.com Tue May 7 10:55:42 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g47HtfL04940;
Tue, 7 May 2002 10:55:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10567
Tue, 7 May 2002 13:03:22 -0400 (EDT)
Message-Id: <200205071705.g47H5ax10386@marajade.sandelman.ottawa.on.ca>
To: Goeman Stefan <Stefan.Goeman@siemens.atea.be>
cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Re: data origin authentication
In-reply-to: Your message of "Tue, 07 May 2002 16:29:53 +0200."
<E76F715C0429D5118F2100508BB9EDEE036FE96B@hrtades7.atea.be>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 07 May 2002 13:05:35 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Goeman" == Goeman Stefan <Stefan.Goeman@siemens.atea.be> writes:
Goeman> I have been reading more carefully through the rfc (not through
Goeman> the draft yet). I is correct to say that if ESP is used in
Goeman> transport mode, there is no data origin authentication? I would
Goeman> say this because the IP header, containing the source IP address
Goeman> is not authenticated. Or am I missing something here?
The IP address is not authenticated. The IP address is just one expression
of the origin.
Origin authentication is provided by the relationship to the trust model
that created the SA. And, as Steve Bellovin has pointed out, you could
essentially throw away the origin IP anyway, and use the SA to provide
the actual numerical origin.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPNgJXYqHRg3pndX9AQEgjQP+IxeGbslJ/LbtimynbFMmgmSh2+2zE6rx
KaNSj7svBwx9MtMupbyWHGu1Wdv/w3BntfN+bgSY1f311r7YomvARLO1MPA+jCTM
vFAXjs31DCfX7lOMEuVoYloaS/S8kgYsBF8/rmPEJ/VpU5hXGxBo58UcYS6s+Y1N
/mz0qQZdl/k=
=5Ufi
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Tue May 7 11:39:17 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g47IdGL06731;
Tue, 7 May 2002 11:39:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10806
Tue, 7 May 2002 13:50:42 -0400 (EDT)
Message-Id: <200205071752.g47Hqfh11664@marajade.sandelman.ottawa.on.ca>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Re: data origin authentication
In-reply-to: Your message of "Tue, 07 May 2002 18:41:40 +0200."
<E76F715C0429D5118F2100508BB9EDEE036FE96C@hrtades7.atea.be>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 07 May 2002 13:52:40 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Goeman" == Goeman Stefan <Stefan.Goeman@siemens.atea.be> writes:
Goeman> If you don't really need to authenticate the header to obtain
Goeman> data origin authentication, why does AH (rfc 2402) authenticates
Goeman> also the IP header, and not only the IP payload?
Please see the archives.
AH is generally considered a historical accident.
I think that it will still prove useful, but not for most people this
decade.
] 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 Tue May 7 11:46:47 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g47IkkL07064;
Tue, 7 May 2002 11:46:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10837
Tue, 7 May 2002 14:01:48 -0400 (EDT)
Date: Tue, 7 May 2002 14:13:46 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Goeman Stefan <Stefan.Goeman@siemens.atea.be>
cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: RE: data origin authentication
In-Reply-To: <E76F715C0429D5118F2100508BB9EDEE036FE96C@hrtades7.atea.be>
Message-ID: <Pine.BSI.3.91.1020507140527.12325C-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 May 2002, Goeman Stefan wrote:
> > Usually, one cares about authenticating the contents, not the header.
>
> If you don't really need to authenticate the header to obtain data origin
> authentication, why does AH (rfc 2402) authenticates also the IP header,
> and not only the IP payload?
Well, you'll note that I said "usually". There are situations where you
would like to be able to trust certain items in the header. For example,
in multicast applications, the source address may not be uniquely
determined by the SA used, and might be significant to the user-level code.
That said, there are many people who think that this feature of AH was
a design mistake, and that the entire AH protocol is now superfluous and
should be removed from IPsec and reclassified as Historic. (There are
other people who disagree.)
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue May 7 12:37:07 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g47Jb6L09101;
Tue, 7 May 2002 12:37:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10958
Tue, 7 May 2002 14:49:14 -0400 (EDT)
Message-ID: <6F0AA176DA68704884B7507AE6907E180817DA@snake012.odetics.com>
From: Christina Helbig <cbh@zyfer.com>
To: "'Joern Sierwald'" <joern@f-secure.com>, ipsec@lists.tislabs.com
Subject: RE: data origin authentication
Date: Tue, 7 May 2002 12:01:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 OAA10955
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello, Joern
if you are a bad guy and you own a in-bound SA you can produced a faked ESP
packet that looks like its come from the other party of your in-bound SA.
Then you can claim that you got this packet from the other party. So the
data origin authentication of ESP (two parties know the same authentication
key) don't deliver non-repudiation of data origin. But a receiver can be
sure that the sender of an incoming ESP packet is only the other party of
the related in-bound SA or the receiver itself. For this proof, I guess, the
receiver needs only <dst IP address, protocol (ESP), SPI> to find the
related SA and the related authentication key. The receiver proofs the
authentication value and this proof delivers the answer, if the sender has
the identity the sender claimed. The check against the ip address of the
sender saves time (if you do it before) and is a MUST but for the data
authentication not really necessary. But I'm also a newcomer in IPSec and
may be I'm wrong.
Christina
> -----Original Message-----
> From: Joern Sierwald [mailto:joern@f-secure.com]
> Sent: Tuesday, May 07, 2002 8:21 AM
> To: ipsec@lists.tislabs.com
> Subject: Re: data origin authentication
>
>
> At 16:29 07.05.2002 +0200, you wrote:
> >Hello All,
> >
> >In rfc 2406 "IP Encapsulating Security Payload", and also in
> >draft-ietf-ipsec-esp-v3-02.txt,
> >I read: "EPS is used to provide confidentiality, data
> origin authentication,
> >connectionless integrity,
> >an anti-replay service (a form of partial sequence
> integrity), and limited
> >traffic flow confidentiality.
> >The set of services provided depends on options selected at
> the time of
> >Security Association (SA)
> >establishment and on the location of the implementation in a network
> >topology."
> >
> >I have been reading more carefully through the rfc (not
> through the draft
> >yet). I is correct to say
> >that if ESP is used in transport mode, there is no data origin
> >authentication? I would say this because
> >the IP header, containing the source IP address is not
> authenticated.
> >Or am I missing something here?
> >
> >
> >Greetings,
> >
> >Stefan.
>
> I guess you are missing something. You receive an ESP packet.
> By looking up
> <dst IP address, protocol (ESP), SPI> you find the IPsec SA.
>
> Now, since you negotiated the SA for transport mode, the SA data will
> contain the
> remote IP address. The SA entry states "<dst addr 1.2.3.4
> (that's us), ESP,
> SPI 0x61782395>, that
> should come from 5.6.7.8". And if it doesn't, you can discard
> the packet.
>
> Or, to explain it in another way:
>
> Transport mode: src IP address is the same for all packets.
> Easy to check.
> Tunnel mode: src IP addresses (inner header) can vary.
> Therefore is must be
> authenticated.
>
> Jörn
>
>
>
From owner-ipsec@lists.tislabs.com Tue May 7 17:09:19 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4809IL18075;
Tue, 7 May 2002 17:09:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11677
Tue, 7 May 2002 19:13:47 -0400 (EDT)
Message-ID: <605C42246151B7498423278ED555306F04C049@skat.sky.com>
From: michael lin <michaell@servgate.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: NAT Traversal and packet reassemble
Date: Tue, 7 May 2002 16:26:59 -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,
To support IPSec fragment packets, the only thing, VPN gateway should do, is
to reassemble AH and ESP packets. In NAT Traversal, all IPSec packets are
encapsulated by UDP header (port 500 or 4500). For first fragment, VPN
gateway can only keep the packet with UDP port 500 and non-IKE marker. But
for the second fragment, there is no UDP header. There is no way to know
this fragment is UDP encapsulated IPSec packet or other UDP packets. That
means VPN gateway should try to reassemble all UDP packets. This will affect
VPN gateway throughput.
It seems no way to solve this problem, right?
Michael
From owner-ipsec@lists.tislabs.com Tue May 7 19:16:38 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g482GcL22059;
Tue, 7 May 2002 19:16:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12175
Tue, 7 May 2002 21:34:14 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020507182331.02c9c820@mira-sjc5-4.cisco.com>
X-Sender: byfraser@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 07 May 2002 18:45:57 -0700
To: ipsec@lists.tislabs.com
From: Barbara Fraser <byfraser@cisco.com>
Subject: New SOI features draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Thanks to the IKEv2 and JFK folks, and Paul Hoffman for developing the SOI
features document. Ted and I would like to urge you to read it and to
discuss it on the list. We need to decide which features are important to
SOI so that we can move forward with the protocol design work. On page 3 of
the document, there are three identified core differences between IKEv2 and
JFK: 1) whether the protocol has one phase or two phases, 2) how DoS
attacks are thwarted, and 3) the use of shared secret authentication.
According to the document, one path the working group can take is to decide
which of these three differences is important and to then select among the
remaining features.
The scenarios where IPsec/IKE is being used, as described in Cheryl's
document, are not included in the features document. Therefore, one area we
must explore is the match between the above 3 differentiating qualities and
the community's use and expectation of IPsec/IKE. Is there an installed
base that expects these features to be present, and given the answer, what
does the working group want to do.
Let's see if we can come to consensus in the next month. This would allow
some time for a new or updated protocol draft to be prepared prior to the
July IETF meeting.
thanks,
Barb
From owner-ipsec@lists.tislabs.com Tue May 7 20:52:38 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g483qbL24444;
Tue, 7 May 2002 20:52:37 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12479
Tue, 7 May 2002 23:13:35 -0400 (EDT)
Date: Tue, 7 May 2002 20:35:32 -0700 (PDT)
From: Srinivasa Addepalli <srao@intotoinc.com>
To: michael lin <michaell@servgate.com>
cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Re: NAT Traversal and packet reassemble
In-Reply-To: <605C42246151B7498423278ED555306F04C049@skat.sky.com>
Message-ID: <Pine.LNX.4.21.0205072030340.26449-100000@intotoinc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 7 May 2002, michael lin wrote:
> Hi,
>
> To support IPSec fragment packets, the only thing, VPN gateway should do, is
> to reassemble AH and ESP packets. In NAT Traversal, all IPSec packets are
> encapsulated by UDP header (port 500 or 4500). For first fragment, VPN
> gateway can only keep the packet with UDP port 500 and non-IKE marker.
SRINI> Now it is non-ESP marker, according to the new draft.
But
> for the second fragment, there is no UDP header. There is no way to know
> this fragment is UDP encapsulated IPSec packet or other UDP packets. That
> means VPN gateway should try to reassemble all UDP packets. This will affect
> VPN gateway throughput.
>
> It seems no way to solve this problem, right?
SRINI> Reassembly is needed for this. Anycase, to support port based
SPD, reassembly is anyway required. Also, extra header should be taken
into consideration for PMTU ( if supported).
>
> Michael
>
--
Srinivasa Rao Addepalli
Intoto Inc. (Enabling Security Infrastructure)
3160, De La Cruz Blvd #100
Santa Clara, CA
USA
From owner-ipsec@lists.tislabs.com Wed May 8 01:42:43 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g488ghL27891;
Wed, 8 May 2002 01:42:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA13348
Wed, 8 May 2002 04:04:03 -0400 (EDT)
Message-ID: <E76F715C0429D5118F2100508BB9EDEE036FE96D@hrtades7.atea.be>
From: Goeman Stefan <Stefan.Goeman@siemens.atea.be>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: RE: data origin authentication
Date: Wed, 8 May 2002 10:11:47 +0200
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
Hello All,
> -----Original Message-----
> From: Christina Helbig [mailto:cbh@zyfer.com]
> Sent: dinsdag 7 mei 2002 21:02
> To: 'Joern Sierwald'; ipsec@lists.tislabs.com
> Subject: RE: data origin authentication
>
>
> Hello, Joern
> if you are a bad guy and you own a in-bound SA you can
> produced a faked ESP
> packet that looks like its come from the other party of your
> in-bound SA.
> Then you can claim that you got this packet from the other
> party. So the
> data origin authentication of ESP (two parties know the same
> authentication
> key) don't deliver non-repudiation of data origin. But a
> receiver can be
> sure that the sender of an incoming ESP packet is only the
> other party of
> the related in-bound SA or the receiver itself.
Non-repudiation.
Hmm.
Checking the rfc's, it is nowhere claimed that ESP and/or AH
offers non-repudiation as a security service.
(But perhaps non-repudiation is a must and then solutions have
to be developed.)
Greetings,
Stefan.
From owner-ipsec@lists.tislabs.com Wed May 8 07:09:31 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g48E9VL21389;
Wed, 8 May 2002 07:09:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14223
Wed, 8 May 2002 09:15:33 -0400 (EDT)
Message-Id: <5.1.0.14.0.20020508000513.02839fd8@dfintra.f-secure.com>
X-Sender: joern@dfintra.f-secure.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 08 May 2002 00:21:49 +0200
To: ipsec@lists.tislabs.com
From: Joern Sierwald <joern@f-secure.com>
Subject: RE: data origin authentication
In-Reply-To: <6F0AA176DA68704884B7507AE6907E180817DA@snake012.odetics.co
m>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA13138
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 12:01 07.05.2002 -0700, you wrote:
>Hello, Joern
>if you are a bad guy and you own a in-bound SA you can produced a faked ESP
>packet that looks like its come from the other party of your in-bound SA.
>Then you can claim that you got this packet from the other party. So the
>data origin authentication of ESP (two parties know the same authentication
>key) don't deliver non-repudiation of data origin. But a receiver can be
>sure that the sender of an incoming ESP packet is only the other party of
>the related in-bound SA or the receiver itself. For this proof, I guess, the
>receiver needs only <dst IP address, protocol (ESP), SPI> to find the
>related SA and the related authentication key. The receiver proofs the
>authentication value and this proof delivers the answer, if the sender has
>the identity the sender claimed. The check against the ip address of the
>sender saves time (if you do it before) and is a MUST but for the data
>authentication not really necessary. But I'm also a newcomer in IPSec and
>may be I'm wrong.
>Christina
I question the "for the data authentication not really necessary" part.
An example. Let's have a syslog client and server. syslog is _unidirectional_
UDP traffic. The connection between the client and the server is IPsec
transport mode.
Now, the IP address of the client (src) shows
up in the logs of the server, and it is valuable information.
If a man-in-the-middle would just alter the src address of the packets, the
information
in the server would be wrong. The point of authentication in ESP is that
the information was not altered in transit! Since the authentication
trailer in ESP
does not handle the IP source address, the receiver has to check (memcmp)
the source address with the expected one. That's part of authentication.
Not some optimization to save time.
Jörn
From owner-ipsec@lists.tislabs.com Wed May 8 07:59:23 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g48ExML24458;
Wed, 8 May 2002 07:59:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14515
Wed, 8 May 2002 10:17:52 -0400 (EDT)
Message-ID: <F86F34FDF1F9D411B7A40008C74C27B8537868@baltimore.com>
From: Chris Trobridge <CTrobridge@baltimore.com>
To: michael lin <michaell@servgate.com>,
"'ipsec@lists.tislabs.com'"
<ipsec@lists.tislabs.com>
Subject: RE: NAT Traversal and packet reassemble
Date: Wed, 8 May 2002 15:30:38 +0100
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
How much of a problem is this?
If you reassemble packets before checking then the only impact is if you're
being hit with fragmented UDP datagrams that you don't need. This should
not happen unless under attack.
I don't see reassembly of non-IPSEC datagrams as being a major impediment to
performance.
Chris
> -----Original Message-----
> From: michael lin [mailto:michaell@servgate.com]
> Sent: 08 May 2002 00:27
> To: 'ipsec@lists.tislabs.com'
> Subject: NAT Traversal and packet reassemble
>
>
> Hi,
>
> To support IPSec fragment packets, the only thing, VPN
> gateway should do, is
> to reassemble AH and ESP packets. In NAT Traversal, all IPSec
> packets are
> encapsulated by UDP header (port 500 or 4500). For first fragment, VPN
> gateway can only keep the packet with UDP port 500 and
> non-IKE marker. But
> for the second fragment, there is no UDP header. There is no
> way to know
> this fragment is UDP encapsulated IPSec packet or other UDP
> packets. That
> means VPN gateway should try to reassemble all UDP packets.
> This will affect
> VPN gateway throughput.
>
> It seems no way to solve this problem, right?
>
> Michael
>
-----------------------------------------------------------------------------------------------------------------
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.
This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com
From owner-ipsec@lists.tislabs.com Wed May 8 12:32:56 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g48JWuL05527;
Wed, 8 May 2002 12:32:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15198
Wed, 8 May 2002 13:25:59 -0400 (EDT)
Message-ID: <605C42246151B7498423278ED555306F04C04D@skat.sky.com>
From: michael lin <michaell@servgate.com>
To: "'Chris Trobridge'" <CTrobridge@baltimore.com>,
"'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: RE: NAT Traversal and packet reassemble
Date: Wed, 8 May 2002 10:38:10 -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
You are right. I can only reassemble the fragmented UDP datagrams whose
destination IP is my Gateway IP and there is a tunnel between source IP and
my Gateway. So the only non-IPSec datagrams would be IKE packets, and most
likely it's with certificate. Suppose it will not affect performance, unless
under attack.
Michael
>
> How much of a problem is this?
>
> If you reassemble packets before checking then the only
> impact is if you're
> being hit with fragmented UDP datagrams that you don't need.
> This should
> not happen unless under attack.
>
> I don't see reassembly of non-IPSEC datagrams as being a
> major impediment to
> performance.
>
> Chris
>
> > -----Original Message-----
> > From: michael lin [mailto:michaell@servgate.com]
> > Sent: 08 May 2002 00:27
> > To: 'ipsec@lists.tislabs.com'
> > Subject: NAT Traversal and packet reassemble
> >
> >
> > Hi,
> >
> > To support IPSec fragment packets, the only thing, VPN
> > gateway should do, is
> > to reassemble AH and ESP packets. In NAT Traversal, all IPSec
> > packets are
> > encapsulated by UDP header (port 500 or 4500). For first
> fragment, VPN
> > gateway can only keep the packet with UDP port 500 and
> > non-IKE marker. But
> > for the second fragment, there is no UDP header. There is no
> > way to know
> > this fragment is UDP encapsulated IPSec packet or other UDP
> > packets. That
> > means VPN gateway should try to reassemble all UDP packets.
> > This will affect
> > VPN gateway throughput.
> >
> > It seems no way to solve this problem, right?
> >
> > Michael
> >
>
>
> --------------------------------------------------------------
> ---------------------------------------------------
> 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.
>
> This footnote confirms that this email message has been swept
> for Content
> Security threats, including computer viruses.
>
> http://www.baltimore.com
>
From owner-ipsec@lists.tislabs.com Wed May 8 12:33:21 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g48JXLL05544;
Wed, 8 May 2002 12:33:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15414
Wed, 8 May 2002 14:47:23 -0400 (EDT)
Message-ID: <003901c1f6c2$5c5a61c0$6729660c@riverside>
From: "Jin Zhang" <jzhang@elmic.com>
To: <ipsec@lists.tislabs.com>
Cc: "Dan Harkins" <dharkins@tibernian.com>
References: <200203300132.g2U1WaH00410@fatty.lounge.org>
Subject: regarding digital signature and IKEv2
Date: Wed, 8 May 2002 11:58:35 -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
The reference of IKEv2 proposal lists FIPS PUB 186, 1994, however, this has
been superseded by FIPS PUB 186-2, 2000. Is there any related change(s) on
IKEv2 proposal?
For example, is IKEv2 proposal going to support another algorithm ECDSA?
And, PKCS#1 should be expired by end of 2002, is IKEv2 going to use it
anyway?
Thanks,
Jin Zhang
Elmic Systems Inc. USA
From owner-ipsec@lists.tislabs.com Wed May 8 12:33:38 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g48JXbL05562;
Wed, 8 May 2002 12:33:37 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14875
Wed, 8 May 2002 11:46:23 -0400 (EDT)
Message-ID: <6F0AA176DA68704884B7507AE6907E180817DD@snake012.odetics.com>
From: Christina Helbig <cbh@zyfer.com>
To: "'Goeman Stefan'" <Stefan.Goeman@siemens.atea.be>
Cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: RE: data origin authentication
Date: Wed, 8 May 2002 08:57:50 -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, Stefan
I haven't claim that ESP offers non-repudiation. ESP offers data origin
authentication without non-repudiation. This was only a remark about a
possible misunderstanding of the term "data origin authentication" in the
sense that there is only one possible origin.
Greetings
Christina
> -----Original Message-----
> From: Goeman Stefan [mailto:Stefan.Goeman@siemens.atea.be]
> Sent: Wednesday, May 08, 2002 1:12 AM
> To: 'ipsec@lists.tislabs.com'
> Subject: RE: data origin authentication
>
>
> Hello All,
>
> > -----Original Message-----
> > From: Christina Helbig [mailto:cbh@zyfer.com]
> > Sent: dinsdag 7 mei 2002 21:02
> > To: 'Joern Sierwald'; ipsec@lists.tislabs.com
> > Subject: RE: data origin authentication
> >
> >
> > Hello, Joern
> > if you are a bad guy and you own a in-bound SA you can
> > produced a faked ESP
> > packet that looks like its come from the other party of your
> > in-bound SA.
> > Then you can claim that you got this packet from the other
> > party. So the
> > data origin authentication of ESP (two parties know the same
> > authentication
> > key) don't deliver non-repudiation of data origin. But a
> > receiver can be
> > sure that the sender of an incoming ESP packet is only the
> > other party of
> > the related in-bound SA or the receiver itself.
>
> Non-repudiation.
> Hmm.
> Checking the rfc's, it is nowhere claimed that ESP and/or AH
> offers non-repudiation as a security service.
>
> (But perhaps non-repudiation is a must and then solutions have
> to be developed.)
>
>
> Greetings,
>
> Stefan.
>
From owner-ipsec@lists.tislabs.com Wed May 8 12:55:23 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g48JtML06123;
Wed, 8 May 2002 12:55:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15529
Wed, 8 May 2002 15:08:40 -0400 (EDT)
Message-ID: <3CD97342.124176E5@cips.nokia.com>
Date: Wed, 08 May 2002 11:49:38 -0700
From: Mike Ruhl <mruhl@cips.nokia.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: ESP+AH
Content-Type: multipart/mixed;
boundary="------------64166ACB4D387A4BE0F0ADA7"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
--------------64166ACB4D387A4BE0F0ADA7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Howdy,
If I send an proposal transform of ESP+AH, is it valid to receive the
propsal back as AH+ESP (instead of ESP+AH)?
Thanks,
Mike
--------------64166ACB4D387A4BE0F0ADA7
Content-Type: text/x-vcard; charset=us-ascii;
name="mruhl.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Mike Ruhl
Content-Disposition: attachment;
filename="mruhl.vcf"
begin:vcard
n:Ruhl;Michael J
tel;work:(831) 440-6472
x-mozilla-html:FALSE
org:Nokia
adr:;;;;;;
version:2.1
email;internet:mruhl@cips.nokia.com
title:Tall Blond Guy
x-mozilla-cpt:;18592
fn:Michael J Ruhl
end:vcard
--------------64166ACB4D387A4BE0F0ADA7--
From owner-ipsec@lists.tislabs.com Wed May 8 14:03:28 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g48L3RL08375;
Wed, 8 May 2002 14:03:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15806
Wed, 8 May 2002 16:23:49 -0400 (EDT)
Date: 8 May 2002 16:25:34 -0400
Message-ID: <001001c1f6ce$83bf1b00$1e72788a@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: "'ipsec list'" <ipsec@lists.tislabs.com>
Subject: Specification of tunnel/transport attribute in IKEv2
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 V6.00.2600.0000
Importance: Normal
In-Reply-To: <012a01c1f50f$9e9f7750$0100a8c0@trlhpc1>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I remember reading a posting on the list recently about the confusion
surrounding the specification of tunnel mode with SA bundles (i.e. if you
are doing ESP+AH, should you specify tunnel mode for one and transport for
the other or tunnel for both). At the bakeoffs, we decided that you should
put tunnel mode in both protocols. Also, we decided that the ordering of the
protocols in the proposal shouldn't matter, since the only ordering that
makes sense is [AH][ESP][IPCOMP].
I figured we should make sure that these ambiguities are cleared up in the
Son-of-IKE candidates. However, in perusing through the IKEv2 draft, I can
find no mention of tunnel mode or transport mode at all. Are the authors
assuming that one of the modes is going to be eliminated before we
standardize SOI, or is this just an oversight? Also, it might be nice to
mention that the ordering of the protocols within the proposal does not
affect the order in which they are applied to IPsec packets.
A final issue is where to specify the group number if (god forbid) you are
using PFS. I think we decided that it should be specified in both the ESP
and AH protocols and optionally in IPCOMP. I wish I could find the
antecedent message (I think it was by Joern), but nothing on this subject
has been posted in the last few days.
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
From owner-ipsec@lists.tislabs.com Wed May 8 15:46:40 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g48MkdL11870;
Wed, 8 May 2002 15:46:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16121
Wed, 8 May 2002 18:10:27 -0400 (EDT)
Date: Thu, 9 May 2002 01:22:35 +0300
Message-Id: <200205082222.BAA26187@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: andrew.krywaniuk@alcatel.com
CC: ipsec@lists.tislabs.com
In-reply-to: <001001c1f6ce$83bf1b00$1e72788a@ca.alcatel.com>
(andrew.krywaniuk@alcatel.com)
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <001001c1f6ce$83bf1b00$1e72788a@ca.alcatel.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Also, we decided that the ordering of the protocols in the proposal
> shouldn't matter, since the only ordering that makes sense is
> [AH][ESP]
But, if I do *WANT* to do [ESP][AH]? Basicly, I want to check IP
headers, but not wanting the sniffers to know that I'm checking...
...and if someone wonders what is checked: if I have
[IP-hdrs][ESP][AH]...
then first ESP gets applied and removed resulting
[IP-hdrs][AH]...
and then AH checks the IP-hdrs.
(and yes, the IPSEC I wrote can do this, if IKE wouldn't object.. :-)
From owner-ipsec@lists.tislabs.com Wed May 8 16:33:22 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g48NXLL13347;
Wed, 8 May 2002 16:33:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16221
Wed, 8 May 2002 18:57:38 -0400 (EDT)
Message-ID: <A090D1CFDEDFB446BD493E0A5462AB28DD4A@persephone.zento.com.au>
From: Russell Harrison <RHarrison@zento.com.au>
To: "'Mike Ruhl'" <mruhl@cips.nokia.com>, ipsec@lists.tislabs.com
Subject: RE: ESP+AH
Date: Thu, 9 May 2002 09:08:16 +1000
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
Mike,
This will be an implementation specific issue, but it should not be a
problem. Irrespective of the ordering of the proposal, the only way it
makes sense to apply both AH and ESP is [AH][ESP].
Regards,
Russell
-----Original Message-----
From: Mike Ruhl [mailto:mruhl@cips.nokia.com]
Sent: Thursday, 9 May 2002 04:50 AM
To: ipsec@lists.tislabs.com
Subject: ESP+AH
Howdy,
If I send an proposal transform of ESP+AH, is it valid to receive the
propsal back as AH+ESP (instead of ESP+AH)?
Thanks,
Mike
NOTICE: This e-mail and any files transmitted with it are confidential and
are only for the use of the person to whom they are addressed. If you are
not the intended recipient you have received this e-mail in error. Any use,
dissemination, forwarding, printing, copying or dealing in any way
whatsoever with this e-mail is strictly prohibited. If you have received
this e-mail in error, please reply immediately by way of advice to us. It is
the addressee's - recipient's duty to virus scan and otherwise test the
information provided before loading onto any computer system. Zento does
not warrant that the information is free of a virus or any other defect or
error. Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the views of
Zento.
From owner-ipsec@lists.tislabs.com Wed May 8 17:38:24 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g490cOL14862;
Wed, 8 May 2002 17:38:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16396
Wed, 8 May 2002 19:57:45 -0400 (EDT)
Date: Wed, 8 May 2002 13:01:00 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Barbara Fraser <byfraser@cisco.com>
cc: <ipsec@lists.tislabs.com>
Subject: 2 phases and assorted comments [Re: New SOI features draft]
In-Reply-To: <4.3.2.7.2.20020507182331.02c9c820@mira-sjc5-4.cisco.com>
Message-ID: <Pine.LNX.4.33.0205081220270.7525-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
First off: Thanks Paul. Excellent document. I particularly like the
short version in section 8.
Main issue: I believe that 2 phases are required.
Reason 1: some of the scenarios in Cheryl's document seem to require
multiple SA's between peers, which calls for 2 phases in my mind;
amortizing the authentication and all that. Examples: IP storage using
finer-granularity Sa's, i.e. per-port; two security gateways using
multiple Sa's between each other for various levels of protection,
different policies, different QoS, etc. We see real-world deployments,
where multiple SA's do in fact exist between two peers (whether they
are end-hosts or security gateways).
Reason 2: We're after a key management protocol, not merely a key
agreement protocol (or at least I am). If we decide on 1 phase, i.e. a
key agreement protocol, we'll need a replacement for all the key
management functions IKEv1 provides and that people need and use for
network stability. That in turn would require a few separate protocols
to replace what we have now, or, if we're lucky, a single one. So who
provides these protocols (or the single one)? Do we have the luxury of
waiting for such a key management protocol to materialize out of thin
air? What's the point of that when we already have one? Is having
functionality split over multiple protocols really that much better
than tightly integrating it into soi?
Along those lines: "reliable and authenticated informational messages"
Yes.
Further along these lines: Doing a complete exchange just to delete an
SA: No (i.e. this ties in with 2 phases and protected and reliable
notifications).
Having to redo your authentication for each key-management-message
(delete, invalid SPI, etc etc): No. (emphatically no). Think big,
i.e. ipsec concentrators. Think small, i.e. ip phones, cell phone,
palm-tops or whatever doesn't have much processor power.
Number of messages: Whatever is necessary. It seems to me the average
(usual) case should be no more than 4 messages (this doesn't seem to
be an issue). Error-cases, or other modes, that add round-trips don't
overly bother me as these should be the exception, not the rule.
Size of messages: Is pretty important (keep them as small as
possible). I believe William keeps pointing out very real problems
with UDP fragmentation and NAT and/or firewalls. Certs are big
enough. We don't need to add to this via large packets, where it can
be avoided.
Birth certificates: I guess I'd rather have dead-peer-detection. They
can cover all derivative SA's between the hosts in one keepalive, and
are useful for failover and high-availability. A combination of
initial-contact (or birth-certificates) and dead-peer-detection seems
useful. If it's an either-or proposition, I vote for
dead-peer-detection.
Cipher-suites versus free-negotiation: I don't particularly care. I
liked Pauls idea of having the protocol be free-form, but define
suites that can be presented in a uniform way in a user-interface, and
which would also limit the number of combinations we need to
test. This strikes me as the best of both worlds. I could live with
cipher-suits, though. There's bigger fish to fry anyway.
Protocol Extensibility, i.e. vendor-extensions: Absolutely necessary
to test out novel ideas. What better way to vet ideas to prevent
untested things being proposed in ID's.. Critical bit: I could live
with it, I could live without it.
jan
On Tue, 7 May 2002, Barbara Fraser wrote:
> Thanks to the IKEv2 and JFK folks, and Paul Hoffman for developing the SOI
> features document. Ted and I would like to urge you to read it and to
> discuss it on the list. We need to decide which features are important to
> SOI so that we can move forward with the protocol design work. On page 3 of
> the document, there are three identified core differences between IKEv2 and
> JFK: 1) whether the protocol has one phase or two phases, 2) how DoS
> attacks are thwarted, and 3) the use of shared secret authentication.
> According to the document, one path the working group can take is to decide
> which of these three differences is important and to then select among the
> remaining features.
>
> The scenarios where IPsec/IKE is being used, as described in Cheryl's
> document, are not included in the features document. Therefore, one area we
> must explore is the match between the above 3 differentiating qualities and
> the community's use and expectation of IPsec/IKE. Is there an installed
> base that expects these features to be present, and given the answer, what
> does the working group want to do.
>
> Let's see if we can come to consensus in the next month. This would allow
> some time for a new or updated protocol draft to be prepared prior to the
> July IETF meeting.
>
> thanks,
> Barb
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
http://www.eff.org/cafe
From owner-ipsec@lists.tislabs.com Wed May 8 18:21:00 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g491KxL16371;
Wed, 8 May 2002 18:20:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16627
Wed, 8 May 2002 20:43:02 -0400 (EDT)
To: Russell Harrison <RHarrison@zento.com.au>
Cc: "'Mike Ruhl'" <mruhl@cips.nokia.com>, ipsec@lists.tislabs.com
In-reply-to: RHarrison's message of Thu, 09 May 2002 09:08:16 +1000.
<A090D1CFDEDFB446BD493E0A5462AB28DD4A@persephone.zento.com.au>
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: ESP+AH
From: itojun@iijlab.net
Date: Thu, 09 May 2002 09:55:34 +0900
Message-ID: <2806.1020905734@itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>If I send an proposal transform of ESP+AH, is it valid to receive the
>>propsal back as AH+ESP (instead of ESP+AH)?
>This will be an implementation specific issue, but it should not be a
>problem. Irrespective of the ordering of the proposal, the only way it
>makes sense to apply both AH and ESP is [AH][ESP].
from experiences from past interop tests, i would be much happier if:
- the order of proposal on IKE packet
- interpretation of proposal
are exactly specified in the document. we saw a lot of varied
interpretation because of the document's unclarity (like how you
specify "tunnel" in the proposal). it is not good to solve protocol
ambiguity in interop events. protocol documents must be unambiguous
enough so that anyone who reads the document will end up in the
same interpretation.
itojun
From owner-ipsec@lists.tislabs.com Thu May 9 12:01:38 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g49J1cL25171;
Thu, 9 May 2002 12:01:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19209
Thu, 9 May 2002 14:08:58 -0400 (EDT)
Message-Id: <5.1.0.14.2.20020509111054.02705008@[192.168.12.25]>
X-Sender: smith@[192.168.12.25]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 May 2002 11:31:10 -0500
To: Russell Harrison <RHarrison@zento.com.au>,
"'Mike Ruhl'" <mruhl@cips.nokia.com>, ipsec@lists.tislabs.com
From: Rick Smith at Secure Computing <rick_smith@securecomputing.com>
Subject: RE: ESP+AH
In-Reply-To: <A090D1CFDEDFB446BD493E0A5462AB28DD4A@persephone.zento.com.
au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 06:08 PM 5/8/2002, Russell Harrison wrote:
> Irrespective of the ordering of the proposal, the only way it
>makes sense to apply both AH and ESP is [AH][ESP].
In a truly practical sense, I don't think it matters which way you do it. You loose a smidgin of benefit either way.
Years back in "Internet Cryptography" I suggested that [AH][ESP] makes the most sense since it makes it possible for a gateway to authenticate a packet without knowing how to decrypt it (tho' I don't know of anyone who ever made use of this capability). Implementers also liked this approach since it let you validate the ciphertext integrity before handing it to the crypto modules which, in the early days, were unnecessarily fragile.
On the other hand, a crypto purist would argue that you get weaker authentication with [AH][ESP]. It's only authenticating the ciphertext. In theory, this could allow you to change the plaintext by varying the encryption process and the changed plaintext wouldn't be detected by the AH.
Of course, this is largely a theoretical concern. It's not immediately clear what an attacker has to gain from this, nor is it clear that this is feasible in any real world IPSEC implementations.
Rick.
smith@securecomputing.com roseville, minnesota
"Authentication" in bookstores http://www.visi.com/crypto/
From owner-ipsec@lists.tislabs.com Thu May 9 22:22:39 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4A5McL11511;
Thu, 9 May 2002 22:22:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20326
Fri, 10 May 2002 00:38:36 -0400 (EDT)
Message-ID: <002401c1f7de$6b10fb80$bc64a8c0@saket>
From: "Saket Dandawate" <sdandawate@pace.stpp.soft.net>
To: <ipsec@lists.tislabs.com>
Subject: IKE v1 are multiple ISAKMP SA allowed
Date: Fri, 10 May 2002 10:21:57 +0530
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
I am implementing IKE v1 and i have few queries regarding ISAKMP SA
formation. Is it possible to have 2 ISAKMP SAs between the same two peers.
Consider the following case.
1. "A" peer places request for ISAKMP SA negotiation.
2. Peer "B" also places request for ISAKMP SA negotiation at the same time.
So, at the same instance two Main Mode negotiations start. RFC 2409 says
that after Main mode negotiation the IPsec SAs can be exchanged by either
sides. So it sound logical to have only 1 main mode negotiation. So what do
we do if two Main Mode's start simultaneously? If we have to discard one
Main Mode which one should we discard?
rfc 2409 doesnt say anything about multiple ISAKMP SA.
thanks and regards
Saket
PSS pune
From owner-ipsec@lists.tislabs.com Fri May 10 12:05:28 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AJ5SL15379;
Fri, 10 May 2002 12:05:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21238
Fri, 10 May 2002 14:15:27 -0400 (EDT)
Message-ID: <033c01c1f81f$d1169fc0$8800a8c0@xujia>
From: "Xu, Jia" <xujia@is.ac.cn>
To: <ipsec@lists.tislabs.com>
References: <002401c1f7de$6b10fb80$bc64a8c0@saket>
Subject: A problem with FreeS/WAN on Redhat Linux 7.2
Date: Fri, 10 May 2002 20:40:07 +0800
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-MIMETrack: Itemize by SMTP Server on www/ =?gb2312?b?0MXPorCyyKvKtdHpytI=?=
=?us-ascii?q?=2F?= =?us-ascii?q?CN?= =?us-ascii?q?=28?=
=?us-ascii?q?Release?= 5.0.1 (Intl)|16 July 1999) at 05/10/2002 08:39:54
PM,
Serialize by Router on www/ =?gb2312?b?0MXPorCyyKvKtdHpytI=?=
=?us-ascii?q?=2F?= =?us-ascii?q?CN?= =?us-ascii?q?=28?=
=?us-ascii?q?Release?= 5.0.1 (Intl)|16 July 1999) at 05/10/2002 08:39:56
PM,
Serialize complete at 05/10/2002 08:39:56 PM
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id OAA21233
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
I ran into a problem when I tried to install the FreeS/WAN 1.97 on Redhat Linux 7.2 (Kernel 2.4.7-10).
After I boot the machine using the new kernel, the IPSec package was installed correctly and I can use the command "ipsec". But IP networking got totally crashed. The route table became null and I can't ping any other machine.
I checked the boot.log and found the following line:
Ifup: Cannot open netlink socket: Address family not supported by protocol.
What does this mean?
Thanks,
Jia
From owner-ipsec@lists.tislabs.com Fri May 10 12:06:13 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AJ6CL15629;
Fri, 10 May 2002 12:06:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21557
Fri, 10 May 2002 14:20:56 -0400 (EDT)
Message-Id: <200205101806.g4AI6FaS002134@kebe.east.sun.com>
Subject: JFK nit
To: ipsec@lists.tislabs.com
Date: Fri, 10 May 2002 14:06:15 -0400 (EDT)
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
Sorry if this has been repeated before...
> 4.1 Structure
>
> Each message is a string of tag-length-value elements concatenated
> together. Tags are one octet. Lengths are two octets, and specify
> the number of octets of the value. Values are always integral
> numbers of octets. All octets are in big-endian order.
Ewwww. This is not a good choice. Modern machines work better with aligned
data! Say you have two nonce tags in a row (Ni, followed by Nr). Say they
start nicely on byte 0x10...
0x10 <Ni tag>
0x11 <Ni len msb>
0x12 <Ni len lsb> == 8 bytes
0x13 Ni msb
...
0x1a Ni lsb
0x1b <Nr tag>
I can load the whole nonce into a register, but I can't, because it starts at
the byte-only-boundary of 0x13.
JFK authors, please address this problem. If you want to discuss matters of
bit-twiddling import, let me know!
Dan
From owner-ipsec@lists.tislabs.com Fri May 10 14:19:43 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ALJgL26985;
Fri, 10 May 2002 14:19:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21773
Fri, 10 May 2002 16:34:15 -0400 (EDT)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p0511171ab901e1eafaea@[165.227.249.18]>
In-Reply-To: <200205101806.g4AI6FaS002134@kebe.east.sun.com>
References: <200205101806.g4AI6FaS002134@kebe.east.sun.com>
Date: Fri, 10 May 2002 13:46:33 -0700
To: Dan McDonald <danmcd@east.sun.com>, ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: JFK nit
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 2:06 PM -0400 5/10/02, Dan McDonald wrote:
>Sorry if this has been repeated before...
Or, more importantly, is part of a recent document that the WG is
using as part of its decision-making process. Please see
draft-ietf-ipsec-soi-features-00.txt, in which this is one of the
options for one of the features listed there.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Fri May 10 14:19:46 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ALJkL26997;
Fri, 10 May 2002 14:19:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21802
Fri, 10 May 2002 16:40:19 -0400 (EDT)
Date: Fri, 10 May 2002 13:49:57 -0700 (PDT)
From: Brett Eldridge <beldridg@pobox.com>
X-X-Sender: beldridg@vertigo.lo0.org
To: "Xu, Jia" <xujia@is.ac.cn>
cc: ipsec@lists.tislabs.com
Subject: Re: A problem with FreeS/WAN on Redhat Linux 7.2
In-Reply-To: <033c01c1f81f$d1169fc0$8800a8c0@xujia>
Message-ID: <Pine.BSO.4.44.0205101345160.29643-100000@vertigo.lo0.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, 10 May 2002, Xu, Jia wrote:
> I checked the boot.log and found the following line:
> Ifup: Cannot open netlink socket: Address family not supported by protocol.
is your kernel built with this option:
$ grep -i netlink .config
CONFIG_NETLINK_DEV=y
i'm not sure that it is the answer, but your error message makes it an
obvious first guess.
- brett
From owner-ipsec@lists.tislabs.com Fri May 10 14:28:51 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ALSoL27194;
Fri, 10 May 2002 14:28:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21832
Fri, 10 May 2002 16:49:22 -0400 (EDT)
Date: 10 May 2002 16:51:04 -0400
Message-ID: <001801c1f864$686126e0$1e72788a@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: "'Barbara Fraser'" <byfraser@cisco.com>,
" 'list'" <ipsec@lists.tislabs.com>
Subject: RE: New SOI features draft
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: <4.3.2.7.2.20020507182331.02c9c820@mira-sjc5-4.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I don't think Paul's document talks about anything that I haven't discussed
in the past, so for the sake of helping the discussion along, I'll summarize
my opinions here.
The IPsec WG has already reinvented the wheel twice, for mostly superficial
reasons. Now we have the choice between fixing some specific problems with
IKEv1 or reinventing the wheel again. I prefer the devil I know to the devil
I don't.
I don't think we should cripple the protocol for the sake of advancing
somebody's political agenda. A method for extensions and vendor ids is
essential. No matter what we do, we are going to run into unforseen
incompatibilities with other protocols, (e.g. the ACK-spoofing on satellite
connections or the sequence number problem with QoS or the problems with
dynamic ports).
People should be able to support whatever combination of encryption and
authentication algorithms they want, including shared secrets. However, I
welcome the idea of GUI ciphersuites to facilitate one-click
interoperability. I think the distinction between negotiation of algorithms
and ukases is BS; they are both negotiation. I do like the new wire formats
for the SA proposals, though. Almost anything would be preferable to what we
have in IKEv1.
We should support identity protection to the extent that it's easy to do.
Protection against passive attacks in both directions is best because then
you don't have to worry about asymmetrical rekeying. I think that the
protocol ought to have plausible deniability. The PD provided by IKEv2 and
JFKr with RSA Sigs is not perfect, but I think it is adequate.
I think we should rationalize the use of PFS by correlating the lifetime of
keymat with the lifetime of the SAs it creates.
Control channels have proven useful in the past. I don't discount the
possibility of using an IPsec SA as a control channel (although hijacking a
data channel would be annoying), but I am wary of a protocol that attempts
to avoid control channels altogether. Also, I will speculate that the QoS
will be an important consideration in the future.
I think that adding 2 extra messages when under attack is the best
engineering trade-off for DoS protection. The bogus UDP fragmentation
avoidance strategy described in IKEv2 is good, although I don't think people
will implement it in the near future due to the layer violation. The
technique in JFK may be superior, but it's an even worse layer violation.
Birth certificates are a worthwhile idea, but they don't solve all the link
state problems, such as when a host crashes and never comes back up (or gets
assigned a different IP in a mobile scenario).
I don't want us to remove all of the error messages from the protocol. Some
tweaking of the current error cases would be nice, though. (I am willing to
volunteer.)
IKEv2 is quite different from v1, so I'm not sure it's going to allow us to
reuse as much of the protocol code as I originally thought. However, what I
realize is that many sections of the ike process that perform tasks other
than IKE negotiation (such as the event handler and the policy engine) can
remain largely unchanged, so IKEv2 really does provide a tangible benefit in
terms of code reuse.
I would also like us to ensure that we remain compatible with the MSec WG.
GDOI is based on IKEv1, and it would be very easy for them to integrate with
IKEv2 as well, but not with JFK.
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Barbara Fraser
> Sent: Tuesday, May 07, 2002 9:46 PM
> To: ipsec@lists.tislabs.com
> Subject: New SOI features draft
>
>
> Thanks to the IKEv2 and JFK folks, and Paul Hoffman for
> developing the SOI
> features document. Ted and I would like to urge you to read it and to
> discuss it on the list. We need to decide which features are
> important to
> SOI so that we can move forward with the protocol design
> work. On page 3 of
> the document, there are three identified core differences
> between IKEv2 and
> JFK: 1) whether the protocol has one phase or two phases, 2) how DoS
> attacks are thwarted, and 3) the use of shared secret authentication.
> According to the document, one path the working group can
> take is to decide
> which of these three differences is important and to then
> select among the
> remaining features.
>
> The scenarios where IPsec/IKE is being used, as described in Cheryl's
> document, are not included in the features document.
> Therefore, one area we
> must explore is the match between the above 3 differentiating
> qualities and
> the community's use and expectation of IPsec/IKE. Is there an
> installed
> base that expects these features to be present, and given the
> answer, what
> does the working group want to do.
>
> Let's see if we can come to consensus in the next month. This
> would allow
> some time for a new or updated protocol draft to be prepared
> prior to the
> July IETF meeting.
>
> thanks,
> Barb
>
From owner-ipsec@lists.tislabs.com Fri May 10 14:29:32 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ALTVL27237;
Fri, 10 May 2002 14:29:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21819
Fri, 10 May 2002 16:47:22 -0400 (EDT)
Message-Id: <200205102059.g4AKxHSj004982@kebe.east.sun.com>
Subject: Re: JFK nit
In-Reply-To: <p0511171ab901e1eafaea@[165.227.249.18]> from Paul Hoffman / VPNC
at "May 10, 2002 01:46:33 pm"
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Date: Fri, 10 May 2002 16:59:17 -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
> >Sorry if this has been repeated before...
>
> Or, more importantly, is part of a recent document that the WG is
> using as part of its decision-making process. Please see
> draft-ietf-ipsec-soi-features-00.txt, in which this is one of the
> options for one of the features listed there.
Ummm, I think you miss my point. I don't see anything in section 6.1 that
deals with data alignment and making sure payloads are optimized for register
load/store operations.
I don't care about JFK's proposed TLV vs. the way IKEv2 does it, but I do
care very much about a TLV that is encoded to optimize for modern CPU design.
Dan
From owner-ipsec@lists.tislabs.com Fri May 10 14:41:31 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ALfUL27406;
Fri, 10 May 2002 14:41:30 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21855
Fri, 10 May 2002 17:01:25 -0400 (EDT)
Date: 10 May 2002 17:03:34 -0400
Message-ID: <001a01c1f866$26f2bf00$1e72788a@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: "'Markku Savela'" <msa@burp.tkv.asdf.org>
Cc: "'list'" <ipsec@lists.tislabs.com>
Subject: RE: Specification of tunnel/transport attribute in IKEv2
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: <200205082222.BAA26187@burp.tkv.asdf.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The merit of this ordering is not the point. Since 90% of IPsec
implementations either fundamentally do not support this feature, or maybe
could support it but have no desire to do so, yours is a rather edge case.
Therefore, I suggest that you enable it via a proprietary extension.
Leaving the specification vague on some critical issues because a few people
had some esoteric objections is exactly where we went wrong with IKEv1.
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: Markku Savela [mailto:msa@burp.tkv.asdf.org]
> Sent: Wednesday, May 08, 2002 6:23 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Specification of tunnel/transport attribute in IKEv2
>
>
>
> > Also, we decided that the ordering of the protocols in the proposal
> > shouldn't matter, since the only ordering that makes sense is
> > [AH][ESP]
>
> But, if I do *WANT* to do [ESP][AH]? Basicly, I want to check IP
> headers, but not wanting the sniffers to know that I'm checking...
>
> ...and if someone wonders what is checked: if I have
>
> [IP-hdrs][ESP][AH]...
>
> then first ESP gets applied and removed resulting
>
> [IP-hdrs][AH]...
>
> and then AH checks the IP-hdrs.
>
> (and yes, the IPSEC I wrote can do this, if IKE wouldn't object.. :-)
>
>
>
From owner-ipsec@lists.tislabs.com Fri May 10 15:00:29 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AM0SL27785;
Fri, 10 May 2002 15:00:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21936
Fri, 10 May 2002 17:21:50 -0400 (EDT)
Date: Sat, 11 May 2002 00:33:40 +0300
Message-Id: <200205102133.AAA02218@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: andrew.krywaniuk@alcatel.com
CC: ipsec@lists.tislabs.com
In-reply-to: <001a01c1f866$26f2bf00$1e72788a@ca.alcatel.com>
(andrew.krywaniuk@alcatel.com)
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <001a01c1f866$26f2bf00$1e72788a@ca.alcatel.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> The merit of this ordering is not the point. Since 90% of IPsec
> implementations either fundamentally do not support this feature, or maybe
> could support it but have no desire to do so, yours is a rather edge case.
> Therefore, I suggest that you enable it via a proprietary extension.
>
> Leaving the specification vague on some critical issues because a few people
> had some esoteric objections is exactly where we went wrong with IKEv1.
In my opinion, IKE went wrong when it started doing policy checking,
instead of just being a key negotiation.
If IKE negotiated only keys, these ordering issues would never have
surfaced.
As far as RFC-2401 is concerned, any ordering is possible (and policy
dictates the required order). Requiring something to be "proprietary
extension" just because some couldn't read the RFC-2401 properly, is
somewhat sad thing.
From owner-ipsec@lists.tislabs.com Sat May 11 10:15:38 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4BHFbL02270;
Sat, 11 May 2002 10:15:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23535
Sat, 11 May 2002 12:29:40 -0400 (EDT)
Message-Id: <200205111641.g4BGfiT68858@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: ipsec@lists.tislabs.com
Subject: addresses and IKEv2
Date: Sat, 11 May 2002 18:41:44 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The IKEv2 specs are far more clean than old IKE RFCs about
addresses of the two "parties" but there are still some
"to be clarify" points or even choices.
I've used my I-D about IPsec/IKEv1 and Mobile IPv6
(draft-dupont-ipsec-mipv6-00.txt) as a reference (BTW I am still
looking for some help for a new version of it).
Each party can get up to 5 addresses:
- the address used for the transport of phase 1 messages (T1)
- the address in the phase 1 identity (I1)
- the address in the party's certificate (C1)
- the address used for the transport of phase 2 messages (T2)
- the address in the phase 2 traffic selector (which replaces IKEv1
phase 2 identity) (I2)
(I don't consider the optional IKEv2 phase 2 identity payload until
it has an interesting semantic when it is an address identity).
A not-really-written-down rule specifies the phase 1 identity must be
the subject or an alternate subject of the party's certificate (when
certificates are used but in any case the identity and the authentication
means must be strongly bound).
So if I1 and C1 exist then I1 == C1.
There are many good reasons to never provide I1 and C1 (the "road warrior"
case, NATs, mobility, etc). So T1 should be the address found in
message headers and should not be verified. I don't disagree with this
choice but it opens a transient fake-NAT attack vulnerability (see PS2).
If only T1 exists in phase 1 then there are two interesting cases,
T1 != T2 and T1 != I2.
The case where the two phases don't get the same address in message headers
is already implicitly taken into account by the IKE-SA SPI notion:
- IKE-SA SPIs are (likely in IKEv1, always in IKEv2) unique
- IKE-SA SPIs permit more than one SA between two parties
- IKE-SA SPIs permit a party to change its address because they,
by definition, index the SAs.
Section 2.11 "Address and Port Agility" should be more explicit about
this kind of usage of SPIs.
Note the statement "IKE implicitly sets up ESP, AH, and IPcomp
associations for the same IP addresses it runs over" must in this
case interpret "IP address it runs over" as (actual) T2, not (old) T1.
In general, the address of the party is found in the last message
protected by the IKE-SA.
The last case is when the TS doesn't match the transport address:
- for a tunnel mode SA establishment, this is only a consequence
of the existence of two headers (T2 goes in the outer one, I2
in the inner one).
- for a transport mode this is an explicit address overwriting
which must be acceptable according to the policy but there is
at least a situation where this is needed (see PS3) so I'll strongly
object if T2 != I2 becomes forbidden for transport mode.
Regards
Francis.Dupont@enst-bretagne.fr
PS1: SUMMARY:
- explain somewhere the identity payload role.
- explain the advantages (and drawbacks) to use names (i.e. not addresses)
as identities (in the general meaning). Perhaps we need some SHOULD/MAY
for the different types of identity payloads.
- explain the role of SPIs of IKE-SA.
- don't throw away the transport/tunnel mode issue in phase 2.
PS2: transient pseudo-NAT attack:
This is an attack using IKE between SGs, not an attack against IKE itself.
The idea is simple: the attacker goes between the two SGs when they are
doing an IKE exchange and changes the source address of messages
(only one with IKEv2 phase 2) to the address of its victim.
If this is not caught by some ingress filtering (RFC 2827) the whole
traffic to the spoofed SG will be redirected to the victim.
This attack is generic against any protocol which can redirect traffic
(mobile IP for instance) and has provision for NAT traversal.
Unfortunately to make the protocol more efficient (two message phase 2
for instance) only makes the attack easier by reducing the time the
attacker must be on the path (where it can already do the pseudo-NAT
attack by redirecting everything to its victim. Here IKE adds the
"transient" feature and the SG (or in mobility the home agent) the mass
effect).
I don't know any defense compatible with NAT traversal (for instance
to protect the party address).
PS3: address overwriting in transport mode:
When an IPv6 mobile node (MN) is in visit (i.e. not at home) and
sends its first binding update (BU) to its home agent (HA)
(aka the home registration), it must protect it using a SA,
for instance a transport mode ESP SA with the home address (H@)
(note this solution has a lower case "must" in the mobile IPv6 I-D).
Until the BU is processed, the MN cannot use its home address:
only the care-of address (Co@) is available. So the MN must use
the Co@ as the source address of IKE messages without a home address
destination option (H@O), because the packets to the MN must be
addressed to its Co@ until the home registration is done (after
the HA will intercept all packets to the MN H@ and tunnel them
to the MN using the Co@, so the issue is only for this particular case).
So the obvious solution is to overwrite the SA address by the proper TS
(it works as in IKEv1 but is easier to explain/implement) *and* to
encode in the policy the authorization to do that (the HA is supposed
to know its MNs so this is a classical key/cert & address binding
problem, local DNSSEC on the home network reverse zone works well
for instance).
From owner-ipsec@lists.tislabs.com Sat May 11 17:36:46 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4C0akL09752;
Sat, 11 May 2002 17:36:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23923
Sat, 11 May 2002 19:50:02 -0400 (EDT)
Message-Id: <200205120002.g4C02fT18078@sydney.East.Sun.COM>
Date: Sat, 11 May 2002 20:02:41 -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: Ikev2 IKE-SA rekey collision--summary
To: ipsec@lists.tislabs.com, dfaucher@lucent.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: SfWWeTM5gwg9IF+Xpuy/sg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It looks like several votes in favor of deterministically choosing
which SA to kill in the case of duplicate SAs, based on initiator nonce.
This definitely should be in the spec, since everyone has to agree.
We can do it in the next editing pass. I haven't seen any objections.
Radia
From owner-ipsec@lists.tislabs.com Sat May 11 18:00:45 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4C10iL10081;
Sat, 11 May 2002 18:00:44 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24036
Sat, 11 May 2002 20:26:08 -0400 (EDT)
Message-Id: <200205120037.g4C0bsT18803@sydney.East.Sun.COM>
Date: Sat, 11 May 2002 20:37:54 -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: Ikev2 Traffic Selector payload
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: TW4rdDMMEtdlc7whE+uREA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I too agree with Valery Smyslov's suggestion: Have the initiator specify
the specifics of the packet that caused it to want to create
the child-SA. However, there are a bunch of ways this
could be done. Any opinions?
For example, we could say that the first selector of TSi MAY be the
specifics of the source of
the packet that's causing the initiator to create the child-SA,
and the first selector of TSr MAY be the specifics of the destination
of the packet.
The responder will choose the largest ranges of addresses and ports
it can accomodate.
So far, no changes to the spec.
But here's the change that incorporates Valery's suggestion, I think:
If the responder has multiple ranges, and can't choose, then he
MUST choose the largest set that encompasses the first TSi and first TSr.
Also, if the initiator didn't put the specifics of the first packet into
the first TSi and first TSr, then should we:
a) generalize the "SINGLE-PAIR-REQUIRED" to instead mean "you have to
be more specific, or
b) (I think I prefer this one), have a new error type for "more specific
ranges required". After receiving such an error, the initiator can
guarantee success next time by putting in the specifics of the
packet into the first TSi and first TSr.
By the way, it's 12 bytes for
each one, so it's 24 bytes of overhead to include
this information.
I'm confused about what a firewall is supposed to do if it's just
configured that when it comes up it creates a set of SAs, and there
is no specific packet that is triggering the SA creation. I suppose
that's just a misconfiguration between the policies of the two sides?
Radia
From owner-ipsec@lists.tislabs.com Sun May 12 22:58:19 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4D5wIL23022;
Sun, 12 May 2002 22:58:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA26495
Mon, 13 May 2002 00:58:32 -0400 (EDT)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: Dan McDonald <danmcd@east.sun.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: JFK nit
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 12 May 2002 20:39:43 -0400
Message-Id: <20020513003943.4A1417B51@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <200205101806.g4AI6FaS002134@kebe.east.sun.com>, Dan McDonald writes
:
>Sorry if this has been repeated before...
>
>> 4.1 Structure
>>
>> Each message is a string of tag-length-value elements concatenated
>> together. Tags are one octet. Lengths are two octets, and specify
>> the number of octets of the value. Values are always integral
>> numbers of octets. All octets are in big-endian order.
>
>
>Ewwww. This is not a good choice. Modern machines work better with aligned
>data! Say you have two nonce tags in a row (Ni, followed by Nr). Say they
>start nicely on byte 0x10...
>
>
> 0x10 <Ni tag>
> 0x11 <Ni len msb>
> 0x12 <Ni len lsb> == 8 bytes
> 0x13 Ni msb
> ...
> 0x1a Ni lsb
> 0x1b <Nr tag>
>
>I can load the whole nonce into a register, but I can't, because it starts at
>the byte-only-boundary of 0x13.
>
>JFK authors, please address this problem. If you want to discuss matters of
>bit-twiddling import, let me know!
>
We're completely agnostic about details like that. "send text".
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Mon May 13 06:17:06 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DDH5L12392;
Mon, 13 May 2002 06:17:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27431
Mon, 13 May 2002 08:34:30 -0400 (EDT)
Message-Id: <200205130851.RAA15095@csnet1.cs.tsinghua.edu.cn>
Date: Mon, 13 May 2002 17:4:18 +0800
From: =?GB2312?Q?=B6=AD=CF=FE=BB=A2?= <dongcat@csnet1.cs.tsinghua.edu.cn>
Reply-To: dongcat@csnet1.cs.tsinghua.edu.cn
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: which number is assigned to ID_IPV4_ADDR?
Organization: =?GB2312?Q?=C7=E5=BB=AA=B4=F3=D1=A7=BC=C6=CB=E3=BB=FA=CF=B5?=
X-mailer: FoxMail 4.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
charset="GB2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id EAA27028
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I found in rfc2408, ISAKMP id type ID_IPV4_ADDR's value is 0.
But in rfc2407, ID_IPV4_ADDR's value is defined as 1. When I inspected
ike message from Win2000(the fifth message of main mode), I found
ID_IPV4_ADDR's value is 1. If it were 0, I will be less confused.
Anyone know which value should be used? I am tired to look into the rfc:(
¡¡
Dong Xiaohu
dongcat@csnet1.cs.tsinghua.edu.cn¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
From owner-ipsec@lists.tislabs.com Mon May 13 06:20:34 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DDKXL12505;
Mon, 13 May 2002 06:20:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27425
Mon, 13 May 2002 08:33:29 -0400 (EDT)
X-Originating-IP: [211.167.226.82]
From: "Jiang He" <hejiang@hotmail.com>
To: ipsec@lists.tislabs.com
Date: Mon, 13 May 2002 15:44:50 +0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F248XU8x6PbhjYRGn3v000173c1@hotmail.com>
X-OriginalArrivalTime: 13 May 2002 07:44:50.0912 (UTC) FILETIME=[1032EE00:01C1FA52]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In RFC2401, for inbound processing, the following packet fields are used to
look up the SA in the SAD: Outer Header's Destination IP address, IPsec
Protocol and SPI. Why not simply use SPI as index? The SPI is enough to look
up SAD.
Using SPI as index, concerning nothing about "Outer Header's Destination IP
address", it might be convenient for SPI to be chosen so as to be a table
index for fast lookups of SAs, and also give a favor IPSec-NAT solution.
He Jiang
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
From owner-ipsec@lists.tislabs.com Mon May 13 06:37:41 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DDbeL12902;
Mon, 13 May 2002 06:37:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27546
Mon, 13 May 2002 08:59:36 -0400 (EDT)
Message-Id: <200205131312.RAA06214@relay1.trustworks.com>
From: "Valery Smyslov" <svan@trustworks.com>
Organization: TWS
To: ipsec@lists.tislabs.com,
Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Date: Mon, 13 May 2002 17:12:34 +0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Ikev2 Traffic Selector payload
In-reply-to: <200205120037.g4C0bsT18803@sydney.East.Sun.COM>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On 11 May 02, at 20:37, Radia Perlman - Boston Center wrote:
Radia,
> I too agree with Valery Smyslov's suggestion: Have the initiator specify
> the specifics of the packet that caused it to want to create
> the child-SA. However, there are a bunch of ways this
> could be done. Any opinions?
Actually, the suggestion could be generalized a bit: let initiator
put into the first TSi and the first TSr selector of the proposed SA
that, from initiator's point of view, is absolutely required for SA
to be useful for him/her. In most cases those TSi and TSr will be
taken from the packet that triggered the negotiation. The following
TSi and TSr (if any) in initiator's proposal reflect what additional
addresses/ports this SA, according to initiator's SPD, should
encompass. In other words, the first TSi and TSr show the minimal SA
"width" that will satisfy initiator, while all TSs (both the first
and the following) - an optimal SA "width" (according to his/her
SPD).
The generalization is that now the first TSi and first TSr can
contain anything, not only a single address and a single port. For
example, they may contain range or subnet. However, if they are
filled from actual packet, they still will contain single values.
> For example, we could say that the first selector of TSi MAY be the
> specifics of the source of
> the packet that's causing the initiator to create the child-SA,
> and the first selector of TSr MAY be the specifics of the destination
> of the packet.
>
> The responder will choose the largest ranges of addresses and ports
> it can accomodate.
>
> So far, no changes to the spec.
Except that the special role of the first TSi and TSr must be
documented.
> But here's the change that incorporates Valery's suggestion, I think:
>
> If the responder has multiple ranges, and can't choose, then he
> MUST choose the largest set that encompasses the first TSi and first TSr.
I'd rather to rephrase this in more general way, for example (taking
as a base 3-rd para from section 2.9):
The Responder is allowed to narrow the choices by selecting a
subset of the traffic, for instance by eliminating one or more
members of the set of traffic selectors provided the set does
not become the NULL set. However, the result of the narrowing
MUST encompass the first TSi and first TSr from initiator's
proposal. Otherwise SA MUST NOT be established.
> Also, if the initiator didn't put the specifics of the first packet into
> the first TSi and first TSr, then should we:
I'm a bit confused here. TS payloads are mandatory and contain at
least one TS substructure (according to the spec). So, "the first"
TSi and TSr are always exist. How responder could know whether
initiator put specifics of the packet into the first TSi and TS or
something else? I'd suggest he/she just always choose his TS so,
that:
1. initiator's the first TSi and TSr MUST be encompassed
2. initiator's the rest TSi and TSr MAY be encompassed (or partly
encompassed)
> a) generalize the "SINGLE-PAIR-REQUIRED" to instead mean "you have to
> be more specific, or
This notification is unnecessary with my original suggestion, but is
still useful with generalized one, because in latter case the first
TSi and TSr may contain ranges or subnets (and port ranges too).
> b) (I think I prefer this one), have a new error type for "more specific
> ranges required". After receiving such an error, the initiator can
> guarantee success next time by putting in the specifics of the
> packet into the first TSi and first TSr.
I'm confused, please see above.
> By the way, it's 12 bytes for
> each one, so it's 24 bytes of overhead to include
> this information.
>
> I'm confused about what a firewall is supposed to do if it's just
> configured that when it comes up it creates a set of SAs, and there
> is no specific packet that is triggering the SA creation. I suppose
> that's just a misconfiguration between the policies of the two sides?
With generalized suggestion it's easy to achieve: initiator just put
the desirable SA selector into the first TSi and TSr.
> Radia
Regards,
Valery Smyslov.
From owner-ipsec@lists.tislabs.com Mon May 13 09:34:46 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DGYjL17650;
Mon, 13 May 2002 09:34:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27722
Mon, 13 May 2002 09:38:04 -0400 (EDT)
Message-Id: <200205131349.g4DDnQR9029024@kebe.east.sun.com>
Subject: Re: JFK nit
In-Reply-To: <20020513003943.4A1417B51@berkshire.research.att.com> from "Steven
M. Bellovin" at "May 12, 2002 08:39:43 pm"
To: "Steven M. Bellovin" <smb@research.att.com>
Date: Mon, 13 May 2002 09:49:26 -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
<SNIP!>
> >JFK authors, please address this problem. If you want to discuss matters of
> >bit-twiddling import, let me know!
> >
>
> We're completely agnostic about details like that. "send text".
Okay! Originally, you have this:
> 4.1 Structure
>
> Each message is a string of tag-length-value elements concatenated
> together. Tags are one octet. Lengths are two octets, and specify
> the number of octets of the value. Values are always integral
> numbers of octets. All octets are in big-endian order.
Here is my proposed replacement text. I'm not sure what the consensus is
w.r.t. 32-bit or 64-bit alignment. That choice will be expressed in {32,64}
bit csh-style regexps. (I.e. given {a,b}, if you want 32-bit, substitute a,
if you want 64-bit, substitute b.)
4.1 Structure
Each message is a string of tag-length-values elements concatenated
together. Each TLV element is alignable on a {32,64}-bit boundary. Tags
are two octets, and lengths are two octets. Lengths specify the number
of octets of the value. A subsequent tag is read at the next {32,64}-bit
boundary. Computing the offset of next boundary from the current
element's length is straightforward: ((len + {3,7}) / {4,8}) * {4,8}.
Any octets needed for alignment padding MUST be set to zero.
NOTE FOR 64-Bit FOLKS: If there's a strong movement toward 64-bitness, you
may wish to increase the type-and-length to total 64 bits, so that the value
starts on a 64-bit boundary. (Useful for loading an 8-byte nonce into a
register with one instruction.)
Dan
From owner-ipsec@lists.tislabs.com Mon May 13 10:09:20 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DH9KL19140;
Mon, 13 May 2002 10:09:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27990
Mon, 13 May 2002 12:19:18 -0400 (EDT)
Message-ID: <3CDFEA74.32E5908E@F-Secure.com>
Date: Mon, 13 May 2002 19:31:48 +0300
From: Ari Huttunen <Ari.Huttunen@f-secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec-list <ipsec@lists.tislabs.com>
Subject: About draft-ietf-ipsec-soi-features-00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 May 2002 16:31:48.0770 (UTC) FILETIME=[ADE93020:01C1FA9B]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I suggest applying the well known KISS principle. In particular,
favor the features that produce the simplest SOI possible, without
too much regard for IKEv1 code re-use. Code is generally fast to
write but slow to actually make function perfectly.
I don't pretend to have read through that whole draft, but I'd
apply the KISS principle to the authentication feature as follows.
Since certificate authentication appears to be sufficient,
and all usable products needs certificate support anyway, throw
out preshared keying. One authentication method is easier
to test and make interoperable than two. Self-signed certs are also
more secure because the private key is still only in one place.
As for dead peer detection, I'd favor IKEv2 on the grounds that
the complexity of always negotiating (or failing to negotiate)
SAs permitting ICMP pings through is more than the complexity
of defining it to work via phase 1 messages and not negotiating
anything between the peers. This is particularly true of tunnel
mode SAs between gateways; who do you ping through the tunnel?
Ari
--
"They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety." - Benjamin Franklin
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 May 13 10:11:18 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DHBHL19264;
Mon, 13 May 2002 10:11:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28026
Mon, 13 May 2002 12:31:21 -0400 (EDT)
From: Yogesh.Swami@nokia.com
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Subject: DOS attacks with Cookies
Date: Mon, 13 May 2002 11:43:19 -0500
Message-ID: <025E7DD4182874489CC2F61EE0FA19CEA7C4@daebe004.NOE.Nokia.com>
Thread-Topic: DOS attacks with Cookies
Thread-Index: AcH6nUme4shNw3bqRlOF4nSIjtIluw==
To: <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 13 May 2002 16:43:19.0608 (UTC) FILETIME=[49AEB380:01C1FA9D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA28018
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
I have a question/comment on the use of Cookies for key exchange. I think there is a potential for very easy and more pointed DOS attacks with the present key exchange mechanisms. Let me give an example to explain this.
Lets say Alice wants to establish a Phase-1 SA with Bob. Also, lets say Trudy--who wants to deny Alice any access to resources--can some how snoop Alice's packets. Also let the round trip time between Alice and Trudy be far less than the roundtrip time between Alice and Bob (say Trudy is on the same LAN as Alice for the sake of this example--but Trudy does not necessarily have to be on the same LAN, all she needs is a) ability to see Alice's packet and b) her round trip time to be less than that of Bob).
When Alice sends her cookie, Trudy sees this packet coming on UDP 500, and quickly responds to Alice's cookie with a random cookie and sets the source IP address in her response packet to be that of Bob and sends it to Alice.
Alice will receive this Cookie response from Trudy long before she can receive Bob's response and since Alice has no way of knowing if this cookie really came from Bob, she will respond to this cookie thinking this is a Legitimate response and proceed with the Deffie Hellmann exchange to Bob.
When Bob receives this cookie, the cookies will not match (Since the cookie was generated by Trudy) and he will just reject the request thinking that Alice was trying to attack him. This way Trudy has successfully prevented Alice from having a secure channel with Bob.
Question: What is Alice supposed to do when she receives a Duplicate Message with a Different Cookie from the same host? Please consider the case when there was a retransmission and the retransmitted packet got corrupted in the way and the two cookies--though legitimate--have different values.
If Trudy can automate this process, she can deny access to anyone who she can snoop. If someone can write a worm that does this automatically and spread this across the internet (in this case on just needs to snoop the loop back interface and does not even need to see packet on the wire) one can create a lot more damage.
If Alice and Bob were to be two SG (security gateways), then Trudy can virtually isolate every one behind Alice's SG from accessing Bob's resources. In the process of avoiding DOS attacks we have opened room for even worse attacks (this is worse because it could be targeted towards a particular set of people without affecting others. So, for example, if two companies want to vote for a merger one of them can prevent the other by simply not allowing any secure channel, while people from the other company can easily do so)
I guess, the only solution is to do authentication before doing anything else -- in which case we don't need any cookies anymore and we can save a round trip too. Any comments?
Thanks
Best Regards
Yogesh
From owner-ipsec@lists.tislabs.com Mon May 13 11:55:05 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DIt5L22436;
Mon, 13 May 2002 11:55:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28333
Mon, 13 May 2002 14:17:56 -0400 (EDT)
Message-ID: <20020513183017.95436.qmail@web21302.mail.yahoo.com>
Date: Mon, 13 May 2002 11:30:17 -0700 (PDT)
From: SatishK Amara <kumar_amara@yahoo.com>
Subject: Re: DOS attacks with Cookies
To: Yogesh.Swami@nokia.com, ipsec@lists.tislabs.com
In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CEA7C4@daebe004.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Yogesh,
The problem you have specified is mentioned in
IKEV2 draft. In this case Alice should process
multiple responses for it's request. This would solve
the problem.
Satish
--- Yogesh.Swami@nokia.com wrote:
> Hi,
>
> I have a question/comment on the use of Cookies for
> key exchange. I think there is a potential for very
> easy and more pointed DOS attacks with the present
> key exchange mechanisms. Let me give an example to
> explain this.
>
> Lets say Alice wants to establish a Phase-1 SA with
> Bob. Also, lets say Trudy--who wants to deny Alice
> any access to resources--can some how snoop Alice's
> packets. Also let the round trip time between Alice
> and Trudy be far less than the roundtrip time
> between Alice and Bob (say Trudy is on the same LAN
> as Alice for the sake of this example--but Trudy
> does not necessarily have to be on the same LAN, all
> she needs is a) ability to see Alice's packet and b)
> her round trip time to be less than that of Bob).
>
> When Alice sends her cookie, Trudy sees this packet
> coming on UDP 500, and quickly responds to Alice's
> cookie with a random cookie and sets the source IP
> address in her response packet to be that of Bob and
> sends it to Alice.
>
> Alice will receive this Cookie response from Trudy
> long before she can receive Bob's response and since
> Alice has no way of knowing if this cookie really
> came from Bob, she will respond to this cookie
> thinking this is a Legitimate response and proceed
> with the Deffie Hellmann exchange to Bob.
>
> When Bob receives this cookie, the cookies will not
> match (Since the cookie was generated by Trudy) and
> he will just reject the request thinking that Alice
> was trying to attack him. This way Trudy has
> successfully prevented Alice from having a secure
> channel with Bob.
>
> Question: What is Alice supposed to do when she
> receives a Duplicate Message with a Different Cookie
> from the same host? Please consider the case when
> there was a retransmission and the retransmitted
> packet got corrupted in the way and the two
> cookies--though legitimate--have different values.
>
> If Trudy can automate this process, she can deny
> access to anyone who she can snoop. If someone can
> write a worm that does this automatically and spread
> this across the internet (in this case on just needs
> to snoop the loop back interface and does not even
> need to see packet on the wire) one can create a lot
> more damage.
>
> If Alice and Bob were to be two SG (security
> gateways), then Trudy can virtually isolate every
> one behind Alice's SG from accessing Bob's
> resources. In the process of avoiding DOS attacks we
> have opened room for even worse attacks (this is
> worse because it could be targeted towards a
> particular set of people without affecting others.
> So, for example, if two companies want to vote for a
> merger one of them can prevent the other by simply
> not allowing any secure channel, while people from
> the other company can easily do so)
>
> I guess, the only solution is to do authentication
> before doing anything else -- in which case we don't
> need any cookies anymore and we can save a round
> trip too. Any comments?
>
> Thanks
> Best Regards
> Yogesh
=====
In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
From owner-ipsec@lists.tislabs.com Mon May 13 11:55:06 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DIt5L22442;
Mon, 13 May 2002 11:55:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28334
Mon, 13 May 2002 14:17:58 -0400 (EDT)
Message-ID: <20020513183003.25276.qmail@web21309.mail.yahoo.com>
Date: Mon, 13 May 2002 11:30:03 -0700 (PDT)
From: SatishK Amara <kumar_amara@yahoo.com>
Subject: Re: DOS attacks with Cookies
To: Yogesh.Swami@nokia.com, ipsec@lists.tislabs.com
In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CEA7C4@daebe004.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Yogesh,
The problem you have specified is mentioned in
IKEV2 draft. In this case Alice should process
multiple responses for it's request. This would solve
the problem.
Satish
--- Yogesh.Swami@nokia.com wrote:
> Hi,
>
> I have a question/comment on the use of Cookies for
> key exchange. I think there is a potential for very
> easy and more pointed DOS attacks with the present
> key exchange mechanisms. Let me give an example to
> explain this.
>
> Lets say Alice wants to establish a Phase-1 SA with
> Bob. Also, lets say Trudy--who wants to deny Alice
> any access to resources--can some how snoop Alice's
> packets. Also let the round trip time between Alice
> and Trudy be far less than the roundtrip time
> between Alice and Bob (say Trudy is on the same LAN
> as Alice for the sake of this example--but Trudy
> does not necessarily have to be on the same LAN, all
> she needs is a) ability to see Alice's packet and b)
> her round trip time to be less than that of Bob).
>
> When Alice sends her cookie, Trudy sees this packet
> coming on UDP 500, and quickly responds to Alice's
> cookie with a random cookie and sets the source IP
> address in her response packet to be that of Bob and
> sends it to Alice.
>
> Alice will receive this Cookie response from Trudy
> long before she can receive Bob's response and since
> Alice has no way of knowing if this cookie really
> came from Bob, she will respond to this cookie
> thinking this is a Legitimate response and proceed
> with the Deffie Hellmann exchange to Bob.
>
> When Bob receives this cookie, the cookies will not
> match (Since the cookie was generated by Trudy) and
> he will just reject the request thinking that Alice
> was trying to attack him. This way Trudy has
> successfully prevented Alice from having a secure
> channel with Bob.
>
> Question: What is Alice supposed to do when she
> receives a Duplicate Message with a Different Cookie
> from the same host? Please consider the case when
> there was a retransmission and the retransmitted
> packet got corrupted in the way and the two
> cookies--though legitimate--have different values.
>
> If Trudy can automate this process, she can deny
> access to anyone who she can snoop. If someone can
> write a worm that does this automatically and spread
> this across the internet (in this case on just needs
> to snoop the loop back interface and does not even
> need to see packet on the wire) one can create a lot
> more damage.
>
> If Alice and Bob were to be two SG (security
> gateways), then Trudy can virtually isolate every
> one behind Alice's SG from accessing Bob's
> resources. In the process of avoiding DOS attacks we
> have opened room for even worse attacks (this is
> worse because it could be targeted towards a
> particular set of people without affecting others.
> So, for example, if two companies want to vote for a
> merger one of them can prevent the other by simply
> not allowing any secure channel, while people from
> the other company can easily do so)
>
> I guess, the only solution is to do authentication
> before doing anything else -- in which case we don't
> need any cookies anymore and we can save a round
> trip too. Any comments?
>
> Thanks
> Best Regards
> Yogesh
=====
In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
From owner-ipsec@lists.tislabs.com Mon May 13 11:55:56 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DItuL22495;
Mon, 13 May 2002 11:55:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28307
Mon, 13 May 2002 14:13:53 -0400 (EDT)
Message-ID: <605C42246151B7498423278ED555306F04C05A@skat.sky.com>
From: michael lin <michaell@servgate.com>
To: "Ipsec (E-mail)" <ipsec@lists.tislabs.com>
Subject: NAT Traversal - Recovering from the expiring NAT mappings
Date: Mon, 13 May 2002 11:26:46 -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,
In draft-ietf-ipsec-nat-ike-02.txt, it said
There are cases where NAT box decides to remove mappings that are still
alive (for example, the keepalive interval is too long, or the NAT box is
rebooted). To recover from those ends which are NOT behind NAT SHOULD use
the last valid authenticated packet from the other end to determine which IP
and port addresses the should be used. The host behind dynamic NAT MUST NOT
do this as otherwise it opens DoS attack possibility, and there is no need
for that, because the IP address or port of other host will not change (it
is not behind NAT).
I cannot fully understand. Suppose following:
A --- NAT --- Internat --- B
1.1.1.1 port x ----->
1.1.1.1 port x ----->
1.1.1.1 port x -----> (LAST packet)
reboot
1.1.1.2 port y -----> (NEXT packet)
If the NEXT packet (source IP 1.1.1.2 and port y) passes the authentication
check, B will know the A's IP and port have been changed, right? But in the
draft, it said "the LAST valid authenticated packet". What does it mean? Why
is it NEXT packet, but LAST packet?
And since the source IP and port could be changed, does it mean B don't need
to check source IP and port? If the packet passes authentication check, the
packet is coming from the right source.
Michael
From owner-ipsec@lists.tislabs.com Mon May 13 12:19:30 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DJJTL23226;
Mon, 13 May 2002 12:19:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28452
Mon, 13 May 2002 14:40:05 -0400 (EDT)
Message-ID: <605C42246151B7498423278ED555306F04C05B@skat.sky.com>
From: michael lin <michaell@servgate.com>
To: "Ipsec (E-mail)" <ipsec@lists.tislabs.com>
Subject: NAT Traversal - Manual key remote user
Date: Mon, 13 May 2002 11:52:25 -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,
If a remote user used manual key, there will be no IKE neogotication to
negociate NAT-Traversal. How does NAT Traversal work? Just enable UDP
Encapsulation (not NAT-Traversal, since there is no IKE) in both client and
server?
Michael
From owner-ipsec@lists.tislabs.com Mon May 13 14:46:41 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4DLkeL27368;
Mon, 13 May 2002 14:46:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28777
Mon, 13 May 2002 17:06:31 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Subject: RE: NAT Traversal - Manual key remote user
Date: Mon, 13 May 2002 14:19:16 -0700
Message-ID: <2E33960095B58E40A4D3345AB9F65EC104545C2C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: NAT Traversal - Manual key remote user
Thread-Index: AcH6sKlQWVnS6fA1QFGqJwsh12xv+QAExooA
From: "William Dixon" <wdixon@windows.microsoft.com>
To: "michael lin" <michaell@servgate.com>,
"Ipsec (E-mail)" <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 13 May 2002 21:19:17.0375 (UTC) FILETIME=[D6E170F0:01C1FAC3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA28774
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Yes, like the rest of the IPsec SA properties.
-----Original Message-----
From: michael lin [mailto:michaell@servgate.com]
Sent: Monday, May 13, 2002 11:52 AM
To: Ipsec (E-mail)
Subject: NAT Traversal - Manual key remote user
Hi,
If a remote user used manual key, there will be no IKE neogotication to
negociate NAT-Traversal. How does NAT Traversal work? Just enable UDP
Encapsulation (not NAT-Traversal, since there is no IKE) in both client
and server?
Michael
From owner-ipsec@lists.tislabs.com Mon May 13 18:59:13 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E1xCL03774;
Mon, 13 May 2002 18:59:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA29148
Mon, 13 May 2002 21:18:11 -0400 (EDT)
Message-ID: <089101c1fae6$bf43acb0$8800a8c0@xujia>
From: "Xu, Jia" <xujia@is.ac.cn>
To: "Jiang He" <hejiang@hotmail.com>, <ipsec@lists.tislabs.com>
References: <F248XU8x6PbhjYRGn3v000173c1@hotmail.com>
Subject: Re:
Date: Tue, 14 May 2002 09:29:09 +0800
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-MIMETrack: Itemize by SMTP Server on www/ =?gb2312?b?0MXPorCyyKvKtdHpytI=?=
=?us-ascii?q?=2F?= =?us-ascii?q?CN?= =?us-ascii?q?=28?=
=?us-ascii?q?Release?= 5.0.1 (Intl)|16 July 1999) at 05/14/2002 09:29:08
AM,
Serialize by Router on www/ =?gb2312?b?0MXPorCyyKvKtdHpytI=?=
=?us-ascii?q?=2F?= =?us-ascii?q?CN?= =?us-ascii?q?=28?=
=?us-ascii?q?Release?= 5.0.1 (Intl)|16 July 1999) at 05/14/2002 09:29:10
AM,
Serialize complete at 05/14/2002 09:29:10 AM
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id VAA29143
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
You should read the standard more carefully.
SPI is used to uniquely identify a security association when both Dest IP and Pro are equal.
Jia----- Original Message -----
From: "Jiang He" <hejiang@hotmail.com>
To: <ipsec@lists.tislabs.com>
Sent: Monday, May 13, 2002 3:44 PM
> In RFC2401, for inbound processing, the following packet fields are used to
> look up the SA in the SAD: Outer Header's Destination IP address, IPsec
> Protocol and SPI. Why not simply use SPI as index? The SPI is enough to look
> up SAD.
> Using SPI as index, concerning nothing about "Outer Header's Destination IP
> address", it might be convenient for SPI to be chosen so as to be a table
> index for fast lookups of SAs, and also give a favor IPSec-NAT solution.
>
> He Jiang
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
>
>
>
From owner-ipsec@lists.tislabs.com Mon May 13 20:23:01 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E3N0L06289;
Mon, 13 May 2002 20:23:00 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29366
Mon, 13 May 2002 22:39:21 -0400 (EDT)
Message-Id: <200205140251.g4E2pVT16937@sydney.East.Sun.COM>
Date: Mon, 13 May 2002 22:51:30 -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: Ikev2 Traffic Selector payload
To: ipsec@lists.tislabs.com, Radia.Perlman@sun.com, svan@trustworks.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: VUKOBwmMoi+9kBDVxlofvg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Valery Smyslov said:
>> The Responder is allowed to narrow the choices by selecting a
>> subset of the traffic, for instance by eliminating one or more
>> members of the set of traffic selectors provided the set does
>> not become the NULL set. However, the result of the narrowing
>> MUST encompass the first TSi and first TSr from initiator's
>> proposal. Otherwise SA MUST NOT be established.
I don't think adding the last 2 sentences work. The part about how the
narrowing MUST encompass...
My suggested wording was that the
From owner-ipsec@lists.tislabs.com Mon May 13 20:26:25 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E3QOL06381;
Mon, 13 May 2002 20:26:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29403
Mon, 13 May 2002 22:52:33 -0400 (EDT)
Message-Id: <200205140304.g4E34XT17324@sydney.East.Sun.COM>
Date: Mon, 13 May 2002 23:04:33 -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: Ikev2 Traffic Selector payload
To: ipsec@lists.tislabs.com, Radia.Perlman@sun.com, svan@trustworks.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: YK5MaCRdFnFFvPhjuWzJWQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
whoops..sorry about that...I'm working remotely with tiny bandwidth and
accidentally clicked on "send" before I was ready to send. Let
me finish my message...
Valery Smyslov said:
>> The Responder is allowed to narrow the choices by selecting a
>> subset of the traffic, for instance by eliminating one or more
>> members of the set of traffic selectors provided the set does
>> not become the NULL set. However, the result of the narrowing
>> MUST encompass the first TSi and first TSr from initiator's
>> proposal. Otherwise SA MUST NOT be established.
I don't think adding the last 2 sentences work. The part about how the
narrowing MUST encompass...
The reason is that unless we *require* the initiator to put a single
source/destination/port into the first selector, your suggested
wording wouldn't work. I don't think we can require it to do that, because
it might be just setting up the SA based on being configured to do so
when it comes up, rather than being triggered by a specific packet.
If Alice (the initiator) has a wider range configured than Bob, then
your wording would cause them not to be able to talk.
We could require Alice, if the SA is being triggered by a specific packet,
to specify the specifics in the first TSi and TSr (my original reply
said that Alice MAY do that, but didn't require her to).
However, if Alice is just bringing up the IKE-SA because she's configured
to do so...not as the result of a specific packet...then all the TSi's and
TSr's would be ranges, and Bob should just do the best he can. He should
certainly be allowed to narrow the range if the first of each TS is a range
rather than a specific address/port.
Radia
From owner-ipsec@lists.tislabs.com Mon May 13 22:47:46 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E5lkL11929;
Mon, 13 May 2002 22:47:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA29778
Tue, 14 May 2002 01:06:54 -0400 (EDT)
Message-ID: <002e01c1fb07$0e2122c0$bc64a8c0@saket>
From: "Saket Dandawate" <sdandawate@pace.stpp.soft.net>
To: <ipsec@lists.tislabs.com>
Subject: IKE v1 multiple ISAKMP SAs
Date: Tue, 14 May 2002 10:50:24 +0530
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi Kousik & Rob
According to you both 2 ISAKMP SAs are possible and cookies would
specify which ISAKMP SA was used.
But i want to know
1. whether it is absolutely necessary that i have to give support for
multiple ISAKMP SAs.
Consider scenarios where there are memory constrains. Could you
suggest me some scheme where i can avoid multiple ISAKMP SAs.
2. Also i want to know what do you do when ISAKMP SA expires.
Do you remove them or refresh the existing ISAKMP SA with new
information.
Also can you justify multiple ISAKMP SAs existence.
Thanks and regards
Saket
Yes, it is, and it can happen because "A" and "B" decide to simultaneously
initiate phase 1. It can also happen because "A" notices that there is
not very much time left on the SA and establishes a second SA (or a third,
or fourth...). As a result, the phase 2 SAs MUST be able to identify the
phase 1 SA used to create them (for delete and error notification purposes).
Additionally, you will have to decide (we allow the user to set either
option) if you will allow phase 2 SA's to 'dangle' past the lifetime of the
phase 1 SA.
While it is very complicated, you might want to look at the Kame, FreeSWAN,
or NetBSD code to see what they have done.
Hope this helps,
rwt
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Saket Dandawate
> Sent: Thursday, May 09, 2002 9:52 PM
> To: ipsec@lists.tislabs.com
> Subject: IKE v1 are multiple ISAKMP SA allowed
>
>
> Hi,
>
> I am implementing IKE v1 and i have few queries regarding ISAKMP SA
> formation. Is it possible to have 2 ISAKMP SAs between the
> same two peers.
>
> Consider the following case.
>
> 1. "A" peer places request for ISAKMP SA negotiation.
> 2. Peer "B" also places request for ISAKMP SA negotiation at
> the same time.
>
> So, at the same instance two Main Mode negotiations start.
> RFC 2409 says
> that after Main mode negotiation the IPsec SAs can be
> exchanged by either
> sides. So it sound logical to have only 1 main mode
> negotiation. So what do
> we do if two Main Mode's start simultaneously? If we have to
> discard one
> Main Mode which one should we discard?
>
> rfc 2409 doesnt say anything about multiple ISAKMP SA.
>
> thanks and regards
> Saket
> PSS pune
>
>
From owner-ipsec@lists.tislabs.com Tue May 14 06:08:22 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ED8ML02980;
Tue, 14 May 2002 06:08:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00681
Tue, 14 May 2002 08:23:41 -0400 (EDT)
X-mProtect: <200205132325> Nokia Silicon Valley Messaging Protection
Message-ID: <3CE04B50.63529636@iprg.nokia.com>
Date: Mon, 13 May 2002 16:25:04 -0700
From: Mukesh Gupta <mgupta@iprg.nokia.com>
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ospf@discuss.microsoft.com, ipsec@lists.tislabs.com
Subject: Using AH for Authentication for OSPFv3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi All,
I am working on providing authentication for OSPFv3 using IPv6 AH
extension header.
RFC 2740 suggests using AH/ESP extension headers of IPv6 for OSPF
authentication but doesn't provide details about how exactly this needs
to be done.
It seems that OSPFv3 shouldn't need to worry about it and it is kernel's
responsibility to provide AH authentication for all OSPFv3 packets. This
way OSPFv3 only receives authenticated packets.
OSPFv3 uses both multicast and unicast packets. Is there any standard
way of handling these packets using IPsec AH ??
Is there any standard way of implementing OSPFv3 Authentication using AH
extension header ?? Is there any vendor out there who has implemented it
??
Comments/Suggestions would be highly appreciated.
regards
Mukesh
--
******************************************************************
Often the best way to win is to forget to keep score.
******************************************************************
Mukesh Gupta
Phone: (650) 625-2264
Cell : (650) 868-9111
http://www.iprg.nokia.com/~mgupta
******************************************************************
From owner-ipsec@lists.tislabs.com Tue May 14 06:13:01 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EDD0L03230;
Tue, 14 May 2002 06:13:00 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00680
Tue, 14 May 2002 08:23:40 -0400 (EDT)
X-Originating-IP: [211.167.226.82]
From: "Jiang He" <hejiang@hotmail.com>
To: ipsec@lists.tislabs.com
Subject: Use message ID with local significance
Date: Tue, 14 May 2002 09:14:24 +0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F131Zf5MfamQFOGYJDU00018c21@hotmail.com>
X-OriginalArrivalTime: 14 May 2002 01:14:25.0268 (UTC) FILETIME=[AFD71340:01C1FAE4]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It is important for identifier such as M-ID with local significance rather
than global ones , especially for exchanges occur simultaneously among
multiple connections.
To use message ID with local significance in phase two of IKE(similar to
tunnel establishment in L2TP):
1) If Alice chooses X1 as the Initiator M-ID when initiating an exchange to
Bob, Alice should set M-ID in HDR to zero and attach a payload to indicate
X1 as initiator's M-ID for subsequent messages from Bob to Alice.
2) Then Bob sets M-ID in HDR to X1 as response to Alice, and also attaches a
payload to indicate Y1 as responder's M-ID for subsequent messages from
Alice to Bob.
3) Now for messages followed within this exchange, if A->B, set M-ID to Y1;
if B->A, set M-ID to X1.
He Jiang
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
From owner-ipsec@lists.tislabs.com Tue May 14 06:33:32 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EDXWL03832;
Tue, 14 May 2002 06:33:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00806
Tue, 14 May 2002 08:48:46 -0400 (EDT)
Message-ID: <001301c1fb47$70144170$1cf22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>,
<ipsec@lists.tislabs.com>, <svan@trustworks.com>
References: <200205140304.g4E34XT17324@sydney.East.Sun.COM>
Subject: Re: Ikev2 Traffic Selector payload
Date: Tue, 14 May 2002 08:01:13 -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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
So the suggestion now is that if the first TSi and TSr
contain a single source/destination/port then the responder's
selection MUST encompass these TSs. Otherwise, the responder
MAY narrow the choices.
----- Original Message -----
From: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>
To: <ipsec@lists.tislabs.com>; <Radia.Perlman@sun.com>;
<svan@trustworks.com>
Sent: Monday, May 13, 2002 10:04 PM
Subject: Re: Ikev2 Traffic Selector payload
| whoops..sorry about that...I'm working remotely with tiny bandwidth and
| accidentally clicked on "send" before I was ready to send. Let
| me finish my message...
|
| Valery Smyslov said:
|
| >> The Responder is allowed to narrow the choices by selecting a
| >> subset of the traffic, for instance by eliminating one or more
| >> members of the set of traffic selectors provided the set does
| >> not become the NULL set. However, the result of the narrowing
| >> MUST encompass the first TSi and first TSr from initiator's
| >> proposal. Otherwise SA MUST NOT be established.
|
| I don't think adding the last 2 sentences work. The part about how the
| narrowing MUST encompass...
|
| The reason is that unless we *require* the initiator to put a single
| source/destination/port into the first selector, your suggested
| wording wouldn't work. I don't think we can require it to do that, because
| it might be just setting up the SA based on being configured to do so
| when it comes up, rather than being triggered by a specific packet.
| If Alice (the initiator) has a wider range configured than Bob, then
| your wording would cause them not to be able to talk.
|
| We could require Alice, if the SA is being triggered by a specific packet,
| to specify the specifics in the first TSi and TSr (my original reply
| said that Alice MAY do that, but didn't require her to).
|
| However, if Alice is just bringing up the IKE-SA because she's configured
| to do so...not as the result of a specific packet...then all the TSi's and
| TSr's would be ranges, and Bob should just do the best he can. He should
| certainly be allowed to narrow the range if the first of each TS is a
range
| rather than a specific address/port.
|
| Radia
|
From owner-ipsec@lists.tislabs.com Tue May 14 06:39:20 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EDdJL03994;
Tue, 14 May 2002 06:39:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00840
Tue, 14 May 2002 08:58:55 -0400 (EDT)
Message-Id: <200205141311.RAA01907@relay1.trustworks.com>
From: "Valery Smyslov" <svan@trustworks.com>
Organization: TWS
To: ipsec@lists.tislabs.com, Radia.Perlman@sun.com
Date: Tue, 14 May 2002 17:12:20 +0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Ikev2 Traffic Selector payload
In-reply-to: <200205140304.g4E34XT17324@sydney.East.Sun.COM>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On 13 May 02, at 23:04, Radia Perlman - Boston Center wrote:
> Valery Smyslov said:
>
> >> The Responder is allowed to narrow the choices by selecting a
> >> subset of the traffic, for instance by eliminating one or more
> >> members of the set of traffic selectors provided the set does
> >> not become the NULL set. However, the result of the narrowing
> >> MUST encompass the first TSi and first TSr from initiator's
> >> proposal. Otherwise SA MUST NOT be established.
>
> I don't think adding the last 2 sentences work. The part about how the
> narrowing MUST encompass...
>
> The reason is that unless we *require* the initiator to put a single
> source/destination/port into the first selector, your suggested
Actually, I suggested that we do require initiator to always put a
traffic selector, that selector of SA being negotiated must
encompass. If SA negotiation is triggered by outgoing packet, this
selector will be taken from the packet and will contain a single
source/destination/address/port. Otherwise, if SA is setting up on
being configured to do so, this selector can be taken from SPD.
> wording wouldn't work. I don't think we can require it to do that, because
> it might be just setting up the SA based on being configured to do so
> when it comes up, rather than being triggered by a specific packet.
> If Alice (the initiator) has a wider range configured than Bob, then
> your wording would cause them not to be able to talk.
I don't see much harm here. Anyway, even if SA is created in this
case, but narrowed by responder, it might appear not to be usable for
initiator when real packet appears. In any case, when real packet
appears, new SA will be created.
> We could require Alice, if the SA is being triggered by a specific packet,
> to specify the specifics in the first TSi and TSr (my original reply
> said that Alice MAY do that, but didn't require her to).
>
> However, if Alice is just bringing up the IKE-SA because she's configured
> to do so...not as the result of a specific packet...then all the TSi's and
> TSr's would be ranges, and Bob should just do the best he can. He should
> certainly be allowed to narrow the range if the first of each TS is a range
> rather than a specific address/port.
Actually, not always. SPD entry may contain single address/port or
list of single values. But this small problem is easy to solve: just
require initiator in this case to put dummy range (represent single
address as a range of length 1) into the first selector.
To summarize:
My suggestion.
1. First TSi and TSr of initiator's TS payloads always contain
traffic description (address(es)/port(s)) that SA being created
must satisfy. This information is taken by initiator:
a) from the packet that triggered that SA negotiation (in this
case those TSi and TSr contain only single address/port)
b) from SPD in case that SA is setting up because initiator is
configured to do so (in this case those TSi and TSr may
contain anything, including range/subnet).
2. Responder always consider the first TSi and TSr as those, that
must be encompassed in resulting SA selector. If this can't be
satisfied, SA is not created.
Your suggestion (as I understand it).
1. If SA negotiation is triggered by the packet, initiator may (or
must) put specifics of this packet into first TSi and TSr. In
this case the first TSi and TSr must contain single values
(address/port).
2. If SA negotiation is performed because initiator is configured to
do so, put information from SPD into the first TSi and TSr. If
this SPD entry contain single address/port or a list of single
addresses/ports, put dummy range into the first TSi and TSr
(represent single address as a range of length 1).
3. If responder sees single address and port in the first TSi and
TSr, he/she must keep this values encompassed in SA selector
while its (possible) narrowing, or SA must not be created.
4. If responder sees anything but single address/port in the first
TSi and TSr, he/she may narow SA selector as he/she wish.
Actually, I can live with your suggestion too.
> Radia
Regards,
Valery Smyslov.
From owner-ipsec@lists.tislabs.com Tue May 14 11:26:26 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EIQQL15334;
Tue, 14 May 2002 11:26:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01485
Tue, 14 May 2002 13:38:54 -0400 (EDT)
Message-Id: <4.3.2.7.1.20020514102916.00ae88a0@golf.cpgdesign.analog.com>
X-Sender: ramana@golf.cpgdesign.analog.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 14 May 2002 10:49:30 -0700
To: Mukesh Gupta <mgupta@iprg.nokia.com>, ospf@discuss.microsoft.com,
ipsec@lists.tislabs.com
From: Ramana Yarlagadda <ramana.yarlagadda@analog.com>
Subject: Re: Using AH for Authentication for OSPFv3
In-Reply-To: <3CE04B50.63529636@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
HI,
>I am working on providing authentication for OSPFv3 using IPv6 AH
>extension header.
>
>RFC 2740 suggests using AH/ESP extension headers of IPv6 for OSPF
>authentication but doesn't provide details about how exactly this needs
>to be done.
>
>It seems that OSPFv3 shouldn't need to worry about it and it is kernel's
>responsibility to provide AH authentication for all OSPFv3 packets. This
>way OSPFv3 only receives authenticated packets.
IPSec provides security at IP level so the OSPF may not need any special
mechanism to provide security services to OSPF data. All you might need
is to configure a policy.
>OSPFv3 uses both multicast and unicast packets. Is there any standard
>way of handling these packets using IPsec AH ??
>
>Is there any standard way of implementing OSPFv3 Authentication using AH
>extension header ?? Is there any vendor out there who has implemented it
>??
The RFC2740 clearly says that OSPF is not doing any Authentication part.
For your reference i am copying the RFC...
Authentication has been removed from the OSPF protocol itself, instead
relying
on IPv6's Authentication Header and Encapsulating Security Payload.
>Comments/Suggestions would be highly appreciated.
-cheers
-ramana
From owner-ipsec@lists.tislabs.com Tue May 14 12:17:01 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4EJH0L16971;
Tue, 14 May 2002 12:17:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01697
Tue, 14 May 2002 14:38:16 -0400 (EDT)
Message-Id: <4.3.2.7.1.20020514114856.00cbcc90@golf.cpgdesign.analog.com>
X-Sender: ramana@golf.cpgdesign.analog.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 14 May 2002 11:49:10 -0700
To: Mukesh Gupta <mgupta@iprg.nokia.com>, ipsec@lists.tislabs.com
From: Ramana Yarlagadda <ramana.yarlagadda@analog.com>
Subject: Re: Using AH for Authentication for OSPFv3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
HI,
>I am working on providing authentication for OSPFv3 using IPv6 AH
>extension header.
>
>RFC 2740 suggests using AH/ESP extension headers of IPv6 for OSPF
>authentication but doesn't provide details about how exactly this needs
>to be done.
>
>It seems that OSPFv3 shouldn't need to worry about it and it is kernel's
>responsibility to provide AH authentication for all OSPFv3 packets. This
>way OSPFv3 only receives authenticated packets.
IPSec provides security at IP level so the OSPF may not need any special
mechanism to provide security services to OSPF data. All you might need
is to configure a policy.
>OSPFv3 uses both multicast and unicast packets. Is there any standard
>way of handling these packets using IPsec AH ??
>
>Is there any standard way of implementing OSPFv3 Authentication using AH
>extension header ?? Is there any vendor out there who has implemented it
>??
The RFC2740 clearly says that OSPF is not doing any Authentication part.
For your reference i am copying the RFC...
Authentication has been removed from the OSPF protocol itself, instead
relying
on IPv6's Authentication Header and Encapsulating Security Payload.
>Comments/Suggestions would be highly appreciated.
-cheers
-ramana
From owner-ipsec@lists.tislabs.com Tue May 14 14:23:54 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ELNrL20660;
Tue, 14 May 2002 14:23:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01869
Tue, 14 May 2002 16:36:08 -0400 (EDT)
X-mProtect: <200205142044> Nokia Silicon Valley Messaging Protection
Message-ID: <3CE1773D.46A19A6B@iprg.nokia.com>
Date: Tue, 14 May 2002 13:44:45 -0700
From: Mukesh Gupta <mgupta@iprg.nokia.com>
Organization: Nokia IPRG
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Ramana Yarlagadda <ramana.yarlagadda@analog.com>
CC: ospf@discuss.microsoft.com, ipsec@lists.tislabs.com
Subject: Re: Using AH for Authentication for OSPFv3
References: <4.3.2.7.1.20020514102916.00ae88a0@golf.cpgdesign.analog.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> IPSec provides security at IP level so the OSPF may not need any special
> mechanism to provide security services to OSPF data. All you might need
> is to configure a policy.
That's right.
> >OSPFv3 uses both multicast and unicast packets. Is there any standard
> >way of handling these packets using IPsec AH ??
> >
> >Is there any standard way of implementing OSPFv3 Authentication using AH
> >extension header ?? Is there any vendor out there who has implemented it
> >??
>
> The RFC2740 clearly says that OSPF is not doing any Authentication part.
> For your reference i am copying the RFC...
>
> Authentication has been removed from the OSPF protocol itself, instead
> relying on IPv6's Authentication Header and Encapsulating Security
> Payload.
I am clear about the part that OSPF is not doing any authentication and
IPsec is going to provide the security required. Since OSPF is going to send
both unicast and multicast traffic and it is going to be a point to
multipoint security, the implementation is little more involved. I was
wondering if there is any standard way of taking care of the issues.
Is there any vendor out there who has implemented this or planning to
implement this in near future ??
regards
Mukesh
--
******************************************************************
Often the test of courage is to not to die,but to live.
******************************************************************
Mukesh Gupta
Phone: (650) 625-2264
Cell : (650) 868-9111
http://www.iprg.nokia.com/~mgupta
******************************************************************
From owner-ipsec@lists.tislabs.com Tue May 14 18:07:24 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4F17NL26007;
Tue, 14 May 2002 18:07:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02347
Tue, 14 May 2002 20:21:34 -0400 (EDT)
Date: Tue, 14 May 2002 20:34:00 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Markku Savela <msa@burp.tkv.asdf.org>
cc: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-Reply-To: <200205102133.AAA02218@burp.tkv.asdf.org>
Message-ID: <Pine.BSI.3.91.1020514203259.14998A-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 May 2002, Markku Savela wrote:
> If IKE negotiated only keys, these ordering issues would never have
> surfaced.
On the contrary: they would have surfaced, in whatever other protocol
was devised to handle the policy checking.
Simply removing these issues from IKE does not make them go away.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Tue May 14 19:49:36 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4F2nZL29193;
Tue, 14 May 2002 19:49:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02592
Tue, 14 May 2002 22:04:56 -0400 (EDT)
Date: Wed, 15 May 2002 05:16:44 +0300
Message-Id: <200205150216.FAA16715@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: henry@spsystems.net
CC: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com
In-reply-to: <Pine.BSI.3.91.1020514203259.14998A-100000@spsystems.net>
(message from Henry Spencer on Tue, 14 May 2002 20:34:00 -0400 (EDT))
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <Pine.BSI.3.91.1020514203259.14998A-100000@spsystems.net>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> On Sat, 11 May 2002, Markku Savela wrote:
> > If IKE negotiated only keys, these ordering issues would never have
> > surfaced.
>
> On the contrary: they would have surfaced, in whatever other protocol
> was devised to handle the policy checking.
>
> Simply removing these issues from IKE does not make them go away.
There is no need for such other protocol. Assuming your implementation
is conformant to RFC-2401, it already does the policy checking,
whether IKE is present or not.
The issue of how the policies are installed to the hosts, is totally
different matter.
From owner-ipsec@lists.tislabs.com Wed May 15 01:01:33 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4F81XL25267;
Wed, 15 May 2002 01:01:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA03346
Wed, 15 May 2002 03:10:33 -0400 (EDT)
Message-ID: <001501c1fbe1$02a0f1c0$4d17fea9@amanda2>
From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
To: "Henry Spencer" <henry@spsystems.net>,
"Markku Savela" <msa@burp.tkv.asdf.org>
Cc: <andrew.krywaniuk@alcatel.com>, <ipsec@lists.tislabs.com>
References: <Pine.BSI.3.91.1020514203259.14998A-100000@spsystems.net>
Subject: Re: Specification of tunnel/transport attribute in IKEv2
Date: Wed, 15 May 2002 10:20:32 +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 6.00.2600.0000
Disposition-Notification-To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In protocol architecture, the policy making should be totally isolated from
the Key Agreement Protocols or Key Transport Protocols.
Ahmed
----- Original Message -----
From: "Henry Spencer" <henry@spsystems.net>
To: "Markku Savela" <msa@burp.tkv.asdf.org>
Cc: <andrew.krywaniuk@alcatel.com>; <ipsec@lists.tislabs.com>
Sent: Wednesday, May 15, 2002 3:34 AM
Subject: Re: Specification of tunnel/transport attribute in IKEv2
> On Sat, 11 May 2002, Markku Savela wrote:
> > If IKE negotiated only keys, these ordering issues would never have
> > surfaced.
>
> On the contrary: they would have surfaced, in whatever other protocol
> was devised to handle the policy checking.
>
> Simply removing these issues from IKE does not make them go away.
>
> Henry Spencer
> henry@spsystems.net
>
>
From owner-ipsec@lists.tislabs.com Wed May 15 06:51:15 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FDpEL22820;
Wed, 15 May 2002 06:51:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04154
Wed, 15 May 2002 09:08:18 -0400 (EDT)
X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to <kivinen@ssh.fi> using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15586.24743.99153.268748@ryijy.hel.fi.ssh.com>
Date: Wed, 15 May 2002 16:20:39 +0300
From: Tero Kivinen <kivinen@ssh.fi>
To: michaell@servgate.com (michael lin)
CC: <ipsec@lists.tislabs.com>
Subject: Re: NAT Traversal - Recovering from the expiring NAT mappings
References: <605C42246151B7498423278ED555306F04C05A@skat.sky.com>
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 8 min
X-Total-Time: 7 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
michaell@servgate.com (michael lin) writes:
> In draft-ietf-ipsec-nat-ike-02.txt, it said
>
> There are cases where NAT box decides to remove mappings that are still
> alive (for example, the keepalive interval is too long, or the NAT box is
> rebooted). To recover from those ends which are NOT behind NAT SHOULD use
> the last valid authenticated packet from the other end to determine which IP
> and port addresses the should be used. The host behind dynamic NAT MUST NOT
> do this as otherwise it opens DoS attack possibility, and there is no need
> for that, because the IP address or port of other host will not change (it
> is not behind NAT).
>
> I cannot fully understand. Suppose following:
>
> A --- NAT --- Internat --- B
>
> 1.1.1.1 port x ----->
> 1.1.1.1 port x ----->
> 1.1.1.1 port x -----> (LAST packet)
>
> reboot
>
> 1.1.1.2 port y -----> (NEXT packet)
This packet is received by the host B, and authenticated, and then it
is processed normally. Note, that for incoming case we do not care the
source IP. After the authentication check it will become the LAST
authenticated packet received.
> If the NEXT packet (source IP 1.1.1.2 and port y) passes the authentication
> check, B will know the A's IP and port have been changed, right?
Yes. And after that whenever it is sending packets back it needs to
use the source address of the last authenticated packet received from
the other as a destination address where to send the packets.
> But in the draft, it said "the LAST valid authenticated packet".
> What does it mean? Why is it NEXT packet, but LAST packet?
Because this is needed for sending the replies back, thus we use the
last authenticated packet in. The on transit incoming packet does not
matter, if we haven't yet seen and authenticated it, and once we have
received and authenticated it, then it is the last packet.
> And since the source IP and port could be changed, does it mean B don't need
> to check source IP and port? If the packet passes authentication check, the
> packet is coming from the right source.
Yes, B does not check the source IP and port, only the destination IP
and port matters and then we do normal authentication checks, but to
send replies back to the proper A we need the destination address and
port for the A, and those MUST be taken from the last authenticated
packet received from the A.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
From owner-ipsec@lists.tislabs.com Wed May 15 07:17:36 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FEHaL24598;
Wed, 15 May 2002 07:17:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04294
Wed, 15 May 2002 09:38:32 -0400 (EDT)
X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to <kivinen@ssh.fi> using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15586.26540.982804.447696@ryijy.hel.fi.ssh.com>
Date: Wed, 15 May 2002 16:50:36 +0300
From: Tero Kivinen <kivinen@ssh.fi>
To: danmcd@east.sun.com (Dan McDonald), ipsec@lists.tislabs.com
Subject: Re: JFK nit
References: <200205131349.g4DDnQR9029024@kebe.east.sun.com>
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 6 min
X-Total-Time: 29 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
danmcd@east.sun.com (Dan McDonald) writes:
> Sorry if this has been repeated before...
Yes, this was repeated when the IKEv1 was specified, and at that point
we decided to remove all padding. The reason was that most of the
material in the packets was still binary byte objects (certificates,
nonces, key exchange payloads, identities etc) or 8 bit or 16 bit
numbers. Also the parsing of the IKE payload compared to the
diffie-hellman / public key signing / verification etc is so fast that
it really doesn't matter. Disadvantage of padding is that it required
quite a lot of more code and caused all kind of bugs where
implementators did that incorrectly.
This was done around 1997 search for the archives for more
information.
> > 4.1 Structure
> >
> > Each message is a string of tag-length-value elements concatenated
> > together. Tags are one octet. Lengths are two octets, and specify
> > the number of octets of the value. Values are always integral
> > numbers of octets. All octets are in big-endian order.
>
>
> Ewwww. This is not a good choice. Modern machines work better with aligned
> data! Say you have two nonce tags in a row (Ni, followed by Nr). Say they
> start nicely on byte 0x10...
>
>
> 0x10 <Ni tag>
> 0x11 <Ni len msb>
> 0x12 <Ni len lsb> == 8 bytes
> 0x13 Ni msb
> ...
> 0x1a Ni lsb
> 0x1b <Nr tag>
>
> I can load the whole nonce into a register, but I can't, because it starts at
> the byte-only-boundary of 0x13.
>
> JFK authors, please address this problem. If you want to discuss matters of
> bit-twiddling import, let me know!
Note, that neither IKEv1 nor the IKEv2 draft address this problem.
They both use unaligned structures all the time.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
From owner-ipsec@lists.tislabs.com Wed May 15 07:49:34 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FEnXL27129;
Wed, 15 May 2002 07:49:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04404
Wed, 15 May 2002 10:10:46 -0400 (EDT)
Date: Wed, 15 May 2002 10:23:28 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: Markku Savela <msa@burp.tkv.asdf.org>
cc: ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-Reply-To: <200205150216.FAA16715@burp.tkv.asdf.org>
Message-ID: <Pine.BSI.3.91.1020515102020.23570E-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 15 May 2002, Markku Savela wrote:
> > Simply removing these issues from IKE does not make them go away.
>
> There is no need for such other protocol. Assuming your implementation
> is conformant to RFC-2401, it already does the policy checking,
> whether IKE is present or not.
It does not do consistency checking to ensure that the policies on the two
ends match. Nor does it have any way of selecting between policy options,
when the other end may not accept all choices. These are practical issues
of great importance, however trivial they may seem in theory.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Wed May 15 07:50:16 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FEoGL27160;
Wed, 15 May 2002 07:50:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04382
Wed, 15 May 2002 10:07:44 -0400 (EDT)
Date: Wed, 15 May 2002 10:20:14 -0400 (EDT)
From: Henry Spencer <henry@spsystems.net>
To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
cc: ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-Reply-To: <001501c1fbe1$02a0f1c0$4d17fea9@amanda2>
Message-ID: <Pine.BSI.3.91.1020515101618.23570D-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 15 May 2002, Prof. Ahmed Bin Abbas Ahmed Ali Adas wrote:
> In protocol architecture, the policy making should be totally isolated from
> the Key Agreement Protocols or Key Transport Protocols.
This is a reasonable principle, but it does not change what I said:
separating the two issues still leaves two issues to be dealt with.
The policy checking within IKE is important, and removing it from IKE does
not remove the requirement that it be dealt with somehow. Esthetically
distasteful though it may be, dealing with it within IKE has been quite
successful and has met users' needs well.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Wed May 15 09:27:39 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FGRdL00765;
Wed, 15 May 2002 09:27:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04642
Wed, 15 May 2002 11: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: <15586.34077.496033.744072@thomasm-u1.cisco.com>
Date: Wed, 15 May 2002 08:56:13 -0700 (PDT)
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Ikev2 Traffic Selector payload
In-Reply-To: <200205120037.g4C0bsT18803@sydney.East.Sun.COM>
References: <200205120037.g4C0bsT18803@sydney.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
Radia Perlman - Boston Center for Networking writes:
> But here's the change that incorporates Valery's suggestion, I think:
>
> If the responder has multiple ranges, and can't choose, then he
> MUST choose the largest set that encompasses the first TSi and first TSr.
Radia,
Is there any real life motivation for this sort of
complication? What you're proposing to fix here
smells much more like it's just smoothing over
configuration errors, with the distinct
possibility that both wrong implementations and
changes of configuration will come back to bite
whomever was relying on this behavior.
IMO, it's worth considering whether we should make
the protocols less tolerant of screwups with crisp
semantics, vs trying to be more forgiving along
with murky semantics. It seems to me that DWIM
semantics with security protocols is a pretty
treacherous road.
Mike
From owner-ipsec@lists.tislabs.com Wed May 15 09:37:28 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FGbSL01429;
Wed, 15 May 2002 09:37:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04672
Wed, 15 May 2002 11:55:35 -0400 (EDT)
To: Tero Kivinen <kivinen@ssh.fi>
Cc: danmcd@east.sun.com (Dan McDonald), ipsec@lists.tislabs.com
Subject: Re: JFK nit
References: <200205131349.g4DDnQR9029024@kebe.east.sun.com> <15586.26540.982804.447696@ryijy.hel.fi.ssh.com>
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <ekr@rtfm.com>
Date: 15 May 2002 09:09:06 -0700
In-Reply-To: Tero Kivinen's message of "Wed, 15 May 2002 16:50:36 +0300"
Message-ID: <kjlmal1jh9.fsf@romeo.rtfm.com>
Lines: 27
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Tero Kivinen <kivinen@ssh.fi> writes:
> danmcd@east.sun.com (Dan McDonald) writes:
> > Sorry if this has been repeated before...
>
> Yes, this was repeated when the IKEv1 was specified, and at that point
> we decided to remove all padding. The reason was that most of the
> material in the packets was still binary byte objects (certificates,
> nonces, key exchange payloads, identities etc) or 8 bit or 16 bit
> numbers. Also the parsing of the IKE payload compared to the
> diffie-hellman / public key signing / verification etc is so fast that
> it really doesn't matter. Disadvantage of padding is that it required
> quite a lot of more code and caused all kind of bugs where
> implementators did that incorrectly.
I tend to agree with Tero here. I'd be extremely surprised if alignment
made any significant performance difference in the IKE/JFK context.
I don't have any specific data for IKE but I do for SSL. SSL uses a
completely unaligned and rather complicated encoding scheme. I've
done extensive profiling of SSL/TLS implementations and marshalling
and unmarshalling doesn't consume any significant fraction of the CPU
time required by the implementation.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
From owner-ipsec@lists.tislabs.com Wed May 15 12:07:36 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FJ7ZL07629;
Wed, 15 May 2002 12:07:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05028
Wed, 15 May 2002 14:20:44 -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: <15586.43515.644098.353766@thomasm-u1.cisco.com>
Date: Wed, 15 May 2002 11:33:31 -0700 (PDT)
To: ipsec@lists.tislabs.com
Subject: question on "code preserving" section in Paul's draft
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
Paul's SOI draft seems to imply that an IKEv2
implementation must also implement IKEv1 as well.
Is that the intention of the IKEv2 authors? If
so, there's more to this issue, not the least of
which is an even *heavier* burden placed on small
memory footprint widgets.
Mike
From owner-ipsec@lists.tislabs.com Wed May 15 14:23:36 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FLNZL11940;
Wed, 15 May 2002 14:23:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05243
Wed, 15 May 2002 16:43:44 -0400 (EDT)
Reply-To: <rob@frohwein.xs4all.nl>
From: "Rob Frohwein" <rob@frohwein.xs4all.nl>
To: "ipsec" <ipsec@lists.tislabs.com>
Subject: authentication
Date: Wed, 15 May 2002 13:56:34 -0700
Message-ID: <PFEILHAGIMDAEANLFHCEIECBCAAA.rob@frohwein.xs4all.nl>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello ,
I know 2 types of authentication from racoon's IKE daemon.
- preshared auth keys
- certificates.
For the case of users with a dynamic ip address the initiator
can only identify itself by a certificate.
On the initiators side a spd must be specified.
At the responder's side no spd is needed.
The initiator's spd triggers IKE to create (with peer) sa keys.
At some phase the initiator sends its certificate.
The responder sends a challenge ...
The responder creates dynamically a spd.
Both IKE's set the sa's (in the kernel).
Why is it not possible for the case of dynamic (unknown) ip address
initiators to identify themselfes by means of pre-shared auth keys?
The IKE daemons on both sides could have a list like:
The initiator ofcourse still needs an spd, for the responder
the spd is created dynamically.
Initiator (client)
my-id-string (e.g. email address) authentication key
Responder (Server)
remote-id-string (e.g. email) authentiaction key
other-remote-id string other-auth key
...
Some hashing scheme on the server side could speed up lookup.
This would be more easy to use for simple case, certificates
are too complex for some cases.
-------------------
Furhermore in the spd tables (at least for kame) ip numbers must be used.
Why not also the possibility for dns name usage?
This is more generic and flexible.
Ofcourse the spd is resident in the kernel, so the kernel needs to
communicate with the IKE daemon to resolv the ip numbers.
greetings
Rob Frohwein.
From owner-ipsec@lists.tislabs.com Wed May 15 14:23:36 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FLNZL11939;
Wed, 15 May 2002 14:23:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05249
Wed, 15 May 2002 16:44:45 -0400 (EDT)
Message-Id: <200205152056.g4FKuUk09579@trpz.com>
To: Michael Thomas <mat@cisco.com>
cc: ipsec@lists.tislabs.com
Subject: Re: question on "code preserving" section in Paul's draft
In-Reply-To: Your message of "Wed, 15 May 2002 11:33:31 PDT."
<15586.43515.644098.353766@thomasm-u1.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <684.1021495619.1@tibernian.com>
Date: Wed, 15 May 2002 13:46:59 -0700
From: Dan Harkins <dharkins@tibernian.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It is not our intention to say "MUST implement" IKEv1. If you have
already implemented IKEv1 then there will be things, like the payload
parsing code, that can be reused when writing IKEv2. If you have not
implemented IKEv1 then "code preservingness" is a non-issue. We're
not forcing people to write IKEv1 so they can reuse code when implemen-
ting IKEv2. Definitely not.
I didn't get that impression from the draft but if you did then
most likely more people did too. What's the particular text that gave
you that impression so it can be re-whacked?
Dan.
On Wed, 15 May 2002 11:33:31 PDT you wrote
>
> Paul's SOI draft seems to imply that an IKEv2
> implementation must also implement IKEv1 as well.
>
> Is that the intention of the IKEv2 authors? If
> so, there's more to this issue, not the least of
> which is an even *heavier* burden placed on small
> memory footprint widgets.
>
> Mike
From owner-ipsec@lists.tislabs.com Wed May 15 16:18:33 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FNIXL13898;
Wed, 15 May 2002 16:18:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05445
Wed, 15 May 2002 18:42:13 -0400 (EDT)
From: mlafon@arkoon.net
X-Lotus-FromDomain: ARKOON
To: ipsec@lists.tislabs.com
Message-ID: <C1256BBA.007E4B51.00@arkoon-mail.arkoon.net>
Date: Thu, 16 May 2002 00:59:26 +0200
Subject: NAT-Traversal - Security Considerations
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I'm wondering myself about problems (one with Transport Mode, the other
with Tunnel Mode) that can affect NAT-Traversal.
draft-ietf-ipsec-udp-encaps-02 deals with conflict problems but (i think)
there are also problems that can occured with only one IPSec Client.
o Transport Mode
+-----+
| M |
+-----+\
\
+----+ \ / +-----+
+| WS |-----+-----------------| S |
+|+----+ / \ +-----+
|+----+ NAT
+----+
Math (M) is behind NAT and establish an SA with Server (S) using
a specific Trafic Descriptor (TS).
After that, S will send all packets for NAT and selected by TS
(everything in many implementations and configurations) to M.
This can cause a denial of service as Workstations (WS) and NAT
device will not be able to communicate with Server (S) anymore.
There is also confidentiality considerations as Math will receive
packets that are not for him.
Am I right or is there a solution to avoid this problem as many
implementations will use the SA for every packet from S to NAT ?
o Tunnel Mode
+-----+
+------| VIM |
NAT | +-----+
+-----+ \ / +----+
| M |-----+------+------| GW |
+-----+ / \ | +----+
| | +----+
| +------| IS |
+--+--+ +----+
| S |
+-----+
Math (M) is behind NAT and establish an SA with Gateway (GW) using a
specific Trafic Descriptor (TS). Using Tunnel Mode, Math will normally
use his private IP address but can also used a spoofed one: Server (S)
or VeryImportantMachine (VIM).
After that, all packet for S or VIM (according to TS) will be sent to
M via UDP encapsulated tunnel. Even packets from Internal Server (IS)
to VIM will be sent to Math.
This can be used by a malicious user to steal packets for VIM or to
deny communication with S.
Am I right or am I missing something ?
How GW can decide if Math's IP is valid and is not a spoofed one ?
--
Mathieu Lafon - Arkoon Network Security
From owner-ipsec@lists.tislabs.com Wed May 15 16:18:35 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FNIZL13910;
Wed, 15 May 2002 16:18:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05430
Wed, 15 May 2002 18:37:11 -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: <15586.58895.262379.898025@thomasm-u1.cisco.com>
Date: Wed, 15 May 2002 15:49:51 -0700 (PDT)
To: Dan Harkins <dharkins@tibernian.com>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: question on "code preserving" section in Paul's draft
In-Reply-To: <200205152056.g4FKuUk09579@trpz.com>
References: <15586.43515.644098.353766@thomasm-u1.cisco.com>
<200205152056.g4FKuUk09579@trpz.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 Harkins writes:
> It is not our intention to say "MUST implement" IKEv1. If you have
> already implemented IKEv1 then there will be things, like the payload
> parsing code, that can be reused when writing IKEv2. If you have not
> implemented IKEv1 then "code preservingness" is a non-issue. We're
> not forcing people to write IKEv1 so they can reuse code when implemen-
> ting IKEv2. Definitely not.
>
> I didn't get that impression from the draft but if you did then
> most likely more people did too. What's the particular text that gave
> you that impression so it can be re-whacked?
Dan,
This is hearsay on my part from Paul's SOI
feature's draft in section 6.2. There's some
speculation about bid down attacks, and in
particular the last paragraph it seems to imply
that it wouldn't be a big deal because IKEv1
is secure... and by extension available.
That's what I was trying to get clarification on.
Mike
From owner-ipsec@lists.tislabs.com Wed May 15 16:59:41 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FNxfL14453;
Wed, 15 May 2002 16:59:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05577
Wed, 15 May 2002 19:26:34 -0400 (EDT)
Message-Id: <200205152338.g4FNcck11960@trpz.com>
To: Michael Thomas <mat@cisco.com>
cc: ipsec@lists.tislabs.com
Subject: Re: question on "code preserving" section in Paul's draft
In-Reply-To: Your message of "Wed, 15 May 2002 15:49:51 PDT."
<15586.58895.262379.898025@thomasm-u1.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <858.1021505347.1@tibernian.com>
Date: Wed, 15 May 2002 16:29:07 -0700
From: Dan Harkins <dharkins@tibernian.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Mike,
Got it. I was looking at 6.4. I must've missed that paragraph on
the first go-round because I think it's incorrect. The 2nd to the
last paragraph of section 2.5 of draft-ietf-ipsec-ikev2-02.txt
mentions how an IKEv2 implementation can avoid being tricked into
speaking IKEv1. Basically, the active attack against the version
would fail when the two peers start sending authenticated IKEv2
messages with the "version" bit set in the IKEv2 header.
Dan.
On Wed, 15 May 2002 15:49:51 PDT you wrote
> Dan Harkins writes:
> > It is not our intention to say "MUST implement" IKEv1. If you have
> > already implemented IKEv1 then there will be things, like the payload
> > parsing code, that can be reused when writing IKEv2. If you have not
> > implemented IKEv1 then "code preservingness" is a non-issue. We're
> > not forcing people to write IKEv1 so they can reuse code when implemen-
> > ting IKEv2. Definitely not.
> >
> > I didn't get that impression from the draft but if you did then
> > most likely more people did too. What's the particular text that gave
> > you that impression so it can be re-whacked?
>
> Dan,
>
> This is hearsay on my part from Paul's SOI
> feature's draft in section 6.2. There's some
> speculation about bid down attacks, and in
> particular the last paragraph it seems to imply
> that it wouldn't be a big deal because IKEv1
> is secure... and by extension available.
>
> That's what I was trying to get clarification on.
>
> Mike
From owner-ipsec@lists.tislabs.com Wed May 15 17:14:10 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4G0EAL14675;
Wed, 15 May 2002 17:14:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05594
Wed, 15 May 2002 19:38:34 -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: <15586.62572.905659.469261@thomasm-u1.cisco.com>
Date: Wed, 15 May 2002 16:51:08 -0700 (PDT)
To: ipsec@lists.tislabs.com
Subject: SOI schizophrenia
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 admit it. I'm having a real hard time deciding
which design philosophy is actually more
appropriate for SOI. I've vacillated quite a few
times and it doesn't seem like it's about to abate
any time soon. What Paul's document tells me
(which pretty jibes with my own judgement) is that
both protocols are vast improvements over IKE, and
they seem to reach quite similar conclusions on
the basic message exchanges. Both put effort into
DoS, and simplify the on-wire combinatorial
explosion of SA establishment. All in all, they
both seem competent.
While Paul points out some of the differences in
design choices such as quick mode, pre-shared
keys, etc, what it seems to me that makes this so
difficult is that there are two different design
philosophies at work here:
1) Lean, compact public key identity keying (JFK)
2) General purpose (IKEv2)
To a degree I agree about Andrew's observation
about the devil we know, but what I think often
gets lost in this mostly-VPN-centric group is that
IKE -- and I'm afraid IKEv2 as well -- is large,
and difficult to put into cheap, embedded
devices. This isn't usually an issue for the
windoze-VPN-to-corporate-edge, but IKE's size is a
pretty hard sell for little widgets with
constrained memory footprints. I've heard all the
arguments about how the hardware folks are being
unreasonable (and heck, beating up on hardware
folks is just clean fun anyway), but I'm not
overstating the difficulty.
So from that standpoint, JFK's hardline stand on
limiting complexity and creature feep is
heartening. I've done some experiements writing a
JFK-like protocol (same in spirit, slightly
different wire format) using raw public key
identities and the results are very heartening; if
the memory police balk at its size, they are just
being obstructionist. This is implementable; no
excuses. Thus for simple widgets which operate in
star topologies to a few well known servers where
the traffic needs transport mode IPsec, JFK is
quite attractive. Maybe other uses too.
On the other hand, VPN's do add a lot of
complexity, and I think that JFK understates
that complexity. While some of that complexity is
certainly gratuitous, I think that there's an
unspoken truth here: VPN's are fundamentally more
complicated than point to point transport mode
SA's, and they drag all kinds of crufty legacy
junk into the mix like legacy authentication,
autoconfiguration, and all the rest. Is it needed?
At some level of course it's "needed"; I doubt
many of us are here for the shear fun of making
Frankenprotocols.
So what to do? What to choose? I'm at a loss. We
could flip a coin to decide the pre-shared and QM
debate, but what I don't see is how to preseve the
different design philosophies which appeal
differently to different audiences. Specifically,
I'm having a real hard time seeing how we can have
a single lean unbloated protocol like JFK without
specific bloat-resistant design constraints...
which violates the VPN desire for generality at
the expense of simplicity and footprint.
Time for some more shock therapy, I guess.
Mike
From owner-ipsec@lists.tislabs.com Thu May 16 03:22:18 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GAMHL24345;
Thu, 16 May 2002 03:22:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA07001
Thu, 16 May 2002 05:32:11 -0400 (EDT)
Message-ID: <3CE37FAC.B1AB4E11@F-Secure.com>
Date: Thu, 16 May 2002 12:45:16 +0300
From: Ari Huttunen <Ari.Huttunen@f-secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mlafon@arkoon.net
CC: ipsec@lists.tislabs.com
Subject: Re: NAT-Traversal - Security Considerations
References: <C1256BBA.007E4B51.00@arkoon-mail.arkoon.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2002 09:45:19.0924 (UTC) FILETIME=[6443DF40:01C1FCBE]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
mlafon@arkoon.net wrote:
>
> I'm wondering myself about problems (one with Transport Mode, the other
> with Tunnel Mode) that can affect NAT-Traversal.
>
> draft-ietf-ipsec-udp-encaps-02 deals with conflict problems but (i think)
> there are also problems that can occured with only one IPSec Client.
>
> o Transport Mode
>
> +-----+
> | M |
> +-----+\
> \
> +----+ \ / +-----+
> +| WS |-----+-----------------| S |
> +|+----+ / \ +-----+
> |+----+ NAT
> +----+
>
> Math (M) is behind NAT and establish an SA with Server (S) using
> a specific Trafic Descriptor (TS).
>
> After that, S will send all packets for NAT and selected by TS
> (everything in many implementations and configurations) to M.
>
> This can cause a denial of service as Workstations (WS) and NAT
> device will not be able to communicate with Server (S) anymore.
> There is also confidentiality considerations as Math will receive
> packets that are not for him.
>
> Am I right or is there a solution to avoid this problem as many
> implementations will use the SA for every packet from S to NAT ?
It would seem to me that the IPsec layer in S needs to apply NAT for
packets that come via the SA, so they appear to come from address Y.
The server in S then thinks it's talking with Y. The return packets
to Y would then be NATed, and put to the SA, all other packets would
go through without any change. This way the TS doesn't apply to packets
to/from address 'NAT', but to address 'Y'. This would break if you want
part of the packets via an SA, and part in plaintext, using TS, because
server would see different IP addresses for the client, so don't do that.
>
> o Tunnel Mode
>
> +-----+
> +------| VIM |
> NAT | +-----+
> +-----+ \ / +----+
> | M |-----+------+------| GW |
> +-----+ / \ | +----+
> | | +----+
> | +------| IS |
> +--+--+ +----+
> | S |
> +-----+
>
> Math (M) is behind NAT and establish an SA with Gateway (GW) using a
> specific Trafic Descriptor (TS). Using Tunnel Mode, Math will normally
> use his private IP address but can also used a spoofed one: Server (S)
> or VeryImportantMachine (VIM).
>
> After that, all packet for S or VIM (according to TS) will be sent to
> M via UDP encapsulated tunnel. Even packets from Internal Server (IS)
> to VIM will be sent to Math.
>
> This can be used by a malicious user to steal packets for VIM or to
> deny communication with S.
>
> Am I right or am I missing something ?
> How GW can decide if Math's IP is valid and is not a spoofed one ?
I had this in draft-huttunen-ipsec-esp-in-udp-00.txt:
>
> It is not possible for a hacker to obtain an arbitrary address in the
> intranet being protected by the GW. If address assignment by the GW
> is provided, only the address assigned to the hacker is allowed to pass
> through the GW. In the other case, address is always assigned to
> the hacker internally by the GW and the (arbitrary) IP address of the
> hacker is always translated by a NAT functionality in the GW.
Perhaps I should have copied it to this current draft? Is it clear?
Ari
>
> --
> Mathieu Lafon - Arkoon Network Security
--
"They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety." - Benjamin Franklin
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 Thu May 16 03:37:10 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GAbAL24601;
Thu, 16 May 2002 03:37:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA07058
Thu, 16 May 2002 05:58:03 -0400 (EDT)
From: mlafon@arkoon.net
X-Lotus-FromDomain: ARKOON
To: Ari Huttunen <Ari.Huttunen@f-secure.com>
cc: ipsec@lists.tislabs.com
Message-ID: <C1256BBB.003851BE.00@arkoon-mail.arkoon.net>
Date: Thu, 16 May 2002 12:15:32 +0200
Subject: Re: NAT-Traversal - Security Considerations
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
ari.huttunen@f-secure.com wrote
> It would seem to me that the IPsec layer in S needs to apply NAT for
> packets that come via the SA, so they appear to come from address Y.
> The server in S then thinks it's talking with Y. The return packets
> to Y would then be NATed, and put to the SA, all other packets would
> go through without any change. This way the TS doesn't apply to packets
> to/from address 'NAT', but to address 'Y'. This would break if you want
> part of the packets via an SA, and part in plaintext, using TS, because
> server would see different IP addresses for the client, so don't do that.
So what is the prefered usage and why does the current draft does not specify
it ? If we're not applying NAT, how do we deal with the blackhole between
S and WS/NAT when NAT-T SA is established ?
>I had this in draft-huttunen-ipsec-esp-in-udp-00.txt:
>>
>> It is not possible for a hacker to obtain an arbitrary address in the
>> intranet being protected by the GW. If address assignment by the GW
>> is provided, only the address assigned to the hacker is allowed to pass
>> through the GW. In the other case, address is always assigned to
>> the hacker internally by the GW and the (arbitrary) IP address of the
>> hacker is always translated by a NAT functionality in the GW.
>
> Perhaps I should have copied it to this current draft? Is it clear?
I don't get the point. If you do not use address assignment, it is the user
who chooses his address depending on the network he is on (hotel, airport, home,
...), so you can't control which IP he chooses.
When we're not using NAT-Traversal, we can be strict and not allow him to use
another IP than his external IP or a fixed address/network. But with NAT-T,
we can't be that strict, can we ?
Or is address assignment mandatory with NAT-Traversal ?
--
Mathieu Lafon - Arkoon Network Security
From owner-ipsec@lists.tislabs.com Thu May 16 06:27:28 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GDRRL05603;
Thu, 16 May 2002 06:27:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07328
Thu, 16 May 2002 08:44:26 -0400 (EDT)
From: Charlie_Kaufman@notesdev.ibm.com
Subject: Re: addresses and IKEv2
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Build V60_M13_04242002 Pre-release 2 April 24, 2002
Message-ID: <OFCCFB056D.82A15BB8-ON85256BBA.00077AE2-85256BBA.000EE666@iris.com>
Date: Tue, 14 May 2002 22:42:45 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build M13TT_05082002 Pre-release 2|May
08, 2002) at 05/15/2002 06:35:44 PM
MIME-Version: 1.0
Content-type: multipart/alternative;
Boundary="0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72"
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72
Content-type: text/plain; charset=US-ASCII
This posting points out the tip of a very large iceberg. I think I
understand some of the issues (but I'm not confident); some seem
unsolvable; and some raise questions about the design goals of IPsec.
Attempts to improve things for some scenarios (e.g. Mobile IP) may make
things worse in others (e.g. Address Translation Gateways).
> Each party can get up to 5 addresses:
> - the address used for the transport of phase 1 messages (T1)
> - the address in the phase 1 identity (I1)
> - the address in the party's certificate (C1)
> - the address used for the transport of phase 2 messages (T2)
> - the address in the phase 2 traffic selector (which replaces IKEv1
> phase 2 identity) (I2)
> (I don't consider the optional IKEv2 phase 2 identity payload until
> it has an interesting semantic when it is an address identity).
>
> A not-really-written-down rule specifies the phase 1 identity must be
> the subject or an alternate subject of the party's certificate (when
> certificates are used but in any case the identity and the authentication
> means must be strongly bound).
You're right that the rules aren't really written down. We tried to copy
IKEv1 on the theory that people were using it and we didn't understand the
issues well enough to have confidence that changes would be improvements.
If there are specific changes or clarifications that you think would be
useful, please propose them.
There is an implicit (or it might in fact be explicit though I couldn't
find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH
messages associated with an IKE SA will have the same source and
destination IP addresses. ESP and AH explicitly state that their SA is
identified by the combination of the Destination IP address and SPI, and
the only anticipated case for having the source address vary for an SPI is
for multi-sender multicast.
The IKEv2 spec doesn't say what an implementation should do if it receives
a cryptographically valid message from an unexpected source address. I
suppose it should. One possibility is that it could specify that such
messages are discarded and possibly logged. A second is that they be
treated as though they were cryptographically invalid. A third is that the
source address be ignored and the packet treated as though it was received
from the expected source address. A fourth is that the source address be
remembered and future messages on the SA be sent to that one.
Why would it matter? I claim that in all cases except Transport mode ESP
(which is an ESP issue rather than an IKE issue), no invalid messages can
be delivered as the result of any of these approaches. The reason it might
be desirable to accept messages from changing source addresses is to allow
the other end of an SA to change IP addresses mid-conversation without
breaking the connection. This argues for the fourth approach. But the
fourth approach makes possible a denial of service attack that is
unacceptable. An attacker need only intercept and prevent delivery of a
single IKE packet and retransmit it with a changed source IP address. The
other end will begin misdirecting responses and the IKE SA will eventually
time out. If we believe we need to be able to handle the case of a mobile
SA, I believe we would have to do it with an authenticated message. This
could be added later, but my going in position would be that if either end
of an SA changes IP addresses then the SA should be broken and
renegotiated. In that case, it doesn't matter which of the first three
approaches an implementation takes because it shouldn't happen (and no
useful attacks could exploit them).
Where addresses are important is in the ESP and AH connections tunnelled or
transported through IPsec SAs. ESP and AH are designed to "transparently"
secure applications that use existing networking APIs and may trust data
differently based on the IP address from which it originates (e.g. the Unix
rtools). For any useful security to be provided, IKE is responsible for
assuring that the authenticated identity corresponds to the IP address of
SAs.
How is this possible?
One way is by having the identities in certificates in fact be IP addresses
rather than names as implied by the quoted text above. Systems may be
deployed that way, but it would surprise me. More likely is that the
"Policy Database" installed as part of IPsec configuration contains a table
matching IP addresses to either public keys or the names that must appear
in certificates used in IKE. How that policy database would be populated
and maintained is one of the great remaining mysteries of IPsec. For
firewall to firewall tunnels, manual configuration works, and I believe
that's how people do it today. But for end to end IPsec to become routine,
better techniques will need to be deployed and standardized. It's a much
harder problem than any already solved in IPsec, so I don't expect progress
soon. I certainly don't want to hold IKEv2 hostage to solving it.
In tunnel mode, it's the inner IP addresses that must be authenticated.
They are because they must match the traffic selectors and the traffic
selectors must match the authenticated names from IKE and in the IPsec
Policy Database. In tunnel mode, the outer IP addresses are like those of
IKE... it doesn't matter what we do with them so long as we don't open
ourselves to denial of service attacks.
In transport mode, it's the outer IP addresses that must be authenticated.
This is tricky because they are not cryptographically protected. What
should ESP or AH do if they receive a transport mode IP packet with IP
addresses that don't match the traffic selectors? I believe the spec says
they should throw them away. This will break transport mode SAs if they
pass through address translation gateways. I believe the right answer to
this is to always use tunnel mode through address translation gateways.
Proposals for tunneling through address translation gateways call for use
of a special tunnel mode that is encapsulated in UDP.
IKEv2 explicitly supports Address Translation Gateways by *not*
authenticating the outer IP addresses in IKE messages. This allows
connections to work even though the outer IP addresses appear different to
the two ends of the IKE (and presumably also ESP) SAs.
It's not clear what we can or should do to provide better support for ATGs
or Mobile IP, but I'm open to suggestions.
--Charlie
This footnote confirms that either (1) this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including computer
viruses, (2) this email message was sent by a virus that appends this
footnote, or (3) (most likely) the sender of this message is trying to
raise awareness of how foolish it would be to place any confidence in
footnotes like this.
--0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
This posting points out the tip of a very large iceberg. I think I understand some of the issues (but I'm not confident); some seem unsolvable; and some raise questions about the design goals of IPsec. Attempts to improve things for some scenarios (e.g. Mobile IP) may make things worse in others (e.g. Address Translation Gateways).
> Each party can get up to 5 addresses:
> - the address used for the transport of phase 1 messages (T1)
> - the address in the phase 1 identity (I1)
> - the address in the party's certificate (C1)
> - the address used for the transport of phase 2 messages (T2)
> - the address in the phase 2 traffic selector (which replaces IKEv1
> phase 2 identity) (I2)
> (I don't consider the optional IKEv2 phase 2 identity payload until
> it has an interesting semantic when it is an address identity).
>
> A not-really-written-down rule specifies the phase 1 identity must be
> the subject or an alternate subject of the party's certificate (when
> certificates are used but in any case the identity and the authentication
> means must be strongly bound).
You're right that the rules aren't really written down. We tried to copy IKEv1 on the theory that people were using it and we didn't understand the issues well enough to have confidence that changes would be improvements. If there are specific changes or clarifications that you think would be useful, please propose them.
There is an implicit (or it might in fact be explicit though I couldn't find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH messages associated with an IKE SA will have the same source and destination IP addresses. ESP and AH explicitly state that their SA is identified by the combination of the Destination IP address and SPI, and the only anticipated case for having the source address vary for an SPI is for multi-sender multicast.
The IKEv2 spec doesn't say what an implementation should do if it receives a cryptographically valid message from an unexpected source address. I suppose it should. One possibility is that it could specify that such messages are discarded and possibly logged. A second is that they be treated as though they were cryptographically invalid. A third is that the source address be ignored and the packet treated as though it was received from the expected source address. A fourth is that the source address be remembered and future messages on the SA be sent to that one.
Why would it matter? I claim that in all cases except Transport mode ESP (which is an ESP issue rather than an IKE issue), no invalid messages can be delivered as the result of any of these approaches. The reason it might be desirable to accept messages from changing source addresses is to allow the other end of an SA to change IP addresses mid-conversation without breaking the connection. This argues for the fourth approach. But the fourth approach makes possible a denial of service attack that is unacceptable. An attacker need only intercept and prevent delivery of a single IKE packet and retransmit it with a changed source IP address. The other end will begin misdirecting responses and the IKE SA will eventually time out. If we believe we need to be able to handle the case of a mobile SA, I believe we would have to do it with an authenticated message. This could be added later, but my going in position would be that if either end of an SA changes IP addresses then the SA sh!
! ould be broken and renegotiated. In that case, it doesn't matter which of the first three approaches an implementation takes because it shouldn't happen (and no useful attacks could exploit them).
Where addresses are important is in the ESP and AH connections tunnelled or transported through IPsec SAs. ESP and AH are designed to "transparently" secure applications that use existing networking APIs and may trust data differently based on the IP address from which it originates (e.g. the Unix rtools). For any useful security to be provided, IKE is responsible for assuring that the authenticated identity corresponds to the IP address of SAs.
How is this possible?
One way is by having the identities in certificates in fact be IP addresses rather than names as implied by the quoted text above. Systems may be deployed that way, but it would surprise me. More likely is that the "Policy Database" installed as part of IPsec configuration contains a table matching IP addresses to either public keys or the names that must appear in certificates used in IKE. How that policy database would be populated and maintained is one of the great remaining mysteries of IPsec. For firewall to firewall tunnels, manual configuration works, and I believe that's how people do it today. But for end to end IPsec to become routine, better techniques will need to be deployed and standardized. It's a much harder problem than any already solved in IPsec, so I don't expect progress soon. I certainly don't want to hold IKEv2 hostage to solving it.
In tunnel mode, it's the inner IP addresses that must be authenticated. They are because they must match the traffic selectors and the traffic selectors must match the authenticated names from IKE and in the IPsec Policy Database. In tunnel mode, the outer IP addresses are like those of IKE... it doesn't matter what we do with them so long as we don't open ourselves to denial of service attacks.
In transport mode, it's the outer IP addresses that must be authenticated. This is tricky because they are not cryptographically protected. What should ESP or AH do if they receive a transport mode IP packet with IP addresses that don't match the traffic selectors? I believe the spec says they should throw them away. This will break transport mode SAs if they pass through address translation gateways. I believe the right answer to this is to always use tunnel mode through address translation gateways. Proposals for tunneling through address translation gateways call for use of a special tunnel mode that is encapsulated in UDP.
IKEv2 explicitly supports Address Translation Gateways by *not* authenticating the outer IP addresses in IKE messages. This allows connections to work even though the outer IP addresses appear different to the two ends of the IKE (and presumably also ESP) SAs.
It's not clear what we can or should do to provide better support for ATGs or Mobile IP, but I'm open to suggestions.
--Charlie
This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this.
--0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72--
From owner-ipsec@lists.tislabs.com Thu May 16 06:30:26 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GDUPL05980;
Thu, 16 May 2002 06:30:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07365
Thu, 16 May 2002 08:51:29 -0400 (EDT)
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60253EF7B@zcard0ke.ca.nortel.com>
From: "Dennis Beard"<beardd@nortelnetworks.com>
To: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: RE: question on "code preserving" section in Paul's draft
Date: Wed, 15 May 2002 15:55:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C1FC4A.7E0E2922"
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_01C1FC4A.7E0E2922
Content-Type: text/plain;
charset="iso-8859-1"
Hi Mike,
Paul can comment in more detail, however "code preserving" does not mean a
full implementation of IKEv1. Radia Perlman can also expand on this topic.
Hope this note finds you well.
Cheers,
Dennis Beard
-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Wednesday, May 15, 2002 2:34 PM
To: ipsec@lists.tislabs.com
Subject: question on "code preserving" section in Paul's draft
Paul's SOI draft seems to imply that an IKEv2
implementation must also implement IKEv1 as well.
Is that the intention of the IKEv2 authors? If
so, there's more to this issue, not the least of
which is an even *heavier* burden placed on small
memory footprint widgets.
Mike
------_=_NextPart_001_01C1FC4A.7E0E2922
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: question on "code preserving" section in Paul's = draft
Hi Mike,
Paul can comment in more detail, however "code = preserving" does not mean a full implementation of IKEv1. = Radia Perlman can also expand on this topic.
Hope this note finds you well.
Cheers,
Dennis Beard
-----Original Message-----
From: Michael Thomas [<3d.htm>mailto:mat@cisco.com]
Sent: Wednesday, May 15, 2002 2:34 PM
To: ipsec@lists.tislabs.com
Subject: question on "code preserving" = section in Paul's draft
Paul's SOI draft seems to imply that an IKEv2
implementation must also implement IKEv1 as = well.
Is that the intention of the IKEv2 authors? If
so, there's more to this issue, not the least = of
which is an even *heavier* burden placed on = small
memory footprint widgets.
= = Mike
------_=_NextPart_001_01C1FC4A.7E0E2922--
--=====================_758883276==_.ALT
Content-Type: text/html; charset="us-ascii"
From owner-ipsec@lists.tislabs.com Thu May 16 09:57:07 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GGv6L17436;
Thu, 16 May 2002 09:57:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07891
Thu, 16 May 2002 12:16:50 -0400 (EDT)
Message-Id: <200205161628.g4GGSqT89870@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: mlafon@arkoon.net
cc: ipsec@lists.tislabs.com
Subject: Re: NAT-Traversal - Security Considerations
In-reply-to: Your message of Thu, 16 May 2002 00:59:26 +0200.
<C1256BBA.007E4B51.00@arkoon-mail.arkoon.net>
Date: Thu, 16 May 2002 18:28:52 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
Math (M) is behind NAT and establish an SA with Gateway (GW) using a
specific Trafic Descriptor (TS). Using Tunnel Mode, Math will normally
use his private IP address but can also used a spoofed one: Server (S)
or VeryImportantMachine (VIM).
=> Math can spoof the address but not the identity so the attack is
a Denial of Service.
This can be used by a malicious user to steal packets for VIM or to
deny communication with S.
=> first (steal packets) should not be critical because M may not
spoof an identity so may not know keys. Second is a DoS and there is
a third one: redirect the traffic to (i.e. flood) a victim.
Am I right or am I missing something ?
=> you don't miss something: NAT traversal capability gives to bad guys
on the path all NAT possibilities and they don't need to stay on the
path (so I call this problem the "transient pseudo-NAT attack").
How GW can decide if Math's IP is valid and is not a spoofed one ?
=> it can't. The stupid defense (authentify the IP address) works but
disables the NAT traversal.
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Thu May 16 10:18:49 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GHInL19254;
Thu, 16 May 2002 10:18:49 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07916
Thu, 16 May 2002 12:43:04 -0400 (EDT)
Message-Id: <200205161539.g4GFd5T89660@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Charlie_Kaufman@notesdev.ibm.com
cc: ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
In-reply-to: Your message of Tue, 14 May 2002 22:42:45 EDT.
<OFCCFB056D.82A15BB8-ON85256BBA.00077AE2-85256BBA.000EE666@iris.com>
Date: Thu, 16 May 2002 17:39:05 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
This posting points out the tip of a very large iceberg. I think I
understand some of the issues (but I'm not confident); some seem
unsolvable; and some raise questions about the design goals of IPsec.
Attempts to improve things for some scenarios (e.g. Mobile IP) may make
things worse in others (e.g. Address Translation Gateways).
=> IMHO Mobile IP and NATs need the same thing: some "address agility".
> Each party can get up to 5 addresses:
> - the address used for the transport of phase 1 messages (T1)
> - the address in the phase 1 identity (I1)
> - the address in the party's certificate (C1)
> - the address used for the transport of phase 2 messages (T2)
> - the address in the phase 2 traffic selector (which replaces IKEv1
> phase 2 identity) (I2)
> (I don't consider the optional IKEv2 phase 2 identity payload until
> it has an interesting semantic when it is an address identity).
>
> A not-really-written-down rule specifies the phase 1 identity must be
> the subject or an alternate subject of the party's certificate (when
> certificates are used but in any case the identity and the authentication
> means must be strongly bound).
You're right that the rules aren't really written down. We tried to copy
IKEv1 on the theory that people were using it and we didn't understand the
issues well enough to have confidence that changes would be improvements.
If there are specific changes or clarifications that you think would be
useful, please propose them.
=> the purpose of my mail was to open the discussion about this kind
of changes/clarifications.
There is an implicit (or it might in fact be explicit though I couldn't
find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH
messages associated with an IKE SA will have the same source and
destination IP addresses. ESP and AH explicitly state that their SA is
identified by the combination of the Destination IP address and SPI, and
the only anticipated case for having the source address vary for an SPI is
for multi-sender multicast.
=> I disagree:
- draft-ietf-ipsec-esp-v3-02.txt (and Stephen Kent's presentation
at the last IETF) makes very clear that SPI should become the unique
identifier of a SA at the exception of multicast destination
(where the issue is not multiple sender but multiple recipients which
can not enforce the unicity of the SPI).
- RFC 2401 is very clear about the outer source address of ESP (and AH)
in tunnel mode: it can be *any* address of the source, etc.
(cf 5.1.2.1 3 NOTE, 5.2.1, etc)
The IKEv2 spec doesn't say what an implementation should do if it receives
a cryptographically valid message from an unexpected source address.
I suppose it should.
=> this is a point which must be fixed. If we agree it should, the IKE-SA
SPI shall become the way to identify "sessions".
One possibility is that it could specify that such
messages are discarded and possibly logged. A second is that they be
treated as though they were cryptographically invalid. A third is that the
source address be ignored and the packet treated as though it was received
from the expected source address. A fourth is that the source address be
remembered and future messages on the SA be sent to that one.
=> only the first and last possibilities have a meaning but
we can not get both.
Why would it matter? I claim that in all cases except Transport mode ESP
(which is an ESP issue rather than an IKE issue), no invalid messages can
be delivered as the result of any of these approaches.
The reason it might be desirable to accept messages from changing
source addresses is to allow the other end of an SA to change IP
addresses mid-conversation without breaking the connection.
=> they are two common cases where this can happen: mobility and NATs.
This argues for the fourth approach.
=> this is why I'd like to get it (or with the first approach a real
discussion).
But the fourth approach makes possible a denial of service attack that is
unacceptable. An attacker need only intercept and prevent delivery of a
single IKE packet and retransmit it with a changed source IP address.
=> this is not the fourth approach because you've added a NAT traversal
property. For mobility (without NAT traversal capability) the source can
authentify its address, for instance you can imagine the protection in IKEv2
is AH+ESP like in place of ESP like only.
The other end will begin misdirecting responses and the IKE SA will
eventually time out.
=> but with very efficient protocols like IKEv2 CREATE-CHILD-SA exchange
to spoof one message is enough.
If we believe we need to be able to handle the case of a mobile
SA, I believe we would have to do it with an authenticated message.
=> I believe you mean a message where the source address is authenticated.
This could be added later, but my going in position would be that
if either end of an SA changes IP addresses then the SA should be
broken and renegotiated.
=> this can become incredibly too expensive if this imply to redo
a DH exchange each time a mobile moves or a NAT resets some state.
Another argument is the authentication in ESP/AH should reject any
packet which doesn't come from the right node, so to check addresses
is both annoying (this removes flexibility) and unnecessary (crypto
is more powerful than access list).
I propose to add this question into SOI requirements.
In that case, it doesn't matter which of the first three
approaches an implementation takes because it shouldn't happen (and no
useful attacks could exploit them).
=> we have to split attacks into attacks from address agility and attacks
from NAT traversal capability. BTW the second kind of attacks is not
only against IKE/SOI and I am writing an I-D about this.
Where addresses are important is in the ESP and AH connections tunnelled or
transported through IPsec SAs. ESP and AH are designed to "transparently"
secure applications that use existing networking APIs and may trust data
differently based on the IP address from which it originates (e.g. the Unix
rtools). For any useful security to be provided, IKE is responsible for
assuring that the authenticated identity corresponds to the IP address of
SAs.
=> If you apply this to ESP/AH we come back to a previous point,
if you apply this to IKE then "road warriors" may not use IKE.
How is this possible?
=> the question is more "is this desirable?"
One way is by having the identities in certificates in fact be IP addresses
rather than names as implied by the quoted text above. Systems may be
deployed that way, but it would surprise me. More likely is that the
"Policy Database" installed as part of IPsec configuration contains a table
matching IP addresses to either public keys or the names that must appear
in certificates used in IKE. How that policy database would be populated
and maintained is one of the great remaining mysteries of IPsec. For
firewall to firewall tunnels, manual configuration works, and I believe
that's how people do it today. But for end to end IPsec to become routine,
better techniques will need to be deployed and standardized. It's a much
harder problem than any already solved in IPsec, so I don't expect progress
soon. I certainly don't want to hold IKEv2 hostage to solving it.
=> IAB recommended to use names in place of addresses, and don't forget
cases like the "road warrior" one.
It seems we are going on the path to separate the identity from the address
but obviously we should not go too far or we'll open the door to new attacks.
Bit I disagree we shouldn't care. And there are many things we can do,
for instance use DNSsec or authentify IKE message headers.
In tunnel mode, it's the inner IP addresses that must be authenticated.
They are because they must match the traffic selectors and the traffic
selectors must match the authenticated names from IKE and in the IPsec
Policy Database. In tunnel mode, the outer IP addresses are like those of
IKE... it doesn't matter what we do with them so long as we don't open
ourselves to denial of service attacks.
=> I believe you aggree that today the issue is not really handled
(for instance many "mobile VPN" setups have no provision against
transient pseudo-NAT attacks) and, even more important, users have
no idea of what to do...
In transport mode, it's the outer IP addresses that must be authenticated.
This is tricky because they are not cryptographically protected. What
should ESP or AH do if they receive a transport mode IP packet with IP
addresses that don't match the traffic selectors? I believe the spec says
they should throw them away.
=> yes, RFC 2401 5.2.1 has a MUST for this case.
This will break transport mode SAs if they pass through address
translation gateways.
=> IMHO this is a good property.
I believe the right answer to
this is to always use tunnel mode through address translation gateways.
Proposals for tunneling through address translation gateways call for use
of a special tunnel mode that is encapsulated in UDP.
=> UDP is another problem which doesn't come from NAT, but for not 1-1
mapping.
IKEv2 explicitly supports Address Translation Gateways by *not*
authenticating the outer IP addresses in IKE messages.
=> and this opens the door to the transient pseudo-NAT attack even
when it is known there is no NAT on the path. I am not against the
feature but against to get it by default (and perhaps always) without
proper considerations about consequences.
This allows
connections to work even though the outer IP addresses appear different to
the two ends of the IKE (and presumably also ESP) SAs.
It's not clear what we can or should do to provide better support for ATGs
or Mobile IP, but I'm open to suggestions.
=> I believe we should both provide better support and better graduation
between what is accepted and consequences on possible attacks.
Perhaps the ipsec WG needs a mobility concern from IESG like the security
concerns received by the mobile-ip WG some times ago?
Thanks
Francis.Dupont@enst-bretagne.fr
PS: random ideas about support/attacks:
- put the address in the identity and check it:
no support, inflexible but very (too?) secure.
(I believe this is supported by many IKE(v1) implementations today
but only testing (or source reading) shows if the check is done)
- put a FQDN in the identity and verify address->FQDN mapping via DNSsec:
addresses can be changed if DNS is updated, rely on DNSsec deploiment.
(perhaps supported by implementations which can get keys/certificates
from DNS but is it from DNS or from DNSsec?)
- spit "transport" addresses and identities, never check them but
don't accept change:
support NAT traversal but not NAT resets or mobility, vulnerable
to transient pseudo-NAT attacks on multiple and two way messages
(seems to be the IKEv2 default)
- spit "transport" addresses and identities, protect IP headers and
accept change between "phases":
support of mobility but not of NAT traversal (i.e. this is the IPv6
solution), no vulnerability
(should be considered for SOI? note to put the (new) source address
inside messages is enough to protect it, this makes "movements" more
explicit too)
- spit "transport" addresses and identities, no header protection,
accept change between "phases":
support of mobility and NAT traversal and NAT reset, vulnerable to
transient pseudo-NAT attacks
(if this is considered for SOI IMHO this should not be the default)
From owner-ipsec@lists.tislabs.com Thu May 16 14:04:42 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GL4gL25644;
Thu, 16 May 2002 14:04:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08421
Thu, 16 May 2002 16:23:26 -0400 (EDT)
Date: Thu, 16 May 2002 13:35:31 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
X-Sender: vilhuber@localhost
To: Rob Frohwein <rob@frohwein.xs4all.nl>
cc: ipsec <ipsec@lists.tislabs.com>
Subject: Re: authentication
In-Reply-To: <PFEILHAGIMDAEANLFHCEIECBCAAA.rob@frohwein.xs4all.nl>
Message-ID: <Pine.LNX.4.21.0205161334010.2302-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 15 May 2002, Rob Frohwein wrote:
> Hello ,
>
> I know 2 types of authentication from racoon's IKE daemon.
> - preshared auth keys
> - certificates.
>
> For the case of users with a dynamic ip address the initiator
> can only identify itself by a certificate.
>
> On the initiators side a spd must be specified.
> At the responder's side no spd is needed.
> The initiator's spd triggers IKE to create (with peer) sa keys.
> At some phase the initiator sends its certificate.
> The responder sends a challenge ...
> The responder creates dynamically a spd.
> Both IKE's set the sa's (in the kernel).
>
> Why is it not possible for the case of dynamic (unknown) ip address
> initiators to identify themselfes by means of pre-shared auth keys?
Because the ID payload is in MM5 which is encrypted. So you need to
find the key without knowing the ID. The only way to do that is by the
IP address.
jan
> The IKE daemons on both sides could have a list like:
> The initiator ofcourse still needs an spd, for the responder
> the spd is created dynamically.
>
> Initiator (client)
> my-id-string (e.g. email address) authentication key
>
> Responder (Server)
> remote-id-string (e.g. email) authentiaction key
> other-remote-id string other-auth key
> ...
>
> Some hashing scheme on the server side could speed up lookup.
>
> This would be more easy to use for simple case, certificates
> are too complex for some cases.
>
> -------------------
>
> Furhermore in the spd tables (at least for kame) ip numbers must be used.
> Why not also the possibility for dns name usage?
> This is more generic and flexible.
> Ofcourse the spd is resident in the kernel, so the kernel needs to
> communicate with the IKE daemon to resolv the ip numbers.
>
>
> greetings
> Rob Frohwein.
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Thu May 16 14:22:46 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GLMkL26187;
Thu, 16 May 2002 14:22:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08485
Thu, 16 May 2002 16:46:32 -0400 (EDT)
Date: Thu, 16 May 2002 13:58:38 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
X-Sender: vilhuber@localhost
To: Michael Thomas <mat@cisco.com>
cc: ipsec@lists.tislabs.com
Subject: Re: SOI schizophrenia
In-Reply-To: <15586.62572.905659.469261@thomasm-u1.cisco.com>
Message-ID: <Pine.LNX.4.21.0205161337340.2302-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 15 May 2002, Michael Thomas wrote:
>
> I admit it. I'm having a real hard time deciding
> which design philosophy is actually more
> appropriate for SOI. I've vacillated quite a few
> times and it doesn't seem like it's about to abate
> any time soon. What Paul's document tells me
> (which pretty jibes with my own judgement) is that
> both protocols are vast improvements over IKE, and
> they seem to reach quite similar conclusions on
> the basic message exchanges. Both put effort into
> DoS, and simplify the on-wire combinatorial
> explosion of SA establishment. All in all, they
> both seem competent.
>
They are both competent from a cryptography point of view, but only
one actually allows key management in any sane way. I think that's
where the two part company, and we as a group need to decide which is
more appropriate: A key *agreement* protocol (JFK) which will require
other protocols (ICMP? Right..) to help solve the current deployment
stability, or a key *management* protocol (IKEv2), that let's you
manage the key we agreed on, without requiring other external
management protocols.
The rest of the topics are in my mind really ancillary (You want it
red? You can have it red. You want cipher suites? You can have those?
You want pre-shared keys? We could add that if necessary. You would
prefer it round instead of square? Done.).
So one important question is:
Is
(simple + n*(extra management protocol)) <
(complex + 0*(extra management protocol))
?
Of course another question might be: Do we need key management? Based
on operational experience and fixing lots of customer deployment and
network stability problems, I'd say that's an emphatic YES.
2 phases? Yes.
Key management? Yes.
Simplicity? Only where it doesn't conflict with being able to maintain
an operational network.
jan
> While Paul points out some of the differences in
> design choices such as quick mode, pre-shared
> keys, etc, what it seems to me that makes this so
> difficult is that there are two different design
> philosophies at work here:
>
> 1) Lean, compact public key identity keying (JFK)
> 2) General purpose (IKEv2)
>
> To a degree I agree about Andrew's observation
> about the devil we know, but what I think often
> gets lost in this mostly-VPN-centric group is that
> IKE -- and I'm afraid IKEv2 as well -- is large,
> and difficult to put into cheap, embedded
> devices. This isn't usually an issue for the
> windoze-VPN-to-corporate-edge, but IKE's size is a
> pretty hard sell for little widgets with
> constrained memory footprints. I've heard all the
> arguments about how the hardware folks are being
> unreasonable (and heck, beating up on hardware
> folks is just clean fun anyway), but I'm not
> overstating the difficulty.
>
> So from that standpoint, JFK's hardline stand on
> limiting complexity and creature feep is
> heartening. I've done some experiements writing a
> JFK-like protocol (same in spirit, slightly
> different wire format) using raw public key
> identities and the results are very heartening; if
> the memory police balk at its size, they are just
> being obstructionist. This is implementable; no
> excuses. Thus for simple widgets which operate in
> star topologies to a few well known servers where
> the traffic needs transport mode IPsec, JFK is
> quite attractive. Maybe other uses too.
>
> On the other hand, VPN's do add a lot of
> complexity, and I think that JFK understates
> that complexity. While some of that complexity is
> certainly gratuitous, I think that there's an
> unspoken truth here: VPN's are fundamentally more
> complicated than point to point transport mode
> SA's, and they drag all kinds of crufty legacy
> junk into the mix like legacy authentication,
> autoconfiguration, and all the rest. Is it needed?
> At some level of course it's "needed"; I doubt
> many of us are here for the shear fun of making
> Frankenprotocols.
>
> So what to do? What to choose? I'm at a loss. We
> could flip a coin to decide the pre-shared and QM
> debate, but what I don't see is how to preseve the
> different design philosophies which appeal
> differently to different audiences. Specifically,
> I'm having a real hard time seeing how we can have
> a single lean unbloated protocol like JFK without
> specific bloat-resistant design constraints...
> which violates the VPN desire for generality at
> the expense of simplicity and footprint.
>
> Time for some more shock therapy, I guess.
>
> Mike
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Thu May 16 14:45:04 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GLj3L27062;
Thu, 16 May 2002 14:45:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08561
Thu, 16 May 2002 17:10: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: <15588.9007.583427.780174@thomasm-u1.cisco.com>
Date: Thu, 16 May 2002 14:22:55 -0700 (PDT)
To: Jan Vilhuber <vilhuber@cisco.com>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: SOI schizophrenia
In-Reply-To: <Pine.LNX.4.21.0205161337340.2302-100000@localhost>
References: <15586.62572.905659.469261@thomasm-u1.cisco.com>
<Pine.LNX.4.21.0205161337340.2302-100000@localhost>
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
Jan Vilhuber writes:
> On Wed, 15 May 2002, Michael Thomas wrote:
>
> >
> > I admit it. I'm having a real hard time deciding
> > which design philosophy is actually more
> > appropriate for SOI. I've vacillated quite a few
> > times and it doesn't seem like it's about to abate
> > any time soon. What Paul's document tells me
> > (which pretty jibes with my own judgement) is that
> > both protocols are vast improvements over IKE, and
> > they seem to reach quite similar conclusions on
> > the basic message exchanges. Both put effort into
> > DoS, and simplify the on-wire combinatorial
> > explosion of SA establishment. All in all, they
> > both seem competent.
> >
>
> They are both competent from a cryptography point of view, but only
> one actually allows key management in any sane way. I think that's
> where the two part company, and we as a group need to decide which is
> more appropriate: A key *agreement* protocol (JFK) which will require
> other protocols (ICMP? Right..) to help solve the current deployment
> stability, or a key *management* protocol (IKEv2), that let's you
> manage the key we agreed on, without requiring other external
> management protocols.
I don't understand what you mean by "management"
in this context. JFK can add and delete SA, and
assigns lifetimes to them. It seems light on a
DPD scheme, but that seems like a negotiable
item. Two phases is just an optmization.
What am I missing?
Mike
From owner-ipsec@lists.tislabs.com Thu May 16 15:52:11 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GMqAL28535;
Thu, 16 May 2002 15:52:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08644
Thu, 16 May 2002 18:17:02 -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: <15588.13017.673564.786273@thomasm-u1.cisco.com>
Date: Thu, 16 May 2002 15:29:45 -0700 (PDT)
To: Charlie_Kaufman@notesdev.ibm.com
Cc: Francis Dupont <Francis.Dupont@enst-bretagne.fr>, ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
In-Reply-To: <OFCCFB056D.82A15BB8-ON85256BBA.00077AE2-85256BBA.000EE666@iris.com>
References: <OFCCFB056D.82A15BB8-ON85256BBA.00077AE2-85256BBA.000EE666@iris.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
Charlie_Kaufman@notesdev.ibm.com writes:
> You're right that the rules aren't really written down. We tried to copy
> IKEv1 on the theory that people were using it and we didn't understand the
> issues well enough to have confidence that changes would be improvements.
> If there are specific changes or clarifications that you think would be
> useful, please propose them.
>
> There is an implicit (or it might in fact be explicit though I couldn't
> find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH
> messages associated with an IKE SA will have the same source and
> destination IP addresses. ESP and AH explicitly state that their SA is
> identified by the combination of the Destination IP address and SPI, and
> the only anticipated case for having the source address vary for an SPI is
> for multi-sender multicast.
>
> The IKEv2 spec doesn't say what an implementation should do if it receives
> a cryptographically valid message from an unexpected source address. I
> suppose it should. One possibility is that it could specify that such
> messages are discarded and possibly logged. A second is that they be
> treated as though they were cryptographically invalid. A third is that the
> source address be ignored and the packet treated as though it was received
> from the expected source address. A fourth is that the source address be
> remembered and future messages on the SA be sent to that one.
>
> Why would it matter? I claim that in all cases except Transport mode ESP
> (which is an ESP issue rather than an IKE issue), no invalid messages can
> be delivered as the result of any of these approaches. The reason it might
> be desirable to accept messages from changing source addresses is to allow
> the other end of an SA to change IP addresses mid-conversation without
> breaking the connection. This argues for the fourth approach. But the
> fourth approach makes possible a denial of service attack that is
> unacceptable. An attacker need only intercept and prevent delivery of a
> single IKE packet and retransmit it with a changed source IP address. The
> other end will begin misdirecting responses and the IKE SA will eventually
> time out. If we believe we need to be able to handle the case of a mobile
> SA, I believe we would have to do it with an authenticated message. This
> could be added later, but my going in position would be that if either end
> of an SA changes IP addresses then the SA should be broken and
> renegotiated. In that case, it doesn't matter which of the first three
> approaches an implementation takes because it shouldn't happen (and no
> useful attacks could exploit them).
>
> Where addresses are important is in the ESP and AH connections tunnelled or
> transported through IPsec SAs. ESP and AH are designed to "transparently"
> secure applications that use existing networking APIs and may trust data
> differently based on the IP address from which it originates (e.g. the Unix
> rtools). For any useful security to be provided, IKE is responsible for
> assuring that the authenticated identity corresponds to the IP address of
> SAs.
Charlie,
I don't really see what this enforcement
specifically at the SPI/dst address lookup is
buying. Lookups for incoming unicast ESP/AH don't
actually need anything more than the SPI itself to
fetch the correct context. For ESP in particular,
I don't see what security property is being
enforced by checking the outer tunnel address. If
you don't have the keying material, the hash will
fail and the packet will never be admitted. The
inner address (eg home address) still needs to be
kosher for the traffic filtering. What's the
problem here?
Like Francis I suspect, there's a lot to be gained
for mobility if we separate routing tags from
identity. In particular, it would be very, very
advantageous to be able to create a tunnel where
the outer routing tag is irrelevant so long as the
inner payloads/integrity all check out. The reason
is that for mobility you may be changing your link
layer and L3 routing information quite often;
renegotiation new SA's would be an *extreme*
hardship!
What happens with IKE is another discussion that
I'll bow out of for the time being...
Mike
From owner-ipsec@lists.tislabs.com Thu May 16 16:09:05 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4GN94L28927;
Thu, 16 May 2002 16:09:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08684
Thu, 16 May 2002 18:35: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: <15588.14074.418189.801514@thomasm-u1.cisco.com>
Date: Thu, 16 May 2002 15:47:22 -0700 (PDT)
To: Charlie_Kaufman@notesdev.ibm.com
Cc: Francis Dupont <Francis.Dupont@enst-bretagne.fr>, ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
In-Reply-To: <OFCCFB056D.82A15BB8-ON85256BBA.00077AE2-85256BBA.000EE666@iris.com>
References: <OFCCFB056D.82A15BB8-ON85256BBA.00077AE2-85256BBA.000EE666@iris.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
Bleah. Ignore my previous brain fart. As far as
IPsec (2401) is concerned the *source* of the
outer tunnel IP header is irrelevant, which is
primarily what mobile/multihomed things want.
I still don't see what security property is being
enforced by the receiver looking up crypto context
based on SPI, outer dest address instead of just
SPI alone (at least in the unicast case). It still
has to pass SPD/selector muster once decrypted.
Mike
Charlie_Kaufman@notesdev.ibm.com writes:
>
> This posting points out the tip of a very large iceberg. I think I
> understand some of the issues (but I'm not confident); some seem
> unsolvable; and some raise questions about the design goals of IPsec.
> Attempts to improve things for some scenarios (e.g. Mobile IP) may make
> things worse in others (e.g. Address Translation Gateways).
>
> > Each party can get up to 5 addresses:
> > - the address used for the transport of phase 1 messages (T1)
> > - the address in the phase 1 identity (I1)
> > - the address in the party's certificate (C1)
> > - the address used for the transport of phase 2 messages (T2)
> > - the address in the phase 2 traffic selector (which replaces IKEv1
> > phase 2 identity) (I2)
> > (I don't consider the optional IKEv2 phase 2 identity payload until
> > it has an interesting semantic when it is an address identity).
> >
> > A not-really-written-down rule specifies the phase 1 identity must be
> > the subject or an alternate subject of the party's certificate (when
> > certificates are used but in any case the identity and the authentication
> > means must be strongly bound).
>
> You're right that the rules aren't really written down. We tried to copy
> IKEv1 on the theory that people were using it and we didn't understand the
> issues well enough to have confidence that changes would be improvements.
> If there are specific changes or clarifications that you think would be
> useful, please propose them.
>
> There is an implicit (or it might in fact be explicit though I couldn't
> find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH
> messages associated with an IKE SA will have the same source and
> destination IP addresses. ESP and AH explicitly state that their SA is
> identified by the combination of the Destination IP address and SPI, and
> the only anticipated case for having the source address vary for an SPI is
> for multi-sender multicast.
>
> The IKEv2 spec doesn't say what an implementation should do if it receives
> a cryptographically valid message from an unexpected source address. I
> suppose it should. One possibility is that it could specify that such
> messages are discarded and possibly logged. A second is that they be
> treated as though they were cryptographically invalid. A third is that the
> source address be ignored and the packet treated as though it was received
> from the expected source address. A fourth is that the source address be
> remembered and future messages on the SA be sent to that one.
>
> Why would it matter? I claim that in all cases except Transport mode ESP
> (which is an ESP issue rather than an IKE issue), no invalid messages can
> be delivered as the result of any of these approaches. The reason it might
> be desirable to accept messages from changing source addresses is to allow
> the other end of an SA to change IP addresses mid-conversation without
> breaking the connection. This argues for the fourth approach. But the
> fourth approach makes possible a denial of service attack that is
> unacceptable. An attacker need only intercept and prevent delivery of a
> single IKE packet and retransmit it with a changed source IP address. The
> other end will begin misdirecting responses and the IKE SA will eventually
> time out. If we believe we need to be able to handle the case of a mobile
> SA, I believe we would have to do it with an authenticated message. This
> could be added later, but my going in position would be that if either end
> of an SA changes IP addresses then the SA should be broken and
> renegotiated. In that case, it doesn't matter which of the first three
> approaches an implementation takes because it shouldn't happen (and no
> useful attacks could exploit them).
>
> Where addresses are important is in the ESP and AH connections tunnelled or
> transported through IPsec SAs. ESP and AH are designed to "transparently"
> secure applications that use existing networking APIs and may trust data
> differently based on the IP address from which it originates (e.g. the Unix
> rtools). For any useful security to be provided, IKE is responsible for
> assuring that the authenticated identity corresponds to the IP address of
> SAs.
>
> How is this possible?
>
> One way is by having the identities in certificates in fact be IP addresses
> rather than names as implied by the quoted text above. Systems may be
> deployed that way, but it would surprise me. More likely is that the
> "Policy Database" installed as part of IPsec configuration contains a table
> matching IP addresses to either public keys or the names that must appear
> in certificates used in IKE. How that policy database would be populated
> and maintained is one of the great remaining mysteries of IPsec. For
> firewall to firewall tunnels, manual configuration works, and I believe
> that's how people do it today. But for end to end IPsec to become routine,
> better techniques will need to be deployed and standardized. It's a much
> harder problem than any already solved in IPsec, so I don't expect progress
> soon. I certainly don't want to hold IKEv2 hostage to solving it.
>
> In tunnel mode, it's the inner IP addresses that must be authenticated.
> They are because they must match the traffic selectors and the traffic
> selectors must match the authenticated names from IKE and in the IPsec
> Policy Database. In tunnel mode, the outer IP addresses are like those of
> IKE... it doesn't matter what we do with them so long as we don't open
> ourselves to denial of service attacks.
>
> In transport mode, it's the outer IP addresses that must be authenticated.
> This is tricky because they are not cryptographically protected. What
> should ESP or AH do if they receive a transport mode IP packet with IP
> addresses that don't match the traffic selectors? I believe the spec says
> they should throw them away. This will break transport mode SAs if they
> pass through address translation gateways. I believe the right answer to
> this is to always use tunnel mode through address translation gateways.
> Proposals for tunneling through address translation gateways call for use
> of a special tunnel mode that is encapsulated in UDP.
>
> IKEv2 explicitly supports Address Translation Gateways by *not*
> authenticating the outer IP addresses in IKE messages. This allows
> connections to work even though the outer IP addresses appear different to
> the two ends of the IKE (and presumably also ESP) SAs.
>
> It's not clear what we can or should do to provide better support for ATGs
> or Mobile IP, but I'm open to suggestions.
>
> --Charlie
>
> This footnote confirms that either (1) this email message has been swept by
> Baltimore MIMEsweeper for Content Security threats, including computer
> viruses, (2) this email message was sent by a virus that appends this
> footnote, or (3) (most likely) the sender of this message is trying to
> raise awareness of how foolish it would be to place any confidence in
> footnotes like this.This posting points out the tip of a very large iceberg. I think I understand some of the issues (but I'm not confident); some seem unsolvable; and some raise questions about the design goals of IPsec. Attempts to improve things for some scenarios (e.g. Mobile IP) may make things worse in others (e.g. Address Translation Gateways).
>
> > Each party can get up to 5 addresses:
> > - the address used for the transport of phase 1 messages (T1)
> > - the address in the phase 1 identity (I1)
> > - the address in the party's certificate (C1)
> > - the address used for the transport of phase 2 messages (T2)
> > - the address in the phase 2 traffic selector (which replaces IKEv1
> > phase 2 identity) (I2)
> > (I don't consider the optional IKEv2 phase 2 identity payload until
> > it has an interesting semantic when it is an address identity).
> >
> > A not-really-written-down rule specifies the phase 1 identity must be
> > the subject or an alternate subject of the party's certificate (when
> > certificates are used but in any case the identity and the authentication
> > means must be strongly bound).
>
> You're right that the rules aren't really written down. We tried to copy IKEv1 on the theory that people were using it and we didn't understand the issues well enough to have confidence that changes would be improvements. If there are specific changes or clarifications that you think would be useful, please propose them.
>
> There is an implicit (or it might in fact be explicit though I couldn't find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH messages associated with an IKE SA will have the same source and destination IP addresses. ESP and AH explicitly state that their SA is identified by the combination of the Destination IP address and SPI, and the only anticipated case for having the source address vary for an SPI is for multi-sender multicast.
>
> The IKEv2 spec doesn't say what an implementation should do if it receives a cryptographically valid message from an unexpected source address. I suppose it should. One possibility is that it could specify that such messages are discarded and possibly logged. A second is that they be treated as though they were cryptographically invalid. A third is that the source address be ignored and the packet treated as though it was received from the expected source address. A fourth is that the source address be remembered and future messages on the SA be sent to that one.
>
> Why would it matter? I claim that in all cases except Transport mode ESP (which is an ESP issue rather than an IKE issue), no invalid messages can be delivered as the result of any of these approaches. The reason it might be desirable to accept messages from changing source addresses is to allow the other end of an SA to change IP addresses mid-conversation without breaking the connection. This argues for the fourth approach. But the fourth approach makes possible a denial of service attack that is unacceptable. An attacker need only intercept and prevent delivery of a single IKE packet and retransmit it with a changed source IP address. The other end will begin misdirecting responses and the IKE SA will eventually time out. If we believe we need to be able to handle the case of a mobile SA, I believe we would have to do it with an authenticated message. This could be added later, but my going in position would be that if either end of an SA changes IP addresses then the !
SA !
> sh!
> ! ould be broken and renegotiated. In that case, it doesn't matter which of the first three approaches an implementation takes because it shouldn't happen (and no useful attacks could exploit them).
>
> Where addresses are important is in the ESP and AH connections tunnelled or transported through IPsec SAs. ESP and AH are designed to "transparently" secure applications that use existing networking APIs and may trust data differently based on the IP address from which it originates (e.g. the Unix rtools). For any useful security to be provided, IKE is responsible for assuring that the authenticated identity corresponds to the IP address of SAs.
>
> How is this possible?
>
> One way is by having the identities in certificates in fact be IP addresses rather than names as implied by the quoted text above. Systems may be deployed that way, but it would surprise me. More likely is that the "Policy Database" installed as part of IPsec configuration contains a table matching IP addresses to either public keys or the names that must appear in certificates used in IKE. How that policy database would be populated and maintained is one of the great remaining mysteries of IPsec. For firewall to firewall tunnels, manual configuration works, and I believe that's how people do it today. But for end to end IPsec to become routine, better techniques will need to be deployed and standardized. It's a much harder problem than any already solved in IPsec, so I don't expect progress soon. I certainly don't want to hold IKEv2 hostage to solving it.
>
> In tunnel mode, it's the inner IP addresses that must be authenticated. They are because they must match the traffic selectors and the traffic selectors must match the authenticated names from IKE and in the IPsec Policy Database. In tunnel mode, the outer IP addresses are like those of IKE... it doesn't matter what we do with them so long as we don't open ourselves to denial of service attacks.
>
> In transport mode, it's the outer IP addresses that must be authenticated. This is tricky because they are not cryptographically protected. What should ESP or AH do if they receive a transport mode IP packet with IP addresses that don't match the traffic selectors? I believe the spec says they should throw them away. This will break transport mode SAs if they pass through address translation gateways. I believe the right answer to this is to always use tunnel mode through address translation gateways. Proposals for tunneling through address translation gateways call for use of a special tunnel mode that is encapsulated in UDP.
>
> IKEv2 explicitly supports Address Translation Gateways by *not* authenticating the outer IP addresses in IKE messages. This allows connections to work even though the outer IP addresses appear different to the two ends of the IKE (and presumably also ESP) SAs.
>
> It's not clear what we can or should do to provide better support for ATGs or Mobile IP, but I'm open to suggestions.
>
> --Charlie
>
> This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this.
From owner-ipsec@lists.tislabs.com Thu May 16 17:01:27 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4H01QL00294;
Thu, 16 May 2002 17:01:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08769
Thu, 16 May 2002 19:25:14 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
Subject: RE: ike-modp-groups-04
Date: Thu, 16 May 2002 16:33:57 -0700
Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D015E5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: ike-modp-groups-04
Thread-Index: AcHwqU3pvZzSAx6wQUyCIKO1Z+JJNwMiCHqg
From: "William Dixon" <wdixon@windows.microsoft.com>
To: <ipsec@lists.tislabs.com>, <kivinen@ssh.fi>
X-OriginalArrivalTime: 16 May 2002 23:33:58.0606 (UTC) FILETIME=[26E8AEE0:01C1FD32]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Tero, Ted, Barbara, isn't this ready for last call ? Is there anything
we can do to get assigned numbers sooner rather than later ?
-----Original Message-----
From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca]
Sent: Tuesday, April 30, 2002 5:10 PM
To: ipsec@lists.tislabs.com
Subject: ike-modp-groups-04
-----BEGIN PGP SIGNED MESSAGE-----
Is there some reason this document has not been published yet?
] ON HUMILITY: to err is human. To moo, bovine. |
firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net
architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[ ] panic("Just another NetBSD/notebook using, kernel hacking,
security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPM8yXYqHRg3pndX9AQF4WwQAxrUMMyFVPHA/zJeoHJ2o7r626+LQ+UYx
SWosLDzzA6GbwXNpeWa93Pefyh/nLt/MgpseVnBdA5CX3dwoFT4Y6B3jctikMoFt
ZYEkrnx//eYqvJzhw0Df3yISWHYdQr1u1lAS5Z0sK+EXgyx0t+ESL9eTK/azVBfY
zngnFDIiYIA=
=qm44
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Thu May 16 23:56:06 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4H6u5L19653;
Thu, 16 May 2002 23:56:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA09611
Fri, 17 May 2002 02:11:45 -0400 (EDT)
Message-ID: <3CE4A269.76287B2D@F-Secure.com>
Date: Fri, 17 May 2002 09:25:45 +0300
From: Ari Huttunen <Ari.Huttunen@f-secure.com>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mlafon@arkoon.net
CC: ipsec@lists.tislabs.com
Subject: Re: NAT-Traversal - Security Considerations
References: <C1256BBB.003851BE.00@arkoon-mail.arkoon.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 May 2002 06:25:45.0837 (UTC) FILETIME=[AD90F1D0:01C1FD6B]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
mlafon@arkoon.net wrote:
>
> ari.huttunen@f-secure.com wrote
>
> > It would seem to me that the IPsec layer in S needs to apply NAT for
> > packets that come via the SA, so they appear to come from address Y.
> > The server in S then thinks it's talking with Y. The return packets
> > to Y would then be NATed, and put to the SA, all other packets would
> > go through without any change. This way the TS doesn't apply to packets
> > to/from address 'NAT', but to address 'Y'. This would break if you want
> > part of the packets via an SA, and part in plaintext, using TS, because
> > server would see different IP addresses for the client, so don't do that.
>
> So what is the prefered usage and why does the current draft does not specify
> it ? If we're not applying NAT, how do we deal with the blackhole between
> S and WS/NAT when NAT-T SA is established ?
The draft is a specification for a protocol, not an implementation guidebook
in how the protocol is to be implemented. Some not-so-obvious security related
issues are mentioned explicitly to guide implementations, but other than that
you're left on your own to implement it.
>
> >I had this in draft-huttunen-ipsec-esp-in-udp-00.txt:
> >>
> >> It is not possible for a hacker to obtain an arbitrary address in the
> >> intranet being protected by the GW. If address assignment by the GW
> >> is provided, only the address assigned to the hacker is allowed to pass
> >> through the GW. In the other case, address is always assigned to
> >> the hacker internally by the GW and the (arbitrary) IP address of the
> >> hacker is always translated by a NAT functionality in the GW.
> >
> > Perhaps I should have copied it to this current draft? Is it clear?
>
> I don't get the point. If you do not use address assignment, it is the user
> who chooses his address depending on the network he is on (hotel, airport, home,
> ...), so you can't control which IP he chooses.
OK. Good that I didn't copy it. :)
>
> When we're not using NAT-Traversal, we can be strict and not allow him to use
> another IP than his external IP or a fixed address/network. But with NAT-T,
> we can't be that strict, can we ?
>
> Or is address assignment mandatory with NAT-Traversal ?
Both transport and tunnel mode can be implemented with a NAT in the IPsec
layer, and tunnel mode can additionally be implemented with address
assignment (DHCP/modeconfig). You may be able to do without them in some
situations. You can look at it like NAT-Traversal ignoring the effects of
any NATs en-route. Still, if addresses need NATing, something must do it,
and that something is likely your IPsec stack.
Ari
--
"They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety." - Benjamin Franklin
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 May 17 03:19:27 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HAJRL14332;
Fri, 17 May 2002 03:19:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA10019
Fri, 17 May 2002 05:32:21 -0400 (EDT)
Message-Id: <200205170944.g4H9iRT93074@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Michael Thomas <mat@cisco.com>
cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
In-reply-to: Your message of Thu, 16 May 2002 15:29:45 PDT.
<15588.13017.673564.786273@thomasm-u1.cisco.com>
Date: Fri, 17 May 2002 11:44:27 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
=> thanks for your support Mike!
What happens with IKE is another discussion that
I'll bow out of for the time being...
=> there is something to do with IKE because SAs come by pairs,
i.e. for the mobile to correspondent way address agility is enough
(and is already in RFC 2401) but for the correspondent to mobile way
something is needed (readdressing exchange?).
Thanks
Francis.Dupont@enst-bretagne.fr
PS: more I think about SOI & mobility, more I believe SOI should have
an optional message header verification, something like a special ID
payload with the party transport parameters. My current idea is, for
IKEv2 for instance:
- optional ID payload of type address with the party transport
parameters (address, protocol (udp), port (500))
- this payload should be the first one (a way to mark it as special)
- if it is present it must be checked against the message header
- the policy should say if this is required to be sent or received
- the policy should say if this can overwrite previous used addresses:
* further IKE messages
* all established SAs with this peer
IMHO only the last point is arguable (i.e. I am still looking for
better solutions).
From owner-ipsec@lists.tislabs.com Fri May 17 03:24:10 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HAOAL14570;
Fri, 17 May 2002 03:24:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA10031
Fri, 17 May 2002 05:37:21 -0400 (EDT)
Message-Id: <200205170949.g4H9n3T93117@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Michael Thomas <mat@cisco.com>
cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
In-reply-to: Your message of Thu, 16 May 2002 15:47:22 PDT.
<15588.14074.418189.801514@thomasm-u1.cisco.com>
Date: Fri, 17 May 2002 11:49:03 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
Bleah. Ignore my previous brain fart. As far as
IPsec (2401) is concerned the *source* of the
outer tunnel IP header is irrelevant, which is
primarily what mobile/multihomed things want.
=> unfortunately many implementations still check the outer source
because this is not explicitely forbidden. Revision of 2401 and
interop tests should clarify this point (IKEv2/ESPv3 were a big step forward
because they make clear that inbound SA selectors are traffic selectors).
Thanks
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Fri May 17 03:24:11 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HAOAL14569;
Fri, 17 May 2002 03:24:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA10044
Fri, 17 May 2002 05:41:22 -0400 (EDT)
Message-Id: <200205170953.g4H9rWT93137@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Lars Eggert <larse@ISI.EDU>
cc: Michael Thomas <mat@cisco.com>, Charlie_Kaufman@notesdev.ibm.com,
ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
In-reply-to: Your message of Thu, 16 May 2002 15:55:29 PDT.
<3CE438E1.9060302@isi.edu>
Date: Fri, 17 May 2002 11:53:32 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
> Like Francis I suspect, there's a lot to be gained
> for mobility if we separate routing tags from
> identity. In particular, it would be very, very
> advantageous to be able to create a tunnel where
> the outer routing tag is irrelevant so long as the
> inner payloads/integrity all check out.
Isn't this accomplished by end-to-end transport mode IPsec that goes
through an unsecured IPIP tunnel?
=> unfortunately this is the opposite because transport mode in IPIP
knows *only* the outer header.
Thanks
Francis.Dupont@enst-bretagne.fr
PS: my favourite question to IPsec people was "is your IPv6 tunnel mode
an interface?" I *never* got a really sensible answer (:-)...
From owner-ipsec@lists.tislabs.com Fri May 17 04:05:17 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HB5HL20361;
Fri, 17 May 2002 04:05:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA10135
Fri, 17 May 2002 06:22:27 -0400 (EDT)
X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to <kivinen@ssh.fi> using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15588.56534.560359.570000@ryijy.hel.fi.ssh.com>
Date: Fri, 17 May 2002 13:35:02 +0300
From: Tero Kivinen <kivinen@ssh.fi>
To: "William Dixon" <wdixon@windows.microsoft.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: ike-modp-groups-04
In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC105D015E5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
References: <2E33960095B58E40A4D3345AB9F65EC105D015E5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 1 min
X-Total-Time: 0 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
William Dixon writes:
> Tero, Ted, Barbara, isn't this ready for last call ? Is there anything
> we can do to get assigned numbers sooner rather than later ?
I don't have any outstanding issues about it, I think it is ready for
the last call.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
From owner-ipsec@lists.tislabs.com Fri May 17 06:12:53 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HDCrL26674;
Fri, 17 May 2002 06:12:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10320
Fri, 17 May 2002 08:24:54 -0400 (EDT)
MBOX-Line: From owner-ipsec@lists.tislabs.com Thu May 16 15:22:19 2002
From: Charlie_Kaufman@notesdev.ibm.com
Subject: Re: addresses and IKEv2
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Build V60_M13_04242002 Pre-release 2 April 24, 2002
Message-ID: <OFCCFB056D.82A15BB8-ON85256BBA.00077AE2-85256BBA.000EE666@iris.com>
Date: Tue, 14 May 2002 22:42:45 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build M13TT_05082002 Pre-release 2|May
08, 2002) at 05/15/2002 06:35:44 PM
MIME-Version: 1.0
Content-type: multipart/alternative;
Boundary="0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72"
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72
Content-type: text/plain; charset=US-ASCII
This posting points out the tip of a very large iceberg. I think I
understand some of the issues (but I'm not confident); some seem
unsolvable; and some raise questions about the design goals of IPsec.
Attempts to improve things for some scenarios (e.g. Mobile IP) may make
things worse in others (e.g. Address Translation Gateways).
> Each party can get up to 5 addresses:
> - the address used for the transport of phase 1 messages (T1)
> - the address in the phase 1 identity (I1)
> - the address in the party's certificate (C1)
> - the address used for the transport of phase 2 messages (T2)
> - the address in the phase 2 traffic selector (which replaces IKEv1
> phase 2 identity) (I2)
> (I don't consider the optional IKEv2 phase 2 identity payload until
> it has an interesting semantic when it is an address identity).
>
> A not-really-written-down rule specifies the phase 1 identity must be
> the subject or an alternate subject of the party's certificate (when
> certificates are used but in any case the identity and the authentication
> means must be strongly bound).
You're right that the rules aren't really written down. We tried to copy
IKEv1 on the theory that people were using it and we didn't understand the
issues well enough to have confidence that changes would be improvements.
If there are specific changes or clarifications that you think would be
useful, please propose them.
There is an implicit (or it might in fact be explicit though I couldn't
find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH
messages associated with an IKE SA will have the same source and
destination IP addresses. ESP and AH explicitly state that their SA is
identified by the combination of the Destination IP address and SPI, and
the only anticipated case for having the source address vary for an SPI is
for multi-sender multicast.
The IKEv2 spec doesn't say what an implementation should do if it receives
a cryptographically valid message from an unexpected source address. I
suppose it should. One possibility is that it could specify that such
messages are discarded and possibly logged. A second is that they be
treated as though they were cryptographically invalid. A third is that the
source address be ignored and the packet treated as though it was received
from the expected source address. A fourth is that the source address be
remembered and future messages on the SA be sent to that one.
Why would it matter? I claim that in all cases except Transport mode ESP
(which is an ESP issue rather than an IKE issue), no invalid messages can
be delivered as the result of any of these approaches. The reason it might
be desirable to accept messages from changing source addresses is to allow
the other end of an SA to change IP addresses mid-conversation without
breaking the connection. This argues for the fourth approach. But the
fourth approach makes possible a denial of service attack that is
unacceptable. An attacker need only intercept and prevent delivery of a
single IKE packet and retransmit it with a changed source IP address. The
other end will begin misdirecting responses and the IKE SA will eventually
time out. If we believe we need to be able to handle the case of a mobile
SA, I believe we would have to do it with an authenticated message. This
could be added later, but my going in position would be that if either end
of an SA changes IP addresses then the SA should be broken and
renegotiated. In that case, it doesn't matter which of the first three
approaches an implementation takes because it shouldn't happen (and no
useful attacks could exploit them).
Where addresses are important is in the ESP and AH connections tunnelled or
transported through IPsec SAs. ESP and AH are designed to "transparently"
secure applications that use existing networking APIs and may trust data
differently based on the IP address from which it originates (e.g. the Unix
rtools). For any useful security to be provided, IKE is responsible for
assuring that the authenticated identity corresponds to the IP address of
SAs.
How is this possible?
One way is by having the identities in certificates in fact be IP addresses
rather than names as implied by the quoted text above. Systems may be
deployed that way, but it would surprise me. More likely is that the
"Policy Database" installed as part of IPsec configuration contains a table
matching IP addresses to either public keys or the names that must appear
in certificates used in IKE. How that policy database would be populated
and maintained is one of the great remaining mysteries of IPsec. For
firewall to firewall tunnels, manual configuration works, and I believe
that's how people do it today. But for end to end IPsec to become routine,
better techniques will need to be deployed and standardized. It's a much
harder problem than any already solved in IPsec, so I don't expect progress
soon. I certainly don't want to hold IKEv2 hostage to solving it.
In tunnel mode, it's the inner IP addresses that must be authenticated.
They are because they must match the traffic selectors and the traffic
selectors must match the authenticated names from IKE and in the IPsec
Policy Database. In tunnel mode, the outer IP addresses are like those of
IKE... it doesn't matter what we do with them so long as we don't open
ourselves to denial of service attacks.
In transport mode, it's the outer IP addresses that must be authenticated.
This is tricky because they are not cryptographically protected. What
should ESP or AH do if they receive a transport mode IP packet with IP
addresses that don't match the traffic selectors? I believe the spec says
they should throw them away. This will break transport mode SAs if they
pass through address translation gateways. I believe the right answer to
this is to always use tunnel mode through address translation gateways.
Proposals for tunneling through address translation gateways call for use
of a special tunnel mode that is encapsulated in UDP.
IKEv2 explicitly supports Address Translation Gateways by *not*
authenticating the outer IP addresses in IKE messages. This allows
connections to work even though the outer IP addresses appear different to
the two ends of the IKE (and presumably also ESP) SAs.
It's not clear what we can or should do to provide better support for ATGs
or Mobile IP, but I'm open to suggestions.
--Charlie
This footnote confirms that either (1) this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including computer
viruses, (2) this email message was sent by a virus that appends this
footnote, or (3) (most likely) the sender of this message is trying to
raise awareness of how foolish it would be to place any confidence in
footnotes like this.
--0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
This posting points out the tip of a very large iceberg. I think I understand some of the issues (but I'm not confident); some seem unsolvable; and some raise questions about the design goals of IPsec. Attempts to improve things for some scenarios (e.g. Mobile IP) may make things worse in others (e.g. Address Translation Gateways).
> Each party can get up to 5 addresses:
> - the address used for the transport of phase 1 messages (T1)
> - the address in the phase 1 identity (I1)
> - the address in the party's certificate (C1)
> - the address used for the transport of phase 2 messages (T2)
> - the address in the phase 2 traffic selector (which replaces IKEv1
> phase 2 identity) (I2)
> (I don't consider the optional IKEv2 phase 2 identity payload until
> it has an interesting semantic when it is an address identity).
>
> A not-really-written-down rule specifies the phase 1 identity must be
> the subject or an alternate subject of the party's certificate (when
> certificates are used but in any case the identity and the authentication
> means must be strongly bound).
You're right that the rules aren't really written down. We tried to copy IKEv1 on the theory that people were using it and we didn't understand the issues well enough to have confidence that changes would be improvements. If there are specific changes or clarifications that you think would be useful, please propose them.
There is an implicit (or it might in fact be explicit though I couldn't find it) assumption that all the IKE phase 1, IKE phase 2, ESP, and AH messages associated with an IKE SA will have the same source and destination IP addresses. ESP and AH explicitly state that their SA is identified by the combination of the Destination IP address and SPI, and the only anticipated case for having the source address vary for an SPI is for multi-sender multicast.
The IKEv2 spec doesn't say what an implementation should do if it receives a cryptographically valid message from an unexpected source address. I suppose it should. One possibility is that it could specify that such messages are discarded and possibly logged. A second is that they be treated as though they were cryptographically invalid. A third is that the source address be ignored and the packet treated as though it was received from the expected source address. A fourth is that the source address be remembered and future messages on the SA be sent to that one.
Why would it matter? I claim that in all cases except Transport mode ESP (which is an ESP issue rather than an IKE issue), no invalid messages can be delivered as the result of any of these approaches. The reason it might be desirable to accept messages from changing source addresses is to allow the other end of an SA to change IP addresses mid-conversation without breaking the connection. This argues for the fourth approach. But the fourth approach makes possible a denial of service attack that is unacceptable. An attacker need only intercept and prevent delivery of a single IKE packet and retransmit it with a changed source IP address. The other end will begin misdirecting responses and the IKE SA will eventually time out. If we believe we need to be able to handle the case of a mobile SA, I believe we would have to do it with an authenticated message. This could be added later, but my going in position would be that if either end of an SA changes IP addresses then the SA !
sh!
! ould be broken and renegotiated. In that case, it doesn't matter which of the first three approaches an implementation takes because it shouldn't happen (and no useful attacks could exploit them).
Where addresses are important is in the ESP and AH connections tunnelled or transported through IPsec SAs. ESP and AH are designed to "transparently" secure applications that use existing networking APIs and may trust data differently based on the IP address from which it originates (e.g. the Unix rtools). For any useful security to be provided, IKE is responsible for assuring that the authenticated identity corresponds to the IP address of SAs.
How is this possible?
One way is by having the identities in certificates in fact be IP addresses rather than names as implied by the quoted text above. Systems may be deployed that way, but it would surprise me. More likely is that the "Policy Database" installed as part of IPsec configuration contains a table matching IP addresses to either public keys or the names that must appear in certificates used in IKE. How that policy database would be populated and maintained is one of the great remaining mysteries of IPsec. For firewall to firewall tunnels, manual configuration works, and I believe that's how people do it today. But for end to end IPsec to become routine, better techniques will need to be deployed and standardized. It's a much harder problem than any already solved in IPsec, so I don't expect progress soon. I certainly don't want to hold IKEv2 hostage to solving it.
In tunnel mode, it's the inner IP addresses that must be authenticated. They are because they must match the traffic selectors and the traffic selectors must match the authenticated names from IKE and in the IPsec Policy Database. In tunnel mode, the outer IP addresses are like those of IKE... it doesn't matter what we do with them so long as we don't open ourselves to denial of service attacks.
In transport mode, it's the outer IP addresses that must be authenticated. This is tricky because they are not cryptographically protected. What should ESP or AH do if they receive a transport mode IP packet with IP addresses that don't match the traffic selectors? I believe the spec says they should throw them away. This will break transport mode SAs if they pass through address translation gateways. I believe the right answer to this is to always use tunnel mode through address translation gateways. Proposals for tunneling through address translation gateways call for use of a special tunnel mode that is encapsulated in UDP.
IKEv2 explicitly supports Address Translation Gateways by *not* authenticating the outer IP addresses in IKE messages. This allows connections to work even though the outer IP addresses appear different to the two ends of the IKE (and presumably also ESP) SAs.
It's not clear what we can or should do to provide better support for ATGs or Mobile IP, but I'm open to suggestions.
--Charlie
This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this.
--0__=0ABBE129DF94FC728f9e8a93df938690918c0ABBE129DF94FC72--
From owner-ipsec@lists.tislabs.com Fri May 17 06:16:03 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HDG3L27208;
Fri, 17 May 2002 06:16:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10314
Fri, 17 May 2002 08:23:54 -0400 (EDT)
Message-ID: <3CE438E1.9060302@isi.edu>
Date: Thu, 16 May 2002 15:55:29 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
CC: Charlie_Kaufman@notesdev.ibm.com,
Francis Dupont
<Francis.Dupont@enst-bretagne.fr>, ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
References: <OFCCFB056D.82A15BB8-ON85256BBA.00077AE2-85256BBA.000EE666@iris.com> <15588.13017.673564.786273@thomasm-u1.cisco.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060904090009040106010005"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a cryptographically signed message in MIME format.
--------------ms060904090009040106010005
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Michael Thomas wrote:
> Like Francis I suspect, there's a lot to be gained
> for mobility if we separate routing tags from
> identity. In particular, it would be very, very
> advantageous to be able to create a tunnel where
> the outer routing tag is irrelevant so long as the
> inner payloads/integrity all check out.
Isn't this accomplished by end-to-end transport mode IPsec that goes
through an unsecured IPIP tunnel?
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms060904090009040106010005
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC
ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP
MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc
MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1
1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU
SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB
BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT
vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d
6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC
HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD
VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV
BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq
hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL
ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA
jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv
0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy
dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E
AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ
d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX
frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB
AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3
dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv
bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB
FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy
NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT
ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq
bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC
9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww
KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI
MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15
1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s
ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY
yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD
ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw
MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAyMDUxNjIyNTUzMVowIwYJKoZIhvcNAQkEMRYEFBHO2Tq6Nh0E
NLLMY54tuUQWhycnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B
CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl
IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF
gUcwDQYJKoZIhvcNAQEBBQAEgYCumLPduMY8aZt4pXpijI4RWLXDUpoy+7pAK37S0yxYUqW+
9tqF7QPTfmmVGQOptUQbEDn0jIXsflHppytMn5/ReCgVEb1B3086ebTBAefRTs9lEDrm3dfu
sTtzsAfprpu5e03mi3O7Oj93et61uowTGxXKp8aU7w3XPcvhq/+I7gAAAAAAAA==
--------------ms060904090009040106010005--
From owner-ipsec@lists.tislabs.com Fri May 17 10:10:37 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HHAaL08625;
Fri, 17 May 2002 10:10:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10889
Fri, 17 May 2002 12:25:09 -0400 (EDT)
Message-ID: <3CE52BEC.1040306@isi.edu>
Date: Fri, 17 May 2002 09:12:28 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
CC: Michael Thomas <mat@cisco.com>, Charlie_Kaufman@notesdev.ibm.com,
ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
References: <200205170953.g4H9rWT93137@givry.rennes.enst-bretagne.fr>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020308070605000502070405"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a cryptographically signed message in MIME format.
--------------ms020308070605000502070405
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Francis Dupont wrote:
> In your previous mail you wrote:
>
> > Like Francis I suspect, there's a lot to be gained
> > for mobility if we separate routing tags from
> > identity. In particular, it would be very, very
> > advantageous to be able to create a tunnel where
> > the outer routing tag is irrelevant so long as the
> > inner payloads/integrity all check out.
>
> Isn't this accomplished by end-to-end transport mode IPsec that goes
> through an unsecured IPIP tunnel?
>
> => unfortunately this is the opposite because transport mode in IPIP
> knows *only* the outer header.
I didn't mean a draft-touch-ipsec tunnel (this time :-), I meant this:
| Tunnel IP Header:| Orig IP Header:| IPsec: | |
| TSrc -> TDst | OSrc -> ODst | Transport Mode | Payload |
I.e. just run IPsec end-to-end over a MobileIP (or other IPIP) tunnel.
But there may be specifics to Mobile IP that I'm ignorant of...
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms020308070605000502070405
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC
ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP
MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc
MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1
1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU
SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB
BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT
vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d
6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC
HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD
VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV
BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq
hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL
ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA
jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv
0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy
dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E
AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ
d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX
frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB
AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3
dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv
bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB
FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy
NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT
ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq
bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC
9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww
KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI
MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15
1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s
ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY
yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD
ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw
MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAyMDUxNzE2MTIyOFowIwYJKoZIhvcNAQkEMRYEFPj1vL9cEUR+
MLiMT1JedqvADZGoMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B
CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl
IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF
gUcwDQYJKoZIhvcNAQEBBQAEgYCwDKhP2y+DD+5iyUSHCTwrKazvd6oNodsdf1fQQ5WMS73X
i2lYqhj6SpO/c/J9RBMHR0DulX01iHNZcJD2S1kiZfVK1LJgI5sX6/ebryq0CQs4cZU8vE4r
IqRI7zdlt/SzH78unohmLcYG6Yoz1uGygWHHJ6zWJ7Ow1zYlnAtxBQAAAAAAAA==
--------------ms020308070605000502070405--
From owner-ipsec@lists.tislabs.com Fri May 17 11:39:24 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HIdOL11438;
Fri, 17 May 2002 11:39:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10989
Fri, 17 May 2002 13:57:45 -0400 (EDT)
From: mlafon@arkoon.net
X-Lotus-FromDomain: ARKOON
To: ipsec@lists.tislabs.com
Message-ID: <C1256BBC.006435F5.00@arkoon-mail.arkoon.net>
Date: Fri, 17 May 2002 20:14:31 +0200
Subject: Re: NAT-Traversal - Security Considerations
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
As I (now) understand it, we must apply NAT to NAT-T packets
using Transport Mode or we create a blackhole between the
Responder and the NAT device.
As it is not obvious (tell me if I'm the only one for who it was
not obvious) and can cause DoS, even with normal use, implementors
should be explicitely warned.
By example :
Implementors are warned that NAT SHOULD be applied to packets
received using Transport Mode encapsulation when the sender is
behind a NAT device.
Without NAT, all packets sent by S to the NAT device or devices
behind it, and following the trafic descriptor of the SA established
will be sent to the peer which has initiated the SA.
This will create a sort of blackhole between S and the NAT device.
Implementators MUST devise ways of preventing such a thing from
occurring; either by disallowing Transport Mode, by applying NAT or
by other means.
Of course, don't forget to correct me if I'm still wrong and note that
I will not allow NAT-T Transport Mode as it is not satisfying for me.
--
Mathieu Lafon - Arkoon Network Security
From owner-ipsec@lists.tislabs.com Fri May 17 12:08:38 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HJ8cL12399;
Fri, 17 May 2002 12:08:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11024
Fri, 17 May 2002 14:30:57 -0400 (EDT)
Message-Id: <3.0.3.32.20020517110546.013cbfc0@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Fri, 17 May 2002 11:05:46 -0700
To: Charlie_Kaufman@notesdev.ibm.com,
Francis Dupont <Francis.Dupont@enst-bretagne.fr>
From: Alex Alten <Alten@attbi.com>
Subject: Re: addresses and IKEv2
Cc: ipsec@lists.tislabs.com
In-Reply-To: <OFCCFB056D.82A15BB8-ON85256BBA.00077AE2-85256BBA.000EE666@
iris.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:42 PM 5/14/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote:
>This posting points out the tip of a very large iceberg. I think I
>understand some of the issues (but I'm not confident); some seem
>unsolvable; and some raise questions about the design goals of IPsec.
>Attempts to improve things for some scenarios (e.g. Mobile IP) may make
>things worse in others (e.g. Address Translation Gateways).
Hello Charlie,
You raise some excellent points as usual.
I have privately thought for a long time that IPsec's dependence on an
IP address to determine an SA to be a fundamental flaw in its design.
To be effective IPsec needs a global address space, in which each host is
uniquely identified, like the Internet was prior to the introduction of
NATs, etc. To make this work a way to dynamically map an Internet address,
including duplicate private non-routable addresses, to a global unique IPSec
address/identifier needs to be made available. Each host can then query
this database to resolve an IP address to a secure IPsec address/identifier.
Cryptography is then used to assure that the IPsec address/identifier is
indeed valid. In this way both MobileIP and NAT can be supported as-is,
because they operate on an insecure non-unique IP address, while IPsec uses
the parallel universe of a secure unique IPsec address/identifier.
However this approach does mean that IPsec can no longer be treated as just
a secure protocol, or set of protocols if you include key management. It
must be part of a security system, which includes this address mapping
facility.
Regards,
- Alex
--
Alex Alten
Alten@ATTBI.com
From owner-ipsec@lists.tislabs.com Fri May 17 12:50:53 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HJoqL13578;
Fri, 17 May 2002 12:50:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11150
Fri, 17 May 2002 15:11:24 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05100316b90b027b1063@[128.89.88.34]>
In-Reply-To: <3.0.3.32.20020517110546.013cbfc0@mail>
References: <3.0.3.32.20020517110546.013cbfc0@mail>
Date: Fri, 17 May 2002 14:56:46 -0400
To: Alex Alten <Alten@attbi.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: addresses and IKEv2
Cc: Charlie_Kaufman@notesdev.ibm.com,
Francis Dupont <Francis.Dupont@enst-bretagne.fr>, ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 11:05 AM -0700 5/17/02, Alex Alten wrote:
>At 10:42 PM 5/14/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote:
>>This posting points out the tip of a very large iceberg. I think I
>>understand some of the issues (but I'm not confident); some seem
>>unsolvable; and some raise questions about the design goals of IPsec.
>>Attempts to improve things for some scenarios (e.g. Mobile IP) may make
>>things worse in others (e.g. Address Translation Gateways).
>
>Hello Charlie,
>
>You raise some excellent points as usual.
>
>I have privately thought for a long time that IPsec's dependence on an
>IP address to determine an SA to be a fundamental flaw in its design.
>To be effective IPsec needs a global address space, in which each host is
>uniquely identified, like the Internet was prior to the introduction of
>NATs, etc. To make this work a way to dynamically map an Internet address,
>including duplicate private non-routable addresses, to a global unique IPSec
>address/identifier needs to be made available. Each host can then query
>this database to resolve an IP address to a secure IPsec address/identifier.
>Cryptography is then used to assure that the IPsec address/identifier is
>indeed valid. In this way both MobileIP and NAT can be supported as-is,
>because they operate on an insecure non-unique IP address, while IPsec uses
>the parallel universe of a secure unique IPsec address/identifier.
>
>However this approach does mean that IPsec can no longer be treated as just
>a secure protocol, or set of protocols if you include key management. It
>must be part of a security system, which includes this address mapping
>facility.
>
>Regards,
>
>- Alex
Alex,
I assume you have read the new ESP ID from last fall, as well as the
new AH ID from this spring, and have followed the WG discussions of
why the SA can be determined by examining just the SPI 9without
referebce to the destination address), for unicast traffic. Given
that context, I'm not sure I understand your comments above. Could
you clarify?
Thanks,
Steve
From owner-ipsec@lists.tislabs.com Fri May 17 19:13:46 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4I2DjL23553;
Fri, 17 May 2002 19:13:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11880
Fri, 17 May 2002 21:31:37 -0400 (EDT)
Reply-To: <ph2000@lvcm.com>
From: "Penny Harper" <ph2000@lvcm.com>
To: "'Francis Dupont'" <Francis.Dupont@enst-bretagne.fr>,
"'Michael Thomas'" <mat@cisco.com>
Cc: <Charlie_Kaufman@notesdev.ibm.com>, <ipsec@lists.tislabs.com>
Subject: RE: addresses and IKEv2
Date: Fri, 17 May 2002 18:43:21 -0700
Message-ID: <005f01c1fe0d$65c4c9b0$6400a8c0@w2ks>
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, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <200205170944.g4H9iRT93074@givry.rennes.enst-bretagne.fr>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Will someone on this list please tell me how to remove myself from the
list? Thanks.
-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Francis Dupont
Sent: Friday, May 17, 2002 2:44 AM
To: Michael Thomas
Cc: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
In your previous mail you wrote:
=> thanks for your support Mike!
What happens with IKE is another discussion that
I'll bow out of for the time being...
=> there is something to do with IKE because SAs come by pairs, i.e. for
the mobile to correspondent way address agility is enough (and is
already in RFC 2401) but for the correspondent to mobile way something
is needed (readdressing exchange?).
Thanks
Francis.Dupont@enst-bretagne.fr
PS: more I think about SOI & mobility, more I believe SOI should have an
optional message header verification, something like a special ID
payload with the party transport parameters. My current idea is, for
IKEv2 for instance:
- optional ID payload of type address with the party transport
parameters (address, protocol (udp), port (500))
- this payload should be the first one (a way to mark it as special)
- if it is present it must be checked against the message header
- the policy should say if this is required to be sent or received
- the policy should say if this can overwrite previous used addresses:
* further IKE messages
* all established SAs with this peer
IMHO only the last point is arguable (i.e. I am still looking for better
solutions).
From owner-ipsec@lists.tislabs.com Fri May 17 21:01:48 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4I41lL26433;
Fri, 17 May 2002 21:01:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12082
Fri, 17 May 2002 23:24:44 -0400 (EDT)
Date: Sat, 18 May 2002 06:36:42 +0300
Message-Id: <200205180336.GAA19829@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: henry@spsystems.net
CC: ipsec@lists.tislabs.com
In-reply-to: <Pine.BSI.3.91.1020515102020.23570E-100000@spsystems.net>
(message from Henry Spencer on Wed, 15 May 2002 10:23:28 -0400 (EDT))
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <Pine.BSI.3.91.1020515102020.23570E-100000@spsystems.net>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: Henry Spencer <henry@spsystems.net>
> On Wed, 15 May 2002, Markku Savela wrote:
> > There is no need for such other protocol. Assuming your implementation
> > is conformant to RFC-2401, it already does the policy checking,
> > whether IKE is present or not.
>
> It does not do consistency checking to ensure that the policies on
> the two ends match. Nor does it have any way of selecting between
> policy options, when the other end may not accept all choices.
> These are practical issues of great importance, however trivial they
> may seem in theory.
There is no need to ensure that policies on two ends match. As per
RFC-2401, policy is checked for each packet. IKE does not need to
check the policy.
As I've said repeatedly, it is easy to detect policy mismatch during
the normal and *required* policy checking on received packet: if it
arrives and "decodes" properly with indicated SA(s) and then fails
the policy check, you have a mismatched policy.
There is no need and never should be any "policy negotiation" protocol
within IKE. I view IPSEC policy as similar concept as firewall
rules. Each host decides and specifies it's requirements outside
IKE. There is no "firewall policy exchange protocol" either, and hosts
manage to communicate over them.
What are "policy options"? If you mean alternatives to the algorithms,
then that is quite ok. My policy migth say
local-port=80 -> ESP (DES3 | BLOWFISH)
and it would accept both. Algorithm is part of the SA definition.
I think part of the confusion is due to fact that freeswan uses the
SPD for storing the traffic selector information, which should really
be attached to the SA.
In above my policy selector is just "local-port=80", but if I have
additional requirement that each connection should use own SA, then
the traffic selectors in the generated negotiation will include both
ports and addressess explicitly (and this information is stored into
each SA directly, not into SPD like freeswan appears to do).
From owner-ipsec@lists.tislabs.com Fri May 17 23:22:59 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4I6MxL05852;
Fri, 17 May 2002 23:22:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA12414
Sat, 18 May 2002 01:44:02 -0400 (EDT)
Message-Id: <200205180546.g4I5kbT00763@fatty.lounge.org>
To: Markku Savela <msa@burp.tkv.asdf.org>
Cc: henry@spsystems.net, ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-Reply-To: Your message of "Sat, 18 May 2002 06:36:42 +0300."
<200205180336.GAA19829@burp.tkv.asdf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <760.1021700797.1@tibernian.com>
Date: Fri, 17 May 2002 22:46:37 -0700
From: Dan Harkins <dharkins@tibernian.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Sat, 18 May 2002 06:36:42 +0300 you wrote
>
> There is no need and never should be any "policy negotiation" protocol
> within IKE. I view IPSEC policy as similar concept as firewall
> rules. Each host decides and specifies it's requirements outside
> IKE. There is no "firewall policy exchange protocol" either, and hosts
> manage to communicate over them.
What if Joe User had an workstation with IP address 172.21.16.5 and
the following policy:
172.21.16.5 <---> 10.1/16, protect via 192.168.10.1
any <--> any, drop
and 192.168.10.1 has the 10.1/16 network on a directly connected interface
and the following policy:
10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5
any <--> any, drop
Here Joe thinks he can access more than the remote gateway will allow.
Joe tries to access 10.1.5.5. How does Joe figure out what the problem is?
In your view of the world each side has SAs that denote their own rules
but there is no communication between them to express a mismatch. Someone
monitoring the 192.168.10.1 gateway may see lots of packets sent from
172.21.16.5 being dropped because they fail a policy check (assuming of
course that someone is monitoring it which is _highly_ unlikely). But that's
about it. To Joe it's a blackhole and "it just doesn't work".
In addition, in your view of how IKE should work it would not be possible
to do IPsec remote access where one end is coming from an unknown IP
address and accessing a protected network behind a gateway. The gateway
cannot know the IP address of the remote client a priori and therefore can't
have any policy information specifying what traffic to and from him is to
be protected, dropped, or bypassed. And since, in your view, IKE is forbidden
from providing any hints it won't work.
A hopeless blackhole and (arguably) the most popular use of IPsec today
being not allowed. That's not a very compelling argument.
Dan.
From owner-ipsec@lists.tislabs.com Sat May 18 05:48:15 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ICmEL17022;
Sat, 18 May 2002 05:48:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12919
Sat, 18 May 2002 07:59:58 -0400 (EDT)
Message-Id: <200205181212.g4ICCCT99062@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Lars Eggert <larse@ISI.EDU>
cc: Michael Thomas <mat@cisco.com>, Charlie_Kaufman@notesdev.ibm.com,
ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
In-reply-to: Your message of Fri, 17 May 2002 09:12:28 PDT.
<3CE52BEC.1040306@isi.edu>
Date: Sat, 18 May 2002 14:12:12 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
This is a cryptographically signed message in MIME format.
I didn't mean a draft-touch-ipsec tunnel (this time :-), I meant this:
| Tunnel IP Header:| Orig IP Header:| IPsec: | |
| TSrc -> TDst | OSrc -> ODst | Transport Mode | Payload |
I.e. just run IPsec end-to-end over a MobileIP (or other IPIP) tunnel.
But there may be specifics to Mobile IP that I'm ignorant of...
=> by definition in Mobile IP the Home Agent may not modify the content
of packets it relays to the Mobile Node (this is why it uses a tunnel
and doesn't add a routing header in Mobile IPv6) so as this transport
mode is end-to-end it is orthogonal to Mobile IP...
Thanks
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Sat May 18 06:20:03 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4IDK3L18167;
Sat, 18 May 2002 06:20:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12977
Sat, 18 May 2002 08:42:02 -0400 (EDT)
Message-Id: <200205181253.g4ICrrT99275@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Alex Alten <Alten@attbi.com>
cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
In-reply-to: Your message of Fri, 17 May 2002 11:05:46 PDT.
<3.0.3.32.20020517110546.013cbfc0@mail>
Date: Sat, 18 May 2002 14:53:53 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
I have privately thought for a long time that IPsec's dependence on an
IP address to determine an SA to be a fundamental flaw in its design.
To be effective IPsec needs a global address space, in which each host is
uniquely identified, like the Internet was prior to the introduction of
NATs, etc. To make this work a way to dynamically map an Internet address,
including duplicate private non-routable addresses, to a global unique IPSec
address/identifier needs to be made available. Each host can then query
this database to resolve an IP address to a secure IPsec address/identifier.
Cryptography is then used to assure that the IPsec address/identifier is
indeed valid. In this way both MobileIP and NAT can be supported as-is,
because they operate on an insecure non-unique IP address, while IPsec uses
the parallel universe of a secure unique IPsec address/identifier.
=> what you want is HIP (Host Identity Payload protocol)...
However this approach does mean that IPsec can no longer be treated as just
a secure protocol, or set of protocols if you include key management. It
must be part of a security system, which includes this address mapping
facility.
=> HIP or any other two space (*) solution should be a major change
in the architecture of the Internet.
Thanks
Francis.Dupont@enst-bretagne.fr
PS (*): systems where locator and identity functions of addresses
are separated.
From owner-ipsec@lists.tislabs.com Sat May 18 07:43:44 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4IEhhL25358;
Sat, 18 May 2002 07:43:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13141
Sat, 18 May 2002 09:59:33 -0400 (EDT)
Message-Id: <200205181411.g4IEBUT99602@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Alex Alten <Alten@attbi.com>
cc: Stephen Kent <kent@bbn.com>, Charlie_Kaufman@notesdev.ibm.com,
ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
In-reply-to: Your message of Fri, 17 May 2002 16:38:06 PDT.
<3.0.3.32.20020517163806.013cc950@mail>
Date: Sat, 18 May 2002 16:11:30 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
The fundamental problem is how can we identify a host unambigously in
real time in order to be able to automate the picking of the correct
crypto key used to authenticate it and then bootstrap the SA? I don't
see the answer anywhere in the RFCs or IDs. Certainly there are a lot
of documents and maybe I've missed seeing it. I know that X.509 certs
are not the answer (the bound name/address is too static and can be
unreliable).
=> I have a different view of this problem: I believe the identity
is really the IKE phase one ID and X.509 certs are the answer. But
of course this is not enough because the problem moves to the relationship
between the identity and the IP address:
- it must be flexible, i.e. I agree here X.509 certs are too static.
- it must be reliable, i.e. if the identity is a FQDN then we have to go
to DNSsec which is not ready and deployed.
- it should be "agile" if we'd like to support mobility, i.e. the previous
solution is not enough dynamic.
- it should be broken if we'd like to support NAT traversal. Of course
this opens the door to obvious security problems.
I'd like to see this WG decides what properties we'd like to get for
addresses, i.e. in the same order:
- authenticated
- indirectly authenticated
- check for integrity
- just pick up as they are got.
The trust is not the same, authentication relies on PKIs, integrity checks
on the peer, last property on ingress filtering and safe infrastructure.
As we use more and more IDs of not address types (as recommended by
the IAB in RFC 2956), this problem should be solved ASAP. IMHO it is
more important than SOI (or at least should be a critical point of SOI).
Thanks
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Sat May 18 09:25:43 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4IGPgL01709;
Sat, 18 May 2002 09:25:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13357
Sat, 18 May 2002 11:45:48 -0400 (EDT)
Message-Id: <200205181556.g4IFuoT99856@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Markku Savela <msa@burp.tkv.asdf.org>
cc: henry@spsystems.net, ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-reply-to: Your message of Sat, 18 May 2002 06:36:42 +0300.
<200205180336.GAA19829@burp.tkv.asdf.org>
Date: Sat, 18 May 2002 17:56:50 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
> From: Henry Spencer <henry@spsystems.net>
> On Wed, 15 May 2002, Markku Savela wrote:
> > There is no need for such other protocol. Assuming your implementation
> > is conformant to RFC-2401, it already does the policy checking,
> > whether IKE is present or not.
>
> It does not do consistency checking to ensure that the policies on
> the two ends match. Nor does it have any way of selecting between
> policy options, when the other end may not accept all choices.
> These are practical issues of great importance, however trivial they
> may seem in theory.
=> I agree with Henry even I use a very different system (KAME/racoon).
There is no need to ensure that policies on two ends match. As per
RFC-2401, policy is checked for each packet. IKE does not need to
check the policy.
=> RFC 2401 says the SPD (it seems to make things even less clear that
policy and SPD are different :-).
As I've said repeatedly, it is easy to detect policy mismatch during
the normal and *required* policy checking on received packet: if it
arrives and "decodes" properly with indicated SA(s) and then fails
the policy check, you have a mismatched policy.
=> this is detected by the kernel a posteriori. The other opinion is
this should be detected by IKE at the SA establishment.
There is no need and never should be any "policy negotiation" protocol
within IKE. I view IPSEC policy as similar concept as firewall
rules. Each host decides and specifies it's requirements outside
IKE. There is no "firewall policy exchange protocol" either, and hosts
manage to communicate over them.
What are "policy options"? If you mean alternatives to the algorithms,
then that is quite ok. My policy migth say
local-port=80 -> ESP (DES3 | BLOWFISH)
and it would accept both. Algorithm is part of the SA definition.
=> if I assume policy==SPD entry, this seems very classical
(key is a traffic selector, options are the "action". I agree algorithms
are in the SA definition).
I think part of the confusion is due to fact that freeswan uses the
SPD for storing the traffic selector information, which should really
be attached to the SA.
=> RFC 2401 says in section 5 "If no policy is found in the SPD that
matches the packet..." (this defines the default action). The whole
RFC 2401 suggests the key of the SPD is a traffic selector. So I disagree
with you (note RFC 2401 doesn't say the opposite too, i.e. your objection
is valid and IPsec implementors in trouble).
In above my policy selector is just "local-port=80", but if I have
additional requirement that each connection should use own SA, then
=> this should be allowed according to RFC 2401 but it seems some
implementations need a SPD entry by connection (?)...
the traffic selectors in the generated negotiation will include both
ports and addressess explicitly (and this information is stored into
each SA directly, not into SPD like freeswan appears to do).
=> KAME has the same symptom... The level "uniq" helps but its meaning
is that to share a SA between two SPD entries is forbidden, i.e. not
a solution to your problem (which IMHO is not the place of the TSs,
but the fact a SPD entry can only point to zero or one SA (bundle)
with a cache/lookup mechanism using only addresses and the "uniq" feature).
Regards
Francis.Dupont@enst-bretagne.fr
PS: I believe this is a result of the incredible confusion in RFC 2401 & co
about addresses in SAs. At the question how many addresses characterized
a SA, you can answer zero, one, two, three or four and find a reference
in a RFC or an I-D...
From owner-ipsec@lists.tislabs.com Sat May 18 15:16:09 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4IMG8L14509;
Sat, 18 May 2002 15:16:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13793
Sat, 18 May 2002 17:37:14 -0400 (EDT)
Date: Sun, 19 May 2002 00:49:50 +0300
Message-Id: <200205182149.AAA20255@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: dharkins@tibernian.com
CC: henry@spsystems.net, ipsec@lists.tislabs.com
In-reply-to: <200205180546.g4I5kbT00763@fatty.lounge.org> (message from Dan
Harkins on Fri, 17 May 2002 22:46:37 -0700)
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <200205180546.g4I5kbT00763@fatty.lounge.org>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: Dan Harkins <dharkins@tibernian.com>
> What if Joe User had an workstation with IP address 172.21.16.5 and
> the following policy:
>
> 172.21.16.5 <---> 10.1/16, protect via 192.168.10.1
> any <--> any, drop
>
> and 192.168.10.1 has the 10.1/16 network on a directly connected interface
> and the following policy:
>
> 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5
> any <--> any, drop
>
> Here Joe thinks he can access more than the remote gateway will allow.
> Joe tries to access 10.1.5.5. How does Joe figure out what the
> problem is?
This is a somewhat different type of policy mismatch than what I was
thinking. In this case, the maintainer of 192.168.10.1 is
intentionally forbidding joe from accessing the 10.1.5.5. If joe still
tries to do that, he is basicly trying to crack the "firewall". It
would be appropriate to alert the 192.168.10.1 maintainer, but I don't
think we should notify the cracker about it.
On the other hand this a good example of why policy selectors should
not be checked in the IKE negotiation. As long as joe stays within
the limits of 10.1.17/24, both sides are happy when they compare the
exchanged packets to their policy selectors.
In above, nothing is yet said about how many SA pairs are being used
between 192.168.10.1 and 172.21.16.5. Assuming only one pair for all
communication, then in the IKE negotiation, the selector information
to be associated with the bots SA's would be
protocol=any
src port=any
dst port=any
> In addition, in your view of how IKE should work it would not be
> possible to do IPsec remote access where one end is coming from an
> unknown IP address and accessing a protected network behind a
> gateway. The gateway cannot know the IP address of the remote client
> a priori and therefore can't have any policy information specifying
> what traffic to and from him is to be protected, dropped, or
> bypassed. And since, in your view, IKE is forbidden from providing
> any hints it won't work.
My view works just fine in such situation. The gateway 192.168.10.1
just has the policy (using your notation)
10.1.17/24 <---> any, protect via "any"
any <--> any, drop
You do need to have the ability to express tunneling with
"any". Assuming joe has the policy as before and wants to connect to
10.1.17.1, then IKE negotiates the SA pair exactly as before (except,
of course, that at least now joe must identify itself in phase 1 with
something that does not depend on address). The resulting SA's would
be exactly the same as before.
Looking the situation at 192.168.10.1...
Incoming protected packet from joe gets decoded, detunneled, revealing
the inner IP: src=172.21.16.5 dst=10.1.17.1 (protected via
172.21.16.5). This will match the policy and gets passed on in clear.
Outgoing clear packet is received from 10.1.17.1 with destination
172.21.16.5. Again, this will match the policy selector
10.1.17/24 <---> any, protect via "any"
At this point there is the first "tricky" issue. In the example, joe
is his own security gateway, so the assumption
any == "any"
would work and just using the inner destination also as outer
destination gives the correct behaviour. Packet is protected using the
proper SA and sent away.
HOWEVER, if joe itself is behind a security gateway (=172.21.16.1),
and 192.168.10.1 receives and outgoing packet with
src=10.1.17.1, dst=172.21.16.5
How does 192.168.10.1 know that in this case any != "any", e.g. packet
should be protected via 172.21.16.1).
Freeswan guys probably install additional policy entry
10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.1
10.1.17/24 <---> any, protect via "any"
any <--> any, drop
This solves the case, when joe is the initator. There is no solution,
if 10.1.17.1 is the initiator (inherently impossible, unless
assumption any == "any" is made).
In my view, the solution could be as follows:
joe's SG (172.21.16.1) negotiates SA's for joe (172.21.16.5), and the
resulting SA has the following info
protocol=any
src port=any
dst port=any
proxy=172.21.16.5
Now, 192.168.10.1 receives the outbound packet
src=10.1.17.1, dst=172.21.16.5
it matches the policy
10.1.17/24 <---> any, protect via "any"
from this it knows that tunneling is required, so it will need to look
for an SA that has proxy=172.21.16.5, and if joe is the initiator,
such thing might be found and packet can be processed.
If SA does not exist, there is not enough information to start
negotiation. Situation is inherently unsolvable (unless a simple
default assumption is attempted, namely the any == "any")
From owner-ipsec@lists.tislabs.com Sat May 18 16:01:57 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4IN1vL16721;
Sat, 18 May 2002 16:01:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13843
Sat, 18 May 2002 18:24:48 -0400 (EDT)
Date: Sun, 19 May 2002 01:36:49 +0300
Message-Id: <200205182236.BAA20271@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: Francis.Dupont@enst-bretagne.fr
CC: henry@spsystems.net, ipsec@lists.tislabs.com
In-reply-to: <200205181556.g4IFuoT99856@givry.rennes.enst-bretagne.fr>
(message from Francis Dupont on Sat, 18 May 2002 17:56:50 +0200)
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <200205181556.g4IFuoT99856@givry.rennes.enst-bretagne.fr>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
> There is no need to ensure that policies on two ends match. As per
> RFC-2401, policy is checked for each packet. IKE does not need to
> check the policy.
>
> => RFC 2401 says the SPD (it seems to make things even less clear that
> policy and SPD are different :-).
SPD is the policy, SAD and SPD are different.
> => RFC 2401 says in section 5 "If no policy is found in the SPD that
> matches the packet..." (this defines the default action). The whole
> RFC 2401 suggests the key of the SPD is a traffic selector. So I disagree
> with you (note RFC 2401 doesn't say the opposite too, i.e. your objection
> is valid and IPsec implementors in trouble).
I was confusing the issue by using "unspecified terminology". In my
view we have two types of "selectors"
- policy selectors (the ones in SPD)
- traffic selectors (used in IKEv2 key negotiations and end up into
SAD)
The latter are just qualifiers that are associated with the negotiated
SA's. And are *ONLY* needed to differentiate multiple SA's between
same endpoints. Instead of "traffic selector", should probably use
some other term to avoid confusion with the actual "traffic selectors"
in the policy.
> In above my policy selector is just "local-port=80", but if I have
> additional requirement that each connection should use own SA, then
>
> => this should be allowed according to RFC 2401 but it seems some
> implementations need a SPD entry by connection (?)...
Yes, they only partial implementations of rfc-2401, most likely due to
IKE limitations. RFC-2401 allows many things, which are not possible
with IKE(v1). I would like to have this mistake avoided by the next
IKEv2, and one way of achieving this result is to remove all policy
checking from the IKE.
> => KAME has the same symptom... The level "uniq" helps but its meaning
> is that to share a SA between two SPD entries is forbidden, i.e. not
> a solution to your problem (which IMHO is not the place of the TSs,
> but the fact a SPD entry can only point to zero or one SA (bundle)
> with a cache/lookup mechanism using only addresses and the "uniq" feature).
In my implementation, there is no pointers from policy selector to
SA. Any policy selector can be associated with any number of SA's and
vice versa.
Also, different bundles can share SA's (if only IKE could negotiate
such thing). Again, if I get policy (and bundle checking) off the IKE,
even SA sharing would start to work fine.
> PS: I believe this is a result of the incredible confusion in RFC 2401 & co
> about addresses in SAs. At the question how many addresses characterized
> a SA, you can answer zero, one, two, three or four and find a reference
> in a RFC or an I-D...
To me there is no confusion in the SA itself. You have a packet, you
extract the selector information from as defined in RFC-2401. There
are only 3 addresses: src, dst and possible IPSEC tunnel address (SG
address). If my policy says
selector => protect by SG
then for incoming packets I must also check that the packet actually
came from SG (I'm not really sure whether this check is really giving
us anything). However, this only applies to tunnels that are specified
within the IPSEC itself.
There may be some confusion about what the src and dst actually are,
in presence of things like IPv6 home address option.
From owner-ipsec@lists.tislabs.com Sun May 19 06:56:59 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4JDuwL26510;
Sun, 19 May 2002 06:56:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14969
Sun, 19 May 2002 09:07:03 -0400 (EDT)
Message-Id: <200205191318.g4JDIuT02040@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Markku Savela <msa@burp.tkv.asdf.org>
cc: henry@spsystems.net, ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-reply-to: Your message of Sun, 19 May 2002 01:36:49 +0300.
<200205182236.BAA20271@burp.tkv.asdf.org>
Date: Sun, 19 May 2002 15:18:56 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote:
> => RFC 2401 says in section 5 "If no policy is found in the SPD that
> matches the packet..." (this defines the default action). The whole
> RFC 2401 suggests the key of the SPD is a traffic selector. So I disagree
> with you (note RFC 2401 doesn't say the opposite too, i.e. your objection
> is valid and IPsec implementors in trouble).
I was confusing the issue by using "unspecified terminology". In my
view we have two types of "selectors"
- policy selectors (the ones in SPD)
- traffic selectors (used in IKEv2 key negotiations and end up into
SAD)
=> I have two concerns with that:
- policy and traffic selectors have the same format (i.e. the only way
to know if a selector is a policy or a traffic one is its "owner").
- I know you'd like that IKEv2 TS are SAD selectors but there is *no*
consensus about this point.
The latter are just qualifiers that are associated with the negotiated
SA's. And are *ONLY* needed to differentiate multiple SA's between
same endpoints. Instead of "traffic selector", should probably use
some other term to avoid confusion with the actual "traffic selectors"
in the policy.
> In above my policy selector is just "local-port=80", but if I have
> additional requirement that each connection should use own SA, then
>
> => this should be allowed according to RFC 2401 but it seems some
> implementations need a SPD entry by connection (?)...
Yes, they only partial implementations of rfc-2401, most likely due to
IKE limitations. RFC-2401 allows many things, which are not possible
with IKE(v1).
=> I have no reason to not believe you but my problem is I can't find
an "open-source" implementation of IPsec which has more than partial
implementations. So I can't judge if your view can be implemented
(or how to implement it).
I would like to have this mistake avoided by the next
IKEv2, and one way of achieving this result is to remove all policy
checking from the IKE.
=> IMHO this is not the good way because we'll only get more unpredicable
results...
In my implementation...
=> is it an open-source one (in order to understand it)?
> PS: I believe this is a result of the incredible confusion in RFC 2401 & co
> about addresses in SAs. At the question how many addresses characterized
> a SA, you can answer zero, one, two, three or four and find a reference
> in a RFC or an I-D...
To me there is no confusion in the SA itself. You have a packet, you
extract the selector information from as defined in RFC-2401.
=> this is a traffic selector view: two (inner) addresses.
There are only 3 addresses: src, dst and possible IPSEC tunnel address (SG
address).
=> I believe the third address is the outer destination. IMHO you should
consider the outer source too because:
- some stupid implementations will check it so you may not just pick up one.
- IKE negociates SAs by pairs and the outer source is the destination
of the second SA in the opposite way.
If my policy says
selector => protect by SG
then for incoming packets I must also check that the packet actually
came from SG (I'm not really sure whether this check is really giving
us anything).
=> so your implementation does an unnecessary check (this check gives nothing
but removes many).
However, this only applies to tunnels that are specified within the
IPSEC itself.
=> so you finish by 4 addresses because of the tunnel mode.
Other answers are:
- zero: draft-ietf-ipsec-esp-v3-02.txt inbound processing of unicasts
- one: RFC 2401 inbound processing (and previous I-D for multicasts)
- two: common sense / transport mode
- three: your first answer and PF_KEY (RFC 2367, the source and destination
are outer addresses, the optional proxy is the inner source)
There may be some confusion about what the src and dst actually are,
in presence of things like IPv6 home address option.
=> home address option, routing header, etc, don't introduce confusion
because their action is guided by their position. For instance
the home address option should be before any IPsec header, so in inbound
processing it is always processed before any IPsec header and IPsec can see
only the home address. The complexity exists only for policy on SGs
but RFC 2401 gives the details of the transport header chasing: the
procedure is to jump between headers using the next header field,
so the content of headers should *not* be interpreted by a SG.
(this point should be made clearer in the next 2401)
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Sun May 19 23:12:59 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4K6CxL10147;
Sun, 19 May 2002 23:12:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA16134
Mon, 20 May 2002 01:29:00 -0400 (EDT)
Message-Id: <200205200531.g4K5VaN01164@fatty.lounge.org>
To: Markku Savela <msa@burp.tkv.asdf.org>
Cc: henry@spsystems.net, ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-Reply-To: Your message of "Sun, 19 May 2002 00:49:50 +0300."
<200205182149.AAA20255@burp.tkv.asdf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1161.1021872696.1@tibernian.com>
Date: Sun, 19 May 2002 22:31:36 -0700
From: Dan Harkins <dharkins@tibernian.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Sun, 19 May 2002 00:49:50 +0300 you wrote
> > From: Dan Harkins <dharkins@tibernian.com>
>
> > What if Joe User had an workstation with IP address 172.21.16.5 and
> > the following policy:
> >
> > 172.21.16.5 <---> 10.1/16, protect via 192.168.10.1
> > any <--> any, drop
> >
> > and 192.168.10.1 has the 10.1/16 network on a directly connected interface
> > and the following policy:
> >
> > 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5
> > any <--> any, drop
> >
> > Here Joe thinks he can access more than the remote gateway will allow.
> > Joe tries to access 10.1.5.5. How does Joe figure out what the
> > problem is?
>
> This is a somewhat different type of policy mismatch than what I was
> thinking. In this case, the maintainer of 192.168.10.1 is
> intentionally forbidding joe from accessing the 10.1.5.5. If joe still
> tries to do that, he is basicly trying to crack the "firewall". It
> would be appropriate to alert the 192.168.10.1 maintainer, but I don't
> think we should notify the cracker about it.
Your firewall analogy is breaking down. Joe is not a "cracker" he is a
user who has been properly authenticated by the gateway. The gateway has
decided that he does wish to give Joe access, just that Joe seems to think
he is entitled to access more than gateway is allowing.
Notification of Joe is the prudent thing to do since he is not a "cracker",
he is a legitimate user with old/stale/incorrect policy. By just blackholing
his packets you have relegated him to oblivion. You obviously have not
dealt with real world use of this technology.
This is not a firewall. It's an IPsec gateway.
> On the other hand this a good example of why policy selectors should
> not be checked in the IKE negotiation. As long as joe stays within
> the limits of 10.1.17/24, both sides are happy when they compare the
> exchanged packets to their policy selectors.
On the contrary, this is a good example of why they should. So that Joe
will know exactly what part of his policy is old/stale/incorrect and
be able to initiate a procedure to fix it. By not checking the only
information Joe will have is "it's broke". I know who your sysadmin
staff is and I know that "it's broke" is not satisfactory to get them
to fix it.
IKE wants to make sure that what is being established is useful and if it
is not then to not establish it. If you want to do away with this utility
then you should have some substitute for it.
> > In addition, in your view of how IKE should work it would not be
> > possible to do IPsec remote access where one end is coming from an
> > unknown IP address and accessing a protected network behind a
> > gateway. The gateway cannot know the IP address of the remote client
> > a priori and therefore can't have any policy information specifying
> > what traffic to and from him is to be protected, dropped, or
> > bypassed. And since, in your view, IKE is forbidden from providing
> > any hints it won't work.
>
> My view works just fine in such situation. The gateway 192.168.10.1
> just has the policy (using your notation)
>
> 10.1.17/24 <---> any, protect via "any"
> any <--> any, drop
>
> You do need to have the ability to express tunneling with
> "any". Assuming joe has the policy as before and wants to connect to
> 10.1.17.1, then IKE negotiates the SA pair exactly as before (except,
> of course, that at least now joe must identify itself in phase 1 with
> something that does not depend on address). The resulting SA's would
> be exactly the same as before.
>
> Looking the situation at 192.168.10.1...
>
> Incoming protected packet from joe gets decoded, detunneled, revealing
> the inner IP: src=172.21.16.5 dst=10.1.17.1 (protected via
> 172.21.16.5). This will match the policy and gets passed on in clear.
>
> Outgoing clear packet is received from 10.1.17.1 with destination
> 172.21.16.5. Again, this will match the policy selector
>
> 10.1.17/24 <---> any, protect via "any"
>
> At this point there is the first "tricky" issue. In the example, joe
> is his own security gateway, so the assumption
>
> any == "any"
>
> would work and just using the inner destination also as outer
> destination gives the correct behaviour. Packet is protected using the
> proper SA and sent away.
>
> HOWEVER, if joe itself is behind a security gateway (=172.21.16.1),
> and 192.168.10.1 receives and outgoing packet with
>
> src=10.1.17.1, dst=172.21.16.5
>
> How does 192.168.10.1 know that in this case any != "any", e.g. packet
> should be protected via 172.21.16.1).
>
> Freeswan guys probably install additional policy entry
>
> 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.1
> 10.1.17/24 <---> any, protect via "any"
> any <--> any, drop
Not just freeswan but every one else who implements this _correctly_.
> This solves the case, when joe is the initator. There is no solution,
> if 10.1.17.1 is the initiator (inherently impossible, unless
> assumption any == "any" is made).
>
> In my view, the solution could be as follows:
>
> joe's SG (172.21.16.1) negotiates SA's for joe (172.21.16.5), and the
> resulting SA has the following info
>
> protocol=any
> src port=any
> dst port=any
> proxy=172.21.16.5
Proxy? Where did that come from? I thought IKE was not permitted to provide
any clarifying information in your view. SA were just established that
specify a destination address, in this case 172.21.16.1. There is no tie
from the policy statement with "any" to this address and a packet sent
to 172.21.16.5 would definitely hit the "any" part of that selector but
there would be no way to locate the correct SA and destination gateway.
Dan.
From owner-ipsec@lists.tislabs.com Mon May 20 00:58:45 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4K7wjL27520;
Mon, 20 May 2002 00:58:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA16386
Mon, 20 May 2002 03:20:16 -0400 (EDT)
Message-ID: <4F7DD203738DD411B71A00B0D03DDECC034A2268@highway>
From: 867 <867@nu.edu.pk>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: How to Capture an IP Packet
Date: Mon, 20 May 2002 13:35:23 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dear all,
Can any body please help me in an issue. I need to capture the IP Packet
after IP layer has processed it, and then place it to the next layer myself.
I am using Linux as the development platform.
Thanks.
Regards,
Usman
From owner-ipsec@lists.tislabs.com Mon May 20 05:48:42 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KCmfL23308;
Mon, 20 May 2002 05:48:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17077
Mon, 20 May 2002 08:05:04 -0400 (EDT)
Message-Id: <3.0.3.32.20020517163806.013cc950@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Fri, 17 May 2002 16:38:06 -0700
To: Stephen Kent <kent@bbn.com>
From: Alex Alten <Alten@attbi.com>
Subject: Re: addresses and IKEv2
Cc: Charlie_Kaufman@notesdev.ibm.com,
Francis Dupont <Francis.Dupont@enst-bretagne.fr>, ipsec@lists.tislabs.com
In-Reply-To: <p05100316b90b027b1063@[128.89.88.34]>
References: <3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 02:56 PM 5/17/2002 -0400, Stephen Kent wrote:
>At 11:05 AM -0700 5/17/02, Alex Alten wrote:
>>At 10:42 PM 5/14/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote:
>>>This posting points out the tip of a very large iceberg. I think I
>>>understand some of the issues (but I'm not confident); some seem
>>>unsolvable; and some raise questions about the design goals of IPsec.
>>>Attempts to improve things for some scenarios (e.g. Mobile IP) may make
>>>things worse in others (e.g. Address Translation Gateways).
>>
>>Hello Charlie,
>>
>>You raise some excellent points as usual.
>>
>>I have privately thought for a long time that IPsec's dependence on an
>>IP address to determine an SA to be a fundamental flaw in its design.
>>To be effective IPsec needs a global address space, in which each host is
>>uniquely identified, like the Internet was prior to the introduction of
>>NATs, etc. To make this work a way to dynamically map an Internet address,
>>including duplicate private non-routable addresses, to a global unique IPSec
>>address/identifier needs to be made available. Each host can then query
>>this database to resolve an IP address to a secure IPsec address/identifier.
>>Cryptography is then used to assure that the IPsec address/identifier is
>>indeed valid. In this way both MobileIP and NAT can be supported as-is,
>>because they operate on an insecure non-unique IP address, while IPsec uses
>>the parallel universe of a secure unique IPsec address/identifier.
>>
>>However this approach does mean that IPsec can no longer be treated as just
>>a secure protocol, or set of protocols if you include key management. It
>>must be part of a security system, which includes this address mapping
>>facility.
>>
>>Regards,
>>
>>- Alex
>
>Alex,
>
>I assume you have read the new ESP ID from last fall, as well as the
>new AH ID from this spring, and have followed the WG discussions of
>why the SA can be determined by examining just the SPI 9without
>referebce to the destination address), for unicast traffic. Given
>that context, I'm not sure I understand your comments above. Could
>you clarify?
>
>Thanks,
>
>Steve
>
Steve,
My comments only apply to the RFCs as they stand today. SPI is a
different beast than what I'm discussing even with your latest ESP
ID adjustments.
The fundamental problem is how can we identify a host unambigously in
real time in order to be able to automate the picking of the correct
crypto key used to authenticate it and then bootstrap the SA? I don't
see the answer anywhere in the RFCs or IDs. Certainly there are a lot
of documents and maybe I've missed seeing it. I know that X.509 certs
are not the answer (the bound name/address is too static and can be
unreliable).
- Alex
--
Alex Alten
Alten@ATTBI.com
From owner-ipsec@lists.tislabs.com Mon May 20 05:48:42 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KCmfL23309;
Mon, 20 May 2002 05:48:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17140
Mon, 20 May 2002 08:10:08 -0400 (EDT)
Message-Id: <200205192330.TAA13625@nwmail.wh.lucent.com>
Content-Type: text/plain;
charset="iso-8859-1"
From: Uri Blumenthal <uri@bell-labs.com>
Reply-To: uri@bell-labs.com
To: Jan Vilhuber <vilhuber@cisco.com>, Michael Thomas <mat@cisco.com>
Subject: Re: SOI schizophrenia
Date: Sun, 19 May 2002 19:29:57 -0400
X-Mailer: KMail [version 1.3.2]
Cc: ipsec@lists.tislabs.com
References: <Pine.LNX.4.21.0205161337340.2302-100000@localhost>
In-Reply-To: <Pine.LNX.4.21.0205161337340.2302-100000@localhost>
Organization: Lucent Technologies / Bell Labs
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA15611
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thursday 16 May 2002 16:58, Jan Vilhuber wrote:
> > All in all, they both seem competent.
>
> They are both competent from a cryptography point of view, but only
> one actually allows key management in any sane way.
Precisely.
> I think that's
> where the two part company, and we as a group need to decide which is
> more appropriate: A key *agreement* protocol (JFK) which will require
> other protocols (ICMP? Right..) to help solve the current deployment
> stability, or a key *management* protocol (IKEv2), that let's you
> manage the key we agreed on, without requiring other external
> management protocols.
Indeed, a crucial distinction between a protocol that does the
necessary math and a protocol that [in addition to that] provides the
services required by the real world deployment.
> Of course another question might be: Do we need key management? Based
> on operational experience and fixing lots of customer deployment and
> network stability problems, I'd say that's an emphatic YES.
I'm surprised that even the question is brought up! Isn't it "of
course"?
--
Regards,
Uri
-=-=-<>-=-=-
<Disclaimer>
From owner-ipsec@lists.tislabs.com Mon May 20 05:49:06 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KCn6L23339;
Mon, 20 May 2002 05:49:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17153
Mon, 20 May 2002 08:12:11 -0400 (EDT)
Message-Id: <200205192330.TAA13625@nwmail.wh.lucent.com>
Content-Type: text/plain;
charset="iso-8859-1"
From: Uri Blumenthal <uri@bell-labs.com>
Reply-To: uri@bell-labs.com
To: Jan Vilhuber <vilhuber@cisco.com>, Michael Thomas <mat@cisco.com>
Subject: Re: SOI schizophrenia
Date: Sun, 19 May 2002 19:29:57 -0400
X-Mailer: KMail [version 1.3.2]
Cc: ipsec@lists.tislabs.com
References: <Pine.LNX.4.21.0205161337340.2302-100000@localhost>
In-Reply-To: <Pine.LNX.4.21.0205161337340.2302-100000@localhost>
Organization: Lucent Technologies / Bell Labs
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA15611
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thursday 16 May 2002 16:58, Jan Vilhuber wrote:
> > All in all, they both seem competent.
>
> They are both competent from a cryptography point of view, but only
> one actually allows key management in any sane way.
Precisely.
> I think that's
> where the two part company, and we as a group need to decide which is
> more appropriate: A key *agreement* protocol (JFK) which will require
> other protocols (ICMP? Right..) to help solve the current deployment
> stability, or a key *management* protocol (IKEv2), that let's you
> manage the key we agreed on, without requiring other external
> management protocols.
Indeed, a crucial distinction between a protocol that does the
necessary math and a protocol that [in addition to that] provides the
services required by the real world deployment.
> Of course another question might be: Do we need key management? Based
> on operational experience and fixing lots of customer deployment and
> network stability problems, I'd say that's an emphatic YES.
I'm surprised that even the question is brought up! Isn't it "of
course"?
--
Regards,
Uri
-=-=-<>-=-=-
<Disclaimer>
From owner-ipsec@lists.tislabs.com Mon May 20 05:51:58 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KCpvL23696;
Mon, 20 May 2002 05:51:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17179
Mon, 20 May 2002 08:16:12 -0400 (EDT)
Message-Id: <200205192330.TAA13625@nwmail.wh.lucent.com>
Content-Type: text/plain;
charset="iso-8859-1"
From: Uri Blumenthal <uri@bell-labs.com>
Reply-To: uri@bell-labs.com
To: Jan Vilhuber <vilhuber@cisco.com>, Michael Thomas <mat@cisco.com>
Subject: Re: SOI schizophrenia
Date: Sun, 19 May 2002 19:29:57 -0400
X-Mailer: KMail [version 1.3.2]
Cc: ipsec@lists.tislabs.com
References: <Pine.LNX.4.21.0205161337340.2302-100000@localhost>
In-Reply-To: <Pine.LNX.4.21.0205161337340.2302-100000@localhost>
Organization: Lucent Technologies / Bell Labs
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA15611
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thursday 16 May 2002 16:58, Jan Vilhuber wrote:
> > All in all, they both seem competent.
>
> They are both competent from a cryptography point of view, but only
> one actually allows key management in any sane way.
Precisely.
> I think that's
> where the two part company, and we as a group need to decide which is
> more appropriate: A key *agreement* protocol (JFK) which will require
> other protocols (ICMP? Right..) to help solve the current deployment
> stability, or a key *management* protocol (IKEv2), that let's you
> manage the key we agreed on, without requiring other external
> management protocols.
Indeed, a crucial distinction between a protocol that does the
necessary math and a protocol that [in addition to that] provides the
services required by the real world deployment.
> Of course another question might be: Do we need key management? Based
> on operational experience and fixing lots of customer deployment and
> network stability problems, I'd say that's an emphatic YES.
I'm surprised that even the question is brought up! Isn't it "of
course"?
--
Regards,
Uri
-=-=-<>-=-=-
<Disclaimer>
From owner-ipsec@lists.tislabs.com Mon May 20 12:11:58 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KJBvL07712;
Mon, 20 May 2002 12:11:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18015
Mon, 20 May 2002 14:28:22 -0400 (EDT)
Date: Mon, 20 May 2002 11:40:57 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Michael Thomas <mat@cisco.com>
cc: <ipsec@lists.tislabs.com>
Subject: Re: SOI schizophrenia
In-Reply-To: <15588.9007.583427.780174@thomasm-u1.cisco.com>
Message-ID: <Pine.LNX.4.21.0205161424390.2302-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 16 May 2002, Michael Thomas wrote:
> Jan Vilhuber writes:
> > On Wed, 15 May 2002, Michael Thomas wrote:
> >
> > >
> > > I admit it. I'm having a real hard time deciding
> > > which design philosophy is actually more
> > > appropriate for SOI. I've vacillated quite a few
> > > times and it doesn't seem like it's about to abate
> > > any time soon. What Paul's document tells me
> > > (which pretty jibes with my own judgement) is that
> > > both protocols are vast improvements over IKE, and
> > > they seem to reach quite similar conclusions on
> > > the basic message exchanges. Both put effort into
> > > DoS, and simplify the on-wire combinatorial
> > > explosion of SA establishment. All in all, they
> > > both seem competent.
> > >
> >
> > They are both competent from a cryptography point of view, but only
> > one actually allows key management in any sane way. I think that's
> > where the two part company, and we as a group need to decide which is
> > more appropriate: A key *agreement* protocol (JFK) which will require
> > other protocols (ICMP? Right..) to help solve the current deployment
> > stability, or a key *management* protocol (IKEv2), that let's you
> > manage the key we agreed on, without requiring other external
> > management protocols.
>
> I don't understand what you mean by "management"
> in this context. JFK can add and delete SA, and
> assigns lifetimes to them. It seems light on a
> DPD scheme, but that seems like a negotiable
> item. Two phases is just an optmization.
>
> What am I missing?
>
In order to delete an SA, the ESP_BYPASS and AH_BYPASS was added to
JFK (although I'd probably call this a kludge.. your mileage may
vary). Note that "When a negotiated SA expires (or shortly before it
does), the JFK protocol is run again." This holds true for deletion as
well. Meaning one rsa operation (at each end) each time. Yes, having a
phase 1 SA is in this respect an optimization, but in my opinion a
critical one. Is doing an RSA sign operation each time you want to
send a tunnel-management message OK? Not in my opinion.
Also, don't forget that you may want to negotiate multiple SA's
between two endpoints (in fact it's quite likely). Doing rsa
signatures every time (for every SA) seems unreasonable. Again, a
phase 1 SA under which to do the add's and delete's is ever so much
cheaper.
As you point out, keepalives or DPD is lacking in JFK as well
(pointing to ICMP pings is an interesting idea, but hardly worthy of a
protocol spec and interoperability; This ICMP section in JFK
constitutes the second punt of key management in the spec; Also, pings
don't scale well. DPD was developped because something like an IKE
ping won't scale).
Second, if you believe that management messages are few and well
defined, building them into your protocol from the start may be OK, I
suppose. If, on the other hand, you believe that you'll need to
address customer and deployment issues as they arise (i.e. if you
believe a protocol is a living, breathing entity that needs to adapt
to changing times and situations), you need a bit more flexibility and
extensibility (and I strongly believe in a vendor-extension mechanism,
which has proven critical in many protocols over the years to test out
new features before proposing them). JFK implicitely (or explicitely?)
slams the door on vendor-extensibility.
Again, a management channel via which I can add different management
messages as I decide I need them is a wonderful idea.
jan
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
From owner-ipsec@lists.tislabs.com Mon May 20 23:49:45 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4L6niL05726;
Mon, 20 May 2002 23:49:44 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA19172
Tue, 21 May 2002 02:07:10 -0400 (EDT)
Date: Tue, 21 May 2002 09:19:22 +0300
Message-Id: <200205210619.JAA02713@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: dharkins@tibernian.com
CC: henry@spsystems.net, ipsec@lists.tislabs.com
In-reply-to: <200205200531.g4K5VaN01164@fatty.lounge.org> (message from Dan
Harkins on Sun, 19 May 2002 22:31:36 -0700)
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <200205200531.g4K5VaN01164@fatty.lounge.org>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: Dan Harkins <dharkins@tibernian.com>
> Notification of Joe is the prudent thing to do since he is not a
> "cracker", he is a legitimate user with old/stale/incorrect
> policy. By just blackholing his packets you have relegated him to
> oblivion. You obviously have not dealt with real world use of this
> technology.
You can either black hole or notify. If gateway 192.168.10.1
has policy
10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5
any <--> any, drop
and joe (172.21.16.5) tries for 10.1.5.5, then in my world
1) IKE establishes phase I between 172.21.16.5 and 192.168.10.1
2) Using this, Joe succesfully negotiates SA's for communicating with
10.1.5.5
3) Joe's encrypted packets to 10.1.5.5 are successfully decoded at
192.168.10.1, but they fail to match the policy => gateway knows
there is policy mismatch or cracking attempt. It can either
- drop the packet (black hole), or
- pass a note to the local IKE, which could decide to send a
notification to the joe's IKE using the existing phase I.
> This is not a firewall. It's an IPsec gateway.
You can do firewall with IPSEC (as far as access control is your
need).
> > joe's SG (172.21.16.1) negotiates SA's for joe (172.21.16.5), and the
> > resulting SA has the following info
> >
> > protocol=any
> > src port=any
> > dst port=any
> > proxy=172.21.16.5
>
> Proxy? Where did that come from? I thought IKE was not permitted to provide
> any clarifying information in your view.
Proxy is better word what in IKEv2 TS is address (or ranges or
whatever). SA destination address is always the address of the other
end point (joe or 192.168.10.1). IKE seems to require the source
address for SA too, but this is not really a requirement -- on a
multihomed node, one could use same SA for all of its source
addressess).
From owner-ipsec@lists.tislabs.com Tue May 21 08:58:28 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LFwRL25698;
Tue, 21 May 2002 08:58:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20256
Tue, 21 May 2002 11:07:21 -0400 (EDT)
Message-Id: <200205211519.g4LFJfk30909@trpz.com>
To: Markku Savela <msa@burp.tkv.asdf.org>
cc: ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-Reply-To: Your message of "Tue, 21 May 2002 09:19:22 +0300."
<200205210619.JAA02713@burp.tkv.asdf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <426.1021993797.1@tibernian.com>
Date: Tue, 21 May 2002 08:09:57 -0700
From: Dan Harkins <dharkins@tibernian.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 21 May 2002 09:19:22 +0300 you wrote
>
> > Notification of Joe is the prudent thing to do since he is not a
> > "cracker", he is a legitimate user with old/stale/incorrect
> > policy. By just blackholing his packets you have relegated him to
> > oblivion. You obviously have not dealt with real world use of this
> > technology.
>
> You can either black hole or notify. If gateway 192.168.10.1
> has policy
>
> 10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5
> any <--> any, drop
>
> and joe (172.21.16.5) tries for 10.1.5.5, then in my world
>
> 1) IKE establishes phase I between 172.21.16.5 and 192.168.10.1
>
> 2) Using this, Joe succesfully negotiates SA's for communicating with
> 10.1.5.5
>
> 3) Joe's encrypted packets to 10.1.5.5 are successfully decoded at
> 192.168.10.1, but they fail to match the policy => gateway knows
> there is policy mismatch or cracking attempt. It can either
>
> - drop the packet (black hole), or
>
> - pass a note to the local IKE, which could decide to send a
> notification to the joe's IKE using the existing phase I.
But you've been arguing all along that IKE should not be doing this.
You've been saying that all it should do is obtain a shared key period
full stop.
> > > joe's SG (172.21.16.1) negotiates SA's for joe (172.21.16.5), and the
> > > resulting SA has the following info
> > >
> > > protocol=any
> > > src port=any
> > > dst port=any
> > > proxy=172.21.16.5
> >
> > Proxy? Where did that come from? I thought IKE was not permitted to provide
> > any clarifying information in your view.
>
> Proxy is better word what in IKEv2 TS is address (or ranges or
> whatever). SA destination address is always the address of the other
> end point (joe or 192.168.10.1). IKE seems to require the source
> address for SA too, but this is not really a requirement -- on a
> multihomed node, one could use same SA for all of its source
> addressess).
But, but, but.... Who cares what the term is. Where is it coming from?
You've been arguing that IKE should not be doing this.
Since you are now talking about having key management sending error messages
indicating mismatched policy and providing clarifying information for the
selector to the peer I guess you have changed your mind.
Dan.
From owner-ipsec@lists.tislabs.com Tue May 21 14:11:46 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LLBjL07861;
Tue, 21 May 2002 14:11:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20873
Tue, 21 May 2002 16:16:00 -0400 (EDT)
Content-Type: text/plain;
charset="us-ascii"
From: Geoffrey Huang <ghuang@cisco.com>
To: ipsec@lists.tislabs.com
Subject: General Comments on draft-ipsec-soi-features-00.txt
Date: Tue, 21 May 2002 13:29:54 -0700
X-Mailer: KMail [version 1.4]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200205211329.54133.ghuang@cisco.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I've read this document, and I have a few comments (more on the protocols than
the document itself). First, thanks to Paul Hoffman for summarizing the key
points of both protocols.
I don't doubt that both protocols achieve authentication and key generation,
so I'll focus on operational issues. In general, I think IKEv2 benefits from
the experience gained in implementing IKEv1 with respect to operational
requirements:
authentication by shared secret (IKEv2 has it, JFK doesn't):
I understand that this is an irksome issue, but nonetheless, my experience is
that users of IKE don't like to be limited in their options for
authentication methods. To this end, if SOI excludes shared secret as an
option for authentication, I think we'd find that we'd have a tough time
persuading users to migrate from the current IKE.
one phase-vs-two phase argument:
The document brings up a valid point when it describes IKEv2's Phase 1 as a
"control channel" for IPSec SAs. The list of management tasks is not to be
overlooked: creating, deleting, and rekeying existing IPSec SAs, sending
protected notifies, and doing DPD are all important operational tasks that
IKEv1 currently supports. Certainly, in current deployments, I've seen where
all of the above are important aspects to IKEv1 as a key management protocol.
I think we've also seen in NAT traversal where 2 phases has turned out to be
useful.
...So there's my $0.02 worth. I think in a separate thread, there was the
distinction made between key agreement and key management. This is an
important distinction.
-g
From owner-ipsec@lists.tislabs.com Tue May 21 23:48:26 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4M6mQL29379;
Tue, 21 May 2002 23:48:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA21722
Wed, 22 May 2002 02:03:59 -0400 (EDT)
Date: Wed, 22 May 2002 09:17:00 +0300
Message-Id: <200205220617.JAA03613@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: dharkins@tibernian.com
CC: ipsec@lists.tislabs.com
In-reply-to: <200205211519.g4LFJfk30909@trpz.com> (message from Dan Harkins on
Tue, 21 May 2002 08:09:57 -0700)
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <200205211519.g4LFJfk30909@trpz.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: Dan Harkins <dharkins@tibernian.com>
> But you've been arguing all along that IKE should not be doing this.
> You've been saying that all it should do is obtain a shared key period
> full stop.
I'm saying IKE should not check the policy. In my view, IKE would have
tasks
- negotiate the Phase I (if two phase model is used). I have no
comments on phase I issues.
- negotiates just SA's in Phase II, does not check the policy.
- the policy mismatch notification would just be an minor addition to
the phase I session. It does not mean IKE need to check
policy. The singal of the "mismatch" occurring would come from the
part of the IPSEC code that implements RFC-2401. How this informed,
is local issue, but if one is using PFKEY like API, this would be
just another generated message (or error report), which is sent to
all registered key managers.
> > Proxy is better word what in IKEv2 TS is address (or ranges or
> > whatever). SA destination address is always the address of the other
> > end point (joe or 192.168.10.1). IKE seems to require the source
> > address for SA too, but this is not really a requirement -- on a
> > multihomed node, one could use same SA for all of its source
> > addressess).
>
> But, but, but.... Who cares what the term is. Where is it coming from?
> You've been arguing that IKE should not be doing this.
>From phase II SA negotiations. I fully support something like the
proposed TS, but as a part of SA information, which separates multiple
SA's that have same end points.
The original IKEv1 actually had almost sufficient fields for the
"TS-like" information, except when implementations tried to
re-interpret them as policy selectors, everything went horribly
wrong... However, the new IKEv2 TS proposal fixes the "almost" part
(perhaps going a bit overboard for the purpose of SA qualifiers...)
From owner-ipsec@lists.tislabs.com Wed May 22 10:01:21 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MH1KL21539;
Wed, 22 May 2002 10:01:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22634
Wed, 22 May 2002 12:10:52 -0400 (EDT)
Message-Id: <200205221623.g4MGN8k09697@trpz.com>
To: Markku Savela <msa@burp.tkv.asdf.org>
cc: ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-Reply-To: Your message of "Wed, 22 May 2002 09:17:00 +0300."
<200205220617.JAA03613@burp.tkv.asdf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <399.1022084005.1@tibernian.com>
Date: Wed, 22 May 2002 09:13:25 -0700
From: Dan Harkins <dharkins@tibernian.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, 22 May 2002 09:17:00 +0300 you wrote
>
> The original IKEv1 actually had almost sufficient fields for the
> "TS-like" information, except when implementations tried to
> re-interpret them as policy selectors, everything went horribly
> wrong...
Horribly wrong? The only trouble that is caused seems to be some
affront to your religous sensibilities. But when everyone else is
the heretic in your eyes maybe it's time to reevaluate your dogma.
Dan.
From owner-ipsec@lists.tislabs.com Thu May 23 01:07:38 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N87bL08815;
Thu, 23 May 2002 01:07:37 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA24075
Thu, 23 May 2002 03:12:06 -0400 (EDT)
Date: Thu, 23 May 2002 10:24:51 +0300
Message-Id: <200205230724.KAA04639@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: dharkins@tibernian.com
CC: ipsec@lists.tislabs.com
In-reply-to: <200205221623.g4MGN8k09697@trpz.com> (message from Dan Harkins on
Wed, 22 May 2002 09:13:25 -0700)
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <200205221623.g4MGN8k09697@trpz.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: Dan Harkins <dharkins@tibernian.com>
> Sender: owner-ipsec@lists.tislabs.com
> Precedence: bulk
>
> On Wed, 22 May 2002 09:17:00 +0300 you wrote
> >
> > The original IKEv1 actually had almost sufficient fields for the
> > "TS-like" information, except when implementations tried to
> > re-interpret them as policy selectors, everything went horribly
> > wrong...
>
> Horribly wrong? The only trouble that is caused seems to be some
> affront to your religous sensibilities. But when everyone else is
> the heretic in your eyes maybe it's time to reevaluate your dogma.
Ok, I admit that saying "went horribly wrong" was a bit sentimental,
but pulling in term "religious" and "dogma" is not appropriate.
This is supposed to be technical discussion and I consider a
non-policy checking IKE technically a better solution to the problem.
- I believe it is a good architecture to clearly separate RFC-2401
part of IPSEC from the key management,
- and implementation claiming to do RFC-2401, does all the necessary
policy checks. IKE doing policy check is unnecessary overhead and
makes IKE dependent on the policy data base.
- IKEv1 and v2 still cause unnecessary limitations to the
possibilities that RFC-2401 allows (and removing these limitations
from IKE by making it just a key negotiation, does not make IPSEC
any more complex, as RFC-2401 compliant implementation will handle
them automaticly):
- shared SA's between bundles,
- does not need to worry if one SA of a bundle expires before some
other (it just gets re-negotiated on its own, if needed)
- asymmetric SA's
- separating policy selectors from those selector like constructs
that differentiate SA's allows independent implementations and
developement of SPD and SAD.
What I think needs to be done is
- phase 1 would be as is
- specify IKEv2 phase 2 negotiation to be just SA negotiation,
- you can optimize and have multiple SA's negotiated at same time
(e.g. you can keep most of the current message formats, just don't
put any significance to the ordering, just treat it as a collection
of SA's to be instantiated)
- basic assumption is to negotiate uni-directional SA's. Again, as
optimization, one could negotiate two-way SA's. But, for this to
work, a new payload is required: it would contain the explicit
selector information for the return traffic.
- the "TS" information only differentiates SA's (and is only remotely
related with the policy selectors)
From owner-ipsec@lists.tislabs.com Thu May 23 07:58:24 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NEwOL03034;
Thu, 23 May 2002 07:58:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24907
Thu, 23 May 2002 10:04:44 -0400 (EDT)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05111719b912a828e83b@[165.227.249.18]>
In-Reply-To: <200205230724.KAA04639@burp.tkv.asdf.org>
References: <200205221623.g4MGN8k09697@trpz.com>
<200205230724.KAA04639@burp.tkv.asdf.org>
Date: Thu, 23 May 2002 07:16:59 -0700
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Specification of tunnel/transport attribute in IKEv2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:24 AM +0300 5/23/02, Markku Savela wrote:
>This is supposed to be technical discussion and I consider a
>non-policy checking IKE technically a better solution to the problem.
Note, however, that Dan has pointed out with very clear examples why
simply moving "policy" from IKE to 2401 will lead to lack of
interoperability in implementations. It seems like your proposed new
view of 2401 will either:
- need some policy negotiation outside of IKE before packets start to flow
- need some policy announcement when bad packets are received
("you're sending me packets that I have no intention of passing to
the inside network")
- cause black holes that cannot be detected
Could you say briefly which of the above you are proposing? If it one
of the first two, which protocol are you saying would be used?
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Thu May 23 11:11:06 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIB5L10017;
Thu, 23 May 2002 11:11:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25358
Thu, 23 May 2002 13:24:04 -0400 (EDT)
From: "Theodore Ts'o" <tytso@mit.edu>
nTo: ietf-secretariat@ietf.org
cc: "Angelos D. Keromytis" <angelos@cs.columbia.edu>, ipsec@lists.tislabs.com,
byfraser@cisco.com
Subject: draft-ietf-ipsec-sctp-03.txt ready for IETF Last Call
Phone: (781) 391-3464
Message-Id: <E17AwVw-0000Qy-00@think.thunk.org>
Date: Thu, 23 May 2002 13:36:36 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
draft-ietf-ipsec-sctp-03.txt is ready for IETF Last Call for progression
to Proposed Standard. Steve, could you please put this on the IESG's
queue and make an announcement to the IETF Announce list.
Angelos, I note that we still need to get an IANA assignment for
ID-LIST. Could you start that in motion, so it's ready for the end of
IETF last call? Thanks!!
- Ted and Barbara
From owner-ipsec@lists.tislabs.com Thu May 23 11:12:50 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NICoL10051;
Thu, 23 May 2002 11:12:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25398
Thu, 23 May 2002 13:31:05 -0400 (EDT)
From: "Theodore Ts'o" <tytso@mit.edu>
To: ipsec@lists.tislabs.com, kivinen@ssh.fi
cc: byfraser@cisco.com
Subject: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt
Phone: (781) 391-3464
Message-Id: <E17Awd6-0000R2-00@think.thunk.org>
Date: Thu, 23 May 2002 13:44:00 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a working group last call for comments for the modp-groups-04
draft, for progression to Proposed Standard. This last call will expire
on June 6th.
Tero, could you please work with IANA to get assignments for the
remaining groups (other than the 1536 group 5). Thanks!!
- Ted and Barbara
From owner-ipsec@lists.tislabs.com Thu May 23 11:13:31 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIDUL10067;
Thu, 23 May 2002 11:13:30 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25423
Thu, 23 May 2002 13:36:07 -0400 (EDT)
From: "Theodore Ts'o" <tytso@mit.edu>
To: ipsec@lists.tislabs.com, sheila.frankel@nist.gov
cc: byfraser@cisco.com
Subject: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
Phone: (781) 391-3464
Message-Id: <E17AwhE-0000R4-00@think.thunk.org>
Date: Thu, 23 May 2002 13:48:16 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a working group last call for comments for the aes-xcbc-mac-01
draft, for progression to Proposed Standard. This last call will expire
on June 6th.
Sheila, could you please work with IANA to get assignments for the
AH_AES_XCBC_MAC_96 and AES-XCBC-MAC-96 for the AH and ESP transforms,
respectively. Many thanks!!
- Ted and Barbara
From owner-ipsec@lists.tislabs.com Thu May 23 11:18:35 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIIZL10202;
Thu, 23 May 2002 11:18:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25347
Thu, 23 May 2002 13:21:04 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020523103227.0341af00@mira-sjc5-4.cisco.com>
X-Sender: byfraser@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 May 2002 10:32:49 -0700
To: "William Dixon" <wdixon@windows.microsoft.com>
From: Barbara Fraser <byfraser@cisco.com>
Subject: RE: ike-modp-groups-04
Cc: <ipsec@lists.tislabs.com>, <kivinen@ssh.fi>
In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC105D015E5@win-msg-01.wingro
up.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Yes, it's ready and we'll be sending out an announcement asap.
Barb
At 04:33 PM 5/16/2002, William Dixon wrote:
>Tero, Ted, Barbara, isn't this ready for last call ? Is there anything
>we can do to get assigned numbers sooner rather than later ?
>
>-----Original Message-----
>From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca]
>Sent: Tuesday, April 30, 2002 5:10 PM
>To: ipsec@lists.tislabs.com
>Subject: ike-modp-groups-04
>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
> Is there some reason this document has not been published yet?
>
>] ON HUMILITY: to err is human. To moo, bovine. |
>firewalls [
>] Michael Richardson, Sandelman Software Works, Ottawa, ON |net
>architect[
>] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
>driver[ ] panic("Just another NetBSD/notebook using, kernel hacking,
>security guy"); [
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3ia
>Charset: latin1
>Comment: Finger me for keys
>
>iQCVAwUBPM8yXYqHRg3pndX9AQF4WwQAxrUMMyFVPHA/zJeoHJ2o7r626+LQ+UYx
>SWosLDzzA6GbwXNpeWa93Pefyh/nLt/MgpseVnBdA5CX3dwoFT4Y6B3jctikMoFt
>ZYEkrnx//eYqvJzhw0Df3yISWHYdQr1u1lAS5Z0sK+EXgyx0t+ESL9eTK/azVBfY
>zngnFDIiYIA=
>=qm44
>-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Thu May 23 11:25:07 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIP6L10445;
Thu, 23 May 2002 11:25:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25359
Thu, 23 May 2002 13:24:09 -0400 (EDT)
From: "Theodore Ts'o" <tytso@mit.edu>
To: ietf-secretariat@ietf.org
cc: "Angelos D. Keromytis" <angelos@cs.columbia.edu>, ipsec@lists.tislabs.com,
byfraser@cisco.com
Subject: draft-ietf-ipsec-sctp-03.txt ready for IETF Last Call
Phone: (781) 391-3464
Message-Id: <E17AwW9-0000R0-00@think.thunk.org>
Date: Thu, 23 May 2002 13:36:49 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
draft-ietf-ipsec-sctp-03.txt is ready for IETF Last Call for progression
to Proposed Standard. Steve, could you please put this on the IESG's
queue and make an announcement to the IETF Announce list.
Angelos, I note that we still need to get an IANA assignment for
ID-LIST. Could you start that in motion, so it's ready for the end of
IETF last call? Thanks!!
- Ted and Barbara
From owner-ipsec@lists.tislabs.com Thu May 23 12:36:12 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NJaCL12485;
Thu, 23 May 2002 12:36:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25687
Thu, 23 May 2002 14:52:38 -0400 (EDT)
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Date: Thu, 23 May 2002 12:05:18 -0700 (PDT)
From: Dong <dong_wei@tsinghua.com>
To: Security_Area_Advisory_Group <saag@mit.edu>,
IPsec <ipsec@lists.tislabs.com>
Subject: Secure QoS
Reply-To: dong_wei@tsinghua.com
X-Originating-Ip: [128.235.249.42]
Message-Id: <20020523190519.2FFB93ECC@sitemail.everyone.net>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
I am trying to do a survey on Secure QoS. Any paper on that? Thx.
Dong
_____________________________________________________________
Get Tsinghua University free email account: www.tsinghua.com
Web site sponsored and hosted by AtFreeWeb.com
_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag
From owner-ipsec@lists.tislabs.com Thu May 23 12:36:13 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NJaCL12486;
Thu, 23 May 2002 12:36:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25675
Thu, 23 May 2002 14:48:37 -0400 (EDT)
Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0E67@MAIL.NetOctave.com>
From: Mark Winstead <Mark.Winstead@NetOctave.com>
To: "'Theodore Ts'o'" <tytso@mit.edu>, ipsec@lists.tislabs.com, kivinen@ssh.fi
Cc: byfraser@cisco.com
Subject: RE: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt
Date: Thu, 23 May 2002 14:47:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C2028A.56729F10"
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_01C2028A.56729F10
Content-Type: text/plain
Since the document itself quotes sources that cite that for 256 bit keys
(like used by AES-256) require for full strength groups in the magnitude of
15400 bits, shouldn't it include a group larger than 8192 bits?
Mark Winstead
NetOctave, Inc.
> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso@mit.edu]
> Sent: Thursday, May 23, 2002 1:44 PM
> To: ipsec@lists.tislabs.com; kivinen@ssh.fi
> Cc: byfraser@cisco.com
> Subject: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt
>
>
>
> This is a working group last call for comments for the modp-groups-04
> draft, for progression to Proposed Standard. This last call
> will expire
> on June 6th.
>
> Tero, could you please work with IANA to get assignments for the
> remaining groups (other than the 1536 group 5). Thanks!!
>
> - Ted and Barbara
>
>
>
------_=_NextPart_001_01C2028A.56729F10
Content-Type: text/html
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=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt =
</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Since the document itself quotes sources that cite =
that for 256 bit keys (like used by AES-256) require for full strength =
groups in the magnitude of 15400 bits, shouldn't it include a group =
larger than 8192 bits?</FONT></P>
<P><FONT SIZE=3D2>Mark Winstead</FONT>
<BR><FONT SIZE=3D2>NetOctave, Inc.</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Theodore Ts'o [<A =
HREF=3D"mailto:tytso@mit.edu">mailto:tytso@mit.edu</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Thursday, May 23, 2002 1:44 PM</FONT>
<BR><FONT SIZE=3D2>> To: ipsec@lists.tislabs.com; =
kivinen@ssh.fi</FONT>
<BR><FONT SIZE=3D2>> Cc: byfraser@cisco.com</FONT>
<BR><FONT SIZE=3D2>> Subject: WG LAST CALL: =
draft-ietf-ipsec-ike-modp-groups-04.txt </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> This is a working group last call for comments =
for the modp-groups-04</FONT>
<BR><FONT SIZE=3D2>> draft, for progression to Proposed =
Standard. This last call </FONT>
<BR><FONT SIZE=3D2>> will expire</FONT>
<BR><FONT SIZE=3D2>> on June 6th.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Tero, could you please work with IANA to get =
assignments for the</FONT>
<BR><FONT SIZE=3D2>> remaining groups (other than the 1536 group =
5). Thanks!!</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
=
=
=
- Ted and Barbara</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C2028A.56729F10--
From owner-ipsec@lists.tislabs.com Thu May 23 12:38:40 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NJceL12546;
Thu, 23 May 2002 12:38:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25710
Thu, 23 May 2002 14:59:39 -0400 (EDT)
Date: 23 May 2002 14:59:51 -0400
Message-ID: <000b01c2028c$05da1310$bd6fe640@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: ipsec@lists.tislabs.com
Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
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: <E17AwhE-0000R4-00@think.thunk.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This draft hasn't really been discussed on the list much. I guess people
figure that "hey, it's just another crypto algorithm... there can't be
anything controversial about it".
The issue which Dave brought up at the meeting and which I sent to the
authors is that XCBC-MAC skirts the "obvious" solution of prepending the
length of the buffer to the hash input. There is an engineering tradeoff
here, which is not mentioned in the draft.
AES-XCBC-MAC:
a) requires 384 bits of keymat
b) does not require that the length of the message be pre-computed
The "obvious" solution:
a) requires 128 bits of keymat
b) requires that the length of the message be pre-computed
Clearly, issue (b) was an important motivation in the design of XCBC-MAC.
My personal opinion is that this rationale makes sense, since key storage
capacity is unlikely to be the limiting factor in the design of any future
hardware. However, the tradeoff ought to at least be discussed on the list
and acknowledged in the draft.
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o
> Sent: Thursday, May 23, 2002 1:48 PM
> To: ipsec@lists.tislabs.com; sheila.frankel@nist.gov
> Cc: byfraser@cisco.com
> Subject: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
>
>
>
> This is a working group last call for comments for the aes-xcbc-mac-01
> draft, for progression to Proposed Standard. This last call
> will expire
> on June 6th.
>
> Sheila, could you please work with IANA to get assignments for the
> AH_AES_XCBC_MAC_96 and AES-XCBC-MAC-96 for the AH and ESP transforms,
> respectively. Many thanks!!
>
> - Ted and Barbara
>
From owner-ipsec@lists.tislabs.com Thu May 23 14:30:10 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NLU9L15159;
Thu, 23 May 2002 14:30:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25989
Thu, 23 May 2002 16:50:17 -0400 (EDT)
X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to <kivinen@ssh.fi> using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15597.22768.322645.225267@ryijy.hel.fi.ssh.com>
Date: Fri, 24 May 2002 00:02:40 +0300
From: Tero Kivinen <kivinen@ssh.fi>
To: Mark Winstead <Mark.Winstead@NetOctave.com>
Cc: "'Theodore Ts'o'" <tytso@mit.edu>, ipsec@lists.tislabs.com,
byfraser@cisco.com
Subject: RE: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt
In-Reply-To: <49B96FCC784BC54F9675A6B558C3464E5D0E67@MAIL.NetOctave.com>
References: <49B96FCC784BC54F9675A6B558C3464E5D0E67@MAIL.NetOctave.com>
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 13 min
X-Total-Time: 32 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Mark Winstead writes:
> Since the document itself quotes sources that cite that for 256 bit keys
> (like used by AES-256) require for full strength groups in the magnitude of
> 15400 bits, shouldn't it include a group larger than 8192 bits?
Generating them using the current hardware resources takes too long
time. We need faster cpu's before we can generate them, but
fortunately we need also faster machines to use them too. When we have
cpu's available that can and will use them then we hopefully have also
cpu time to generate them.
We tried to calculate the 16386 bit group for couple of few weeks but
with no luck. The calculation of the 8192 bit group took 13 days on a
one machine, but for the 16386 bit group each step requires about 8
times more time, and the estimated value how far it needs to go until
it finds one also goes up by factor of 2-4 or so. This means that
calculating it on one machine would take several months or years. Also
proving it to actually being a prime would take about same time...
Calculating 12288 bit group should be possible in few months even with
one machine.
If you have 50 or so spare machines with modern cpu and nothing to do,
then we can try to generate bigger groups, I can provide the software
to run.
We can always issue new rfc when those groups are actually generated,
there is no point of waiting them now.
--
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 May 23 14:31:31 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NLVVL15196;
Thu, 23 May 2002 14:31:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26001
Thu, 23 May 2002 16:56:16 -0400 (EDT)
Message-ID: <80B684C5E29FD211AA8000A0C9CDD9190CE5A231@il0015exch005u.ih.lucent.com>
From: "Kopeikin, Roy A (Roy)" <rkopeikin@lucent.com>
To: dong_wei@tsinghua.com, Security_Area_Advisory_Group <saag@mit.edu>,
IPsec <ipsec@lists.tislabs.com>
Subject: RE: Secure QoS
Date: Thu, 23 May 2002 16:08:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dong,
Please be a little more precise in what you are asking for, i.e.
3-5 bullet list items on what kind of security you seek.
Roy
-----Original Message-----
From: Dong [mailto:dong_wei@tsinghua.com]
Sent: Thursday, May 23, 2002 2:05 PM
To: Security_Area_Advisory_Group; IPsec
Subject: Secure QoS
Hi,
I am trying to do a survey on Secure QoS. Any paper on that? Thx.
Dong
_____________________________________________________________
Get Tsinghua University free email account: www.tsinghua.com
Web site sponsored and hosted by AtFreeWeb.com
_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag
From owner-ipsec@lists.tislabs.com Thu May 23 17:24:06 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O0O6L18527;
Thu, 23 May 2002 17:24:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26319
Thu, 23 May 2002 19:33:39 -0400 (EDT)
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Date: Thu, 23 May 2002 16:46:08 -0700 (PDT)
From: Dong <dong_wei@tsinghua.com>
To: IPsec <ipsec@lists.tislabs.com>,
Security_Area_Advisory_Group <saag@mit.edu>
Reply-To: dong_wei@tsinghua.com
X-Originating-Ip: [128.235.249.42]
Message-Id: <20020523234609.3FA1B2756@sitemail.everyone.net>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Roy,
I just read a paper "Preventing Denial of Service Attacks on Quality of Service", which is written by some guys from N.C. State university and UC Davis. The service quality to legimative users could be degraded by attacks on control flow or data flow. For example, an illegal user can forge a reservation message, so he can receive an unauthorized amount of resources. I just wanna to know what threats exist in providing QoS, and what the state-of-art techniques to prevent, detect and counter those attacks, and of course recovery mothods as well.
Thx a lot.
Dong
Dong,
Please be a little more precise in what you are asking for, i.e.
3-5 bullet list items on what kind of security you seek.
Roy
-----Original Message-----
From: Dong [mailto:dong_wei@tsinghua.com]
Sent: Thursday, May 23, 2002 2:05 PM
To: Security_Area_Advisory_Group; IPsec
Subject: Secure QoS
Hi,
I am trying to do a survey on Secure QoS. Any paper on that? Thx.
Dong
_____________________________________________________________
Get Tsinghua University free email account: www.tsinghua.com
Web site sponsored and hosted by AtFreeWeb.com
_____________________________________________________________
Get Tsinghua University free email account: www.tsinghua.com
Web site sponsored and hosted by AtFreeWeb.com
_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag
From owner-ipsec@lists.tislabs.com Thu May 23 18:42:57 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O1guL20188;
Thu, 23 May 2002 18:42:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26558
Thu, 23 May 2002 20:55:51 -0400 (EDT)
MBOX-Line: From owner-ipsec@lists.tislabs.com Thu May 23 16:53:29 2002
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05111719b912a828e83b@[165.227.249.18]>
In-Reply-To: <200205230724.KAA04639@burp.tkv.asdf.org>
References: <200205221623.g4MGN8k09697@trpz.com>
<200205230724.KAA04639@burp.tkv.asdf.org>
Date: Thu, 23 May 2002 07:16:59 -0700
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Specification of tunnel/transport attribute in IKEv2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:24 AM +0300 5/23/02, Markku Savela wrote:
>This is supposed to be technical discussion and I consider a
>non-policy checking IKE technically a better solution to the problem.
Note, however, that Dan has pointed out with very clear examples why
simply moving "policy" from IKE to 2401 will lead to lack of
interoperability in implementations. It seems like your proposed new
view of 2401 will either:
- need some policy negotiation outside of IKE before packets start to flow
- need some policy announcement when bad packets are received
("you're sending me packets that I have no intention of passing to
the inside network")
- cause black holes that cannot be detected
Could you say briefly which of the above you are proposing? If it one
of the first two, which protocol are you saying would be used?
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Thu May 23 20:00:14 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O30EL21699;
Thu, 23 May 2002 20:00:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA26740
Thu, 23 May 2002 22:13:04 -0400 (EDT)
Date: Fri, 24 May 2002 05:26:01 +0300
Message-Id: <200205240226.FAA05371@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: paul.hoffman@vpnc.org
CC: ipsec@lists.tislabs.com
In-reply-to: <p05111719b912a828e83b@[165.227.249.18]> (message from Paul
Hoffman / VPNC on Thu, 23 May 2002 07:16:59 -0700)
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <200205221623.g4MGN8k09697@trpz.com>
<200205230724.KAA04639@burp.tkv.asdf.org> <p05111719b912a828e83b@[165.227.249.18]>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
> - need some policy negotiation outside of IKE before packets start
> to flow
Sort of, administrators of both sides have to agree to allow the
packets to flow. Then, both sides modify their policies accordingly. I
don't see any need for "policy negotiation protocol" between end
hosts.
I do see that sometimes a general IPSEC policy exchange format
might be a useful thing. A policy described in this notation could be
transferred to the users via different methods (email, http, etc).
> - need some policy announcement when bad packets are received
> ("you're sending me packets that I have no intention of passing to
> the inside network")
Not policy announcement. Just optional notification from one IKE to
another. This would alert the sender that there is "black hole".
1) Sends encodes the packet with SA(s)
2) Receiver successfully decodes the packet with SA(s)
3) Receiver checks that the uncovered plain packet matches the policy
(as described in RFC-2401).
4) If packet does not match the policy, then there is a policy
mismatch and a potential black hole (or cracking attempt). A
notification can be sent to all key management servers. This notice
could contain selector data from the packet and SA(s). IKE (or any
other key manager) receive this message and from it can deduce
whether the problem SA's are negotiated by it. If so, it can use
the phase 1 session to pass the appropriate information to the
other end.
5) Upon receiving the notification, the sender knows that it's packets
are not accepted. Solving the problem requires human
intervention.
IKE can do above without any knowledge about the actual policy.
This way even handles the black holes, that current IKE does not
detect: sender sends packets using wrong SA (like, negotiate SA for
telnet traffic, but use FTP over it).
From owner-ipsec@lists.tislabs.com Thu May 23 23:11:04 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O6B4L28306;
Thu, 23 May 2002 23:11:04 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA27129
Fri, 24 May 2002 01:12:13 -0400 (EDT)
Message-Id: <3.0.3.32.20020523222844.0139a9d8@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Thu, 23 May 2002 22:28:44 -0700
To: Stephen Kent <kent@bbn.com>
From: Alex Alten <Alten@attbi.com>
Subject: Re: addresses and IKEv2
Cc: ipsec@lists.tislabs.com
In-Reply-To: <p05100303b90ea5049163@[128.89.88.34]>
References: <3.0.3.32.20020517163806.013cc950@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517163806.013cc950@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 09:07 AM 5/20/2002 -0400, Stephen Kent wrote:
>At 4:38 PM -0700 5/17/02, Alex Alten wrote:
>>
>> >Alex,
>>>
>>>I assume you have read the new ESP ID from last fall, as well as the
>>>new AH ID from this spring, and have followed the WG discussions of
>>>why the SA can be determined by examining just the SPI 9without
>>>referebce to the destination address), for unicast traffic. Given
>>>that context, I'm not sure I understand your comments above. Could
>>>you clarify?
>>>
>>>Thanks,
>>>
>>>Steve
>>>
>>
>>Steve,
>>
>>My comments only apply to the RFCs as they stand today. SPI is a
>>different beast than what I'm discussing even with your latest ESP
>>ID adjustments.
>>
>>The fundamental problem is how can we identify a host unambigously in
>>real time in order to be able to automate the picking of the correct
>>crypto key used to authenticate it and then bootstrap the SA? I don't
>>see the answer anywhere in the RFCs or IDs. Certainly there are a lot
>>of documents and maybe I've missed seeing it. I know that X.509 certs
>>are not the answer (the bound name/address is too static and can be
>>unreliable).
>>
>>- Alex
>
>if the concern is, as you state above, the initial binding of host ID
>to a credential, then an X.509 cert with a name seems to address the
>problem, irrespective of a static address binding. IKE provides for
>exchange of certs that contains names, e.g., DNS names or DNs, and if
>one uses SPD entries with these symbolic names for IP address
>selectors, the mapping to current addresses will happen dynamically.
>
>Steve
>
Steve,
On the surface using a global name space like DNS seems like a good
idea. But the fundamental problem is that a DNS name maps to an IP
address which is already a slippery beast. Also not every IP address
has a corresponding DNS name. And a DNS name can map to multiple IP
addresses. So the certificate binding of a DNS name to a Public Key is
not a practical approach. A X.500 DN is even worse, except for LDAP
trees, it is hardly used.
A much better approach is to have a large, global numerical address space.
Each host then is assigned a unique security address from this space. IP
addresses can flit in and out of existence for a host, but it's security
address remains fixed, a least for the duration between enrollment and
revocation in an "IPsec global system". If one can reliably assign a
unique number to each host, then it can be used to look up the authentication
key in a secure database to verify that indeed a particular host is assigned
that number. Once you can rely on this number, effectively a global host id,
it is much more practical to automate the setting up of a VPN between two
hosts, even in the context of Mobile IP or through a NAT or even between two
different organizations.
It seems to me that until the issue of how to effectively identify hosts and
manage the resulting address space is agreed upon all the IKEs and JFKs
will be failures. Or at best they will only be a way to automate the key
suite
negotiation between two hosts (or VPN gateways), thus providing just a modest
advantage over the manual keying that dominates IPsec VPN setup today.
- Alex
--
Alex Alten
Alten@ATTBI.com
From owner-ipsec@lists.tislabs.com Fri May 24 00:50:59 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O7oxL17765;
Fri, 24 May 2002 00:50:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA27318
Fri, 24 May 2002 02:59:22 -0400 (EDT)
Date: Fri, 24 May 2002 00:11:10 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Markku Savela <msa@burp.tkv.asdf.org>
cc: <paul.hoffman@vpnc.org>, <ipsec@lists.tislabs.com>
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-Reply-To: <200205240226.FAA05371@burp.tkv.asdf.org>
Message-ID: <Pine.LNX.4.33.0205240009570.22844-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Sure sounds like an administrative nightmare (as well as wasted
bandwidth) to me, when we could simply do it via negotiation in an
automated fashion.
jan
On Fri, 24 May 2002, Markku Savela wrote:
> > From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
>
> > - need some policy negotiation outside of IKE before packets start
> > to flow
>
> Sort of, administrators of both sides have to agree to allow the
> packets to flow. Then, both sides modify their policies accordingly. I
> don't see any need for "policy negotiation protocol" between end
> hosts.
>
> I do see that sometimes a general IPSEC policy exchange format
> might be a useful thing. A policy described in this notation could be
> transferred to the users via different methods (email, http, etc).
>
> > - need some policy announcement when bad packets are received
> > ("you're sending me packets that I have no intention of passing to
> > the inside network")
>
> Not policy announcement. Just optional notification from one IKE to
> another. This would alert the sender that there is "black hole".
>
> 1) Sends encodes the packet with SA(s)
>
> 2) Receiver successfully decodes the packet with SA(s)
>
> 3) Receiver checks that the uncovered plain packet matches the policy
> (as described in RFC-2401).
>
> 4) If packet does not match the policy, then there is a policy
> mismatch and a potential black hole (or cracking attempt). A
> notification can be sent to all key management servers. This notice
> could contain selector data from the packet and SA(s). IKE (or any
> other key manager) receive this message and from it can deduce
> whether the problem SA's are negotiated by it. If so, it can use
> the phase 1 session to pass the appropriate information to the
> other end.
>
> 5) Upon receiving the notification, the sender knows that it's packets
> are not accepted. Solving the problem requires human
> intervention.
>
> IKE can do above without any knowledge about the actual policy.
>
> This way even handles the black holes, that current IKE does not
> detect: sender sends packets using wrong SA (like, negotiate SA for
> telnet traffic, but use FTP over it).
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
http://www.eff.org/cafe
From owner-ipsec@lists.tislabs.com Fri May 24 06:30:56 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ODUtL10940;
Fri, 24 May 2002 06:30:55 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27938
Fri, 24 May 2002 08:42:51 -0400 (EDT)
Message-ID: <3CED779D.50203@netscape.net>
Date: Thu, 23 May 2002 23:13:33 +0000
From: Marc Solsona <markusduc@netscape.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0rc2) Gecko/20020513 Netscape/7.0b1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Markku Savela <msa@burp.tkv.asdf.org>
CC: paul.hoffman@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <200205221623.g4MGN8k09697@trpz.com> <200205230724.KAA04639@burp.tkv.asdf.org> <p05111719b912a828e83b@[165.227.249.18]> <200205240226.FAA05371@burp.tkv.asdf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailer: Unknown (No Version)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It wouldn't hurt to thing in terms of large scale deployments. Try to be
in the shoes of the administrator that is taking care of a mid size ISP.
The scenario could look like several VPNs per customer, hundreds of
customers (hopefully), probably each customer using an independent box.
I don't mean that what it is being discussed is wrong, but I would like
to bring this up.
If the complexity is in the protocol, vendors try to make it easier in
their implementations. Some get it right some don't.
My 2c.
marc.
Markku Savela wrote:
>>From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
>>
>>
>
>
>
>>- need some policy negotiation outside of IKE before packets start
>>to flow
>>
>>
>
>Sort of, administrators of both sides have to agree to allow the
>packets to flow. Then, both sides modify their policies accordingly. I
>don't see any need for "policy negotiation protocol" between end
>hosts.
>
>I do see that sometimes a general IPSEC policy exchange format
>might be a useful thing. A policy described in this notation could be
>transferred to the users via different methods (email, http, etc).
>
>
>
>>- need some policy announcement when bad packets are received
>>("you're sending me packets that I have no intention of passing to
>>the inside network")
>>
>>
>
>Not policy announcement. Just optional notification from one IKE to
>another. This would alert the sender that there is "black hole".
>
>1) Sends encodes the packet with SA(s)
>
>2) Receiver successfully decodes the packet with SA(s)
>
>3) Receiver checks that the uncovered plain packet matches the policy
> (as described in RFC-2401).
>
>4) If packet does not match the policy, then there is a policy
> mismatch and a potential black hole (or cracking attempt). A
> notification can be sent to all key management servers. This notice
> could contain selector data from the packet and SA(s). IKE (or any
> other key manager) receive this message and from it can deduce
> whether the problem SA's are negotiated by it. If so, it can use
> the phase 1 session to pass the appropriate information to the
> other end.
>
>5) Upon receiving the notification, the sender knows that it's packets
> are not accepted. Solving the problem requires human
> intervention.
>
>IKE can do above without any knowledge about the actual policy.
>
>This way even handles the black holes, that current IKE does not
>detect: sender sends packets using wrong SA (like, negotiate SA for
>telnet traffic, but use FTP over it).
>
>
>
--
Your favorite stores, helpful shopping tools and great gift ideas.
Experience the convenience of buying online with Shop@Netscape!
http://shopnow.netscape.com/
From owner-ipsec@lists.tislabs.com Fri May 24 06:30:56 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ODUuL10942;
Fri, 24 May 2002 06:30:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27939
Fri, 24 May 2002 08:42:50 -0400 (EDT)
Message-ID: <3CED86D4.116A78F4@cs.ucdavis.edu>
Date: Thu, 23 May 2002 17:18:28 -0700
From: "S. Felix Wu" <wu@cs.ucdavis.edu>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: dong_wei@tsinghua.com
CC: IPsec <ipsec@lists.tislabs.com>,
Security_Area_Advisory_Group <saag@mit.edu>
Subject: Re:
References: <20020523234609.3FA1B2756@sitemail.everyone.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I am a co-author of the paper you mentioned. I feel that the subject
of Secure QoS (or QoS security) is not very related to the core
interest of the IPsec working group. (maybe more related to DiffServ.)
In the ArQos project (http://arqos.csc.ncsu.edu), we are concerning
attackers stealing the bandwidth, one way or the other (i.e, via
control plane or data plane). Publications can be found there.
However, DoS concern for IKE (or IKEv2 and JFK) might be relevent
for this working group as many messages have been posted here lately.
-Felix
Dong wrote:
>
> Roy,
>
> I just read a paper "Preventing Denial of Service Attacks on Quality of Service", which is written by some guys from N.C. State university and UC Davis. The service quality to legimative users could be degraded by attacks on control flow or data flow. For example, an illegal user can forge a reservation message, so he can receive an unauthorized amount of resources. I just wanna to know what threats exist in providing QoS, and what the state-of-art techniques to prevent, detect and counter those attacks, and of course recovery mothods as well.
>
> Thx a lot.
>
> Dong
>
> Dong,
> Please be a little more precise in what you are asking for, i.e.
>
> 3-5 bullet list items on what kind of security you seek.
>
> Roy
>
> -----Original Message-----
> From: Dong [mailto:dong_wei@tsinghua.com]
> Sent: Thursday, May 23, 2002 2:05 PM
> To: Security_Area_Advisory_Group; IPsec
> Subject: Secure QoS
>
> Hi,
>
> I am trying to do a survey on Secure QoS. Any paper on that? Thx.
>
> Dong
>
> _____________________________________________________________
> Get Tsinghua University free email account: www.tsinghua.com
> Web site sponsored and hosted by AtFreeWeb.com
>
> _____________________________________________________________
> Get Tsinghua University free email account: www.tsinghua.com
> Web site sponsored and hosted by AtFreeWeb.com
>
> _____________________________________________________________
> Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag
--
----------------------------------------------------------------------
Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu
Associate Professor http://www.cs.ucdavis.edu/~wu
Computer Science Department office: 1-530-754-7070
University of California at Davis fax: 1-530-752-4767
----------------------------------------------------------------------
From owner-ipsec@lists.tislabs.com Fri May 24 07:59:09 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OEx9L16386;
Fri, 24 May 2002 07:59:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28175
Fri, 24 May 2002 10:15:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05100303b913fc24c5a8@[128.89.88.34]>
In-Reply-To: <3.0.3.32.20020523222844.0139a9d8@mail>
References: <3.0.3.32.20020517163806.013cc950@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517163806.013cc950@mail>
<3.0.3.32.20020523222844.0139a9d8@mail>
Date: Fri, 24 May 2002 10:24:46 -0400
To: Alex Alten <Alten@attbi.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: addresses and IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Alex,
>Steve,
>
>On the surface using a global name space like DNS seems like a good
>idea. But the fundamental problem is that a DNS name maps to an IP
>address which is already a slippery beast. Also not every IP address
>has a corresponding DNS name. And a DNS name can map to multiple IP
>addresses. So the certificate binding of a DNS name to a Public Key is
>not a practical approach. A X.500 DN is even worse, except for LDAP
>trees, it is hardly used.
In IKE, the mapping between any symbolic name and an IP address is
dynamic, so when this sort of symbolic name use is appropriate for
locally administered access control (via the SPD), the problems your
cite here do not seem to arise.
>A much better approach is to have a large, global numerical address space.
>Each host then is assigned a unique security address from this space. IP
>addresses can flit in and out of existence for a host, but it's security
>address remains fixed, a least for the duration between enrollment and
>revocation in an "IPsec global system". If one can reliably assign a
>unique number to each host, then it can be used to look up the authentication
>key in a secure database to verify that indeed a particular host is assigned
>that number. Once you can rely on this number, effectively a global host id,
>it is much more practical to automate the setting up of a VPN between two
>hosts, even in the context of Mobile IP or through a NAT or even between two
>different organizations.
I disagree. Experience has shown that access control systems are very
much prone to human error when new forms of ID are introduced that
are not readily understood by the people managing these systems. We
are comfortable with DNS names, so DNS names are appropriate here.
DNs are more descriptive in some contexts, and some people are
comfortable with them, so they are appropriate in some contexts as
well. A new set of globally unique, numerical IDs will be alien to
everyone and will require mapping to some form of name that people do
relate to, and the creation of that mapping will introduce errors.
>It seems to me that until the issue of how to effectively identify hosts and
>manage the resulting address space is agreed upon all the IKEs and JFKs
>will be failures. Or at best they will only be a way to automate the key
>suite
>negotiation between two hosts (or VPN gateways), thus providing just a modest
>advantage over the manual keying that dominates IPsec VPN setup today.
I don't see your point. End users and system administrators already
make use of the DNS to identify the vast majority of hosts, because
this is the way that we refer to these hosts in our applications.
Thus it makes sense to retain that way of identifying hosts in access
control systems, to minimize confusion.
Steve
From owner-ipsec@lists.tislabs.com Fri May 24 08:00:55 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OF0tL16530;
Fri, 24 May 2002 08:00:55 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28223
Fri, 24 May 2002 10:24:38 -0400 (EDT)
Message-ID: <20020524143641.97990.qmail@web21302.mail.yahoo.com>
Date: Fri, 24 May 2002 07:36:41 -0700 (PDT)
From: SatishK Amara <kumar_amara@yahoo.com>
Subject: Re:
To: dong_wei@tsinghua.com, IPsec <ipsec@lists.tislabs.com>,
Security_Area_Advisory_Group <saag@mit.edu>
In-Reply-To: <20020523234609.3FA1B2756@sitemail.everyone.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Why don't you use IPSEC to secure RSVP.
Satish Amara
--- Dong <dong_wei@tsinghua.com> wrote:
> Roy,
>
> I just read a paper "Preventing Denial of Service
> Attacks on Quality of Service", which is written by
> some guys from N.C. State university and UC Davis.
> The service quality to legimative users could be
> degraded by attacks on control flow or data flow.
> For example, an illegal user can forge a reservation
> message, so he can receive an unauthorized amount of
> resources. I just wanna to know what threats exist
> in providing QoS, and what the state-of-art
> techniques to prevent, detect and counter those
> attacks, and of course recovery mothods as well.
>
> Thx a lot.
>
> Dong
>
>
> Dong,
> Please be a little more precise in what you are
> asking for, i.e.
>
> 3-5 bullet list items on what kind of security you
> seek.
>
> Roy
>
> -----Original Message-----
> From: Dong [mailto:dong_wei@tsinghua.com]
> Sent: Thursday, May 23, 2002 2:05 PM
> To: Security_Area_Advisory_Group; IPsec
> Subject: Secure QoS
>
>
> Hi,
>
> I am trying to do a survey on Secure QoS. Any paper
> on that? Thx.
>
> Dong
>
>
_____________________________________________________________
> Get Tsinghua University free email account:
> www.tsinghua.com
> Web site sponsored and hosted by AtFreeWeb.com
>
>
>
>
_____________________________________________________________
> Get Tsinghua University free email account:
> www.tsinghua.com
> Web site sponsored and hosted by AtFreeWeb.com
>
>
_____________________________________________________________
> Promote your group and strengthen ties to your
> members with email@yourgroup.org by Everyone.net
http://www.everyone.net/?btn=tag
=====
In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
From owner-ipsec@lists.tislabs.com Fri May 24 09:05:05 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OG54L19293;
Fri, 24 May 2002 09:05:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28386
Fri, 24 May 2002 11:19:54 -0400 (EDT)
Date: Fri, 24 May 2002 18:32:00 +0300
Message-Id: <200205241532.SAA06102@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: vilhuber@cisco.com
CC: paul.hoffman@vpnc.org, ipsec@lists.tislabs.com
In-reply-to: <Pine.LNX.4.33.0205240009570.22844-100000@janpc-home.cisco.com>
(message from Jan Vilhuber on Fri, 24 May 2002 00:11:10 -0700 (PDT))
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <Pine.LNX.4.33.0205240009570.22844-100000@janpc-home.cisco.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: Jan Vilhuber <vilhuber@cisco.com>
>
> Sure sounds like an administrative nightmare (as well as wasted
> bandwidth) to me, when we could simply do it via negotiation in an
> automated fashion.
I assume you must be referring to the policy maintenance, because
there is nothing "administrative" in my proposed "policy mismatch
notification".
As to policy, you *cannot* negotiate it automaticly. What use is a policy
which can be automaticly modified by at will?
If I have a policy
- allow HTTP traffic to my WEB server using IPSEC
- drop other
Surely you don't want anyone "negotiating" this into
- allow HTTP traffic to my WEB server using IPSEC
- allow ANY with NUL ESP
- drop other
So, I assume when you are talking about "negotiating policy", it is
something which I don't consider as a part of policy? As I have said
earlier, I have no problem allowing choices in SA algorithm. If
desired, the policy just lists the allowed alternatives and IKE can
pick one which is common. (If you are using PFKEY, then just look at
ACQUIRE message: it has list of alternatives).
.
From owner-ipsec@lists.tislabs.com Fri May 24 09:59:27 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OGxRL21546;
Fri, 24 May 2002 09:59:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28474
Fri, 24 May 2002 12:19:13 -0400 (EDT)
Date: Fri, 24 May 2002 09:30:45 -0700 (PDT)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Markku Savela <msa@burp.tkv.asdf.org>
cc: <paul.hoffman@vpnc.org>, <ipsec@lists.tislabs.com>
Subject: Re: Specification of tunnel/transport attribute in IKEv2
In-Reply-To: <200205241532.SAA06102@burp.tkv.asdf.org>
Message-ID: <Pine.LNX.4.33.0205240929340.24507-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 Fri, 24 May 2002, Markku Savela wrote:
> > From: Jan Vilhuber <vilhuber@cisco.com>
> >
> > Sure sounds like an administrative nightmare (as well as wasted
> > bandwidth) to me, when we could simply do it via negotiation in an
> > automated fashion.
>
> I assume you must be referring to the policy maintenance, because
> there is nothing "administrative" in my proposed "policy mismatch
> notification".
>
> As to policy, you *cannot* negotiate it automaticly.
Maybe, but in the interest of maintaining a properly functioning
network and being able to troubleshoot it (and interoperate between
vendors), this negotiation is somewhat important (critical in my
mind).
Yea... we COULD configure everything manually. Good luck.
jan
> What use is a policy
> which can be automaticly modified by at will?
>
> If I have a policy
>
> - allow HTTP traffic to my WEB server using IPSEC
> - drop other
>
> Surely you don't want anyone "negotiating" this into
>
> - allow HTTP traffic to my WEB server using IPSEC
> - allow ANY with NUL ESP
> - drop other
>
> So, I assume when you are talking about "negotiating policy", it is
> something which I don't consider as a part of policy? As I have said
> earlier, I have no problem allowing choices in SA algorithm. If
> desired, the policy just lists the allowed alternatives and IKE can
> pick one which is common. (If you are using PFKEY, then just look at
> ACQUIRE message: it has list of alternatives).
>
>
>
> .
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
http://www.eff.org/cafe
From owner-ipsec@lists.tislabs.com Fri May 24 12:19:11 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OJJAL24538;
Fri, 24 May 2002 12:19:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28687
Fri, 24 May 2002 14:35:30 -0400 (EDT)
Reply-To: <jrodriguez@intellinet-tech.com>
From: "Jeremy Rodriguez" <jrodriguez@intellinet-tech.com>
To: <ipsec@lists.tislabs.com>
Subject: remove jrodriguez@intellinet-tech.com
Date: Fri, 24 May 2002 14:49:43 -0400
Message-ID: <HMEIJMEKLHGNJPCDCEBOEECDDBAA.jrodriguez@intellinet-tech.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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <Pine.LNX.4.33.0205240929340.24507-100000@janpc-home.cisco.com>
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 Jan Vilhuber
Sent: Friday, May 24, 2002 12:31 PM
To: Markku Savela
Cc: paul.hoffman@vpnc.org; ipsec@lists.tislabs.com
Subject: Re: Specification of tunnel/transport attribute in IKEv2
On Fri, 24 May 2002, Markku Savela wrote:
> > From: Jan Vilhuber <vilhuber@cisco.com>
> >
> > Sure sounds like an administrative nightmare (as well as wasted
> > bandwidth) to me, when we could simply do it via negotiation in an
> > automated fashion.
>
> I assume you must be referring to the policy maintenance, because
> there is nothing "administrative" in my proposed "policy mismatch
> notification".
>
> As to policy, you *cannot* negotiate it automaticly.
Maybe, but in the interest of maintaining a properly functioning
network and being able to troubleshoot it (and interoperate between
vendors), this negotiation is somewhat important (critical in my
mind).
Yea... we COULD configure everything manually. Good luck.
jan
> What use is a policy
> which can be automaticly modified by at will?
>
> If I have a policy
>
> - allow HTTP traffic to my WEB server using IPSEC
> - drop other
>
> Surely you don't want anyone "negotiating" this into
>
> - allow HTTP traffic to my WEB server using IPSEC
> - allow ANY with NUL ESP
> - drop other
>
> So, I assume when you are talking about "negotiating policy", it is
> something which I don't consider as a part of policy? As I have said
> earlier, I have no problem allowing choices in SA algorithm. If
> desired, the policy just lists the allowed alternatives and IKE can
> pick one which is common. (If you are using PFKEY, then just look at
> ACQUIRE message: it has list of alternatives).
>
>
>
> .
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
http://www.eff.org/cafe
From owner-ipsec@lists.tislabs.com Fri May 24 16:00:43 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ON0hL28585;
Fri, 24 May 2002 16:00:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29001
Fri, 24 May 2002 18:17:21 -0400 (EDT)
From: "Hilarie Orman, Purple Streak Development" <hilarie@xmission.com>
To: ipsec@lists.tislabs.com
In-reply-to: Yourmessage <15597.22768.322645.225267@ryijy.hel.fi.ssh.com>
Subject: RE: WG LAST CALL: draft-ietf-ipsec-ike-modp-groups-04.txt
Message-Id: <E17BNZT-0004Kb-00@xmission.xmission.com>
Date: Fri, 24 May 2002 16:30:03 -0600
X-Spam-Status: No, hits=-4.4 required=8.0 tests=IN_REP_TO version=2.20
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I can't see any reason to use groups for which the discrete log
problem is harder than 128 bits. Even that is a stretch and you'd
have to go to some trouble to justify it. This blind matching of
keysizes is ridiculous. Key length should not be equated with
security requirement.
Hilarie
From owner-ipsec@lists.tislabs.com Fri May 24 17:10:22 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4P0ALL00307;
Fri, 24 May 2002 17:10:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29062
Fri, 24 May 2002 19:28:31 -0400 (EDT)
Message-Id: <3.0.3.32.20020524164356.01289ba0@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Fri, 24 May 2002 16:43:56 -0700
To: Stephen Kent <kent@bbn.com>
From: Alex Alten <Alten@attbi.com>
Subject: Re: addresses and IKEv2
Cc: ipsec@lists.tislabs.com
In-Reply-To: <p05100303b913fc24c5a8@[128.89.88.34]>
References: <3.0.3.32.20020523222844.0139a9d8@mail>
<3.0.3.32.20020517163806.013cc950@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517163806.013cc950@mail>
<3.0.3.32.20020523222844.0139a9d8@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Steve,
I'm not talking about a host's local database. We need a way to uniquely
AND SECURELY identify any host worldwide from any other host. You don't
want to replicate this information to every host, you'd have over 100 million
entries to distribute to each one!
I like DNS too, a nice simple hierarchy, it is easy to uniquely name hosts,
and a simple distributed model for managing the address space. But it has a
crippling drawback from a security perspective. A DNS name cannot be any
better
at identifying a host than it's resolved IP address. And we know how
ephemeral IP addresses can be given the rise of DHCP and NAT. The only
secure way to absolutely identify a host is to assign it a (randomly) unique
crypto key. But before you can pull the correct key (RSA or AES) you need to
find it. For this you need a unique number that doesn't keep being changed
underneath you. So unfortunately DNS doesn't make the cut. No amount of
wishful
thinking is going to make it work properly for us.
To reiterate my position: IPsec needs to have a global, secure address space
that uniquely identifies every participating host. It needs to be simple to
understand, distributable, and easy to manage. And it needs to be able to
dynamically map into the IP address space on demand, including private
network non-routable addresses.
That's the requirements as I see them. Anything less than this means
you can't use IPsec unencumbered across the Internet.
- Alex
At 10:24 AM 5/24/2002 -0400, Stephen Kent wrote:
>Alex,
>
>>Steve,
>>
>>On the surface using a global name space like DNS seems like a good
>>idea. But the fundamental problem is that a DNS name maps to an IP
>>address which is already a slippery beast. Also not every IP address
>>has a corresponding DNS name. And a DNS name can map to multiple IP
>>addresses. So the certificate binding of a DNS name to a Public Key is
>>not a practical approach. A X.500 DN is even worse, except for LDAP
>>trees, it is hardly used.
>
>In IKE, the mapping between any symbolic name and an IP address is
>dynamic, so when this sort of symbolic name use is appropriate for
>locally administered access control (via the SPD), the problems your
>cite here do not seem to arise.
>
>>A much better approach is to have a large, global numerical address space.
>>Each host then is assigned a unique security address from this space. IP
>>addresses can flit in and out of existence for a host, but it's security
>>address remains fixed, a least for the duration between enrollment and
>>revocation in an "IPsec global system". If one can reliably assign a
>>unique number to each host, then it can be used to look up the
authentication
>>key in a secure database to verify that indeed a particular host is assigned
>>that number. Once you can rely on this number, effectively a global host
id,
>>it is much more practical to automate the setting up of a VPN between two
>>hosts, even in the context of Mobile IP or through a NAT or even between two
>>different organizations.
>
>I disagree. Experience has shown that access control systems are very
>much prone to human error when new forms of ID are introduced that
>are not readily understood by the people managing these systems. We
>are comfortable with DNS names, so DNS names are appropriate here.
>DNs are more descriptive in some contexts, and some people are
>comfortable with them, so they are appropriate in some contexts as
>well. A new set of globally unique, numerical IDs will be alien to
>everyone and will require mapping to some form of name that people do
>relate to, and the creation of that mapping will introduce errors.
>
>>It seems to me that until the issue of how to effectively identify hosts and
>>manage the resulting address space is agreed upon all the IKEs and JFKs
>>will be failures. Or at best they will only be a way to automate the key
>>suite
>>negotiation between two hosts (or VPN gateways), thus providing just a
modest
>>advantage over the manual keying that dominates IPsec VPN setup today.
>
>I don't see your point. End users and system administrators already
>make use of the DNS to identify the vast majority of hosts, because
>this is the way that we refer to these hosts in our applications.
>Thus it makes sense to retain that way of identifying hosts in access
>control systems, to minimize confusion.
>
>Steve
>
--
Alex Alten
Alten@ATTBI.com
From owner-ipsec@lists.tislabs.com Fri May 24 20:27:00 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4P3R0L03719;
Fri, 24 May 2002 20:27:00 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29326
Fri, 24 May 2002 22:41:43 -0400 (EDT)
Date: Sat, 25 May 2002 05:54:06 +0300
Message-Id: <200205250254.FAA06547@burp.tkv.asdf.org>
From: Markku Savela <msa@burp.tkv.asdf.org>
To: vilhuber@cisco.com
CC: paul.hoffman@vpnc.org, ipsec@lists.tislabs.com
In-reply-to: <Pine.LNX.4.33.0205240929340.24507-100000@janpc-home.cisco.com>
(message from Jan Vilhuber on Fri, 24 May 2002 09:30:45 -0700 (PDT))
Subject: Re: Specification of tunnel/transport attribute in IKEv2
References: <Pine.LNX.4.33.0205240929340.24507-100000@janpc-home.cisco.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> From: Jan Vilhuber <vilhuber@cisco.com>
> Maybe, but in the interest of maintaining a properly functioning
> network and being able to troubleshoot it (and interoperate between
> vendors), this negotiation is somewhat important (critical in my
> mind).
>
> Yea... we COULD configure everything manually. Good luck.
Well, we all need good luck in that case. There is no policy
negotiation in the current IKE either.
Note however, that my proposal is:
- in phase II, only SA's are negotiated, without policy checks
I have no objections, if IKE or something installs or removes
additional policy lines in PHASE 1, after the user has been
authenticated. Thus, a policy could initially be
- drop all
and there would some local database of users that can establish VPN or
some other access, for example
joe -> setup VPN
bob -> allow HTTP with ESP
alice -> setup VPN
so when joe connects from 172.2.1.1 and authenticates itself as joe,
then IKE or something could add a policy line and result would be
remote 172.2.1.1 -> protect via 172.2.1.11
drop all
Similarly, if bob connects from 172.2.1.2, the policy is again augmented
remote 172.2.1.1 -> protect via 172.2.1.1
remote 172.2.1.2 local-port 80 -> use ESP
drop all
Note, the policies must still be locally configured. It is a security
breach, if other end can define the policy lines.
From owner-ipsec@lists.tislabs.com Fri May 24 20:31:06 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4P3V6L03792;
Fri, 24 May 2002 20:31:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29356
Fri, 24 May 2002 22:50:42 -0400 (EDT)
To: SatishK Amara <kumar_amara@yahoo.com>
Cc: dong_wei@tsinghua.com, IPsec <ipsec@lists.tislabs.com>,
Security_Area_Advisory_Group <saag@mit.edu>
Subject: Re:
References: <20020524143641.97990.qmail@web21302.mail.yahoo.com>
From: Derek Atkins <warlord@mit.edu>
Date: 24 May 2002 23:00:52 -0400
In-Reply-To: <20020524143641.97990.qmail@web21302.mail.yahoo.com>
Message-ID: <sjmd6vlhqxn.fsf@kikki.mit.edu>
Lines: 86
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Because IPsec is hop-by-hop but you want RSVP end-to-end.
-derek
SatishK Amara <kumar_amara@yahoo.com> writes:
> Why don't you use IPSEC to secure RSVP.
>
> Satish Amara
> --- Dong <dong_wei@tsinghua.com> wrote:
> > Roy,
> >
> > I just read a paper "Preventing Denial of Service
> > Attacks on Quality of Service", which is written by
> > some guys from N.C. State university and UC Davis.
> > The service quality to legimative users could be
> > degraded by attacks on control flow or data flow.
> > For example, an illegal user can forge a reservation
> > message, so he can receive an unauthorized amount of
> > resources. I just wanna to know what threats exist
> > in providing QoS, and what the state-of-art
> > techniques to prevent, detect and counter those
> > attacks, and of course recovery mothods as well.
> >
> > Thx a lot.
> >
> > Dong
> >
> >
> > Dong,
> > Please be a little more precise in what you are
> > asking for, i.e.
> >
> > 3-5 bullet list items on what kind of security you
> > seek.
> >
> > Roy
> >
> > -----Original Message-----
> > From: Dong [mailto:dong_wei@tsinghua.com]
> > Sent: Thursday, May 23, 2002 2:05 PM
> > To: Security_Area_Advisory_Group; IPsec
> > Subject: Secure QoS
> >
> >
> > Hi,
> >
> > I am trying to do a survey on Secure QoS. Any paper
> > on that? Thx.
> >
> > Dong
> >
> >
> _____________________________________________________________
> > Get Tsinghua University free email account:
> > www.tsinghua.com
> > Web site sponsored and hosted by AtFreeWeb.com
> >
> >
> >
> >
> _____________________________________________________________
> > Get Tsinghua University free email account:
> > www.tsinghua.com
> > Web site sponsored and hosted by AtFreeWeb.com
> >
> >
> _____________________________________________________________
> > Promote your group and strengthen ties to your
> > members with email@yourgroup.org by Everyone.net
> http://www.everyone.net/?btn=tag
>
>
> =====
> In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.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 Sat May 25 08:51:07 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4PFp7L27249;
Sat, 25 May 2002 08:51:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00615
Sat, 25 May 2002 11:00:50 -0400 (EDT)
Message-Id: <5.1.0.14.0.20020525111240.00ac5c40@localhost>
X-Sender: mshore@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 25 May 2002 11:17:54 -0400
To: RJ Atkinson <rja@extremenetworks.com>, Derek Atkins <warlord@mit.edu>
From: Melinda Shore <mshore@cisco.com>
Subject: Re: [saag] Re:
Cc: SatishK Amara <kumar_amara@yahoo.com>, dong_wei@tsinghua.com,
IPsec <ipsec@lists.tislabs.com>,
Security_Area_Advisory_Group <saag@mit.edu>
In-Reply-To: <28CF8658-6FEF-11D6-895A-00039357A82A@extremenetworks.com>
References: <sjmd6vlhqxn.fsf@kikki.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote:
>Hmm. I would rather say that RSVP is hop-by-hop and
>that (normally) AH/ESP are end-to-end.
In terms of addressing, RSVP is end-to-end in one
direction (sender->receiver) and hop-by-hop in the
other (receiver->sender).
>However, if one used (for example) AH with an asymmetric algorithm,
>one could perform hop-by-hop authentication of the
>packet with AH. This has obvious computational cost
>issues so might not be the best choice.
The packet payload is going to be modified at each hop,
as well, in both directions.
Melinda
From owner-ipsec@lists.tislabs.com Mon May 27 03:27:41 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RARfJ29312;
Mon, 27 May 2002 03:27:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA04373
Mon, 27 May 2002 05:21:06 -0400 (EDT)
Message-ID: <3CF1FD39.DBCC3653@ccs.bbk.ac.uk>
Date: Mon, 27 May 2002 10:32:41 +0100
From: Ken Brown <k.brown@ccs.bbk.ac.uk>
Reply-To: k.brown@ccs.bbk.ac.uk
Organization: Birkbeck College Central Computing Services
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alex Alten <Alten@attbi.com>
CC: Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com
Subject: Re: addresses and IKEv2
References: <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517110546.013cbfc0@mail> <3.0.3.32.20020517163806.013cc950@mail> <3.0.3.32.20020523222844.0139a9d8@mail> <3.0.3.32.20020524164356.01289ba0@mail>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Alex Alten wrote:
[...snip...]
> To reiterate my position: IPsec needs to have a global, secure address space
> that uniquely identifies every participating host. It needs to be simple to
> understand, distributable, and easy to manage. And it needs to be able to
> dynamically map into the IP address space on demand, including private
> network non-routable addresses.
>
> That's the requirements as I see them. Anything less than this means
> you can't use IPsec unencumbered across the Internet.
The trouble is that potentially any device is an IPsec host (or should
that be ("any device is potentially an IPsec host"?). So you need a
scheme for naming everything. Which is a much bigger job than defining
IPsec protocols, and has been tried a number of times, littering
standard space with documents mostly beginning with "X." - using the
least bad existing system (whichever it happens to be) is almost
certainly going to be more feasible than devising and managing your own
- let alone persuading the entire world to use it. It's not as if such a
thing can be invisibly built in to software that implements the protocol
- you have to have a way of issuing names, controlling their use, and
making sure the naming system itself is both robust and is reliable.
That's going to mean some central registry and a global network of
keyservers or nameservers (even if they aren't called that).
We can get away with a global namespace of, say, MAC addresses,
hardwired into devices or assigned locally by software, because we don't
/really/ care if someone doesn't play ball - as long as they remain on
their own networks that's their problem. (well ,except for edge routers,
but you see what I mean). It doesn't really have to secure or global
(though it is a bit easier if it is global). The IP namespace gets a
lot more political and centralised, and the DNS even more political,
because decentralised. And your system - in which everything has to be
both globally unique /and/ secure, /and/ participating devices have to
be able to find out each others names anywhere in the world - is also
going to be complex and political.
Of course it might be that the statement "you can't use IPsec
unencumbered across the Internet" is going to be true.
Ken Brown
Birkbeck College, London University
From owner-ipsec@lists.tislabs.com Mon May 27 23:04:59 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4S64wJ08644;
Mon, 27 May 2002 23:04:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA05910
Tue, 28 May 2002 01:12:16 -0400 (EDT)
Message-Id: <3.0.3.32.20020527222820.0135e9e8@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Mon, 27 May 2002 22:28:20 -0700
To: k.brown@ccs.bbk.ac.uk
From: Alex Alten <Alten@attbi.com>
Subject: Re: addresses and IKEv2
Cc: Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com
In-Reply-To: <3CF1FD39.DBCC3653@ccs.bbk.ac.uk>
References: <3.0.3.32.20020523222844.0139a9d8@mail>
<3.0.3.32.20020517163806.013cc950@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517163806.013cc950@mail>
<3.0.3.32.20020523222844.0139a9d8@mail>
<3.0.3.32.20020524164356.01289ba0@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ken,
I appreciate your insightful remarks below. You have "hit the nail on the
head" as we say on this side of the Atlantic. In fact your remarks contain
the nuggets of the solution, which as you have correctly pointed out, will
be both technical and political in nature. My comments in response to
yours are interspersed with yours below.
Sincerely,
- Alex
At 10:32 AM 5/27/2002 +0100, Ken Brown wrote:
>Alex Alten wrote:
>
>[...snip...]
>
>> To reiterate my position: IPsec needs to have a global, secure address
space
>> that uniquely identifies every participating host. It needs to be
simple to
>> understand, distributable, and easy to manage. And it needs to be able to
>> dynamically map into the IP address space on demand, including private
>> network non-routable addresses.
>>
>> That's the requirements as I see them. Anything less than this means
>> you can't use IPsec unencumbered across the Internet.
>
>
>The trouble is that potentially any device is an IPsec host (or should
>that be ("any device is potentially an IPsec host"?). So you need a
>scheme for naming everything. Which is a much bigger job than defining
>IPsec protocols, and has been tried a number of times, littering
>standard space with documents mostly beginning with "X." - using the
>least bad existing system (whichever it happens to be) is almost
>certainly going to be more feasible than devising and managing your own
>- let alone persuading the entire world to use it. It's not as if such a
>thing can be invisibly built in to software that implements the protocol
>- you have to have a way of issuing names, controlling their use, and
>making sure the naming system itself is both robust and is reliable.
>That's going to mean some central registry and a global network of
>keyservers or nameservers (even if they aren't called that).
>
I absolutely agree with this above paragraph. I wish we could use an
existing standard, but unfortunately the successful ones require that
all the participants are to be trustworthy and will follow the rules.
This cannot be the basis of our address system, unfortunately we must
assume that a significant number of hosts will be untrustworthy (not
to mention the different policies of each organization that must be
enforced separately).
And yes, this probably means a set of key servers, probably one per
organization, across the Internet. At first a central (trusted)
registry may not be required, but once trusted organization networks
start linking up in great numbers then one, or a limited number, would
be needed.
>We can get away with a global namespace of, say, MAC addresses,
>hardwired into devices or assigned locally by software, because we don't
>/really/ care if someone doesn't play ball - as long as they remain on
>their own networks that's their problem. (well ,except for edge routers,
>but you see what I mean). It doesn't really have to secure or global
>(though it is a bit easier if it is global). The IP namespace gets a
>lot more political and centralised, and the DNS even more political,
>because decentralised. And your system - in which everything has to be
>both globally unique /and/ secure, /and/ participating devices have to
>be able to find out each others names anywhere in the world - is also
>going to be complex and political.
>
Yes, I'm afraid you are absolutely right. Technically I'm absolutely
certain we could come up with a very good model (you're right it doesn't
have to be secure or global, but it can't be as transient as IP addresses),
but then how to handle the politics of assigning blocks of addresses (or
whatever) will be a serious challenge. Also, especially in light of Sept.
11th, we will need be very careful about how we handle key distribution and
escrow. The days of when a few long haired guys with PhD's here in the US
could quietly do things are long gone.
>Of course it might be that the statement "you can't use IPsec
>unencumbered across the Internet" is going to be true.
>
Which might not be such a bad thing in my mind. I've not been happy
with the rest of the IPsec design, which I've documented thoroughly in
prior postings to this WG. I wouldn't mind seeing a fresh start with a
clean sheet of paper (and with a lot fewer people involved). I'll
probably get publicly flamed for these comments, right Dan?
>Ken Brown
>Birkbeck College, London University
>
--
Alex Alten
Alten@ATTBI.com
From owner-ipsec@lists.tislabs.com Tue May 28 06:38:30 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4SDcTJ24331;
Tue, 28 May 2002 06:38:30 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06793
Tue, 28 May 2002 08:42:59 -0400 (EDT)
Date: Sat, 25 May 2002 10:53:22 -0400
Subject: Re: [saag] Re:
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: SatishK Amara <kumar_amara@yahoo.com>, dong_wei@tsinghua.com,
IPsec <ipsec@lists.tislabs.com>,
Security_Area_Advisory_Group <saag@mit.edu>
To: Derek Atkins <warlord@mit.edu>
From: RJ Atkinson <rja@extremenetworks.com>
In-Reply-To: <sjmd6vlhqxn.fsf@kikki.mit.edu>
Message-Id: <28CF8658-6FEF-11D6-895A-00039357A82A@extremenetworks.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Friday, May 24, 2002, at 11:00 , Derek Atkins wrote:
> Because IPsec is hop-by-hop but you want RSVP end-to-end.
>
> -derek
Hmm. I would rather say that RSVP is hop-by-hop and
that (normally) AH/ESP are end-to-end.
However, if one used (for example) AH with an asymmetric algorithm,
one could perform hop-by-hop authentication of the
packet with AH. This has obvious computational cost
issues so might not be the best choice.
> SatishK Amara <kumar_amara@yahoo.com> writes:
>
>> Why don't you use IPSEC to secure RSVP.
>>
>> Satish Amara
From owner-ipsec@lists.tislabs.com Wed May 29 07:21:18 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TELHJ05327;
Wed, 29 May 2002 07:21:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11317
Wed, 29 May 2002 09:41:26 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "Melinda Shore" <mshore@cisco.com>
Cc: "IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE: [saag] Re:
Date: Wed, 29 May 2002 15:59:00 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCCEHCEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <5.1.0.14.0.20020529094532.00ab6b90@localhost>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi
>
>
> At 03:43 PM 5/29/02 +0200, Hannes Tschofenig wrote:
> >rsvp travels hop-by-hop (rsvp capable nodes) from one end-point
> to an other
> >(except if you use some rsvp extensions like rsvp proxy etc.).
> hence "RSVP
> >is end-to-end in one direction (sender->receiver)" confuses me
> somehow. the
> >security for rsvp is build on hop-by-hop security based on a
> chain-of-trust.
>
> In the sender->receiver direction, the destination IP address
> in the Path message is the receiver's. In the receiver->
> sender direction, the destination IP address in the Resv message
> is the address of the PHOP that was picked up by the Path
> message.
true. the path message is used for path-pinning to allow the resv message to
travel the same way back. but this is not related to the question of
end-to-end or hop-by-hop protection. both messages travel hop-by-hop.
do you think that the hop-by-hop security in rsvp is a good or a bad thing?
should there be more than what is currently provided?
ciao
hannes
>
> Melinda
From owner-ipsec@lists.tislabs.com Wed May 29 07:22:32 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEMVJ05768;
Wed, 29 May 2002 07:22:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11243
Wed, 29 May 2002 09:31:21 -0400 (EDT)
Message-Id: <5.1.0.14.0.20020529094532.00ab6b90@localhost>
X-Sender: mshore@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 29 May 2002 09:48:37 -0400
To: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [saag] Re:
Cc: "IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
In-Reply-To: <BIEMJDFDALACOIGHKCHCAEHAEHAA.Hannes.Tschofenig@mchp.siemen
s.de>
References: <5.1.0.14.0.20020525111240.00ac5c40@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 03:43 PM 5/29/02 +0200, Hannes Tschofenig wrote:
>rsvp travels hop-by-hop (rsvp capable nodes) from one end-point to an other
>(except if you use some rsvp extensions like rsvp proxy etc.). hence "RSVP
>is end-to-end in one direction (sender->receiver)" confuses me somehow. the
>security for rsvp is build on hop-by-hop security based on a chain-of-trust.
In the sender->receiver direction, the destination IP address
in the Path message is the receiver's. In the receiver->
sender direction, the destination IP address in the Resv message
is the address of the PHOP that was picked up by the Path
message.
Melinda
From owner-ipsec@lists.tislabs.com Wed May 29 07:22:33 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEMWJ05775;
Wed, 29 May 2002 07:22:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11209
Wed, 29 May 2002 09:26:23 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "Melinda Shore" <mshore@cisco.com>,
"RJ Atkinson" <rja@extremenetworks.com>, "Derek Atkins" <warlord@mit.edu>
Cc: "SatishK Amara" <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE: [saag] Re:
Date: Wed, 29 May 2002 15:43:30 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCAEHAEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <5.1.0.14.0.20020525111240.00ac5c40@localhost>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi
what do you mean by "in terms of addressing"?
my understanding of rsvp is:
rsvp travels hop-by-hop (rsvp capable nodes) from one end-point to an other
(except if you use some rsvp extensions like rsvp proxy etc.). hence "RSVP
is end-to-end in one direction (sender->receiver)" confuses me somehow. the
security for rsvp is build on hop-by-hop security based on a chain-of-trust.
ciao
hannes
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Melinda Shore
> Sent: Saturday, May 25, 2002 5:18 PM
> To: RJ Atkinson; Derek Atkins
> Cc: SatishK Amara; dong_wei@tsinghua.com; IPsec;
> Security_Area_Advisory_Group
> Subject: Re: [saag] Re:
>
>
> At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote:
> >Hmm. I would rather say that RSVP is hop-by-hop and
> >that (normally) AH/ESP are end-to-end.
>
> In terms of addressing, RSVP is end-to-end in one
> direction (sender->receiver) and hop-by-hop in the
> other (receiver->sender).
>
> >However, if one used (for example) AH with an asymmetric algorithm,
> >one could perform hop-by-hop authentication of the
> >packet with AH. This has obvious computational cost
> >issues so might not be the best choice.
>
> The packet payload is going to be modified at each hop,
> as well, in both directions.
>
> Melinda
From owner-ipsec@lists.tislabs.com Wed May 29 07:22:47 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEMkJ05867;
Wed, 29 May 2002 07:22:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11316
Wed, 29 May 2002 09:41:25 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "Derek Atkins" <derek@ihtfp.com>
Cc: "SatishK Amara" <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE: IPsec and RSVP
Date: Wed, 29 May 2002 15:59:00 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCAEHCEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <sjm8z632hor.fsf@kikki.mit.edu>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi
>
> "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de> writes:
>
> > hi
> >
> > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp
> > capable router)?
>
> You lose the authentication of the end-point requesting the
> reservation.
rsvp does not provide this property. there is no end-to-end authentication
(if i understood you correctly).
> If you use ipsec in this way, then each router
> knows its peer, but you have no transitive authentication.
usually you would like to use the chain-of-trust principal, which means that
it is as good as the weakest link.
> The only protection you get is protection of on-the-wire
> request.
true. you protect along an unknown number of non-rsvp capable routers.
> You have no protection against a corrupt router
> along the path, or indeed no way to know what the actual
> original request was.
there is no protection against corrupt routers in rsvp.
who do you want to know where the original request came from? (the
end-point?, networks in between, or all nodes in between?)
in rsvp you have no separation of mutable and non-mutable fields and since
rsvp router may modify or add something to the message it is difficult (not
possible) to use end-to-end security.
do you think there is a strong need to provide end-to-end security in rsvp?
ciao
hannes
>
> > ciao
> > hannes
>
> -derek
>
> --
> Derek Atkins
> Computer and Internet Security Consultant
> derek@ihtfp.com www.ihtfp.com
From owner-ipsec@lists.tislabs.com Wed May 29 07:23:26 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TENPJ06083;
Wed, 29 May 2002 07:23:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11211
Wed, 29 May 2002 09:26:26 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "RJ Atkinson" <rja@extremenetworks.com>, "Derek Atkins" <warlord@mit.edu>
Cc: "SatishK Amara" <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE: [saag] Re:
Date: Wed, 29 May 2002 15:43:31 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCCEHAEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <28CF8658-6FEF-11D6-895A-00039357A82A@extremenetworks.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi
>
> On Friday, May 24, 2002, at 11:00 , Derek Atkins wrote:
> > Because IPsec is hop-by-hop but you want RSVP end-to-end.
> >
> > -derek
>
> Hmm. I would rather say that RSVP is hop-by-hop and
> that (normally) AH/ESP are end-to-end.
but no one prevents you from using ipsec ah/esp in a hop-by-hop mode for
protecting rsvp.
>
> However, if one used (for example) AH with an asymmetric algorithm,
> one could perform hop-by-hop authentication of the
> packet with AH.
what do you mean by "AH with an asymmetric algorithm" ? IKE with an
asymmetric authentiction mode?
> This has obvious computational cost
> issues so might not be the best choice.
ciao
hannes
>
> > SatishK Amara <kumar_amara@yahoo.com> writes:
> >
> >> Why don't you use IPSEC to secure RSVP.
> >>
> >> Satish Amara
From owner-ipsec@lists.tislabs.com Wed May 29 07:23:43 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TENhJ06204;
Wed, 29 May 2002 07:23:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11249
Wed, 29 May 2002 09:33:21 -0400 (EDT)
To: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
Cc: "Melinda Shore" <mshore@cisco.com>,
"RJ Atkinson" <rja@extremenetworks.com>,
"SatishK Amara" <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
From: Derek Atkins <derek@ihtfp.com>
Subject: Re: [saag] Re: IPsec and RSVP
References: <BIEMJDFDALACOIGHKCHCAEHAEHAA.Hannes.Tschofenig@mchp.siemens.de>
Date: 29 May 2002 09:45:33 -0400
In-Reply-To: <BIEMJDFDALACOIGHKCHCAEHAEHAA.Hannes.Tschofenig@mchp.siemens.de>
Message-ID: <sjm4rgr2hky.fsf@kikki.mit.edu>
Lines: 57
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
And we're saying that this chain-of-trust is a bad model, because
anyone close to an edge can inject any amount of bogus data into the
network. Once it's injected, it's even TRUSTED! One major problem is
that you lose the origin of the request after the first hop, not to
mention the actual request itself.
-derek
"Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de> writes:
> hi
>
> what do you mean by "in terms of addressing"?
>
> my understanding of rsvp is:
> rsvp travels hop-by-hop (rsvp capable nodes) from one end-point to an other
> (except if you use some rsvp extensions like rsvp proxy etc.). hence "RSVP
> is end-to-end in one direction (sender->receiver)" confuses me somehow. the
> security for rsvp is build on hop-by-hop security based on a chain-of-trust.
>
> ciao
> hannes
>
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Melinda Shore
> > Sent: Saturday, May 25, 2002 5:18 PM
> > To: RJ Atkinson; Derek Atkins
> > Cc: SatishK Amara; dong_wei@tsinghua.com; IPsec;
> > Security_Area_Advisory_Group
> > Subject: Re: [saag] Re:
> >
> >
> > At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote:
> > >Hmm. I would rather say that RSVP is hop-by-hop and
> > >that (normally) AH/ESP are end-to-end.
> >
> > In terms of addressing, RSVP is end-to-end in one
> > direction (sender->receiver) and hop-by-hop in the
> > other (receiver->sender).
> >
> > >However, if one used (for example) AH with an asymmetric algorithm,
> > >one could perform hop-by-hop authentication of the
> > >packet with AH. This has obvious computational cost
> > >issues so might not be the best choice.
> >
> > The packet payload is going to be modified at each hop,
> > as well, in both directions.
> >
> > Melinda
>
--
Derek Atkins
Computer and Internet Security Consultant
derek@ihtfp.com www.ihtfp.com
From owner-ipsec@lists.tislabs.com Wed May 29 07:26:14 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEQDJ07729;
Wed, 29 May 2002 07:26:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11336
Wed, 29 May 2002 09:47:25 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "Derek Atkins" <derek@ihtfp.com>
Cc: "Melinda Shore" <mshore@cisco.com>,
"RJ Atkinson" <rja@extremenetworks.com>,
"SatishK Amara" <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE: [saag] Re: IPsec and RSVP
Date: Wed, 29 May 2002 16:04:54 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCGEHCEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <sjm4rgr2hky.fsf@kikki.mit.edu>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi
>
>
> And we're saying that this chain-of-trust is a bad model, because
> anyone close to an edge can inject any amount of bogus data into the
> network.
you have to differentiate between data traffic and signaling traffic.
if you change the chain-of-trust model and require end-to-end nature than
this implies that you
don't want any router to modify rsvp message (adding something etc.). this
is possible by introducing mutable and non-mutable fields and protecting the
non-mutable fields end-to-end. the only information you can protect is what
qos was requested by one end. since rsvp is not used by its own you could
also protect this information at the application layer for example using
sip. if nodes in between are unable to verify this information then this
would also work. what do you think?
> Once it's injected, it's even TRUSTED!
yes - if a router is malicious then you have a problem.
injecting data traffic by someone else (unauthorized user) is something
different.
injecting unprotected signaling messages is again something different.
> One major problem is
> that you lose the origin of the request after the first hop, not to
> mention the actual request itself.
which nodes need this information and for what?
ciao
hannes
>
> -derek
>
> "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de> writes:
>
> > hi
> >
> > what do you mean by "in terms of addressing"?
> >
> > my understanding of rsvp is:
> > rsvp travels hop-by-hop (rsvp capable nodes) from one end-point
> to an other
> > (except if you use some rsvp extensions like rsvp proxy etc.).
> hence "RSVP
> > is end-to-end in one direction (sender->receiver)" confuses me
> somehow. the
> > security for rsvp is build on hop-by-hop security based on a
> chain-of-trust.
> >
> > ciao
> > hannes
> >
> >
> > > -----Original Message-----
> > > From: owner-ipsec@lists.tislabs.com
> > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Melinda Shore
> > > Sent: Saturday, May 25, 2002 5:18 PM
> > > To: RJ Atkinson; Derek Atkins
> > > Cc: SatishK Amara; dong_wei@tsinghua.com; IPsec;
> > > Security_Area_Advisory_Group
> > > Subject: Re: [saag] Re:
> > >
> > >
> > > At 10:53 AM 5/25/02 -0400, RJ Atkinson wrote:
> > > >Hmm. I would rather say that RSVP is hop-by-hop and
> > > >that (normally) AH/ESP are end-to-end.
> > >
> > > In terms of addressing, RSVP is end-to-end in one
> > > direction (sender->receiver) and hop-by-hop in the
> > > other (receiver->sender).
> > >
> > > >However, if one used (for example) AH with an asymmetric algorithm,
> > > >one could perform hop-by-hop authentication of the
> > > >packet with AH. This has obvious computational cost
> > > >issues so might not be the best choice.
> > >
> > > The packet payload is going to be modified at each hop,
> > > as well, in both directions.
> > >
> > > Melinda
> >
>
> --
> Derek Atkins
> Computer and Internet Security Consultant
> derek@ihtfp.com www.ihtfp.com
From owner-ipsec@lists.tislabs.com Wed May 29 07:29:46 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TETjJ09745;
Wed, 29 May 2002 07:29:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11208
Wed, 29 May 2002 09:26:22 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "SatishK Amara" <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: ipsec to secure rsvp
Date: Wed, 29 May 2002 15:43:29 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCMEGPEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <20020524143641.97990.qmail@web21302.mail.yahoo.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi
there is no reason why not to use ipsec to secure rsvp. especially in the
core network (between routers) this might be a reasonable approach. using
ipsec to secure the traffic between the application (end-host) and the first
hop router is however more difficult.
ciao
hannes
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara
> Sent: Friday, May 24, 2002 4:37 PM
> To: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group
> Subject: Re:
>
>
> Why don't you use IPSEC to secure RSVP.
>
> Satish Amara
> --- Dong <dong_wei@tsinghua.com> wrote:
> > Roy,
> >
> > I just read a paper "Preventing Denial of Service
> > Attacks on Quality of Service", which is written by
> > some guys from N.C. State university and UC Davis.
> > The service quality to legimative users could be
> > degraded by attacks on control flow or data flow.
> > For example, an illegal user can forge a reservation
> > message, so he can receive an unauthorized amount of
> > resources. I just wanna to know what threats exist
> > in providing QoS, and what the state-of-art
> > techniques to prevent, detect and counter those
> > attacks, and of course recovery mothods as well.
> >
> > Thx a lot.
> >
> > Dong
> >
> >
> > Dong,
> > Please be a little more precise in what you are
> > asking for, i.e.
> >
> > 3-5 bullet list items on what kind of security you
> > seek.
> >
> > Roy
> >
> > -----Original Message-----
> > From: Dong [mailto:dong_wei@tsinghua.com]
> > Sent: Thursday, May 23, 2002 2:05 PM
> > To: Security_Area_Advisory_Group; IPsec
> > Subject: Secure QoS
> >
> >
> > Hi,
> >
> > I am trying to do a survey on Secure QoS. Any paper
> > on that? Thx.
> >
> > Dong
> >
> >
> _____________________________________________________________
> > Get Tsinghua University free email account:
> > www.tsinghua.com
> > Web site sponsored and hosted by AtFreeWeb.com
> >
> >
> >
> >
> _____________________________________________________________
> > Get Tsinghua University free email account:
> > www.tsinghua.com
> > Web site sponsored and hosted by AtFreeWeb.com
> >
> >
> _____________________________________________________________
> > Promote your group and strengthen ties to your
> > members with email@yourgroup.org by Everyone.net
> http://www.everyone.net/?btn=tag
>
>
> =====
> In natural science, Nature has given us a world and we're just to
> discover its laws. In computers, we can stuff laws into it and
> create a world -- Alan Kay
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
From owner-ipsec@lists.tislabs.com Wed May 29 07:30:19 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEUIJ10025;
Wed, 29 May 2002 07:30:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11237
Wed, 29 May 2002 09:30:20 -0400 (EDT)
To: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
Cc: "SatishK Amara" <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
From: Derek Atkins <derek@ihtfp.com>
Subject: Re: IPsec and RSVP
References: <BIEMJDFDALACOIGHKCHCOEGPEHAA.Hannes.Tschofenig@mchp.siemens.de>
Date: 29 May 2002 09:43:16 -0400
In-Reply-To: <BIEMJDFDALACOIGHKCHCOEGPEHAA.Hannes.Tschofenig@mchp.siemens.de>
Message-ID: <sjm8z632hor.fsf@kikki.mit.edu>
Lines: 24
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
"Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de> writes:
> hi
>
> what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp
> capable router)?
You lose the authentication of the end-point requesting the
reservation. If you use ipsec in this way, then each router
knows its peer, but you have no transitive authentication.
The only protection you get is protection of on-the-wire
request. You have no protection against a corrupt router
along the path, or indeed no way to know what the actual
original request was.
> ciao
> hannes
-derek
--
Derek Atkins
Computer and Internet Security Consultant
derek@ihtfp.com www.ihtfp.com
From owner-ipsec@lists.tislabs.com Wed May 29 07:34:03 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEY2J11261;
Wed, 29 May 2002 07:34:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11212
Wed, 29 May 2002 09:26:26 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "Derek Atkins" <warlord@mit.edu>, "SatishK Amara" <kumar_amara@yahoo.com>
Cc: <dong_wei@tsinghua.com>, "IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE:
Date: Wed, 29 May 2002 15:43:30 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCOEGPEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <sjmd6vlhqxn.fsf@kikki.mit.edu>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi
what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp
capable router)?
ciao
hannes
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins
> Sent: Saturday, May 25, 2002 5:01 AM
> To: SatishK Amara
> Cc: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group
> Subject: Re:
>
>
> Because IPsec is hop-by-hop but you want RSVP end-to-end.
>
> -derek
>
> SatishK Amara <kumar_amara@yahoo.com> writes:
>
> > Why don't you use IPSEC to secure RSVP.
> >
> > Satish Amara
> > --- Dong <dong_wei@tsinghua.com> wrote:
> > > Roy,
> > >
> > > I just read a paper "Preventing Denial of Service
> > > Attacks on Quality of Service", which is written by
> > > some guys from N.C. State university and UC Davis.
> > > The service quality to legimative users could be
> > > degraded by attacks on control flow or data flow.
> > > For example, an illegal user can forge a reservation
> > > message, so he can receive an unauthorized amount of
> > > resources. I just wanna to know what threats exist
> > > in providing QoS, and what the state-of-art
> > > techniques to prevent, detect and counter those
> > > attacks, and of course recovery mothods as well.
> > >
> > > Thx a lot.
> > >
> > > Dong
> > >
> > >
> > > Dong,
> > > Please be a little more precise in what you are
> > > asking for, i.e.
> > >
> > > 3-5 bullet list items on what kind of security you
> > > seek.
> > >
> > > Roy
> > >
> > > -----Original Message-----
> > > From: Dong [mailto:dong_wei@tsinghua.com]
> > > Sent: Thursday, May 23, 2002 2:05 PM
> > > To: Security_Area_Advisory_Group; IPsec
> > > Subject: Secure QoS
> > >
> > >
> > > Hi,
> > >
> > > I am trying to do a survey on Secure QoS. Any paper
> > > on that? Thx.
> > >
> > > Dong
> > >
> > >
> > _____________________________________________________________
> > > Get Tsinghua University free email account:
> > > www.tsinghua.com
> > > Web site sponsored and hosted by AtFreeWeb.com
> > >
> > >
> > >
> > >
> > _____________________________________________________________
> > > Get Tsinghua University free email account:
> > > www.tsinghua.com
> > > Web site sponsored and hosted by AtFreeWeb.com
> > >
> > >
> > _____________________________________________________________
> > > Promote your group and strengthen ties to your
> > > members with email@yourgroup.org by Everyone.net
> > http://www.everyone.net/?btn=tag
> >
> >
> > =====
> > In natural science, Nature has given us a world and we're just
> to discover its laws. In computers, we can stuff laws into it and
> create a world -- Alan Kay
> >
> > __________________________________________________
> > Do You Yahoo!?
> > LAUNCH - Your Yahoo! Music Experience
> > http://launch.yahoo.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 May 29 07:46:24 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TEkNJ17957;
Wed, 29 May 2002 07:46:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11469
Wed, 29 May 2002 10:05:42 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "Melinda Shore" <mshore@cisco.com>
Cc: "IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE: [saag] Re:
Date: Wed, 29 May 2002 16:22:36 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCKEHDEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <5.1.0.14.0.20020529100110.00aad1b0@localhost>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi melinda
>
>
> At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote:
> >do you think that the hop-by-hop security in rsvp is a good or a
> bad thing?
> >should there be more than what is currently provided?
>
> There needs to be more than what is currently provided,
> but, as always, there's a big keying/cert problem, particularly
> in a multi-"domain" environment.
i fully agree with you. especially in a generic end-to-end case this might
be quite difficult.
> I don't think the threat
> environment is particularly well-understood (I've seen your
> NSIS draft but haven't gone through it in detail).
i would like to hear your opinion about it.
> Clearly
> IPSec is not the right answer for Path messages, however,
> because while the addressing is end-to-end the payload
> contents do change as the packet transits participating
> routers.
yes. ipsec is definitely not the choice for end-to-end security since it
does not allow intermediate nodes to modify the messages.
i however have difficulties with the statement that end-to-end security
introduced in rsvp solves all problems. (i think that it even introduces
more.) my observation is that the interaction between rsvp and other
protocols like sip is important especially for accounting and since rsvp is
often used together with other protocols.
ciao
hannes
>
> Melinda
From owner-ipsec@lists.tislabs.com Wed May 29 09:36:11 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TGaAJ16484;
Wed, 29 May 2002 09:36:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11957
Wed, 29 May 2002 11:50:11 -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: <15604.64389.520614.112373@thomasm-u1.cisco.com>
Date: Wed, 29 May 2002 09:02:13 -0700 (PDT)
To: Derek Atkins <derek@ihtfp.com>
Cc: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>,
"SatishK Amara" <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: Re: IPsec and RSVP
In-Reply-To: <sjm8z632hor.fsf@kikki.mit.edu>
References: <BIEMJDFDALACOIGHKCHCOEGPEHAA.Hannes.Tschofenig@mchp.siemens.de>
<sjm8z632hor.fsf@kikki.mit.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
Derek Atkins writes:
> "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de> writes:
>
> > hi
> >
> > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp
> > capable router)?
>
> You lose the authentication of the end-point requesting the
> reservation. If you use ipsec in this way, then each router
> knows its peer, but you have no transitive authentication.
> The only protection you get is protection of on-the-wire
> request. You have no protection against a corrupt router
> along the path, or indeed no way to know what the actual
> original request was.
Derek,
There are two different forms of crypto needed for
RSVP: a hop-by-hop integrity object and a policy
object. IPsec could in theory replace the
integrity object, but cannot replace the policy
object. Considering that there is no key
distribution for the hop-by-hop integrity objects,
IPsec might not be a bad choice in some
situations.
Mike
From owner-ipsec@lists.tislabs.com Wed May 29 09:51:09 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TGp8J22512;
Wed, 29 May 2002 09:51:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11375
Wed, 29 May 2002 09:49:32 -0400 (EDT)
Message-Id: <5.1.0.14.0.20020529100110.00aad1b0@localhost>
X-Sender: mshore@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 29 May 2002 10:06:51 -0400
To: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
From: Melinda Shore <mshore@cisco.com>
Subject: RE: [saag] Re:
Cc: "IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
In-Reply-To: <BIEMJDFDALACOIGHKCHCCEHCEHAA.Hannes.Tschofenig@mchp.siemen
s.de>
References: <5.1.0.14.0.20020529094532.00ab6b90@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote:
>do you think that the hop-by-hop security in rsvp is a good or a bad thing?
>should there be more than what is currently provided?
There needs to be more than what is currently provided,
but, as always, there's a big keying/cert problem, particularly
in a multi-"domain" environment. I don't think the threat
environment is particularly well-understood (I've seen your
NSIS draft but haven't gone through it in detail). Clearly
IPSec is not the right answer for Path messages, however,
because while the addressing is end-to-end the payload
contents do change as the packet transits participating
routers.
Melinda
From owner-ipsec@lists.tislabs.com Wed May 29 11:22:45 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TIMhJ03158;
Wed, 29 May 2002 11:22:44 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11210
Wed, 29 May 2002 09:26:23 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: <dong_wei@tsinghua.com>, "IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: qos threats
Date: Wed, 29 May 2002 15:43:28 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCKEGPEHAA.Hannes.Tschofenig@mchp.siemens.de>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <20020523234609.3FA1B2756@sitemail.everyone.net>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi
regarding threats you might read (and maybe comment) a threat draft related
to nsis;
see:
http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-00.txt
ciao
hannes
ps: your comments are welcome.
Title : NSIS Threats
Author(s) : H. Tschofenig
Filename : draft-tschofenig-nsis-threats-00.txt
Pages : 9
Date : 24-May-02
As the work in the NSIS working has begun to describe requirements
and the framework people started thinking about possible security
implication. This document should provide a starting point for the
discussion at the NSIS interim meeting and at the NSIS working group
mailing list regarding the security issues that have to be
addressed. It does not describe threats for a particular published
protocol. This memo is furthermore meant to create awareness for the
security within the group. The threat scenarios in this document are
matched against the security requirements described in [1].
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dong
> Sent: Friday, May 24, 2002 1:46 AM
> To: IPsec; Security_Area_Advisory_Group
> Subject:
>
>
> Roy,
>
> I just read a paper "Preventing Denial of Service Attacks on
> Quality of Service", which is written by some guys from N.C.
> State university and UC Davis. The service quality to legimative
> users could be degraded by attacks on control flow or data flow.
> For example, an illegal user can forge a reservation message, so
> he can receive an unauthorized amount of resources. I just wanna
> to know what threats exist in providing QoS, and what the
> state-of-art techniques to prevent, detect and counter those
> attacks, and of course recovery mothods as well.
>
> Thx a lot.
>
> Dong
>
>
> Dong,
> Please be a little more precise in what you are asking for, i.e.
>
> 3-5 bullet list items on what kind of security you seek.
>
> Roy
>
> -----Original Message-----
> From: Dong [mailto:dong_wei@tsinghua.com]
> Sent: Thursday, May 23, 2002 2:05 PM
> To: Security_Area_Advisory_Group; IPsec
> Subject: Secure QoS
>
>
> Hi,
>
> I am trying to do a survey on Secure QoS. Any paper on that? Thx.
>
> Dong
>
> _____________________________________________________________
> Get Tsinghua University free email account: www.tsinghua.com
> Web site sponsored and hosted by AtFreeWeb.com
>
>
>
> _____________________________________________________________
> Get Tsinghua University free email account: www.tsinghua.com
> Web site sponsored and hosted by AtFreeWeb.com
>
> _____________________________________________________________
> Promote your group and strengthen ties to your members with
> email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag
From owner-ipsec@lists.tislabs.com Wed May 29 12:34:40 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TJYdJ00851;
Wed, 29 May 2002 12:34:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12401
Wed, 29 May 2002 14:51:25 -0400 (EDT)
Message-ID: <3CF50554.4B48FA53@cs.ucdavis.edu>
Date: Wed, 29 May 2002 09:44:04 -0700
From: "S. Felix Wu" <wu@cs.ucdavis.edu>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@mchp.siemens.de>,
kumar_amara@yahoo.com, dong_wei@tsinghua.com,
IPsec <ipsec@lists.tislabs.com>,
Security_Area_Advisory_Group <saag@mit.edu>
Subject: Re: ipsec to secure rsvp
References: <BIEMJDFDALACOIGHKCHCMEGPEHAA.Hannes.Tschofenig@mchp.siemens.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The tricky part (my personal opinion) is that, using IPSec, you
must know the other endpoint's IP address to establish the SA in
the first place. According to my understanding, at least in general,
in RSVP, you do NOT know the next hop RSVP router's IP address in
path finding messages (I assume that not every Internet router will
support RSVP), and sometimes route path might change unpredictably.
Therefore, (according to my old/dusty memory), Fred Baker's proposal
to secure RSVP is based on a key table and key ID to allow the next
hop trusted RSVP router to authenticate (HMAC fashion) the message
without prior seesion-key exchange.
I have admitted that I haven't followed the thread of progress in
RSVP security for a while, so maybe things have been changed.
-Felix
Hannes Tschofenig wrote:
>
> hi
>
> there is no reason why not to use ipsec to secure rsvp. especially in the
> core network (between routers) this might be a reasonable approach. using
> ipsec to secure the traffic between the application (end-host) and the first
> hop router is however more difficult.
>
> ciao
> hannes
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara
> > Sent: Friday, May 24, 2002 4:37 PM
> > To: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group
> > Subject: Re:
> >
> >
> > Why don't you use IPSEC to secure RSVP.
> >
> > Satish Amara
> > --- Dong <dong_wei@tsinghua.com> wrote:
> > > Roy,
> > >
> > > I just read a paper "Preventing Denial of Service
> > > Attacks on Quality of Service", which is written by
> > > some guys from N.C. State university and UC Davis.
> > > The service quality to legimative users could be
> > > degraded by attacks on control flow or data flow.
> > > For example, an illegal user can forge a reservation
> > > message, so he can receive an unauthorized amount of
> > > resources. I just wanna to know what threats exist
> > > in providing QoS, and what the state-of-art
> > > techniques to prevent, detect and counter those
> > > attacks, and of course recovery mothods as well.
> > >
> > > Thx a lot.
> > >
> > > Dong
> > >
> > >
> > > Dong,
> > > Please be a little more precise in what you are
> > > asking for, i.e.
> > >
> > > 3-5 bullet list items on what kind of security you
> > > seek.
> > >
> > > Roy
> > >
> > > -----Original Message-----
> > > From: Dong [mailto:dong_wei@tsinghua.com]
> > > Sent: Thursday, May 23, 2002 2:05 PM
> > > To: Security_Area_Advisory_Group; IPsec
> > > Subject: Secure QoS
> > >
> > >
> > > Hi,
> > >
> > > I am trying to do a survey on Secure QoS. Any paper
> > > on that? Thx.
> > >
> > > Dong
> > >
> > >
> > _____________________________________________________________
> > > Get Tsinghua University free email account:
> > > www.tsinghua.com
> > > Web site sponsored and hosted by AtFreeWeb.com
> > >
> > >
> > >
> > >
> > _____________________________________________________________
> > > Get Tsinghua University free email account:
> > > www.tsinghua.com
> > > Web site sponsored and hosted by AtFreeWeb.com
> > >
> > >
> > _____________________________________________________________
> > > Promote your group and strengthen ties to your
> > > members with email@yourgroup.org by Everyone.net
> > http://www.everyone.net/?btn=tag
> >
> >
> > =====
> > In natural science, Nature has given us a world and we're just to
> > discover its laws. In computers, we can stuff laws into it and
> > create a world -- Alan Kay
> >
> > __________________________________________________
> > Do You Yahoo!?
> > LAUNCH - Your Yahoo! Music Experience
> > http://launch.yahoo.com
--
----------------------------------------------------------------------
Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu
Associate Professor http://www.cs.ucdavis.edu/~wu
Computer Science Department office: 1-530-754-7070
University of California at Davis fax: 1-530-752-4767
----------------------------------------------------------------------
From owner-ipsec@lists.tislabs.com Wed May 29 12:34:49 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TJYmJ00868;
Wed, 29 May 2002 12:34:49 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12402
Wed, 29 May 2002 14:51:26 -0400 (EDT)
Message-ID: <3CF509D5.C0530394@cs.ucdavis.edu>
Date: Wed, 29 May 2002 10:03:18 -0700
From: "S. Felix Wu" <wu@cs.ucdavis.edu>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@mchp.siemens.de>
CC: Derek Atkins <warlord@mit.edu>, SatishK Amara <kumar_amara@yahoo.com>,
dong_wei@tsinghua.com, IPsec <ipsec@lists.tislabs.com>,
Security_Area_Advisory_Group <saag@mit.edu>
Subject: Re:
References: <BIEMJDFDALACOIGHKCHCOEGPEHAA.Hannes.Tschofenig@mchp.siemens.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It depends on what are the security requirements and threats.
In my opinion, RSVP security is really neither hop-by-hop nor
end-to-end (or I should say it is a mixture of both).
Certain fields in RSVP are "mutable" (for example, maximum
available bandwidth along the route path), and therefore, a
pure end-to-end will not be possible. On the other hand, if
we assume (i.e., our threat model) that an intermediate RSVP
router (on the route path) can be malicious, then you need
some forms of end-to-end to protect at least those "static"
fields in an end-to-end fashion.
My students and I studied this problem a few years ago and the
following is a web link to our paper:
http://arqos.csc.ncsu.edu/papers/1999_10_iwqos99.pdf
This work is somewhat old, but hopefully it will provide some
information about the technical difficulties in dealing with
RSVP security.
-Felix
Hannes Tschofenig wrote:
>
> hi
>
> what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp
> capable router)?
>
> ciao
> hannes
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins
> > Sent: Saturday, May 25, 2002 5:01 AM
> > To: SatishK Amara
> > Cc: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group
> > Subject: Re:
> >
> >
> > Because IPsec is hop-by-hop but you want RSVP end-to-end.
> >
> > -derek
> >
> > SatishK Amara <kumar_amara@yahoo.com> writes:
> >
> > > Why don't you use IPSEC to secure RSVP.
> > >
> > > Satish Amara
> > > --- Dong <dong_wei@tsinghua.com> wrote:
> > > > Roy,
> > > >
> > > > I just read a paper "Preventing Denial of Service
> > > > Attacks on Quality of Service", which is written by
> > > > some guys from N.C. State university and UC Davis.
> > > > The service quality to legimative users could be
> > > > degraded by attacks on control flow or data flow.
> > > > For example, an illegal user can forge a reservation
> > > > message, so he can receive an unauthorized amount of
> > > > resources. I just wanna to know what threats exist
> > > > in providing QoS, and what the state-of-art
> > > > techniques to prevent, detect and counter those
> > > > attacks, and of course recovery mothods as well.
> > > >
> > > > Thx a lot.
> > > >
> > > > Dong
> > > >
> > > >
> > > > Dong,
> > > > Please be a little more precise in what you are
> > > > asking for, i.e.
> > > >
> > > > 3-5 bullet list items on what kind of security you
> > > > seek.
> > > >
> > > > Roy
> > > >
> > > > -----Original Message-----
> > > > From: Dong [mailto:dong_wei@tsinghua.com]
> > > > Sent: Thursday, May 23, 2002 2:05 PM
> > > > To: Security_Area_Advisory_Group; IPsec
> > > > Subject: Secure QoS
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I am trying to do a survey on Secure QoS. Any paper
> > > > on that? Thx.
> > > >
> > > > Dong
> > > >
> > > >
> > > _____________________________________________________________
> > > > Get Tsinghua University free email account:
> > > > www.tsinghua.com
> > > > Web site sponsored and hosted by AtFreeWeb.com
> > > >
> > > >
> > > >
> > > >
> > > _____________________________________________________________
> > > > Get Tsinghua University free email account:
> > > > www.tsinghua.com
> > > > Web site sponsored and hosted by AtFreeWeb.com
> > > >
> > > >
> > > _____________________________________________________________
> > > > Promote your group and strengthen ties to your
> > > > members with email@yourgroup.org by Everyone.net
> > > http://www.everyone.net/?btn=tag
> > >
> > >
> > > =====
> > > In natural science, Nature has given us a world and we're just
> > to discover its laws. In computers, we can stuff laws into it and
> > create a world -- Alan Kay
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > LAUNCH - Your Yahoo! Music Experience
> > > http://launch.yahoo.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
--
----------------------------------------------------------------------
Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu
Associate Professor http://www.cs.ucdavis.edu/~wu
Computer Science Department office: 1-530-754-7070
University of California at Davis fax: 1-530-752-4767
----------------------------------------------------------------------
From owner-ipsec@lists.tislabs.com Wed May 29 14:15:09 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TLF8J18691;
Wed, 29 May 2002 14:15:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12649
Wed, 29 May 2002 16:34: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: <15605.15926.912770.654169@thomasm-u1.cisco.com>
Date: Wed, 29 May 2002 13:46:46 -0700 (PDT)
To: "S. Felix Wu" <wu@cs.ucdavis.edu>
Cc: Hannes Tschofenig <Hannes.Tschofenig@mchp.siemens.de>,
kumar_amara@yahoo.com, dong_wei@tsinghua.com,
IPsec <ipsec@lists.tislabs.com>,
Security_Area_Advisory_Group <saag@mit.edu>
Subject: Re: ipsec to secure rsvp
In-Reply-To: <3CF50554.4B48FA53@cs.ucdavis.edu>
References: <BIEMJDFDALACOIGHKCHCMEGPEHAA.Hannes.Tschofenig@mchp.siemens.de>
<3CF50554.4B48FA53@cs.ucdavis.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
S. Felix Wu writes:
> Therefore, (according to my old/dusty memory), Fred Baker's proposal
> to secure RSVP is based on a key table and key ID to allow the next
> hop trusted RSVP router to authenticate (HMAC fashion) the message
> without prior seesion-key exchange.
Right. There are two competing goals going on with
RSVP in this respect: router alert as a discovery
mechanism, and security desires which need to know
the how to key the next hop integrity object. I
don't really see how you reconcile that unless you
have group keys on your integrity objects which
makes me a little queasy.
Mike
From owner-ipsec@lists.tislabs.com Wed May 29 15:11:18 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TMBIJ20101;
Wed, 29 May 2002 15:11:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12846
Wed, 29 May 2002 17:33:24 -0400 (EDT)
Message-ID: <001501c2075a$0d1f4780$6540fea9@amanda2>
From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
To: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>,
"Melinda Shore" <mshore@cisco.com>
Cc: "IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
References: <5.1.0.14.0.20020529094532.00ab6b90@localhost> <5.1.0.14.0.20020529100110.00aad1b0@localhost>
Subject: Re: [saag] Re:
Date: Thu, 30 May 2002 00:44:44 +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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi
The best approach in my view is to use CORBA and CORBsec to deal with path
messages, I believe if CORBA routers can be realized very soon, most of your
IPsec shortcomings will be resolved.
Ahmed
----- Original Message -----
From: "Melinda Shore" <mshore@cisco.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
Cc: "IPsec" <ipsec@lists.tislabs.com>; "Security_Area_Advisory_Group"
<saag@mit.edu>
Sent: Wednesday, May 29, 2002 5:06 PM
Subject: RE: [saag] Re:
> At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote:
> >do you think that the hop-by-hop security in rsvp is a good or a bad
thing?
> >should there be more than what is currently provided?
>
> There needs to be more than what is currently provided,
> but, as always, there's a big keying/cert problem, particularly
> in a multi-"domain" environment. I don't think the threat
> environment is particularly well-understood (I've seen your
> NSIS draft but haven't gone through it in detail). Clearly
> IPSec is not the right answer for Path messages, however,
> because while the addressing is end-to-end the payload
> contents do change as the packet transits participating
> routers.
>
> Melinda
>
From owner-ipsec@lists.tislabs.com Wed May 29 17:36:35 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4U0aZJ24822;
Wed, 29 May 2002 17:36:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13075
Wed, 29 May 2002 19:57:07 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05100301b9194ee15f07@[10.0.1.2]>
In-Reply-To: <3.0.3.32.20020524164356.01289ba0@mail>
References: <3.0.3.32.20020523222844.0139a9d8@mail>
<3.0.3.32.20020517163806.013cc950@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517110546.013cbfc0@mail>
<3.0.3.32.20020517163806.013cc950@mail>
<3.0.3.32.20020523222844.0139a9d8@mail>
<3.0.3.32.20020524164356.01289ba0@mail>
Date: Wed, 29 May 2002 20:10:41 -0400
To: Alex Alten <Alten@attbi.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: addresses and IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 4:43 PM -0700 5/24/02, Alex Alten wrote:
>Steve,
>
>I'm not talking about a host's local database. We need a way to uniquely
>AND SECURELY identify any host worldwide from any other host. You don't
>want to replicate this information to every host, you'd have over 100 million
>entries to distribute to each one!
Oh, well, you've moved the problem well beyond the bounds of the
IPsec WG, given this description of what you are looking for. Also,
given my earlier comments about the desirability of not creating new
ID forms for use in access control systems, I think we have a
fundamental disagreement here.
>I like DNS too, a nice simple hierarchy, it is easy to uniquely name hosts,
>and a simple distributed model for managing the address space. But it has a
>crippling drawback from a security perspective. A DNS name cannot be any
>better
>at identifying a host than it's resolved IP address.
>And we know how
>ephemeral IP addresses can be given the rise of DHCP and NAT. The only
>secure way to absolutely identify a host is to assign it a (randomly) unique
>crypto key. But before you can pull the correct key (RSA or AES) you need to
>find it. For this you need a unique number that doesn't keep being changed
>underneath you. So unfortunately DNS doesn't make the cut. No amount of
>wishful
>thinking is going to make it work properly for us.
I think your argument above is faulty. If I choose to use DNS names
as a basis for access control decisions, and if I have credentials
(e.g., certificates) that allow a machine or person to verify that
the entity at the other end of a key management exchange is the
entity with the DNS name in question, then I can dynamically bind the
name to the current address at the time an SA is created and I have
achieved the access control goals without needing to introduce the
sort of new ID scheme to which you are alluding.
>To reiterate my position: IPsec needs to have a global, secure address space
>that uniquely identifies every participating host. It needs to be simple to
>understand, distributable, and easy to manage. And it needs to be able to
>dynamically map into the IP address space on demand, including private
>network non-routable addresses.
>
>That's the requirements as I see them. Anything less than this means
>you can't use IPsec unencumbered across the Internet.
we don't need a global, secure address space. we need secure means of
mapping IDs to credentials, and mapping those IDs to SA, in real
time, as you note immediately above. These two notions are not the
same.
Steve
From owner-ipsec@lists.tislabs.com Thu May 30 07:31:25 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UEVO103536;
Thu, 30 May 2002 07:31:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14816
Thu, 30 May 2002 09:33:59 -0400 (EDT)
Message-ID: <000a01c207e0$4839a000$2daafea9@amanda2>
From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
To: "Davenport Michael" <davenport_michael@bah.com>
Cc: <ipsec@lists.tislabs.com>
References: <NFBBKDFGMKODILIOLBDHAEIBDBAA.davenport_michael@bah.com>
Subject: Re: [saag] Re:
Date: Thu, 30 May 2002 16:45:36 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Mike
I believe most big vendors are looking at it right now, see
http://www.omg.org
Ahmed
----- Original Message -----
From: "Davenport Michael" <davenport_michael@bah.com>
To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
Sent: Thursday, May 30, 2002 4:16 PM
Subject: RE: [saag] Re:
> Ahmed:
>
> I never heard of COBRA routers. Do you have info or a link I can go to?
> Sounds interesting....
>
> v/r,
>
> Mike
>
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Prof. Ahmed Bin Abbas
> Ahmed Ali Adas
> Sent: Wednesday, May 29, 2002 5:45 PM
> To: Hannes Tschofenig; Melinda Shore
> Cc: IPsec; Security_Area_Advisory_Group
> Subject: Re: [saag] Re:
>
>
> Hi
>
> The best approach in my view is to use CORBA and CORBsec to deal with path
> messages, I believe if CORBA routers can be realized very soon, most of
your
> IPsec shortcomings will be resolved.
>
> Ahmed
> ----- Original Message -----
> From: "Melinda Shore" <mshore@cisco.com>
> To: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
> Cc: "IPsec" <ipsec@lists.tislabs.com>; "Security_Area_Advisory_Group"
> <saag@mit.edu>
> Sent: Wednesday, May 29, 2002 5:06 PM
> Subject: RE: [saag] Re:
>
>
> > At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote:
> > >do you think that the hop-by-hop security in rsvp is a good or a bad
> thing?
> > >should there be more than what is currently provided?
> >
> > There needs to be more than what is currently provided,
> > but, as always, there's a big keying/cert problem, particularly
> > in a multi-"domain" environment. I don't think the threat
> > environment is particularly well-understood (I've seen your
> > NSIS draft but haven't gone through it in detail). Clearly
> > IPSec is not the right answer for Path messages, however,
> > because while the addressing is end-to-end the payload
> > contents do change as the packet transits participating
> > routers.
> >
> > Melinda
> >
>
From owner-ipsec@lists.tislabs.com Thu May 30 08:03:47 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UF3k105358;
Thu, 30 May 2002 08:03:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14944
Thu, 30 May 2002 10:24:35 -0400 (EDT)
Message-ID: <000701c207e7$57562b60$2daafea9@amanda2>
From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
To: "Pete Chown" <Pete.Chown@skygate.co.uk>
Cc: <ipsec@lists.tislabs.com>
References: <5.1.0.14.0.20020529094532.00ab6b90@localhost><5.1.0.14.0.20020529100110.00aad1b0@localhost> <001501c2075a$0d1f4780$6540fea9@amanda2> <1022756199.6080.76.camel@hyena.skygate.co.uk>
Subject: Re: [saag] Re:
Date: Thu, 30 May 2002 17:32:53 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1256"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Pete
CORBASec standard to my knowledge has finished. Noting that CORBA-3
specification defines transport level firewalls, application level
firewalls, and most interesting GIOP. Transport level firewalls work at TCP
port 683 for IIOP and 684 for IIOP/SSL.
Ahmed
----- Original Message -----
From: "Pete Chown" <Pete.Chown@skygate.co.uk>
To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
Sent: Thursday, May 30, 2002 1:56 PM
Subject: Re: [saag] Re:
> Prof. Ahmed Bin Abbas Ahmed Ali Adas wrote:
>
> > The best approach in my view is to use CORBA and CORBsec to deal with
path
> > messages, I believe if CORBA routers can be realized very soon, most of
your
> > IPsec shortcomings will be resolved.
>
> Have they sorted out the firewall draft yet? Last time I looked they
> were still trying to solve this and other security related problems,
> because of difficulties with the architecture of IIOP.
>
> Also wasn't there a problem where CORBAsec progressed but some companion
> document didn't, meaning that CORBA security wasn't specified as
> completely as had been intended? (My memory's going, I can't remember
> exactly what happened -- sorry.)
>
> In a lot of ways I think GIOP is preferable to the XML-based encodings
> that have come more recently. XML is more verbose, and parsing it
> requires extra code. By contrast, GIOP's structure is very simple.
>
> Yet in spite of this, it is much easier to use SOAP or XML-RPC. I think
> there are two reasons. Firstly the lack of the firewall spec makes it
> very difficult to proxy. Secondly all the other security measures are
> very complicated and under-specified.
>
> --
> Pete
>
From owner-ipsec@lists.tislabs.com Thu May 30 08:48:17 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UFmGn10061;
Thu, 30 May 2002 08:48:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15070
Thu, 30 May 2002 10:54:56 -0400 (EDT)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869AD9@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" <alaadas@kaau.edu.sa>,
Davenport Michael <davenport_michael@bah.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: [saag] Re:
Date: Thu, 30 May 2002 08:08:49 -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
> Mike
>
> I believe most big vendors are looking at it right now, see
I don't. I know of more major platform vendors who are stating that they
have no intention of further work on CORBA than are platform members of OMG.
The only major companies with Platform membership of OMG at this stage are
Motorola, Rockwell Collins and DaimlerChrysler. These are not names I
usually associate with IP routing.
> The best approach in my view is to use CORBA and CORBsec to deal with path
> messages, I believe if CORBA routers can be realized very soon, most of
your
> IPsec shortcomings will be resolved.
How?
There are several companies that have built Web Services SOAP routers. It is
not immediately apparent to me how any of their products is relevant to this
problem.
The problem is essentially caused by the introduction of a feature that
requires a degree of trust in what is considered by the IPSEC threat model
to be an untrusted device.
I suspect that the QoS problem cannot be solved through application of the
end-to-end principle. This should not be a great suprise since the
end-to-end principle is a conclusion, not an axiom. Those that treat it as
an axiom are likely to get overly ideological about the issue.
The end-to-end argument was originally an argument about complexity.
Complexity is easier to manage at the edge of the network rather than the
middle. This morphed into a subtly different security argument that the
security context of a message should be managed 'end-to-end'. This is a
problematic argument since a transaction may have many messages and the
'ends' of the transaction may not align with the 'ends' of the constituent
messages.
While it is nice to build theoretical models in which the only trusted
parties are the end points, QoS inherently depends on the end points
trusting each of the intermediate routers to meet the necessary QoS
characteristic.
Furthermore the routers must trust the originator of any QoS messages since
otherwise a malicious user may perform a DoS attack against the entire
network by issuing bogus QoS reservation messages.
[Observation, QoS is not an issue if the network resources are not
constrained in some manner]
This latter problem indicates to me that it is not feasible to support QoS
on an unrestricted public network without some form of resource management
mechanism (probably related to monetary payment) to support it. What could
be a tricky problem of trust is thus simplified, instead of the hard problem
of 'is it Alice' we have the easier problem of 'can she pay'. The trust
relationships precisely align to the relationship between resource
allocators.
The resulting business models may or may not turn out to be 'all you can
eat'. I suspect however that some incentive is required.
This problem appears to me to require the following components:
1) Trustworthy routing information
2) Means by which a router may determine that a reservation message
is signed by a trustworthy actor.
3) Means by which a router may notify charging mechanism
The end-to-end principle indicates that the routers should certainly not be
performing heavyweight crypto.
The model I would favor would involve some form of bandwidth reservations
actor that can perform processing of the bandwidth reservation request then
issue RSVP messages tagged with MAC authenticators and Kerberos tickets for
each of the routers concerned.
Phill
From owner-ipsec@lists.tislabs.com Thu May 30 09:14:43 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UGEhn11241;
Thu, 30 May 2002 09:14:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15158
Thu, 30 May 2002 11:26:22 -0400 (EDT)
Message-ID: <000d01c207ef$e940a020$2daafea9@amanda2>
From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>,
"Davenport Michael" <davenport_michael@bah.com>
Cc: <ipsec@lists.tislabs.com>
References: <2F3EC696EAEED311BB2D009027C3F4F405869AD9@vhqpostal.verisign.com>
Subject: Re: [saag] Re:
Date: Thu, 30 May 2002 18:37:29 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Phillip
I believe that the CORBASec and SECIOP in its design offer features for
end-to-end message transit without you have to make various scenarios each
day of attacks on IPSec. You got to look into the protocol architecture to
realize that it is true a different ideology, but rather a sound one in my
view, instead of building upon the old tech of TCP/IP and Cryptology.
Looking at the ISO/OSI seven layers. CORBA/GIOP/IIOP/SECIOP can offer
features that are more modular and secure. I do not know why major IP
vendors abandoned CORBA, but look in the literature and you will find that
they might come back to it. My estimate is that they are worried about
investments in current products.
Ahmed
----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Prof. Ahmed Bin Abbas Ahmed Ali Adas'" <alaadas@kaau.edu.sa>;
"Davenport Michael" <davenport_michael@bah.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, May 30, 2002 6:08 PM
Subject: RE: [saag] Re:
>
> > Mike
> >
> > I believe most big vendors are looking at it right now, see
>
> I don't. I know of more major platform vendors who are stating that they
> have no intention of further work on CORBA than are platform members of
OMG.
> The only major companies with Platform membership of OMG at this stage are
> Motorola, Rockwell Collins and DaimlerChrysler. These are not names I
> usually associate with IP routing.
>
> > The best approach in my view is to use CORBA and CORBsec to deal with
path
> > messages, I believe if CORBA routers can be realized very soon, most of
> your
> > IPsec shortcomings will be resolved.
>
> How?
>
> There are several companies that have built Web Services SOAP routers. It
is
> not immediately apparent to me how any of their products is relevant to
this
> problem.
>
>
> The problem is essentially caused by the introduction of a feature that
> requires a degree of trust in what is considered by the IPSEC threat model
> to be an untrusted device.
>
> I suspect that the QoS problem cannot be solved through application of the
> end-to-end principle. This should not be a great suprise since the
> end-to-end principle is a conclusion, not an axiom. Those that treat it as
> an axiom are likely to get overly ideological about the issue.
>
> The end-to-end argument was originally an argument about complexity.
> Complexity is easier to manage at the edge of the network rather than the
> middle. This morphed into a subtly different security argument that the
> security context of a message should be managed 'end-to-end'. This is a
> problematic argument since a transaction may have many messages and the
> 'ends' of the transaction may not align with the 'ends' of the constituent
> messages.
>
> While it is nice to build theoretical models in which the only trusted
> parties are the end points, QoS inherently depends on the end points
> trusting each of the intermediate routers to meet the necessary QoS
> characteristic.
>
> Furthermore the routers must trust the originator of any QoS messages
since
> otherwise a malicious user may perform a DoS attack against the entire
> network by issuing bogus QoS reservation messages.
>
> [Observation, QoS is not an issue if the network resources are not
> constrained in some manner]
>
> This latter problem indicates to me that it is not feasible to support QoS
> on an unrestricted public network without some form of resource management
> mechanism (probably related to monetary payment) to support it. What could
> be a tricky problem of trust is thus simplified, instead of the hard
problem
> of 'is it Alice' we have the easier problem of 'can she pay'. The trust
> relationships precisely align to the relationship between resource
> allocators.
>
> The resulting business models may or may not turn out to be 'all you can
> eat'. I suspect however that some incentive is required.
>
>
> This problem appears to me to require the following components:
>
> 1) Trustworthy routing information
> 2) Means by which a router may determine that a reservation message
> is signed by a trustworthy actor.
> 3) Means by which a router may notify charging mechanism
>
> The end-to-end principle indicates that the routers should certainly not
be
> performing heavyweight crypto.
>
> The model I would favor would involve some form of bandwidth reservations
> actor that can perform processing of the bandwidth reservation request
then
> issue RSVP messages tagged with MAC authenticators and Kerberos tickets
for
> each of the routers concerned.
>
>
> Phill
From owner-ipsec@lists.tislabs.com Thu May 30 09:15:40 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UGFdn11279;
Thu, 30 May 2002 09:15:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15197
Thu, 30 May 2002 11:36:26 -0400 (EDT)
Date: Thu, 30 May 2002 11:48:40 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
Message-ID: <20020530154839.GA3903@think.thunk.org>
References: <E17AwhE-0000R4-00@think.thunk.org> <000b01c2028c$05da1310$bd6fe640@ca.alcatel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000b01c2028c$05da1310$bd6fe640@ca.alcatel.com>
User-Agent: Mutt/1.3.28i
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, May 23, 2002 at 02:59:51PM -0400, Andrew Krywaniuk wrote:
> This draft hasn't really been discussed on the list much. I guess people
> figure that "hey, it's just another crypto algorithm... there can't be
> anything controversial about it".
>
> The issue which Dave brought up at the meeting and which I sent to the
> authors is that XCBC-MAC skirts the "obvious" solution of prepending the
> length of the buffer to the hash input. There is an engineering tradeoff
> here, which is not mentioned in the draft.
>
> AES-XCBC-MAC:
> a) requires 384 bits of keymat
> b) does not require that the length of the message be pre-computed
>
> The "obvious" solution:
> a) requires 128 bits of keymat
> b) requires that the length of the message be pre-computed
>
> Clearly, issue (b) was an important motivation in the design of XCBC-MAC.
>
> My personal opinion is that this rationale makes sense, since key storage
> capacity is unlikely to be the limiting factor in the design of any future
> hardware. However, the tradeoff ought to at least be discussed on the list
> and acknowledged in the draft.
A week has gone by and there doesn't appear to have been any
discussion on this point which Andrew has raised. Does anybody think
that the extra use of keying material used by AES-XCBC-MAC is a
problem? We will assume that silence means people are OK with it as
it currently stands.
Andrew, how strongly do you feel about requesting the draft be
modified to include discussion of this tradeoff? I suspect that if
you contribute text to the document authors, it would probably
increase the likelihood that the draft will include discussion on this
point. :-)
- Ted
From owner-ipsec@lists.tislabs.com Fri May 31 00:16:48 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V7Gmg14412;
Fri, 31 May 2002 00:16:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16557
Fri, 31 May 2002 02:31:38 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "Michael Thomas" <mat@cisco.com>, "S. Felix Wu" <wu@cs.ucdavis.edu>
Cc: <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE: ipsec to secure rsvp
Date: Fri, 31 May 2002 08:49:05 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCEEMDEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
In-Reply-To: <15605.15926.912770.654169@thomasm-u1.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi mike!
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, May 29, 2002 10:47 PM
> To: S. Felix Wu
> Cc: Hannes Tschofenig; kumar_amara@yahoo.com; dong_wei@tsinghua.com;
> IPsec; Security_Area_Advisory_Group
> Subject: Re: ipsec to secure rsvp
>
>
> S. Felix Wu writes:
> > Therefore, (according to my old/dusty memory), Fred Baker's proposal
> > to secure RSVP is based on a key table and key ID to allow the next
> > hop trusted RSVP router to authenticate (HMAC fashion) the message
> > without prior seesion-key exchange.
>
> Right. There are two competing goals going on with
> RSVP in this respect: router alert as a discovery
> mechanism, and security desires which need to know
> the how to key the next hop integrity object. I
> don't really see how you reconcile that unless you
> have group keys on your integrity objects which
> makes me a little queasy.
i fully agree with you.
if you want to use protection based on symmetric cryptography then you first
must learn the identity of the node to whom you want to authenticate to.
(and the keys need to be in place).
with public key cryptography things are somewhat different. but from a
pratical perspective it does not provide the necessary performance. i guess
you can agree with me on this issue.
>
> Mike
ciao
hannes
From owner-ipsec@lists.tislabs.com Fri May 31 00:16:48 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V7Gmg14411;
Fri, 31 May 2002 00:16:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16558
Fri, 31 May 2002 02:31:39 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "S. Felix Wu" <wu@cs.ucdavis.edu>, <kumar_amara@yahoo.com>,
<dong_wei@tsinghua.com>, "IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE: ipsec to secure rsvp
Date: Fri, 31 May 2002 08:49:06 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCIEMDEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
In-Reply-To: <3CF50554.4B48FA53@cs.ucdavis.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi felix!
> -----Original Message-----
> From: S. Felix Wu [mailto:wu@cs.ucdavis.edu]
> Sent: Wednesday, May 29, 2002 6:44 PM
> To: Hannes Tschofenig; kumar_amara@yahoo.com; dong_wei@tsinghua.com;
> IPsec; Security_Area_Advisory_Group
> Subject: Re: ipsec to secure rsvp
>
>
>
> The tricky part (my personal opinion) is that, using IPSec, you
> must know the other endpoint's IP address to establish the SA in
> the first place. According to my understanding, at least in general,
> in RSVP, you do NOT know the next hop RSVP router's IP address in
> path finding messages (I assume that not every Internet router will
> support RSVP), and sometimes route path might change unpredictably.
true - rsvp does not describe how to learn the identity of the next rsvp
aware next hop (i think it the documents say something like 'by other
means...'). this information needs to be available otherwise the integrity
object cannot be added.
>
> Therefore, (according to my old/dusty memory), Fred Baker's proposal
> to secure RSVP is based on a key table and key ID to allow the next
> hop trusted RSVP router to authenticate (HMAC fashion) the message
> without prior seesion-key exchange.
that is not going to work. maybe he said something more.
>
> I have admitted that I haven't followed the thread of progress in
> RSVP security for a while, so maybe things have been changed.
there has not been a discussion as far as i remember.
ciao
hannes
>
> -Felix
>
>
>
> Hannes Tschofenig wrote:
> >
> > hi
> >
> > there is no reason why not to use ipsec to secure rsvp.
> especially in the
> > core network (between routers) this might be a reasonable
> approach. using
> > ipsec to secure the traffic between the application (end-host)
> and the first
> > hop router is however more difficult.
> >
> > ciao
> > hannes
> >
> > > -----Original Message-----
> > > From: owner-ipsec@lists.tislabs.com
> > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of SatishK Amara
> > > Sent: Friday, May 24, 2002 4:37 PM
> > > To: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group
> > > Subject: Re:
> > >
> > >
> > > Why don't you use IPSEC to secure RSVP.
> > >
> > > Satish Amara
> > > --- Dong <dong_wei@tsinghua.com> wrote:
> > > > Roy,
> > > >
> > > > I just read a paper "Preventing Denial of Service
> > > > Attacks on Quality of Service", which is written by
> > > > some guys from N.C. State university and UC Davis.
> > > > The service quality to legimative users could be
> > > > degraded by attacks on control flow or data flow.
> > > > For example, an illegal user can forge a reservation
> > > > message, so he can receive an unauthorized amount of
> > > > resources. I just wanna to know what threats exist
> > > > in providing QoS, and what the state-of-art
> > > > techniques to prevent, detect and counter those
> > > > attacks, and of course recovery mothods as well.
> > > >
> > > > Thx a lot.
> > > >
> > > > Dong
> > > >
> > > >
> > > > Dong,
> > > > Please be a little more precise in what you are
> > > > asking for, i.e.
> > > >
> > > > 3-5 bullet list items on what kind of security you
> > > > seek.
> > > >
> > > > Roy
> > > >
> > > > -----Original Message-----
> > > > From: Dong [mailto:dong_wei@tsinghua.com]
> > > > Sent: Thursday, May 23, 2002 2:05 PM
> > > > To: Security_Area_Advisory_Group; IPsec
> > > > Subject: Secure QoS
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I am trying to do a survey on Secure QoS. Any paper
> > > > on that? Thx.
> > > >
> > > > Dong
> > > >
> > > >
> > > _____________________________________________________________
> > > > Get Tsinghua University free email account:
> > > > www.tsinghua.com
> > > > Web site sponsored and hosted by AtFreeWeb.com
> > > >
> > > >
> > > >
> > > >
> > > _____________________________________________________________
> > > > Get Tsinghua University free email account:
> > > > www.tsinghua.com
> > > > Web site sponsored and hosted by AtFreeWeb.com
> > > >
> > > >
> > > _____________________________________________________________
> > > > Promote your group and strengthen ties to your
> > > > members with email@yourgroup.org by Everyone.net
> > > http://www.everyone.net/?btn=tag
> > >
> > >
> > > =====
> > > In natural science, Nature has given us a world and we're just to
> > > discover its laws. In computers, we can stuff laws into it and
> > > create a world -- Alan Kay
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > LAUNCH - Your Yahoo! Music Experience
> > > http://launch.yahoo.com
>
> --
> ----------------------------------------------------------------------
> Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu
> Associate Professor http://www.cs.ucdavis.edu/~wu
> Computer Science Department office: 1-530-754-7070
> University of California at Davis fax: 1-530-752-4767
> ----------------------------------------------------------------------
From owner-ipsec@lists.tislabs.com Fri May 31 00:21:44 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V7Lhg15344;
Fri, 31 May 2002 00:21:44 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16555
Fri, 31 May 2002 02:31:35 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "Michael Thomas" <mat@cisco.com>, "Derek Atkins" <derek@ihtfp.com>
Cc: "SatishK Amara" <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE: IPsec and RSVP
Date: Fri, 31 May 2002 08:49:06 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCKEMDEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
In-Reply-To: <15604.64389.520614.112373@thomasm-u1.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi derek!
> Derek,
>
> There are two different forms of crypto needed for
> RSVP: a hop-by-hop integrity object and a policy
> object.
true. the policy object can additionally contain a integrity object
(together with the other credentials there).
> IPsec could in theory replace the
> integrity object, but cannot replace the policy
> object. Considering that there is no key
> distribution for the hop-by-hop integrity objects,
> IPsec might not be a bad choice in some
> situations.
>
> Mike
From owner-ipsec@lists.tislabs.com Fri May 31 00:24:23 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V7ONg15888;
Fri, 31 May 2002 00:24:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16556
Fri, 31 May 2002 02:31:38 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "S. Felix Wu" <wu@cs.ucdavis.edu>
Cc: "Derek Atkins" <warlord@mit.edu>, "SatishK Amara" <kumar_amara@yahoo.com>,
<dong_wei@tsinghua.com>, "IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>
Subject: RE:
Date: Fri, 31 May 2002 08:49:05 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCGEMDEHAA.Hannes.Tschofenig@mchp.siemens.de>
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.2910.0)
In-Reply-To: <3CF509D5.C0530394@cs.ucdavis.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi felix!
>
>
> It depends on what are the security requirements and threats.
yes, this is always true. when looking at the threats for a qos signling
protocol it had two problems:
a) why do you really need end-to-end security if the protocol operates in a
hop-by-hop manner. i understand if someone mentiones the accounting issues
(who pays for what). but it is strange to introduce them all into a qos
signaling protocol since there are other protocols that have to executed
first in a typical application (i.e. rsvp or other qos signaling protocols
will not be send between the two endpoints without running other protocols
too - if used for end-to-end qos signaling).
b) the threat about a malicous qos (rsvp) aware node.
if an adversary manages to hack into a aaa, sip, etc. network element then
he is obviously able to do many actions. why should this be different for
rsvp (or other qos signaling protocols)? if an adversary is able to hack
into the pdp, into an edge router, etc. then he is able to mount all types
of attacks. who should this be prevented?
the only difference between rsvp and for example aaa or sip is the possibly
large number of nodes involved in the qos signaling. there is however an
architectural question whether this is really necessary/practical since
there are extensions that suggest that only the access network should store
per-flow information (i.e. run rsvp) and the core networks have aggregated
flows (trunks) for example based on diffserv. hence in practice the number
of nodes is not as large as it might look at the first sight.
additionally there is a strong desire to keep the latency (and bandwidth
consumption with signaling) low.
> In my opinion, RSVP security is really neither hop-by-hop nor
> end-to-end (or I should say it is a mixture of both).
it is definitely not end-to-end. with hop-by-hop you are right since there
are two integrity objects: one within the rsvp message part of the message
and the other one in the policy object. additionally there are credentials
in the policy object. furtheremore there are policy aware and policy unaware
nodes.
>
> Certain fields in RSVP are "mutable" (for example, maximum
> available bandwidth along the route path), and therefore, a
> pure end-to-end will not be possible. On the other hand, if
> we assume (i.e., our threat model) that an intermediate RSVP
> router (on the route path) can be malicious, then you need
> some forms of end-to-end to protect at least those "static"
> fields in an end-to-end fashion.
i agree with you. rsvp has mutable and non-mutable fields but they are not
labled as such (or there is no separation between mutable and non-mutalbe
fields). hence it is difficult to simply protect them by adding an other
"end-to-end integrity-object". additionally with this approach you obviously
introduce key management protocols which might be not too easy to solve
(establishing security associations between two arbitrary nodes turned out
to be difficult lacking a global pki, or aaa/kerberos, etc. infrastructure.
if some other protocols are executed before rsvp starts ( these protocols
have already allowed to figure out who will pay for what) then these
credentials (i call it opaque token) only need to be included into rsvp
without a need to add end-to-end security issues into rsvp itself and allow
other protocols to do that (e.g. sip). there is obviously a need to have a
interaction with other protocols including diameter (aaa in general) since
accounting records need to be produced and transmitted to the appropriate
locations.
>
> My students and I studied this problem a few years ago and the
> following is a web link to our paper:
>
> http://arqos.csc.ncsu.edu/papers/1999_10_iwqos99.pdf
>
> This work is somewhat old, but hopefully it will provide some
> information about the technical difficulties in dealing with
> RSVP security.
thanks. i read it some time ago. i do not remember it exactly but i think
you did not propose to use end-to-end security - it was more like a network
to network hop security using digital signatures.
ciao
hannes
> -Felix
>
>
> Hannes Tschofenig wrote:
> >
> > hi
> >
> > what speaks against applying ipsec hop-by-hop (whereby a hop is a rsvp
> > capable router)?
> >
> > ciao
> > hannes
> >
> > > -----Original Message-----
> > > From: owner-ipsec@lists.tislabs.com
> > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins
> > > Sent: Saturday, May 25, 2002 5:01 AM
> > > To: SatishK Amara
> > > Cc: dong_wei@tsinghua.com; IPsec; Security_Area_Advisory_Group
> > > Subject: Re:
> > >
> > >
> > > Because IPsec is hop-by-hop but you want RSVP end-to-end.
> > >
> > > -derek
> > >
> > > SatishK Amara <kumar_amara@yahoo.com> writes:
> > >
> > > > Why don't you use IPSEC to secure RSVP.
> > > >
> > > > Satish Amara
> > > > --- Dong <dong_wei@tsinghua.com> wrote:
> > > > > Roy,
> > > > >
> > > > > I just read a paper "Preventing Denial of Service
> > > > > Attacks on Quality of Service", which is written by
> > > > > some guys from N.C. State university and UC Davis.
> > > > > The service quality to legimative users could be
> > > > > degraded by attacks on control flow or data flow.
> > > > > For example, an illegal user can forge a reservation
> > > > > message, so he can receive an unauthorized amount of
> > > > > resources. I just wanna to know what threats exist
> > > > > in providing QoS, and what the state-of-art
> > > > > techniques to prevent, detect and counter those
> > > > > attacks, and of course recovery mothods as well.
> > > > >
> > > > > Thx a lot.
> > > > >
> > > > > Dong
> > > > >
> > > > >
> > > > > Dong,
> > > > > Please be a little more precise in what you are
> > > > > asking for, i.e.
> > > > >
> > > > > 3-5 bullet list items on what kind of security you
> > > > > seek.
> > > > >
> > > > > Roy
> > > > >
> > > > > -----Original Message-----
> > > > > From: Dong [mailto:dong_wei@tsinghua.com]
> > > > > Sent: Thursday, May 23, 2002 2:05 PM
> > > > > To: Security_Area_Advisory_Group; IPsec
> > > > > Subject: Secure QoS
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I am trying to do a survey on Secure QoS. Any paper
> > > > > on that? Thx.
> > > > >
> > > > > Dong
> > > > >
> > > > >
> > > > _____________________________________________________________
> > > > > Get Tsinghua University free email account:
> > > > > www.tsinghua.com
> > > > > Web site sponsored and hosted by AtFreeWeb.com
> > > > >
> > > > >
> > > > >
> > > > >
> > > > _____________________________________________________________
> > > > > Get Tsinghua University free email account:
> > > > > www.tsinghua.com
> > > > > Web site sponsored and hosted by AtFreeWeb.com
> > > > >
> > > > >
> > > > _____________________________________________________________
> > > > > Promote your group and strengthen ties to your
> > > > > members with email@yourgroup.org by Everyone.net
> > > > http://www.everyone.net/?btn=tag
> > > >
> > > >
> > > > =====
> > > > In natural science, Nature has given us a world and we're just
> > > to discover its laws. In computers, we can stuff laws into it and
> > > create a world -- Alan Kay
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > LAUNCH - Your Yahoo! Music Experience
> > > > http://launch.yahoo.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
>
> --
> ----------------------------------------------------------------------
> Dr. S. (Shyhtsun) Felix Wu wu@cs.ucdavis.edu
> Associate Professor http://www.cs.ucdavis.edu/~wu
> Computer Science Department office: 1-530-754-7070
> University of California at Davis fax: 1-530-752-4767
> ----------------------------------------------------------------------
From owner-ipsec@lists.tislabs.com Fri May 31 00:24:23 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V7ONg15889;
Fri, 31 May 2002 00:24:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16588
Fri, 31 May 2002 02:39:37 -0400 (EDT)
From: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
To: "SatishK Amara" <kumar_amara@yahoo.com>, <dong_wei@tsinghua.com>,
"IPsec" <ipsec@lists.tislabs.com>,
"Security_Area_Advisory_Group" <saag@mit.edu>,
"Michael Thomas" <mat@cisco.com>, "Derek Atkins" <derek@ihtfp.com>
Subject: end-to-end security and proxy rsvp
Date: Fri, 31 May 2002 08:49:00 +0200
Message-ID: <BIEMJDFDALACOIGHKCHCCEMDEHAA.Hannes.Tschofenig@mchp.siemens.de>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi
from the previous mails i read that some of you would like to see end-to-end
security in a qos signaling protocol. i don't know how many of you have read
the draft about proxy rsvp where a node along the path simply acts on behalf
of an end-node. if using end-to-end security within rsvp then the proxy rsvp
case is quite difficult in the sense that the other end-host (although
possibly not rsvp capable) has to transmit credentials to (an possibly
unknown) rsvp proxy to let him act on his behalf.
what do you think? is there a security problem with the proxy rsvp approach?
see draft: draft-ietf-rsvp-proxy-03.txt
(there might also be similar issues related to the draft localized rsvp
draft-manner-lrsvp-00.txt which also uses proxy ideas).
ciao
hannes
From owner-ipsec@lists.tislabs.com Fri May 31 01:42:17 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V8gHg26434;
Fri, 31 May 2002 01:42:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA16840
Fri, 31 May 2002 03:57:20 -0400 (EDT)
MBOX-Line: From owner-ipsec@lists.tislabs.com Thu May 30 15:52:26 2002
Message-ID: <000a01c207e0$4839a000$2daafea9@amanda2>
From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
To: "Davenport Michael" <davenport_michael@bah.com>
Cc: <ipsec@lists.tislabs.com>
References: <NFBBKDFGMKODILIOLBDHAEIBDBAA.davenport_michael@bah.com>
Subject: Re: [saag] Re:
Date: Thu, 30 May 2002 16:45:36 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Mike
I believe most big vendors are looking at it right now, see
http://www.omg.org
Ahmed
----- Original Message -----
From: "Davenport Michael" <davenport_michael@bah.com>
To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
Sent: Thursday, May 30, 2002 4:16 PM
Subject: RE: [saag] Re:
> Ahmed:
>
> I never heard of COBRA routers. Do you have info or a link I can go to?
> Sounds interesting....
>
> v/r,
>
> Mike
>
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Prof. Ahmed Bin Abbas
> Ahmed Ali Adas
> Sent: Wednesday, May 29, 2002 5:45 PM
> To: Hannes Tschofenig; Melinda Shore
> Cc: IPsec; Security_Area_Advisory_Group
> Subject: Re: [saag] Re:
>
>
> Hi
>
> The best approach in my view is to use CORBA and CORBsec to deal with path
> messages, I believe if CORBA routers can be realized very soon, most of
your
> IPsec shortcomings will be resolved.
>
> Ahmed
> ----- Original Message -----
> From: "Melinda Shore" <mshore@cisco.com>
> To: "Hannes Tschofenig" <Hannes.Tschofenig@mchp.siemens.de>
> Cc: "IPsec" <ipsec@lists.tislabs.com>; "Security_Area_Advisory_Group"
> <saag@mit.edu>
> Sent: Wednesday, May 29, 2002 5:06 PM
> Subject: RE: [saag] Re:
>
>
> > At 03:59 PM 5/29/02 +0200, Hannes Tschofenig wrote:
> > >do you think that the hop-by-hop security in rsvp is a good or a bad
> thing?
> > >should there be more than what is currently provided?
> >
> > There needs to be more than what is currently provided,
> > but, as always, there's a big keying/cert problem, particularly
> > in a multi-"domain" environment. I don't think the threat
> > environment is particularly well-understood (I've seen your
> > NSIS draft but haven't gone through it in detail). Clearly
> > IPSec is not the right answer for Path messages, however,
> > because while the addressing is end-to-end the payload
> > contents do change as the packet transits participating
> > routers.
> >
> > Melinda
> >
>
From owner-ipsec@lists.tislabs.com Fri May 31 08:34:25 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VFYPg25286;
Fri, 31 May 2002 08:34:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17582
Fri, 31 May 2002 10:35:28 -0400 (EDT)
From: "David A. Mcgrew" <mcgrew@cisco.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
"Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
Date: Fri, 31 May 2002 07:47:46 -0700
Message-ID: <FPELKLHKCBJLMMMNOGDFGEMLDEAA.mcgrew@cisco.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.2910.0)
In-Reply-To: <20020530154839.GA3903@think.thunk.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ted, Andrew,
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o
> Sent: Thursday, May 30, 2002 8:49 AM
> To: Andrew Krywaniuk
> Cc: ipsec@lists.tislabs.com
> Subject: Re: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
>
>
> On Thu, May 23, 2002 at 02:59:51PM -0400, Andrew Krywaniuk wrote:
> > This draft hasn't really been discussed on the list much. I guess people
> > figure that "hey, it's just another crypto algorithm... there can't be
> > anything controversial about it".
> >
> > The issue which Dave brought up at the meeting and which I sent to the
> > authors is that XCBC-MAC skirts the "obvious" solution of prepending the
> > length of the buffer to the hash input. There is an engineering tradeoff
> > here, which is not mentioned in the draft.
> >
> > AES-XCBC-MAC:
> > a) requires 384 bits of keymat
> > b) does not require that the length of the message be pre-computed
> >
> > The "obvious" solution:
> > a) requires 128 bits of keymat
> > b) requires that the length of the message be pre-computed
> >
> > Clearly, issue (b) was an important motivation in the design of
> XCBC-MAC.
> >
> > My personal opinion is that this rationale makes sense, since
> key storage
> > capacity is unlikely to be the limiting factor in the design of
> any future
> > hardware. However, the tradeoff ought to at least be discussed
> on the list
> > and acknowledged in the draft.
>
> A week has gone by and there doesn't appear to have been any
> discussion on this point which Andrew has raised. Does anybody think
> that the extra use of keying material used by AES-XCBC-MAC is a
> problem? We will assume that silence means people are OK with it as
> it currently stands.
I agree with Andrew on this point (and was on vacation for the last week
:-). IMO it makes sense for the WG to record that kind of rationale, and
the draft is the natural place to do that.
As for the tradeoff, XCBC-MAC seems like a fine choice to me, though
hardware vendors may not like the increased memory requirement.
David
>
> Andrew, how strongly do you feel about requesting the draft be
> modified to include discussion of this tradeoff? I suspect that if
> you contribute text to the document authors, it would probably
> increase the likelihood that the draft will include discussion on this
> point. :-)
>
> - Ted
From owner-ipsec@lists.tislabs.com Fri May 31 10:23:36 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VHNag02010;
Fri, 31 May 2002 10:23:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17809
Fri, 31 May 2002 12:25:08 -0400 (EDT)
Reply-To: <jharwood@vesta-corp.com>
From: "Joseph D. Harwood" <jharwood@vesta-corp.com>
To: "'David A. Mcgrew'" <mcgrew@cisco.com>, "'Theodore Ts'o'" <tytso@mit.edu>,
"'Andrew Krywaniuk'" <andrew.krywaniuk@alcatel.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
Date: Fri, 31 May 2002 09:37:37 -0700
Organization: Vesta Corporation
Message-ID: <001101c208c1$79e471c0$beb9fea9@Yellowstone>
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, Build 10.0.3416
In-Reply-To: <FPELKLHKCBJLMMMNOGDFGEMLDEAA.mcgrew@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-Loop-Detect: 1
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The increased amount of memory is one consideration; another is the
increased memory bandwidth. My estimate is that storing three keys
instead of storing just one key will add about 10% to the memory
bandwidth for SA accesses. But you also have the option of storing just
the original key and generating K1, K2, and K3 on the fly. With proper
pipelining it will affect latency but not throughput. So another
trade-off is (amount of memory, memory bandwidth) vs. (number of gates).
Best Regards,
Joseph D. Harwood
(408) 838-9434
jharwood@vesta-corp.com
www.vesta-corp.com
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]
> On Behalf Of David A. Mcgrew
> Sent: Friday, May 31, 2002 7:48 AM
> To: Theodore Ts'o; Andrew Krywaniuk
> Cc: ipsec@lists.tislabs.com
> Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
>
> Ted, Andrew,
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o
> > Sent: Thursday, May 30, 2002 8:49 AM
> > To: Andrew Krywaniuk
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
> >
> >
> > On Thu, May 23, 2002 at 02:59:51PM -0400, Andrew Krywaniuk wrote:
> > > This draft hasn't really been discussed on the list much. I guess
> people
> > > figure that "hey, it's just another crypto algorithm... there
can't be
> > > anything controversial about it".
> > >
> > > The issue which Dave brought up at the meeting and which I sent to
the
> > > authors is that XCBC-MAC skirts the "obvious" solution of
prepending
> the
> > > length of the buffer to the hash input. There is an engineering
> tradeoff
> > > here, which is not mentioned in the draft.
> > >
> > > AES-XCBC-MAC:
> > > a) requires 384 bits of keymat
> > > b) does not require that the length of the message be pre-computed
> > >
> > > The "obvious" solution:
> > > a) requires 128 bits of keymat
> > > b) requires that the length of the message be pre-computed
> > >
> > > Clearly, issue (b) was an important motivation in the design of
> > XCBC-MAC.
> > >
> > > My personal opinion is that this rationale makes sense, since
> > key storage
> > > capacity is unlikely to be the limiting factor in the design of
> > any future
> > > hardware. However, the tradeoff ought to at least be discussed
> > on the list
> > > and acknowledged in the draft.
> >
> > A week has gone by and there doesn't appear to have been any
> > discussion on this point which Andrew has raised. Does anybody
think
> > that the extra use of keying material used by AES-XCBC-MAC is a
> > problem? We will assume that silence means people are OK with it as
> > it currently stands.
>
> I agree with Andrew on this point (and was on vacation for the last
week
> :-). IMO it makes sense for the WG to record that kind of rationale,
and
> the draft is the natural place to do that.
>
> As for the tradeoff, XCBC-MAC seems like a fine choice to me, though
> hardware vendors may not like the increased memory requirement.
>
> David
>
> >
> > Andrew, how strongly do you feel about requesting the draft be
> > modified to include discussion of this tradeoff? I suspect that if
> > you contribute text to the document authors, it would probably
> > increase the likelihood that the draft will include discussion on
this
> > point. :-)
> >
> > - Ted
From owner-ipsec@lists.tislabs.com Fri May 31 11:43:29 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VIhSg05193;
Fri, 31 May 2002 11:43:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18027
Fri, 31 May 2002 13:51:51 -0400 (EDT)
Date: 31 May 2002 13:52:59 -0400
Message-ID: <001c01c208cc$01eaa260$696ae640@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: "'=SMTP" <tytso@mit.edu'>
Cc: "'=SMTP" <ipsec@lists.tislabs.com'>
Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
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: <20020530154839.GA3903@think.thunk.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> A week has gone by and there doesn't appear to have been any
> discussion on this point which Andrew has raised. Does anybody think
> that the extra use of keying material used by AES-XCBC-MAC is a
> problem? We will assume that silence means people are OK with it as
> it currently stands.
Okay, so either everyone agrees with the design decision or no one cares. On
this list, it's usually best to assume the latter.
> Andrew, how strongly do you feel about requesting the draft be
> modified to include discussion of this tradeoff? I suspect that if
> you contribute text to the document authors, it would probably
> increase the likelihood that the draft will include discussion on this
> point. :-)
I'm not fanatical about this particular issue, but I think that many drafts
could benefit from some explanation of the design rationale. This may save
us a bunch of redundant questions on the mailing list 2 years from now (the
downside being that vague drafts may be more likely to progress to RFC if no
one can find anything concrete to object to).
XCBC-MAC does not appear to be controversial, so it would be better to
document the design decision, especially since the crucial reference in the
draft [XCBC-MAC-1] is a broken link. I already suggested this to the authors
by private e-mail some time back. It could be as simple as a 2 sentence
add-on:
AES-XCBC-MAC-96 actually requires 384 bits of keying material (128
bits for the AES keysize + 2 times the blocksize). This keying mate-
rial can either be provided through the key generation mechanism or
it can be generated from a single 128-bit key. The latter approach
has been selected for AES-XCBC-MAC-96, since it is analogous to other
authenticators used within IPsec.
"The reason XCBC-MAC uses 3 keys is so the length of the input stream does
not need to be known in advance. This may be useful for systems that do
one-pass assembly of large packets."
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso@mit.edu]
> Sent: Thursday, May 30, 2002 11:49 AM
> To: Andrew Krywaniuk
> Cc: ipsec@lists.tislabs.com
> Subject: Re: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
>
>
> On Thu, May 23, 2002 at 02:59:51PM -0400, Andrew Krywaniuk wrote:
> > This draft hasn't really been discussed on the list much. I
> guess people
> > figure that "hey, it's just another crypto algorithm...
> there can't be
> > anything controversial about it".
> >
> > The issue which Dave brought up at the meeting and which I
> sent to the
> > authors is that XCBC-MAC skirts the "obvious" solution of
> prepending the
> > length of the buffer to the hash input. There is an
> engineering tradeoff
> > here, which is not mentioned in the draft.
> >
> > AES-XCBC-MAC:
> > a) requires 384 bits of keymat
> > b) does not require that the length of the message be pre-computed
> >
> > The "obvious" solution:
> > a) requires 128 bits of keymat
> > b) requires that the length of the message be pre-computed
> >
> > Clearly, issue (b) was an important motivation in the
> design of XCBC-MAC.
> >
> > My personal opinion is that this rationale makes sense,
> since key storage
> > capacity is unlikely to be the limiting factor in the
> design of any future
> > hardware. However, the tradeoff ought to at least be
> discussed on the list
> > and acknowledged in the draft.
>
> A week has gone by and there doesn't appear to have been any
> discussion on this point which Andrew has raised. Does anybody think
> that the extra use of keying material used by AES-XCBC-MAC is a
> problem? We will assume that silence means people are OK with it as
> it currently stands.
>
> Andrew, how strongly do you feel about requesting the draft be
> modified to include discussion of this tradeoff? I suspect that if
> you contribute text to the document authors, it would probably
> increase the likelihood that the draft will include discussion on this
> point. :-)
>
> - Ted
>
From owner-ipsec@lists.tislabs.com Fri May 31 15:54:45 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VMsjg11734;
Fri, 31 May 2002 15:54:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18332
Fri, 31 May 2002 18:07:40 -0400 (EDT)
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD0174A7C3@mailserver.sylantro.com>
From: "Eric Nielsen" <Eric.Nielsen@sylantro.com>
To: ipsec@lists.tislabs.com
Subject: Public Keys to initiate IPsec.
Date: Fri, 31 May 2002 15:14:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 10E92A45557198-01-01
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I have been listening in on the IPsec discussion (as best as I can) for
some time, but I am sure my question/suggestion will show naivety to
many aspects of IPsec, but I must ask.
I am having trouble deciphering IPsec to determine the best way to
deploy it in large scale. I have an idea of how it might work and would
like to test these ideas out, or at least set me straight so I can find
the best way to move forward deploying IPsec based security.
IPsec communications work well once setup. But key and session management
is less straightforward. IKE, JFK, and IKEv2 provide means to bootstrap
the process of setting up a secure connection, but I worry about the
potential performance impacts of thousands of simultaneous restarts when
a server recovers. Administration must be minimized, too.
The deployment in mind has
* > 10,000 clients to a server.
* The clients are small, embedded systems
* Can make restriction that secure connections are always initiated by
the client
* A trust relationship will persist with that client unless some
administrative action is taken to remove that trust.
* Will use Transport mode AH
I would like some level of trust to persist beyond one point in time, or
to be distributed among servers. I have focused on performing the IKE
Phase 1 negotiations faster and simpler to administer: IKE Phase 1
negotiations include:
- negotiation of security parameters
- establish a shared secret
- authenticate identities.
Here is a process that I think might perform that work.
=======================================================================
Step 1:
Before setting up the network connection both sides would be
provided a human password grade shared secret key, one that non-
technical people will not fear or mis-type. This is outside of IPsec.
Step 2:
To initiate the process of creating a secure communication path,
the embedded unit would generate a large private/public key pair (e.g.,
RSA with at minimum 1028 bits). [an issue here is key randomness].
Step 3:
One end point will contact the other with negotiation parameters.
In addition to the already defined parameters, that (big) packet would
include:
- the endpoint's public key
- an [optional] endpoint identifier
- a signature that covers the public key, endpoint ID, and private
shared password.
The receiver will first validate the ID (it any) for:
a) is the ID one that the server will service?
b) is the ID is valid still for first-time initiation of a secure
relationship?
After this simple validation the receiver could then do the more
processor intensive work validating the signature in the negotiation
request. If the receiver does not include this capability, it will
ignore these negotiation parameters and proceed down another path.
Step 4:
A response is crafted that selects this type of negotiation. The
response includes the public key signed in the same way as in step 2.
Upon completion of Step 4 the two ends have authenticated, authorized,
and have securely exchanged public keys. It looks like the two ends are
ready for Phase 2 to create/share session keys. They may be symmetric
keys for ESP or a private/public key pair for AH.
Beyond Initialization:
It would be best if the Phase 1 public keys were durable, being
renegotiated only on an as needed basis. Phase 1 negotiations should
persist past IP address changes. Each end can attempt to re-initiate
Phase 1 to create a new durable public/private key pair. Each new key
requires a signature using the prior durable key. Either end can refuse
the update by policy, and then have the option to terminate the trust
relationship, thus requiring a new password to start the initialization
process from square one.
This Phase 1 negotiated information may be shared among servers to
assure smooth disaster recovery. Upon recovery the server receiving
IPsec packets would reply that the session has expired and then recreate
only the Phase 2 exchange.
========================================================================
All that said, is there a streamlined process like this I can implement
within IPsec/IKE/IKEv2/JFK today? Are there key differences or security
holes that may or may not make it possible to use this kind of process?
Thank you for your attention,
Eric
Eric Nielsen
Chief Technology Strategist
Sylantro Systems Corporation http://www.sylantro.com
910 E. Hamilton Ave.
Campbell, CA 95008 USA
+1.408.626.2345
From owner-ipsec@lists.tislabs.com Fri May 31 20:52:01 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id g513q1g16253;
Fri, 31 May 2002 20:52:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA18701
Fri, 31 May 2002 23:05:15 -0400 (EDT)
Message-ID: <08a101c2091b$0281c060$1f02a8c0@entrust.com>
From: "Greg Carter" <greg@carter-engineering.com>
To: <ipsec@lists.tislabs.com>
References: <79FEAA5FABA7D411BF580001023D1BBD0174A7C3@mailserver.sylantro.com>
Subject: Re: Public Keys to initiate IPsec.
Date: Fri, 31 May 2002 23:18:32 -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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
----- Original Message -----
From: "Eric Nielsen" <Eric.Nielsen@sylantro.com>
Subject: Public Keys to initiate IPsec.
>They may be symmetric keys for ESP or a private/public key pair for AH.
AH uses symmetric based cryptography.
> ========================================================================
> All that said, is there a streamlined process like this I can implement
> within IPsec/IKE/IKEv2/JFK today?
Not really, at least not in IKE v1.
>Are there key differences or security
> holes that may or may not make it possible to use this kind of process?
What you have describe as your phase one is in essence a PKI and enrolling a
client into that PKI with the one time password. IKE assumes that you
already have the trust relationship in place, either through a shared key or
via a certified public key. All(!)you are doing in IKE is verifying the
identity, you are not managing the identities credentials within your trust
'hierarchy'. Combining the two operations would unnecessarily complicate
IKE.
Check out the PKIX working group, specifically RFC 2510, and/or RFC 2797.
But I would look into finding more about SCEP before implementing 2797 if
you want an "on line" enrolment protocol.
Bye.
Greg.