From owner-ipsec@lists.tislabs.com Fri Nov 1 08:09: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 gA1G9DW08120;
Fri, 1 Nov 2002 08:09:13 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14070
Fri, 1 Nov 2002 10:27:03 -0500 (EST)
From: Charlie_Kaufman@notesdev.ibm.com
Subject: Re: A question about traffic selector
To: wmyking49@yahoo.com.cn
Cc: ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002
Message-ID: <OFF70DD71F.85B2ED83-ON85256C64.00504BC2-85256C64.0052C46E@iris.com>
Date: Fri, 1 Nov 2002 10:04:02 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/01/2002
10:27:11 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
<wmyking49@yahoo.com.cn> wrote:
> I read the doc draft-ietf-ipsec-ikev2-03.txt, and i'm
> confused by the description about traffic selector.
> The follow is in 4.9:
> It is possible for the Responder's policy to contain
> multiple smaller ranges, all encompassed by the
> Initiator's traffic selector, and with the Responder's
> policy being that each of those ranges should be sent
> over a different SA. Continuing the example above, Bob
> might have a policy of being willing to tunnel those
> addresses to and from Alice, but might require that
> each address pair be on a separately negotiated
> child-SA. If Alice generated her request in response
> to an incoming packet from 10.2.16.43 to 18.16.2.123,
> there would be no way for Bob to determine which pair
> of addresses it is most urgent to tunnel, and he
> would have to make his best guess or reject the
> request with a status of SINGLE-PAIR-REQUIRED.
>
> 1.What is it means that "might require that each
> address pair be on a separately negotiated child-SA"?
> If is the "each address pair" imply a pair of a single
> address, such as 10.2.16.43 and 18.16.2.123?
Yes. The current RFC on the configuration database for
IPsec says that an endpoint may have a policy that each
pair of tunnelled addresses gets it's own SA. This means
a <source, destination> pair of individual IP addresses.
> 2.The sentence "If Alice generated her request in
> response to an incoming packet from 10.2.16.43 to
> 18.16.2.123" puzzles me. As we know, 10.2.16.43 is on
> Alice's side and 18.16.2.123 is on Bob's side, but the
> word incoming is used here. So i have to think it is
> Alice's request that from 10.2.16.43 to 18.16.2.123.
> Why do the doc say "there would be no way for Bob to
> determine which pair of addresses it is most urgent to
> tunnel"?
>
Problems with describing directions... suggestions for
alternate wording would be
welcome. Here's what I was thinking: Alice and Bob are firewalls with
an IPsec connection between them. In the example, Alice receives
a packet from the private network side with original source address
10.2.16.43 and destination address somewhere beyond Bob at
18.16.2.123. This is the packet I referred to as "incoming". It will
be "outgoing" to Alice on the IPsec tunnel once that tunnel exists.
If she has no existing SA on which she can tunnel that
packet, she will request a new SA. If Alice is willing to build one
big tunnel but Bob wants a separate tunnel for each address pair,
Alice will propose a big tunnel (say from 10.2.16.* to 18.16.2.*) but
Bob will want to narrow it to just the addresses in the packet
motivating the request. But without special work by Alice, Bob
will have no idea what the addresses in that packet were, and
therefore what to narrow the selector to. That's what I meant by
"no way for Bob to determine which pair of addresses it is most
urgent to tunnel".
--Charlie
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
From owner-ipsec@lists.tislabs.com Sat Nov 2 16:26: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 gA30Q8W17014;
Sat, 2 Nov 2002 16:26:08 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16508
Sat, 2 Nov 2002 18:46:48 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200e61b9ea13fd6e98@[165.227.249.21]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Sat, 2 Nov 2002 15:46:57 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Fwd: Last Call: IPsec Configuration Policy Model to Proposed
Standard
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Earlier this week, the IESG issued the following announcement. Those
folks here who care about IPsec policy management but haven't been
active in the IPSP WG should definitely take a look at the documents
that are now in IETF-wide last call.
--Paul Hoffman, Director
--VPN Consortium
>To: IETF-Announce: ;
>Cc: ipsec-policy@vpnc.org
>From: The IESG <iesg-secretary@ietf.org>
>SUBJECT: Last Call: IPsec Configuration Policy Model to Proposed Standard
>Reply-to: iesg@ietf.org
>Date: Mon, 28 Oct 2002 14:55:53 -0500
>Sender: owner-ipsec-policy@mail.vpnc.org
>List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
>List-ID: <ipsec-policy.vpnc.org>
>List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>
>
>
>
>The IESG has received a request from the IP Security Policy Working
>Group to consider publication of the following Internet-Drafts
>as Proposed Standards:
>
> o IPsec Configuration Policy Model
> <draft-ietf-ipsp-config-policy-model-06.txt>
> o IPSec Policy Information Base
> <draft-ietf-ipsp-ipsecpib-05.txt>
>
>The IESG will also consider publication of IP Security Policy Requirements
><draft-ietf-ipsp-requirements-02.txt> as an Informational RFC.
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send any comments to the
>iesg@ietf.org or ietf@ietf.org mailing lists by 2002-11-11.
>
>Files can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-06.txt
>http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-05.txt
>http://www.ietf.org/internet-drafts/draft-ietf-ipsp-requirements-02.txt
From owner-ipsec@lists.tislabs.com Mon Nov 4 08:49: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 gA4GnqW11115;
Mon, 4 Nov 2002 08:49:52 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19523
Mon, 4 Nov 2002 11:00:37 -0500 (EST)
From: Charlie_Kaufman@notesdev.ibm.com
In-Reply-To: <200210301429.DAA242004@ruru.cs.auckland.ac.nz>
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
To: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002
Message-ID: <OF9C379683.848477F0-ON85256C67.00064160-85256C67.0007D05B@iris.com>
Date: Sun, 3 Nov 2002 20:25:20 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/04/2002
11:01:11 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Based on this discussion, I propose change the MUST requirements to 1024
and 2048 bit RSA keys (both public and private), with a MAY for all other
sizes. I would expect most implementations would implement a large
collection of sizes, but this avoids unnecessary growth of the testing
matrix. (And yes, I'll fix the wording so that the MUST requirements have
the keyword MUST in them).
Objections? I'm concerned about the following:
Bill Sommerfeld <sommerfeld@east.sun.com> wrote:
> For what it's worth, I'll repeat what I said last time.. *in real
> life* I've seen both PGP and SSH implementations generate keys with
> moduli which were a bit or two shorter than the desired size.
Key generation implementations that pick random primes sometimes come up
with moduli a bit or two shorter than they had intended. There is something
to be said for explicitly allowing them by requiring support for such
moduli. On the other hand, at one time the default CSP that shipped with
Microsoft Windows had a restriction that it could only work with moduli
that were a multiple of 8 bits (or was it 16 bits?) long. When I inquired
at the time, I was told that they knew about the problem but had no plans
to fix it. I don't know whether they have. There may be other
implementations around with similar restrictions, so there is something to
be said for disallowing keys that would break those implementations. My
opinion is that the conservative course is to only require support of 1024
and 2048 bit keys, but I really don't much care (so long as we make a
decision).
What about DSS keys? I made them a MUST in my draft, and one person
protested. How many would protest if it were a MAY? I don't think DSS keys
are much used, but it seemed politically correct to require them anyway. I
don't even have an opinion on this one... just wrote what I thought would
raise the fewest howls.
--Charlie
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
From owner-ipsec@lists.tislabs.com Mon Nov 4 09:59: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 gA4HxrW15094;
Mon, 4 Nov 2002 09:59:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19699
Mon, 4 Nov 2002 12:31:44 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100306b9ec5e01cd6d@[128.89.88.34]>
In-Reply-To:
<OF9C379683.848477F0-ON85256C67.00064160-85256C67.0007D05B@iris.com>
References:
<OF9C379683.848477F0-ON85256C67.00064160-85256C67.0007D05B@iris.com>
Date: Mon, 4 Nov 2002 12:27:20 -0500
To: Charlie_Kaufman@notesdev.ibm.com
From: Stephen Kent <kent@bbn.com>
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 8:25 PM -0500 11/3/02, Charlie_Kaufman@notesdev.ibm.com wrote:
>Based on this discussion, I propose change the MUST requirements to 1024
>and 2048 bit RSA keys (both public and private), with a MAY for all other
>sizes. I would expect most implementations would implement a large
>collection of sizes, but this avoids unnecessary growth of the testing
>matrix. (And yes, I'll fix the wording so that the MUST requirements have
>the keyword MUST in them).
>
>Objections? I'm concerned about the following:
>
>Bill Sommerfeld <sommerfeld@east.sun.com> wrote:
>> For what it's worth, I'll repeat what I said last time.. *in real
>> life* I've seen both PGP and SSH implementations generate keys with
>> moduli which were a bit or two shorter than the desired size.
>
>Key generation implementations that pick random primes sometimes come up
>with moduli a bit or two shorter than they had intended. There is something
>to be said for explicitly allowing them by requiring support for such
>moduli. On the other hand, at one time the default CSP that shipped with
>Microsoft Windows had a restriction that it could only work with moduli
>that were a multiple of 8 bits (or was it 16 bits?) long. When I inquired
>at the time, I was told that they knew about the problem but had no plans
>to fix it. I don't know whether they have. There may be other
>implementations around with similar restrictions, so there is something to
>be said for disallowing keys that would break those implementations. My
>opinion is that the conservative course is to only require support of 1024
>and 2048 bit keys, but I really don't much care (so long as we make a
>decision).
>
>What about DSS keys? I made them a MUST in my draft, and one person
>protested. How many would protest if it were a MAY? I don't think DSS keys
>are much used, but it seemed politically correct to require them anyway. I
>don't even have an opinion on this one... just wrote what I thought would
>raise the fewest howls.
>
> --Charlie
Charlie,
I think the 1024 and 2048 MUSTs for RSA are right, based on Peter's
comments and my observations as well (e.g., from, my days as CTO for
CVyberTrust).
I think DSS is not used much commercially, so a MAY might be about
right here. I'll ask my Gov contacts if they see this as a problem,
i.e., do they need to use DSS certs with IPsec in commercial products.
Steve
From owner-ipsec@lists.tislabs.com Mon Nov 4 09:59: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 gA4HxsW15096;
Mon, 4 Nov 2002 09:59:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19674
Mon, 4 Nov 2002 12:23:40 -0500 (EST)
From: "Geoffrey Huang" <ghuang@cisco.com>
To: "Edward Wilkinson" <ewilkinson@efficient.com>, <ipsec@lists.tislabs.com>
Subject: RE: Dead peer detection
Date: Fri, 1 Nov 2002 13:36:20 -0800
Message-ID: <MEEJLOJCKGGPCNBGDIJACEAHCBAA.ghuang@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_001A_01C281AB.A9D8E5B0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <36C2EB69D2F9D411A9AB00D0B7200334F81E17@eniwest.inside.efficient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_001A_01C281AB.A9D8E5B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hi Ed,
The draft has expired, but I've attached a copy of it. I'd like to move the
draft forward (wherever that might be), but the focus in the WG lately has
been on IKEv2.
> I have wondered around the working groups site and could not find the
> draft-ietf-ipsec-dpd-00.txt any longer nor could I find any on going
> conversations on the subject. Was this draft allowed to expire
> without any
> further discussions, or was another draft started.
> I understand that some products do "dead peer detection" and was wondering
> if this draft was how it was to be done or if the use of lower
> re-key timer
This is the method that Cisco devices use.
> (say 600 seconds) in phase one would have the same effect, if one was to
> delete the phase 2 sa's if the phase one negotiations failed.
It depends on your implementation. If you always maintain a Phase 1 SA
("Continuous Channel Mode") when there are Phase 2 SAs, then doing as you
propose might be one solution. Keep in mind, however, that it won't scale
well if you have to frequently rekey. Essentially, you'd be using a Phase 1
negotiation to do the DPD; the difference is that DPD involves 2 notify
messages (a "hello" and an ACK). Using a Phase 1 for DPD requires at least
3 messages, plus a DH...Added to this is the concern that 600 seconds might
be too coarse an interval before detecting a black hole.
-g
> Thanks
> Ed Wilkinson
>
------=_NextPart_000_001A_01C281AB.A9D8E5B0
Content-Type: text/plain;
name="draft-ietf-ipsec-dpd-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-ipsec-dpd-00.txt"
IPSec Working Group=20
G. Huang=20
S. Beaulieu=20
Internet Draft D. Rochefort=20
Document: draft-ietf-ipsec-dpd-01.txt Cisco Systems, Inc.=20
Expires: January 2002 August 2001=20
=20
=20
A Traffic-Based Method of Detecting Dead IKE Peers=20
=20
=20
Status of this Memo=20
=20
This document is an Internet-Draft and is in full conformance=20
with all provisions of Section 10 of RFC2026.=20
=20
=20
Internet-Drafts are working documents of the Internet Engineering=20
Task Force (IETF), its areas, and its working groups. Note that =
other groups may also distribute working documents as Internet-
Drafts.=20
=20
Internet-Drafts are draft documents valid for a maximum of six=20
months and may be updated, replaced, or obsoleted by other documents=20
at any time. It is inappropriate to use Internet-Drafts as=20
reference material or to cite them other than as "work in progress."=20
=20
The list of current Internet-Drafts can be accessed at=20
http://www.ietf.org/ietf/1id-abstracts.txt=20
The list of Internet-Draft Shadow Directories can be accessed at=20
http://www.ietf.org/shadow.html.=20
=20
=20
Abstract=20
=20
This draft describes a method of detecting a dead IKE peer. The=20
method, called Dead Peer Detection (DPD) uses IPSec traffic patterns=20
to limit the number of IKE messages sent. DPD, like other keepalive=20
mechanisms, is often necessary to perform IKE peer failover, or to=20
reclaim lost resources.=20
=20
=20
Table of Contents=20
=20
Status of this Memo................................................1=20
Abstract...........................................................1=20
1. Introduction....................................................2=20
2. Conventions used in this document...............................3=20
3. Document Roadmap................................................3=20
4. Keepalives vs. Heartbeats.......................................3=20
4.1 Keepalives:..................................................3=20
4.2 Heartbeats:..................................................4=20
=20
Huang, Beaulieu, Rochefort Expires January 2002 1 =
=0C
A Traffic-Based Method of Detecting Dead IKE Peers August 2001 =
=20
=20
5. DPD Protocol....................................................5=20
5.1 DPD Vendor ID................................................6=20
5.2 Message Exchanges............................................6=20
5.3 NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format...............7=20
5.4 Impetus for DPD Exchange.....................................8=20
5.5 Implementation Suggestion....................................8=20
5.6 Comparisons..................................................8=20
6. Resistance to Replay Attack and False Proof of Liveliness.......9=20
6.1 Sequence Number in DPD Messages..............................9=20
6.2 Selection and Maintenance of Sequence Numbers................9=20
7. Acknowledgements................................................9=20
8. References......................................................9=20
9. Editors' Address................................................9=20
=20
=20
1. Introduction=20
=20
When two peers communicate with IKE/IPSec, the situation may arise=20
in which connectivity between the two goes down unexpectedly. This=20
situation can arise because of routing problems, one host rebooting,=20
etc., and in such cases, there is often no way for IKE and IPSec to =
identify the loss of peer connectivity. As such, the SAs can remain =
=20
until their lifetimes naturally expire, resulting in a "black hole"=20
situation where packets are tunneled to oblivion. It is often=20
desirable to recognize black holes as soon as possible so that an=20
entity can failover to a different peer quickly. Likewise, it is=20
sometimes necessary to detect black holes to recover lost resources.=20
=20
This problem of detecting a dead IKE peer has been addressed by=20
proposals that require sending periodic HELLO/ACK messages to prove=20
liveliness. These schemes tend to be unidirectional (a HELLO only)=20
or bidirectional (a HELLO/ACK pair). For the purpose of this draft,=20
the term "heartbeat" will refer to a unidirectional message to prove=20
liveliness. Likewise, the term "keepalive" will refer to a=20
bidirectional message.=20
=20
The problem with current heartbeat and keepalive proposals is their=20
reliance upon their messages to be sent at regular intervals. In=20
the implementation, this translates into managing some timer to=20
service these message intervals. Similarly, because rapid detection=20
of the dead peer is often desired, these messages must be sent with=20
some frequency, again translating into considerable overhead for=20
message processing. In implementations and installations where=20
managing large numbers of simultaneous IKE sessions is of concern,=20
these regular heartbeats/keepalives prove to be infeasible.=20
=20
To this end, this draft proposes an approach to detect peer=20
liveliness without needing to send messages at regular intervals.=20
This scheme is called Dead Peer Detection (DPD).=20
=20
=20
=20
Huang, Beaulieu, Rochefort Expires January 2002 2 =
=0C
A Traffic-Based Method of Detecting Dead IKE Peers August 2001 =
=20
=20
2. Conventions used in this document=20
=20
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20
this document are to be interpreted as described in RFC-2119 [1].=20
=20
=20
3. Document Roadmap=20
=20
As mentioned above, there are already proposed solutions to the=20
problem of detecting dead peers. Section 4 examines a keepalives-=20
based approach as well as a heartbeats-based approach. A brief=20
comparison is also made between schemes based on the IPSec SA and=20
schemes based on the IKE SA. DPD is an IKE SA-based scheme. =20
Section 5 presents the DPD proposal fully, highlighting differences=20
between DPD and the schemes presented in Section 4 and emphasizing=20
scalability issues. Section 6 examines security issues surrounding=20
replayed messages and false liveliness, drawing upon work already=20
presented in the Heartbeats draft [2].=20
=20
4. Keepalives vs. Heartbeats=20
4.1 Keepalives: =20
Consider a keepalives scheme in which peer A and peer B require=20
regular acknowledgements of each other's liveliness. The messages=20
are exchanged by means of an authenticated notify payload. The two=20
peers must agree upon the interval at which keepalives are sent,=20
meaning that some negotiation is required during Phase 1. For any=20
prompt failover to be possible, the keepalives must also be sent at=20
rather frequent intervals -- around 10 seconds or so. In this=20
hypothetical keepalives scenario, peers A and B agree to exchange=20
keepalives every 10 seconds. Essentially, every 10 seconds, one=20
peer must send a HELLO to the other. This HELLO serves as proof of=20
liveliness for the sending entity. In turn, the other peer must=20
acknowledge each keepalive HELLO. If the 10 seconds elapse, and one=20
side has not received a HELLO, it will send the HELLO message=20
itself, using the peer's ACK as proof of liveliness. Receipt of=20
either a HELLO or ACK causes an entity's keepalive timer to reset. =20
Failure to receive an ACK in a certain period of time signals an=20
error. A clarification is presented below:=20
=20
Scenario 1: =20
Peer A's 10-second timer elapses first, and it sends a HELLO to B. =20
B responds with an ACK.=20
=20
Peer A: Peer B: =20
10 second timer fires; ------> =20
wants to know that B is alive; =20
sends HELLO.=20
Receives HELLO; acknowledges =20
A's liveliness;=20
<------ resets keepalive timer, sends =20
ACK.=20
Receives ACK as proof of =20
=20
Huang, Beaulieu, Rochefort Expires January 2002 3 =
=0C
A Traffic-Based Method of Detecting Dead IKE Peers August 2001 =
=20
=20
B's liveliness; resets timer.=20
=20
Scenario 2: =20
Peer A's 10-second timer elapses first, and it sends a HELLO to B. =20
B fails to respond. A can retransmit, in case its initial HELLO is=20
lost. This situation describes how peer A detects its peer is dead.=20
=20
Peer A: Peer B (dead):=20
=20
10 second timer fires; ------X =20
wants to know that B is =20
alive; sends HELLO.=20
=20
Retransmission timer ------X =20
expires; initial message =20
could have been lost in =20
transit; A increments =20
error counter and =20
sends another HELLO.=20
=20
. . .=20
=20
After some number of errors, A assumes B is dead; deletes SAs and=20
possibly initiates failover.=20
=20
An advantage of this scheme is that the party interested in the=20
other peer's liveliness begins the message exchange. In Scenario 1,=20
peer A is interested in peer B's liveliness, and peer A consequently=20
sends the HELLO. It is conceivable in such a scheme that peer B=20
would never be interested in peer A's liveliness. In such a case,=20
the onus would always lie on peer A to initiate the exchange.=20
=20
4.2 Heartbeats: =20
By contrast, consider a proof-of-liveliness scheme involving=20
unidirectional (unacknowledged) messages. An entity interested in=20
its peer's liveliness would rely on the peer itself to send periodic=20
messages demonstrating liveliness. In such a scheme, the message=20
exchange might look like this:=20
=20
Scenario 3: =20
Peer A and Peer B are interested in each other's liveliness. Each=20
peer depends on the other to send periodic HELLOs.=20
=20
=20
Peer A: Peer B: =20
10 second timer fires; ------> =20
sends HELLO. Timer also =20
signals expectation of =20
B's HELLO.=20
Receives HELLO as proof of A's=20
liveliness.=20
=20
<------ 10 second timer fires; sends=20
=20
Huang, Beaulieu, Rochefort Expires January 2002 4 =
=0C
A Traffic-Based Method of Detecting Dead IKE Peers August 2001 =
=20
=20
HELLO. =20
Receives HELLO as proof =20
of B's liveliness.=20
=20
Scenario 4: =20
Peer A fails to receive HELLO from B and marks the peer dead. This=20
is how an entity detects its peer is dead.=20
=20
Peer A: Peer B (dead): =20
10 second timer fires; ------X =20
sends HELLO. Timer also =20
signals expectation of=20
B's HELLO.=20
=20
. . .=20
=20
Some time passes and A assumes B is dead.=20
=20
The disadvantage of this scheme is the reliance upon the peer to=20
demonstrate liveliness. To this end, peer B might never be =20
interested in peer A's liveliness. Nonetheless, if A is interested=20
B's liveliness, B must be aware of this, and maintain the necessary=20
state information to send periodic HELLOs to A. The disadvantage of=20
such a scheme becomes clear in the remote-access scenario. Consider=20
a VPN aggregator that terminates a large number of sessions (on the=20
order of 50,000 peers or so). Each peer requires fairly rapid=20
failover, therefore requiring the aggregator to send HELLO packets=20
every 10 seconds or so. Such a scheme simply lacks scalability, as=20
the aggregator must send 50,000 messages every few seconds.=20
=20
In both of these schemes (keepalives and heartbeats), some=20
negotiation of message interval must occur, so that each entity can=20
know how often its peer expects a HELLO. This immediately adds a=20
degree of complexity. Similarly, the need to send periodic messages =
(regardless of other IPSec/IKE activity), also increases=20
computational overhead to the system.=20
=20
=20
5. DPD Protocol=20
DPD addresses the shortcomings of IKE keepalives- and heartbeats-
schemes by introducing a more reasonable logic governing message=20
exchange. Essentially, keepalives and heartbeats mandate exchange=20
of HELLOs at regular intervals. By contrast, with DPD, each peer=92s =
DPD state is largely independent of the other=92s. A peer is free to =
request proof of liveliness when it needs it -- not at mandated=20
intervals. This asynchronous property of DPD exchanges allows fewer=20
messages to be sent, and this is how DPD achieves greater=20
scalability.=20
=20
As an elaboration, consider two DPD peers A and B. If there is=20
ongoing IPSec traffic between the two, there is little need for=20
proof of liveliness. The IPSec traffic itself serves as the proof=20
of liveliness. If, on the other hand, a period of time lapses=20
=20
Huang, Beaulieu, Rochefort Expires January 2002 5 =
=0C
A Traffic-Based Method of Detecting Dead IKE Peers August 2001 =
=20
=20
during which no packet-exchange occurs, the liveliness of each peer=20
is questionable. Knowledge of the peer=92s liveliness, however, is=20
only urgently necessary if there is traffic to be sent. For=20
example, if peer A has some IPSec packets to send after the period=20
of idleness, it will need to know if peer B is still alive. At this=20
point, peer A can initiate the DPD exchange.=20
=20
To this end, each peer may have different requirements for detecting=20
proof of liveliness. Peer A, for example, may require rapid=20
failover, whereas peer B's requirements for resource cleanup are=20
less urgent. In DPD, each peer can define its own "worry metric" =96 =
an interval that defines the urgency of the DPD exchange. =20
Continuing the example, peer A might define its DPD interval to be=20
10 seconds. Then, if peer A sends outbound IPSec traffic, but fails=20
to receive any inbound traffic for 10 seconds, it can initiate a DPD=20
exchange.=20
=20
Peer B, on the other hand, defines its less urgent DPD interval to=20
be 5 minutes. If the IPSec session is idle for 5 minutes, peer B=20
can initiate a DPD exchange the next time it sends IPSec packets.=20
=20
It is important to note that the decision about when to initiate a=20
DPD exchange is implementation specific. An implementation might=20
even define the DPD messages to be at regular intervals following=20
idle periods. See section 5.5 for more implementation suggestions.=20
=20
5.1 DPD Vendor ID=20
To demonstrate DPD capability, an entity must send the DPD vendor=20
ID. Both peers of an IKE session MUST send the DPD vendor ID before=20
DPD exchanges can begin. The format of the DPD Vendor ID is:=20
=20
1=20
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
! !M!M!=20
! HASHED_VENDOR_ID !J!N!=20
! !R!R!=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
=20
where HASHED_VENDOR_ID =3D {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1, =
0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}, and MJR and MNR=20
correspond to the current major and minor version of this protocol=20
(1 and 0 respectively). An IKE peer MUST send the Vendor ID if it=20
wishes to take part in DPD exchanges.=20
=20
5.2 Message Exchanges=20
=20
The DPD exchange is a bidirectional (HELLO/ACK) Notify message. The=20
exchange is defined as:=20
=20
Sender Responder=20
-------- -----------=20
HDR*, NOTIFY(R-U-THERE), HASH ------>=20
=20
Huang, Beaulieu, Rochefort Expires January 2002 6 =
=0C
A Traffic-Based Method of Detecting Dead IKE Peers August 2001 =
=20
=20
=20
<------ HDR*, NOTIFY(R-U-THERE-=20
ACK), HASH=20
=20
The R-U-THERE message corresponds to a "HELLO" and the R-U-THERE-ACK=20
corresponds to an "ACK." Both messages are simply ISAKMP Notify=20
payloads, and as such, this draft defines these two new ISAKMP=20
Notify message types:=20
=20
Notify Message Value =20
R-U-THERE 36136=20
R-U-THERE-ACK 36137=20
=20
An entity that has sent the DPD Vendor ID MUST respond to an R-U-
THERE query. Furthermore, an entity MUST reject unencrypted R-U-
THERE and R-U-THERE-ACK messages. =20
=20
5.3 NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format=20
When sent, the R-U-THERE message MUST take the following form:=20
=20
1 2 3=20
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=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
! Next Payload ! RESERVED ! Payload Length !=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
! Domain of Interpretation (DOI) !=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
! Protocol-ID ! SPI Size =3D 16 ! Notify Message Type !=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
! !=20
~ Security Parameter Index (SPI) ~=20
! !=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
! !=20
~ Notification Data ~=20
! !=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
=20
As this message is an ISAKMP NOTIFY, the Next Payload, RESERVED, and=20
Payload Length fields should be set accordingly. The remaining=20
fields are set as:=20
=20
- Domain of Interpretation (4 octets) - SHOULD be set to IPSEC-DOI.=20
=20
- Protocol ID (1 octet) =96 MUST be set to the protocol ID for =
ISAKMP.=20
=20
- SPI Size (2 octets) - SHOULD be set to sixteen (16), the length of=20
two octet-sized ISAKMP cookies.=20
=20
- Notify Message Type (2 octets) - MUST be set to R-U-THERE=20
=20
- Security Parameter Index (16 octets) - SHOULD be set to the=20
cookies of the Initiator and Responder of the IKE SA (in that =20
=20
Huang, Beaulieu, Rochefort Expires January 2002 7 =
=0C
A Traffic-Based Method of Detecting Dead IKE Peers August 2001 =
=20
=20
order)=20
=20
- Notification Data (4 octets) - MUST be set to the sequence number=20
corresponding to this message=20
=20
The format of the R-U-THERE-ACK message is the same, with the=20
exception that the Notify Message Type MUST be set to R-U-THERE-ACK. =
=20
Again, the Notification Data MUST be sent to the sequence number=20
corresponding to the received R-U-THERE message.=20
=20
5.4 Impetus for DPD Exchange=20
Again, rather than relying on some negotiated time interval to force=20
the exchange of messages, DPD does not mandate the exchange of R-U-=20
THERE messages at any time. Instead, an IKE peer SHOULD send an R-
U-THERE query to its peer only if it is interested in the liveliness=20
of this peer. To this end, if traffic is regularly exchanged=20
between two peers, either peer SHOULD use this traffic as proof of=20
liveliness, and both peers SHOULD NOT initiate a DPD exchange.=20
=20
5.5 Implementation Suggestion=20
Since the liveliness of a peer is only questionable when no traffic=20
is exchanged, a viable implementation might begin by monitoring=20
idleness. Along these lines, a peer's liveliness is only important=20
when there is outbound traffic to be sent. To this end, an=20
implementation can initiate a DPD exchange (i.e., send an R-U-THERE=20
message) when there has been some period of idleness, followed by=20
the desire to send outbound traffic. Likewise, an entity can=20
initiate a DPD exchange if it has sent outbound IPSec traffic, but=20
not received any inbound IPSec packets in response. A complete DPD=20
exchange (i.e., transmission of R-U-THERE and receipt of=20
corresponding R-U-THERE-ACK) will serve as proof of liveliness until=20
the next idle period.=20
=20
Again, since DPD does not mandate any interval, this "idle period"=20
(or "worry metric") is left as an implementation decision. It is=20
not a negotiated value.=20
=20
5.6 Comparisons=20
The performance benefit that DPD offers over traditional keepalives-=20
and heartbeats-schemes comes from the fact that regular messages do=20
not need to be sent. Thus, the need to maintain timer state is =20
mitigated, and the number of IKE messages to be processed is=20
reduced. As a consequence, the scalability of DPD is much better=20
than keepalives and heartbeats.=20
=20
DPD maintains the HELLO/ACK model presented by keepalives, as it=20
follows that an exchange is initiated only by an entity interested=20
in the liveliness of its peer.=20
=20
=20
=20
Huang, Beaulieu, Rochefort Expires January 2002 8 =
=0C
A Traffic-Based Method of Detecting Dead IKE Peers August 2001 =
=20
=20
6. Resistance to Replay Attack and False Proof of Liveliness =20
6.1 Sequence Number in DPD Messages =20
To guard against message replay attacks and false proof of=20
liveliness, a 32-bit sequence number MUST be presented with each R-
U-THERE message. A responder to an R-U-THERE message MUST send an=20
R-U-THERE-ACK with the same sequence number. Upon receipt of the R-
U-THERE-ACK message, the initial sender SHOULD check the validity of=20
the sequence number. The initial sender SHOULD reject the R-U-
THERE-ACK if the sequence number fails to match the one sent with=20
the R-U-THERE message.=20
=20
Additionally, both the receiver of the R-U-THERE and the R-U-THERE-
ACK message SHOULD check the validity of the Initiator and Responder=20
cookies presented in the SPI field of the payload.=20
=20
6.2 Selection and Maintenance of Sequence Numbers=20
As both DPD peers can initiate a DPD exchange (i.e., both peers can=20
send R-U-THERE messages), each peer MUST maintain its own sequence=20
number for R-U-THERE messages. The first R-U-THERE message sent in=20
a session MUST be a randomly chosen number. To prevent rolling past=20
overflowing the 32-bit boundary, the high-bit of the sequence number=20
initially SHOULD be set to zero. Subsequent R-U-THERE messages MUST=20
increment the sequence number by one. Sequence numbers MAY reset at=20
the expiry of the IKE SA, moving to a newly chosen random number.=20
Each entity SHOULD also maintain its peer's R-U-THERE sequence=20
number, and an entity SHOULD reject the R-U-THERE message if it=20
fails to match the expected sequence number.=20
=20
Implementations MAY maintain a window of acceptable sequence=20
numbers, but this specification makes no assumptions about how this=20
is done. Again, it is an implementation specific detail.=20
=20
=20
7. Acknowledgements=20
The authors of this draft would like to thank Andrew Krywaniuk and=20
Tero Kivinen for the idea of using a sequence number in keepalive=20
exchanges to prevent replay attacks. They presented this idea in=20
[2]. Likewise, many engineers at Cisco contributed to this=20
proposal, including Scott Fanning, Steve Goldhaber, Natalie Timms,=20
Jan Vilhuber, and Victor Volpe.=20
=20
=20
8. References=20
1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate=20
Requirement Levels", BCP 14, RFC 2119, March 1997=20
=20
2 Krywaniuk, A., Kivinen, T., "Using Isakmp Heartbeats for =20
Dead Peer Detection," <draft-ietf-ipsec-heartbeats-01.txt> =20
(work in progress), July 2000.=20
=20
=20
9. Editors' Address=20
=20
=20
Huang, Beaulieu, Rochefort Expires January 2002 9 =
=0C
A Traffic-Based Method of Detecting Dead IKE Peers August 2001 =
=20
=20
Geoffrey Huang=20
Cisco Systems, Inc.=20
170 West Tasman Drive=20
San Jose, CA 95134=20
Phone: (408) 525-5354=20
Email: ghuang@cisco.com=20
=20
Stephane Beaulieu=20
Cisco Systems, Inc.=20
2000 Innovation Drive=20
Kanata, ON=20
Canada, K2K 3E8=20
Phone: (613) 271-3678=20
Email: stephane@cisco.com=20
=20
Dany Rochefort=20
Cisco Systems, Inc.=20
124 Grove Street, Suite 205=20
Franklin, MA 02038=20
Phone: (508) 553-6136=20
Email: danyr@cisco.com=20
=20
The IPsec working group can be contacted through the chairs:=20
=20
Barbara Fraser=20
byfraser@cisco.com=20
Cisco Systems, Inc.=20
=20
Ted T'so=20
tytso@mit.edu=20
Massachusetts Institute of Technology=20
=20
=20
=20
Huang, Beaulieu, Rochefort Expires January 2002 10 =0C
------=_NextPart_000_001A_01C281AB.A9D8E5B0--
From owner-ipsec@lists.tislabs.com Mon Nov 4 10:02:08 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 gA4I28W15163;
Mon, 4 Nov 2002 10:02:08 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19711
Mon, 4 Nov 2002 12:33:45 -0500 (EST)
Date: Tue, 5 Nov 2002 05:16:32 +1300 (NZDT)
Message-ID: <200211041616.FAA290006@ruru.cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: Charlie_Kaufman@notesdev.ibm.com, pgut001@cs.auckland.ac.nz
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Charlie_Kaufman@notesdev.ibm.com writes:
>Bill Sommerfeld <sommerfeld@east.sun.com> wrote:
>>For what it's worth, I'll repeat what I said last time.. *in real
>>life* I've seen both PGP and SSH implementations generate keys with
>>moduli which were a bit or two shorter than the desired size.
>
>Key generation implementations that pick random primes sometimes come up with
>moduli a bit or two shorter than they had intended.
The PGP missing-bits problem was in old 2.x versions. 5.x used bnlib for its
bignum work which had code in there to ensure that if you asked for n bits,
you got exactly n bits (from memory I think it set the high bits to ensure
that the number is exactly n bits long, i.e. 2^(n-1) <= number < 2^n). I
assume newer versions still use the same code. SSH (specifically OpenSSH)
does odd things with its keygen, including setting e=35, so I don't think
that's a good example to follow.
>What about DSS keys?
I've heard of those. I've even got one or two DSA certs, you can find them
"rare species" section of the museum. It's right next to the "mythological
creatures" section, which holds the X9.42 DH certs.
Peter.
From owner-ipsec@lists.tislabs.com Mon Nov 4 10:03: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 gA4I34W15213;
Mon, 4 Nov 2002 10:03:04 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19705
Mon, 4 Nov 2002 12:32:45 -0500 (EST)
Date: Mon, 4 Nov 2002 12:03:32 +0200
From: Teemu Alakoski <teemu.alakoski@tut.fi>
To: ipsec@lists.tislabs.com
Subject: Public key distribution methods?
Message-ID: <20021104100331.GA17307@alakoski.ton.tut.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
I'm writing my diploma thesis about key exchange and public key
distribution in IPSec environment.
I would like to know what are opinions on this list concerning different
ways to distribute public keys for use in IKE/IKEv2 authentication. I have
understood that LDAPv3 is the strongest candidate for this purpose, and
another mechanism is DNS TXT RRs as described in
draft-richardson-ipsec-opportunistic -draft. Are there other mechanisms that
should be taken into consideration?
Or should I be asking this on the pkix mailing list?
Thanks
Teemu Alakoski
From owner-ipsec@lists.tislabs.com Mon Nov 4 10:44: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 gA4IiIW17957;
Mon, 4 Nov 2002 10:44:18 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19960
Mon, 4 Nov 2002 13:13:02 -0500 (EST)
Message-Id: <200211041813.gA4IDerL021918@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@east.sun.com>
To: Charlie_Kaufman@notesdev.ibm.com
cc: pgut001@cs.auckland.ac.nz (Peter Gutmann), ipsec@lists.tislabs.com,
owner-ipsec@lists.tislabs.com
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
In-Reply-To: Your message of "Sun, 03 Nov 2002 20:25:20 EST."
<OF9C379683.848477F0-ON85256C67.00064160-85256C67.0007D05B@iris.com>
Reply-to: sommerfeld@east.sun.com
Date: Mon, 04 Nov 2002 13:13:39 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> My opinion is that the conservative course is to only require
> support of 1024 and 2048 bit keys, but I really don't much care (so
> long as we make a decision).
Unless someone can demonstrate there's a meaningful difference in
security between a 1022-bit and a 1024-bit key, may I suggest that
Postel's rule of thumb ("Be liberal in what you accept and
conservative in what you send") applies here?
- MUST generate keys with moduli which are exactly at these bit sizes
- SHOULD accept keys with moduli even if slightly smaller than the mandatory
sizes.
- Bill
From owner-ipsec@lists.tislabs.com Mon Nov 4 11:42: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 gA4JgJW21815;
Mon, 4 Nov 2002 11:42:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20264
Mon, 4 Nov 2002 14:10:51 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0510030db9ec7344cc68@[128.89.88.34]>
In-Reply-To: <20021104100331.GA17307@alakoski.ton.tut.fi>
References: <20021104100331.GA17307@alakoski.ton.tut.fi>
Date: Mon, 4 Nov 2002 14:10:40 -0500
To: Teemu Alakoski <teemu.alakoski@tut.fi>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Public key distribution methods?
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 12:03 PM +0200 11/4/02, Teemu Alakoski wrote:
>Hi,
>
>I'm writing my diploma thesis about key exchange and public key
>distribution in IPSec environment.
>
>I would like to know what are opinions on this list concerning different
>ways to distribute public keys for use in IKE/IKEv2 authentication. I have
>understood that LDAPv3 is the strongest candidate for this purpose, and
>another mechanism is DNS TXT RRs as described in
>draft-richardson-ipsec-opportunistic -draft. Are there other mechanisms that
>should be taken into consideration?
>
>Or should I be asking this on the pkix mailing list?
>
>Thanks
>Teemu Alakoski
Teemu,
Since IKE has provisions to "push" certs and CRLs to an IPsec (IKE)
peer, neither DNS nor LDAP is needed as a means to distribute these
data items. Note that unlike e-mail, where a sender needs to know the
cert for a recipient before the sender can encrypt a message for that
recipient, IPsec as a realtime protocol can exchange all of the PKI
data items needed during the SA establishment procedure.
To be fair, there are some limitations with this approach. First, it
means moving more bits across the wire during SA establishment, and
we have seen some problems re fragmentation when the IKE UDP packets
get big, e.g., as a result of packing in too many certs/CRLs. Also,
if one wants to keep the number of messages exchanged to a minimum,
there is the issue of what cert path to send to the other IPsec peer.
In general, one does not know what roots the other peer knows and
thus what path will be usable by them. So, one can argue for using
repositories such as the DNS or LDAP servers to hold certs and CRLs
for CAs "higher up the cert path" to minimize the amount of PKI data
two IKE peers put in messages, and to keep the message exchanges to a
minimum.
Steve
From owner-ipsec@lists.tislabs.com Mon Nov 4 13:37: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 gA4LbHW28172;
Mon, 4 Nov 2002 13:37:17 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21345
Mon, 4 Nov 2002 15:57:03 -0500 (EST)
Message-Id: <200211042056.gA4KuUQj004645@marajade.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
In-reply-to: Your message of "Mon, 04 Nov 2002 13:13:39 EST."
<200211041813.gA4IDerL021918@thunk.east.sun.com>
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 04 Nov 2002 15:56:30 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Bill" == Bill Sommerfeld <sommerfeld@east.sun.com> writes:
>> My opinion is that the conservative course is to only require
>> support of 1024 and 2048 bit keys, but I really don't much care (so
>> long as we make a decision).
Bill> Unless someone can demonstrate there's a meaningful difference in
Bill> security between a 1022-bit and a 1024-bit key, may I suggest that
Bill> Postel's rule of thumb ("Be liberal in what you accept and
Bill> conservative in what you send") applies here?
Bill> - MUST generate keys with moduli which are exactly at these bit sizes
Bill> - SHOULD accept keys with moduli even if slightly smaller than the mandatory
Bill> sizes.
I strongly agree.
The FreeSWAN default key size is presently 2192 bits. Why that number?
Because it is a bit bigger than 2048.
] 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 Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPcbe4YqHRg3pndX9AQHJUQP9FR4dFVN9j9UdKEERY6iPfY/+BR2MQfYC
Nj/CzORy52mvUb7TtrMsVfGynAYTZMaBTCR/RBJgl5O3zk9IZzeF/eaS+G+8Zdga
q7YQvcJFq4X/sYAlIwe8LFpts5YPvJZk2Mn3luy9H2ln2mqlzBjjDCT2BXia93+H
WiNVamPtzRg=
=DTiE
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Mon Nov 4 14:18: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 gA4MIFW00865;
Mon, 4 Nov 2002 14:18:15 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21441
Mon, 4 Nov 2002 16:44:44 -0500 (EST)
Message-ID: <3DC6EA68.439837A3@lucent.com>
Date: Mon, 04 Nov 2002 16:45:12 -0500
From: Uri Blumenthal <uri@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
References: <200211041813.gA4IDerL021918@thunk.east.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Bill Sommerfeld wrote:
> Unless someone can demonstrate there's a meaningful difference in
> security between a 1022-bit and a 1024-bit key, may I suggest that
> Postel's rule of thumb ("Be liberal in what you accept and
> conservative in what you send") applies here?
>
> - MUST generate keys with moduli which are exactly at these bit sizes
> - SHOULD accept keys with moduli even if slightly smaller than the
> mandatory sizes.
Considering the reality we live i - I second this opinion.
From owner-ipsec@lists.tislabs.com Mon Nov 4 23:03: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 gA573Nv29778;
Mon, 4 Nov 2002 23:03:23 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA22503
Tue, 5 Nov 2002 01:25:32 -0500 (EST)
Message-ID: <002e01c28494$382a07a0$45bbfea9@amanda2>
Reply-To: "Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
From: "Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
To: <sommerfeld@east.sun.com>
Cc: <ipsec@lists.tislabs.com>
References: <200211041813.gA4IDerL021918@thunk.east.sun.com>
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
Date: Tue, 5 Nov 2002 09:26:02 +0300
Organization: KAAU
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
Bill
All of us know that 1024 bits key makes 128 - 8 bit bytes, since the
computer industry is shifting more and more to embedded cryptography, i.e in
the VLSI chips. I believe we should keep the pattern of integral multiples
of bytes. In other words we keep the 1024 bits keys.
Regards
Ahmed Adas
alaadas@kaau.edu.sa
----- Original Message -----
From: "Bill Sommerfeld" <sommerfeld@east.sun.com>
To: <Charlie_Kaufman@notesdev.ibm.com>
Cc: "Peter Gutmann" <pgut001@cs.auckland.ac.nz>; <ipsec@lists.tislabs.com>;
<owner-ipsec@lists.tislabs.com>
Sent: Monday, November 04, 2002 9:13 PM
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
> > My opinion is that the conservative course is to only require
> > support of 1024 and 2048 bit keys, but I really don't much care (so
> > long as we make a decision).
>
> Unless someone can demonstrate there's a meaningful difference in
> security between a 1022-bit and a 1024-bit key, may I suggest that
> Postel's rule of thumb ("Be liberal in what you accept and
> conservative in what you send") applies here?
>
> - MUST generate keys with moduli which are exactly at these bit sizes
> - SHOULD accept keys with moduli even if slightly smaller than the
mandatory
> sizes.
>
> - Bill
>
From owner-ipsec@lists.tislabs.com Tue Nov 5 08:36: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 gA5Gaav29857;
Tue, 5 Nov 2002 08:36:36 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23447
Tue, 5 Nov 2002 11:01:00 -0500 (EST)
Message-Id: <200211051600.gA5G0VrL007663@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@east.sun.com>
To: "Ahmed Bin Abbas Ahmed Ali Adas" <alaadas@kaau.edu.sa>
cc: sommerfeld@east.sun.com, ipsec@lists.tislabs.com
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
In-Reply-To: Your message of "Tue, 05 Nov 2002 09:26:02 +0300."
<002e01c28494$382a07a0$45bbfea9@amanda2>
Reply-to: sommerfeld@east.sun.com
Date: Tue, 05 Nov 2002 11:00:31 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> All of us know that 1024 bits key makes 128 - 8 bit bytes, since the
> computer industry is shifting more and more to embedded cryptography, i.e in
> the VLSI chips. I believe we should keep the pattern of integral multiples
> of bytes. In other words we keep the 1024 bits keys.
Is there any particular reason why it's difficult to make an
implementation which doesn't break if the high order bit of the high
order byte of the modulus is zero?
- Bill
From owner-ipsec@lists.tislabs.com Tue Nov 5 08:41: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 gA5Gfev29985;
Tue, 5 Nov 2002 08:41:41 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23446
Tue, 5 Nov 2002 11:01:00 -0500 (EST)
Message-Id: <200211051601.gA5G1ZGk007714@kebe.east.sun.com>
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
In-Reply-To: <002e01c28494$382a07a0$45bbfea9@amanda2> from Ahmed Bin Abbas Ahmed
Ali Adas at "Nov 5, 2002 09:26:02 am"
To: Ahmed Bin Abbas Ahmed Ali Adas <alaadas@kaau.edu.sa>
Date: Tue, 5 Nov 2002 11:01:34 -0500 (EST)
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
> All of us know that 1024 bits key makes 128 - 8 bit bytes, since the
> computer industry is shifting more and more to embedded cryptography, i.e
> in the VLSI chips. I believe we should keep the pattern of integral
> multiples of bytes. In other words we keep the 1024 bits keys.
I strongly disagree. The _implementation_ of a 1023-bit key will be padded
to the logical 8-bit boundary, of course. When _generating_ a prime, that
prime may not always have the most-significant bit set out of the, say, 1024
bits possible. That prime then becomes a 1023-bit prime.
Many device drivers roll-over-and-die because of this, and that's just a bug.
Align things to 1024 for the hardware, but don't limit the user because it
adds a few bits to a device driver.
I have not yet seen a compelling performance case for not handling small
aberrations in size in the device driver. I will gladly accept real-world
data that indicates accepting 1023 or 1022 bit primes will slow down
performance to an unacceptable level.
Dan
From owner-ipsec@lists.tislabs.com Tue Nov 5 08: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 gA5GgQv00519;
Tue, 5 Nov 2002 08:42:26 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23465
Tue, 5 Nov 2002 11:12:06 -0500 (EST)
Date: 5 Nov 2002 10:51:22 -0500
Message-ID: <002001c284e3$31955cb0$1e72788a@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: "'ipsec'" <ipsec@lists.tislabs.com>
Subject: RE: Fwd: Re: IKEv2 Key Size Conformance Requirements
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1256"
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: <002e01c28494$382a07a0$45bbfea9@amanda2>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I still haven't figured out what the big deal is. If someone wants to use a
1022 bit key, can't they just call it a 1024 bit key where the 2 leading
bits are zero? Is there some RSA chip/library out there that assumes that
the high bit is a 1? The math works either way.
Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ahmed Bin
> Abbas Ahmed
> Ali Adas
> Sent: Tuesday, November 05, 2002 1:26 AM
> To: sommerfeld@east.sun.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
>
>
> Bill
>
> All of us know that 1024 bits key makes 128 - 8 bit bytes, since the
> computer industry is shifting more and more to embedded
> cryptography, i.e in
> the VLSI chips. I believe we should keep the pattern of
> integral multiples
> of bytes. In other words we keep the 1024 bits keys.
>
> Regards
>
> Ahmed Adas
> alaadas@kaau.edu.sa
>
> ----- Original Message -----
> From: "Bill Sommerfeld" <sommerfeld@east.sun.com>
> To: <Charlie_Kaufman@notesdev.ibm.com>
> Cc: "Peter Gutmann" <pgut001@cs.auckland.ac.nz>;
> <ipsec@lists.tislabs.com>;
> <owner-ipsec@lists.tislabs.com>
> Sent: Monday, November 04, 2002 9:13 PM
> Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
>
>
> > > My opinion is that the conservative course is to only require
> > > support of 1024 and 2048 bit keys, but I really don't
> much care (so
> > > long as we make a decision).
> >
> > Unless someone can demonstrate there's a meaningful difference in
> > security between a 1022-bit and a 1024-bit key, may I suggest that
> > Postel's rule of thumb ("Be liberal in what you accept and
> > conservative in what you send") applies here?
> >
> > - MUST generate keys with moduli which are exactly at
> these bit sizes
> > - SHOULD accept keys with moduli even if slightly smaller than the
> mandatory
> > sizes.
> >
> > - Bill
> >
>
From owner-ipsec@lists.tislabs.com Tue Nov 5 09:07: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 gA5H7sv02145;
Tue, 5 Nov 2002 09:07:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23574
Tue, 5 Nov 2002 11:38:43 -0500 (EST)
Message-Id: <200211051639.gA5GdBf9007790@kebe.east.sun.com>
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
In-Reply-To: <002001c284e3$31955cb0$1e72788a@ca.alcatel.com> from Andrew Krywaniuk
at "Nov 5, 2002 10:51:22 am"
To: andrew.krywaniuk@alcatel.com
Date: Tue, 5 Nov 2002 11:39:11 -0500 (EST)
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
First off, please send plaintext e-mails, folks. I'm getting sick of seeing:
> [Charset windows-1256 unsupported, skipping...]
Anyway...
> I still haven't figured out what the big deal is. If someone wants to use a
> 1022 bit key, can't they just call it a 1024 bit key where the 2 leading
> bits are zero? Is there some RSA chip/library out there that assumes that
> the high bit is a 1? The math works either way.
Hardware people need 1024 bits, even if it's leading-0-padded. Some (very
broken) software bignum implementations can't deal with leading zeroes.
Fortunately, it usually takes just one well-placed example and the bugs get
fixed. Unfortunately, there's a lot of brain-damage in the world.
Dan
From owner-ipsec@lists.tislabs.com Tue Nov 5 13:52: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 gA5Lq0v18851;
Tue, 5 Nov 2002 13:52:00 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24236
Tue, 5 Nov 2002 16:10:20 -0500 (EST)
Message-Id: <200211052110.gA5LAAm3020939@marajade.sandelman.ottawa.on.ca>
To: andrew.krywaniuk@alcatel.com
cc: "'ipsec'" <ipsec@lists.tislabs.com>
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
In-reply-to: Your message of "05 Nov 2002 10:51:22 EST."
<002001c284e3$31955cb0$1e72788a@ca.alcatel.com>
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 05 Nov 2002 16:10:10 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Andrew" == Andrew Krywaniuk <andrew.krywaniuk@alcatel.com> writes:
Andrew> I still haven't figured out what the big deal is. If someone wants to use a
Andrew> 1022 bit key, can't they just call it a 1024 bit key where the 2 leading
Andrew> bits are zero? Is there some RSA chip/library out there that assumes that
Andrew> the high bit is a 1? The math works either way.
Well, the OpenSSH people think that this is "broken", that you'd have a 1022
bit key. I think that this reflects a misunderstanding of how public key
cryptography works.
I agree with you, however.
] 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 Debian GNU/Linux using, kernel hacking, security guy"); [
From owner-ipsec@lists.tislabs.com Tue Nov 5 14:50: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 gA5Mo6v20845;
Tue, 5 Nov 2002 14:50:06 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24463
Tue, 5 Nov 2002 17:20:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f06b9edf48ac57b@[165.227.249.18]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 5 Nov 2002 14:20:53 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Adding revised identities to IKEv2
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Greetings again. draft-ietf-ipsec-ikev2-03 adds some new functionality
to IKEv2, but doesn't cover better use of identities and certificates.
This idea got some support on the list a while ago, but it might have
been hard for people to see how it would affect IKEv2. I propose the
following changes to draft-ietf-ipsec-ikev2-03; do others agree?
----------
In section 3, change the format of the four messages.
Change message 1 from:
HDR, SAi1, KEi, Ni
to:
HDR, SAi1, KEi, Ni, IDAccepted [, TrustedRoot]
Change message 2 from:
HDR, SAr1, KEr, Nr, [CERTREQ]
to:
HDR, SAr1, KEr, Nr, IDAccepted [, TrustedRoot]
Change message 3 from:
HDR, SAi1, KEi, Ni, Nr,
SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr}
to:
HDR, SAi1, KEi, Ni, Nr,
SK {FullID, IDAccepted, [IDr,]
AUTH, SAi2, TSi, TSr}
Change message 4 from:
HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
to:
HDR, SK {FullID, IDAccepted, AUTH,
SAr2, TSi, TSr}
----------
At the end of section 3.1, add:
In order to prevent a downgrade attack (where the attacker elides
identity types from an IDAccepted payload that the attacker cannot
spoof), messages 3 contains an exact copy of the IDAccepted payload from
message 2, and Message 4 contains an exact copy of the IDAccepted
payload from message 1. The IDAccepted payload in message 3 MUST be an
exact copy of the IDAceepted payload from message 2. The IDAccepted
payload in message 4 MUST be an exact copy of the IDAceepted payload
from message 1.
----------
In section 4.15 (Authentication of the IKE-SA), remove the first
sentence of the third paragraph ("Optionally, message 3...").
----------
Add a new section 4.16, and bump the numbers of the rest of the
subsections in section 4.
4.16 Identities and certificates
IKEv2 fixes 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. The fix covers both topics at once because they are
related. In doing so, it removes the certificate, certificate request,
or ID payloads from IKEv1 and replaces them with the TrustedRoot,
IDAccepted, and FullID payloads, which have very different semantics.
Messages 1 and 2 MAY include a TrustedRoot payload. The TrustedRoot
payload includes a series of one or more PKIX [PKIX] keyIdentifiers of
roots trusted by the sender. This payload is completely optional and is
used only to inform the recipient of what capabilities the sender has.
Messages 1 and 2 MUST include exactly one IDAccepted payload. The
payload holds a series of one or more fields indicating the FullID types
that the sender will accept. The receiver MUST NOT send any FullID
payloads in messages 3 or 4 that are not listed in the sender's
IDAccepted payload. Messages 3 and 4 MUST include exactly one FullID
payload.
----------
Replace 5.5 (Identification Payload), 5.6 (Certificate Payload), and
5.7 (Certificate Request Payload) with the following three sections.
5.5 FullID Payload
The FullID Payload, denoted FullID in this memo, allows peers to
identify themselves to each other. The FullID Payload appears in
messages 3 and 4, and names the identity associated with the AUTH
payload.
The FullID Payload consists of the IKE generic header followed by
identification fields as follows:
1 2 3
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Identification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FullID Payload Format
o ID Type (1 octet) - Specifies the type of Identification being
used.
o RESERVED - MUST be sent as zero; MUST be ignored.
o Identification Data (variable length) - Value, as indicated by
the Identification Type. The length of the Identification Data
is computed from the size in the ID payload header.
The payload type for the Identification Payload is XXXX. ****This
should not be 5; that is, we should not re-use the payload number
from IKEv1's Identity payload.*****
The following table lists the assigned values for the FullID
Type field, followed by a description of the Identification Data
which follows:
The payload's
format is an ID type followed by the content. The ID types are:
ID Type Value
------- -----
RESERVED 0
PKIX certificate 1
A standalone PKIX certificate.
Certificate bundle 2
A simple ASN.1 sequence of PKIX certificates. A bundle can have
end-entity certificates and/or certificates from a chain to a
root. The first certificate in the bundle is the sender's
preferred identity certificate, but beyond that there is no
meaning to the ordering.
Hash-and-URL of PKIX certificate 3
The first 20 octets are the SHA-1 hash of a certificate; the
rest is a URL that resolves to the certificate. This is
described in more detail below.
URL to a PKIX certificate bundle 4
This is described in more detail below.
PKIX keyIdentifier 5
Identifies a self-signed certificate that the receiver has
already pre-loaded. Note that this is only useful when using
self-signed certificates.
IDForSharedSecret 6
This is only for use with shared secrets. It is an ASCII
string (all octets are 31 < x < 127) of any length.
5.5.1 Using URLs and caching certificates
For FullID types 3 and 4, the URL scheme must be "http", although it can
be on any port number. The URL can be to a persistent repository, or it
might be to the initiating machine (such as for a remote access client).
If a recipient uses FullID type 3, it might cache the certificate with
the hash as an index, or the certificate can be retrieved from the URL.
Of course, retrieving a certificate from a URL means many more round
trips before the key exchange protocol can finish. On the other hand, if
the certificate has been cached, no additional processing is needed and
the certificate does not need to be sent in the UDP-based protocol.
If a system that is using certificates knows that it cannot resolve URLs
(for example, because it is not yet on the Internet), it SHOULD use
FullID types 1 and 2 in its IDAccepted payload. If a system can resolve
URLs, it SHOULD use type 3 and 4 unless it is sure that it does not have
the certificate of the other side, such as if it has just recovered from
a crash and its cache is empty. All systems should be able to handle
certificate bundles because the other party might have multiple
identities which have different certificates.
5.6 IDAccepted Payload
The IDAccepted Payload, denoted IDAccepted in this memo, specifies
the FullID types that the sender allows the recipient to use.
The IDAccepted Payload is defined as follows:
1 2 3
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Number of IDs ! RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ < ID types > ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: IDAccepted Payload Format
o Number of IDs (1 octet) - This field indicates the number
of ID types in the payload.
o RESERVED - MUST be sent as zero; MUST be ignored.
Each additional octet is a unique FullID Type expressed as a single
octet.
The payload type for the Identification Payload is XXXX. ****This
should not be 6; that is, we should not re-use the payload number
from IKEv1's Certificate payload.*****
5.7 TrustedRoot Payload
The TrustedRoot Payload, denoted TrustedRoot in this memo,
provides a means to specify the root certificates that the sender
implicitly trusts.
The TrustedRoot Payload is defined as follows:
1 2 3
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 !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Num of keyIDs ! RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ <keyIdentifiers of roots> ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TrustedRoot Payload Format
o Number of keyIDs (1 octet) - This field indicates the number
of keyIdentifiers in the payload.
o RESERVED - MUST be sent as zero; MUST be ignored.
The rest of the payload is the
o keyIdentifiers (variable length) - Contains an keyIdentifiers
of certificates, concatenated. keyIdentifiers are SHA-1 hashes,
so each keyIdentifier is always 20 octets long. The structure and
semantics of keyIdentifiers are defined in [PKIX].
The payload type for the TrustedRoot Payload is XXXX. ****This
should not be 7; that is, we should not re-use the payload number
from IKEv1's Certificate Request payload.*****
----------
Additional notify messages for section 5.10.1:
CERT-NOT-FOUND-AT-URL 36
Could not get the certificate through the URL that was given in the
FullID type 3 payload. This could be due to connectivity problems,
an error from the HTTP server, a malformed URL, or a host of other
reasons.
CERT-BUNDLE-NOT-FOUND-AT-URL 37
Could not get the certificate bundle through the URL that was given
in the FullID type 4 payload. This could be due to connectivity
problems, an error from the HTTP server, a malformed URL, or a host
of other reasons.
MALFORMED-CERT-BUNDLE 38
The certificate bundle was malformed.
NO-CERT-MATCHES-KEYID 39
Could not find the certificate that matches the keyIdentifier in the
FullID type 5 payload.
ID-FOR-SHARED-SECRET-NOT-USABLE 40
Could not use the IDForSharedSecret in the FullID type 6 payload.
This could be due to the ID not being recognized, or it being
recognized but it resulted in an failed signature validation.
----------
Add the following to section 7 (Security Considerations):
Sending a TrustedRoot payload exposes information about the sender of
the payload to a passive attack. The attacker can determine
information about the sender, such as which roots the sender trusts.
For users in a corporate environment, the TrustedRoot payload may
reveal who the sender's employer.
An attacker snooping on a receiver can learn the identity of the
senders who use certificates that are not cached by the receiver by
watching the HTTP traffic generated from the receiver.
----------
Add the following to section 10 (References)
[PKIX] Housley, R., et. al., "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3280, April 2002.
----------
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Tue Nov 5 17:25: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 gA61PHv27107;
Tue, 5 Nov 2002 17:25:18 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24768
Tue, 5 Nov 2002 19:48:17 -0500 (EST)
Message-ID: <9F5E83E17008D31193DD0090274E75050FC97F63@mailhost.bridgew.edu>
From: "Georgion, Thomas" <TGEORGION@bridgew.edu>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Question regarding old Key Recovery information
Date: Tue, 5 Nov 2002 19:50:06 -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
Hello,
I'm also writing my dimploma thesis on an element of IPSec and I would like
to know if anyone on this list knows where any of the old research
information is on IPSec key recovery. I've been able to dredge up a ton of
information relating to relevent internet drafts etc... but it seems that
all of the research is no longer easily available online.
To clarify I'm not writing my thesis on key recovery and do recognize that
the technology is very, very dead. Rather I am writing on integrating
transport protected IPSec LAN's with Network based IDS, and the ideas that
were developed for secure key transmission would be very valuable to me.
Has anyone researched integrating IPSec with NIDS, especially through
changes during IKEv2?
Thanks much!
From owner-ipsec@lists.tislabs.com Tue Nov 5 23:47: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 gA67lZv26048;
Tue, 5 Nov 2002 23:47:35 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA25515
Wed, 6 Nov 2002 02:14:32 -0500 (EST)
Message-Id: <4.3.2.7.2.20021105223954.16da4990@mira-sjcm-4.cisco.com>
X-Sender: cmadson@mira-sjcm-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 05 Nov 2002 23:14:35 -0800
To: Jari Arkko <jari.arkko@kolumbus.fi>
From: Cheryl Madson <cmadson@cisco.com>
Subject: Re: request to review draft in mobile IP wg
Cc: ipsec@lists.tislabs.com, Vijay Devarapalli <vijayd@iprg.nokia.com>,
Francis Dupont <Francis.Dupont@enst-bretagne.fr>,
Michael Thomas <mat@cisco.com>, kmiles@cisco.com, kleung@cisco.com,
alpesh@cisco.com
In-Reply-To: <3DBD6768.70207@kolumbus.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 08:35 AM 10/28/2002, Jari Arkko wrote:
>Hi,
>
>I'd like to ask the help of the IPsec WG to take a look at a draft
>which is being worked on in the Mobile IP working group.
<snip>
Jari,
[Speak up if the formatting comes out too weird; I think I stripped
all of the residual formatting from cut-and-paste, but it's hard to
tell...]
I've taken a quick pass through the draft. It's a great improvement
over previous drafts -- I can almost understand it now ;-).
I have several comments, split up into issues and comments. Some
of this may be simply because I don't fully understand MIP, but it
probably wouldn't hurt to have a bit more detail for those in the
IPsec-geek-but-MIP-novice camp (and who may find the main draft
more than a little intimidating...).
Issues:
a. I'd understood that MobileIP supported its own tunnels between
a MN and an HA. Is the intent that these IPsec tunnels (which
don't simply represent a securing of MobileIP tunnels) are
replacing the MobileIP tunnels?
b. Sequence of events relative to changeover of addresses relative to
changing IKE and/or IPsec endpoints. This issue is glossed over too
much in this draft; this should be spelled out in much greater detail.
[This is the area that makes me the most nervous, since there is so
little detail; I can't convince myself that things will behave properly.]
+ When should new CoA be used? Immediately? Upon completion of the
BU/BA exchange?
+ What happens if BU or BA is dropped?
+ May need recommendations as to how to handle address change
during a rekey -- there is a potential for higher chance of lost
packets,
at least in the short term. If out-of-sequence events cause more
retransmissions in a shorter period of time, this could become
problematic for certain types of devices in this space.
+ May need recommendations as to how to handle address change for
things like dead peer detection/keepalives. [I'll ask (cringingly
-- is that
a word?) -- would NAT also be a possibility in this scenario?]
c. What differences, if any, are there when a MN acts as a MR?
d. Is it possible for a MN to have several simultaneous connections to
different HAs? How does this scenario play out relative to this draft?
e. There is no hiding of the home address-to-COA binding. It might not hurt
to point this out. Is this acceptable?
f. Relative to packet handling for BU/BA and PD/PA messages:
are there other scenarios where the value in the Home Address Option/
RH2 headers should not override the address in the v6 header? If so,
how will a node be able to distinguish?
Comments
a. Buried amongst the discussion of manual keying, there is a
comment about dealing with new prefixes. Why is this not
mentioned at all until here -- why isn't this discussed earlier
in the general processing discussions, or at least in the
Requirements chapter? Also, it seems like the text in this section
and the dynamic keying section could be better aligned.
+ Are all of these addresses active at once? What triggers their
usage?
b. Very little is said of IKE in the requirements section. I'd like to see
more
of an outline of the requirements of MNs and HAs relative to IKE in this
section.
c. What is the granularity of a "user" relative to a MN? Can a MN support more
than one user? (Do they get separate home addresses? Share a home
address? ??) If so, how is that associated with traffic selectors
(which traffic
selectors are associated with which user)?
d. Something that just came off the top of my head, so I've done no analysis
whatsoever: has there been any analysis of a separate step for
performing
address mapping on IKE and IPsec packets (e.g. they do their processing
based on home address, and something else maps between that and the
CoA)? [I probably should be appalled at myself for that suggestion...]
+ IKE should already be selecting its SAs based on cookies.
+ ESP would have no affect. AH could be done with the home address
in the outer IPv6 header.
I didn't have time to look at the base draft. And I don't think I'll have
time to revisit
this draft in any detail anytime soon... but I'll try to keep an eye on
this thread
when I get the time, or we can talk in Atlanta.
thx (Kiitos ;-) - C
====================================
Cheryl Madson
Core IP Engineering; Security and Services
Cisco Systems, Inc.
cmadson@cisco.com
From owner-ipsec@lists.tislabs.com Wed Nov 6 06:45: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 gA6EjAv10332;
Wed, 6 Nov 2002 06:45:10 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26392
Wed, 6 Nov 2002 09:13:13 -0500 (EST)
content-class: urn:content-classes:message
Subject: IKEv2 and legacy Authentication
MIME-Version: 1.0
Date: Wed, 6 Nov 2002 11:23:13 +0100
Content-Type: multipart/signed;
boundary="----=_NextPart_000_0000_01C28586.E4DEBE30";
protocol="application/x-pkcs7-signature";
micalg=SHA1
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <28C92BFE6EB5C943B15743D0E11E60360467D2@rumba.cefriel.it>
X-MS-Has-Attach: yes
Thread-Topic: IKEv2 and legacy Authentication
Thread-Index: AcKFfoLEoPw3pjk5QeiOOVz5LMTTAA==
From: "Antonio Forzieri" <antonio.forzieri@cefriel.it>
To: <ipsec@lists.tislabs.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0000_01C28586.E4DEBE30
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hi,
I've read draft-ietf-ipsec-revised-identity-00.txt and I agree with Paul
Hoffman's idea of integrating Ikev2 with this draft.
I also read about the opprtunity of using legacy authentication with
Ikev2 however, what i can't understand is the way this kind of
authentication should work.
What should contain FullID payload in that case? (for example in
username and password scenario)
>From draft-ietf-ipsec-revised-identity-00.txt:
[CITE]
As simple scenario is username-and-password. The IDForSharedSecret is
the username, and the key added to the HMAC is the password.
[CITE]
What does it means?
Can one peer use Legacy authentication (remote user) and the other peer
(the SGTW) use another kind of auth (X.509 cert)?
Thanks
--
Antonio Forzieri
------=_NextPart_000_0000_01C28586.E4DEBE30
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpDCCAy0w
ggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0
ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx
KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA
dGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJa
QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u
MSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBl
cnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp
19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRu
RKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex
2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEA
x+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7S
bGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oH
dYsM3VGEa+T40c53ooEwggMzMIICnKADAgECAgMIKcswDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UE
ChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29u
YWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMjA4MjgxMDA0NTlaFw0wMzA4MjgxMDA0NTla
MGwxETAPBgNVBAQTCEZvcnppZXJpMRAwDgYDVQQqEwdBbnRvbmlvMRkwFwYDVQQDExBBbnRvbmlv
IEZvcnppZXJpMSowKAYJKoZIhvcNAQkBFhthbnRvbmlvLmZvcnppZXJpQGNlZnJpZWwuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDP0SjpMF0xFARSnLZ/iP7YJx67uSiSQF4sN3xx
bmlUUOqxl7mLPlfRd7GHFhyh/3ZRW4twyJoBN3+WkZ+av45LrL05+sEcUQSgjFF/PREOHkKrGQNr
xi3FEtQy0fHrNYSdMfNpsUBUVoFGGpXU+oDldhB5IY9/URASg/Us4dMs7tGxBvoDdUslOzv+Tl5z
/Ex9jxIsKEjqMh755L2EWxJqamCwmNIdjYMSgnW8XyFVe7aU2+gPX3HHmtzeJAkyjsN5RX++/xct
ax4/avUkjrQ/xiIibLf+7A1U/59FXrH5vQEhY9mL/MMimcdNiadX9OHTiR4vqetomG/gmkCQihw3
AgMBAAGjODA2MCYGA1UdEQQfMB2BG2FudG9uaW8uZm9yemllcmlAY2VmcmllbC5pdDAMBgNVHRMB
Af8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBANe26j/NbV8+kIU9mx6FjfO+GJdMA6dWK/SjjdcPLrSw
DjscDORyWpNKLiQAX7OJBLjmuoQT0XagvO84C84HkJtKLIGnh0WNx+6QcT1Snn6Cg3kvGqHeRx2c
EhS5sPZ5ONV6q4Na5h2Is5a5a5ZgknhvsKbRXbERZ2s1oVtP//BgMIIDODCCAqGgAwIBAgIQZkVy
t8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGlu
ZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp
bEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIxCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMG
VGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPH
CSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW
3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAt
CYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEt
Mjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGx
S0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwb
vAP0teuiR59sogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0ie
zqWf54TYyWJirQXGMYIDKzCCAycCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0
ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD
ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu
OC4zMAIDCCnLMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTAyMTEwNjEwMjMxM1owIwYJKoZIhvcNAQkEMRYEFI1WW7+7deJ6YIrC26v+qjVV
LKi3MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH
MA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93
bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE
AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCnLMA0GCSqGSIb3DQEBAQUABIIB
AIClrlXUiPZ5eT0uOAsrBm17aUVzAP0IimJNQ9Iw1mkXVWIai01qLERorVGcJ7qHLzS/bnxQsxD0
Kh5vXtSCwAVp5ChYARJqaUxZ2dfkGlIxX9RyNcLOdnLMYcNB+yf57SJ3a7MAArA5R6vCMSL3kMtI
FSslEd1ZGn6hvNFLng7YH69UWOex7chWlp6oKXzZFq1YK9GnB8WBLdYtJlVysb1Rnt/nFBbzt6LC
f5w5zufN0IsQoNq09BnYuEMxvKAhqNS24RuRkC27GknZZiem3llJ7rQiU55q2QupD83eCO2smlzv
WrQGSbeYCT/HGRWVorxUYhTLHUiHl6rt5Vd5PmIAAAAAAAA=
------=_NextPart_000_0000_01C28586.E4DEBE30--
From owner-ipsec@lists.tislabs.com Wed Nov 6 06:46: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 gA6EkDv10396;
Wed, 6 Nov 2002 06:46:13 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26400
Wed, 6 Nov 2002 09:14:13 -0500 (EST)
Message-Id: <200211061130.GAA12299@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-udp-encaps-04.txt
Date: Wed, 06 Nov 2002 06:30:04 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : UDP Encapsulation of IPsec Packets
Author(s) : A. Huttunen et al.
Filename : draft-ietf-ipsec-udp-encaps-04.txt
Pages : 0
Date : 2002-11-5
This draft defines methods to encapsulate and decapsulate
IP Encapsulating Security Payload (ESP) packets inside UDP packets
for the purpose of traversing Network Address Translators.
ESP encapsulation as defined in this document is capable of being
used in both IPv4 and IPv6 scenarios. The encapsulation is used
whenever negotiated using Internet Key Exchange (IKE).
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-04.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-udp-encaps-04.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-04.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2002-11-5193241.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-udp-encaps-04.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2002-11-5193241.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Wed Nov 6 07: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 gA6FJjv12280;
Wed, 6 Nov 2002 07:19:45 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26854
Wed, 6 Nov 2002 09:52:14 -0500 (EST)
Message-Id: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Tue, 05 Nov 2002 14:20:53 PST.
<p05200f06b9edf48ac57b@[165.227.249.18]>
Date: Wed, 06 Nov 2002 15:52:18 +0100
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:
Greetings again. draft-ietf-ipsec-ikev2-03 adds some new functionality
to IKEv2, but doesn't cover better use of identities and certificates.
=> I really prefer your way to deal with identities/certificates than
the traditional IKEv[12] one with its unspecified link between identities
and addresses. But it shows we have to understand exactly what could/should
be the usage of addresses in key management protocols too (see after).
A little point: if the URL is to the initiating machine there can be
some bootstrap problems (to get it can need an IPsec-protected connection
to the initiator), so this case should be added to the unresolvable URLs.
Thanks
Francis.Dupont@enst-bretagne.fr
PS: according to IKEv2 drafts, IKE implicitly sets up IPsec SAs
for the same IP addresses it runs over, so these addresses are important:
- they are not protected at all, this opens the door to Dos attacks
(not against IKE, but using IKE to redirect traffic) and ables
NAT traversal for IKE messages.
- if they were protected or if the network is trust to keep them
unchanged in route, the peer can be trusted or not to put its proper
address.
- the fact IKE needs more than a sigle exchange of two packets, one each
way, gives a weak proof the peer is really at its address (this is
the "return routability" proof).
- if the address is bound to the authentication (for instance the address
is an alternate subject name of the certificate) a strong proof is
available but without a specified way to control its use.
From owner-ipsec@lists.tislabs.com Wed Nov 6 11:31: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 gA6JVpv28233;
Wed, 6 Nov 2002 11:31:51 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27438
Wed, 6 Nov 2002 13:47:48 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15817.23906.865682.76556@thomasm-u1.cisco.com>
Date: Wed, 6 Nov 2002 10:20:18 -0800 (PST)
To: Stephen Kent <kent@bbn.com>
Cc: Teemu Alakoski <teemu.alakoski@tut.fi>, ipsec@lists.tislabs.com
Subject: MTU considerations (was: Public key distribution methods?)
In-Reply-To: <p0510030db9ec7344cc68@[128.89.88.34]>
References: <20021104100331.GA17307@alakoski.ton.tut.fi>
<p0510030db9ec7344cc68@[128.89.88.34]>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent writes:
> To be fair, there are some limitations with this approach. First, it
> means moving more bits across the wire during SA establishment, and
> we have seen some problems re fragmentation when the IKE UDP packets
> get big, e.g., as a result of packing in too many certs/CRLs.
Honestly, I'm sort of surprised that this wg
hasn't been bludgeoned by the transport police
about this. My understanding is that certs are
quite often in and of themselves bigger than
ethernet max MTU which means that IKE phase I is
fragmenting in a significant set of cases.
Should this have been reflected in the
requirements? I'm not suggesting a solution here,
but I'd think that for large VPN concentrators
during restart conditions this may be an not
insignificant issue.
Mike
From owner-ipsec@lists.tislabs.com Wed Nov 6 12:57: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 gA6Kvrv04839;
Wed, 6 Nov 2002 12:57:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27570
Wed, 6 Nov 2002 14:58:13 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f09b9ef24a321e7@[165.227.249.18]>
In-Reply-To: <15817.23906.865682.76556@thomasm-u1.cisco.com>
References: <20021104100331.GA17307@alakoski.ton.tut.fi>
<p0510030db9ec7344cc68@[128.89.88.34]>
<15817.23906.865682.76556@thomasm-u1.cisco.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Wed, 6 Nov 2002 11:58:20 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: MTU considerations (was: Public key distribution methods?)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:20 AM -0800 11/6/02, Michael Thomas wrote:
>I'm not suggesting a solution here,
Er, I did. Yesterday, as a matter of fact. :-) See my message about
adding the revised identity to IKEv2.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Wed Nov 6 16:09: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 gA709lv13748;
Wed, 6 Nov 2002 16:09:47 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27983
Wed, 6 Nov 2002 18:34:32 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15817.38776.163098.368771@thomasm-u1.cisco.com>
Date: Wed, 6 Nov 2002 14:28:08 -0800 (PST)
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Cc: ipsec@lists.tislabs.com
Subject: Re: MTU considerations (was: Public key distribution methods?)
In-Reply-To: <p05200f09b9ef24a321e7@[165.227.249.18]>
References: <20021104100331.GA17307@alakoski.ton.tut.fi>
<p0510030db9ec7344cc68@[128.89.88.34]>
<15817.23906.865682.76556@thomasm-u1.cisco.com>
<p05200f09b9ef24a321e7@[165.227.249.18]>
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 Hoffman / VPNC writes:
> At 10:20 AM -0800 11/6/02, Michael Thomas wrote:
> >I'm not suggesting a solution here,
>
> Er, I did. Yesterday, as a matter of fact. :-) See my message about
> adding the revised identity to IKEv2.
Ah, sorry. Insert standard hopelessly behind disclaimer :)
Mike
From owner-ipsec@lists.tislabs.com Wed Nov 6 16:40: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 gA70ejv15020;
Wed, 6 Nov 2002 16:40:45 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28062
Wed, 6 Nov 2002 19:11:42 -0500 (EST)
Message-ID: <1b5e89839d24839d709e637969682af73dc9afc1@watchguard.com>
From: James Huang <james.huang@watchguard.com>
To: ipsec@lists.tislabs.com, "'l2tpext@ietf.org'" <l2tpext@ietf.org>
Subject: UDP-encapsulated IPsec Transport mode
Date: Wed, 6 Nov 2002 16:11:46 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all,
In the appendix A of draft-ietf-ipsec-udp-encaps-04.txt, there is
some discussions on the issue of multiple clients running UDP-encapsulated
IPsec transport mode tunnels behind a NAT box. However, I did not find any
discussion on another related issue: In the traffic selector (ID) payload
the client sends out during quick mode exchange, should the client use its
own private address or the public routable address (i.e. the NAT box's
public IP address)? If it the later, how does the client know about that
public address? This seems to be a serious issue, especially for L2TP
voluntary tunnels secured by IPsec (in transport mode).
Regards,
James C. Huang
From owner-ipsec@lists.tislabs.com Wed Nov 6 17:09: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 gA719Sv16313;
Wed, 6 Nov 2002 17:09:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28116
Wed, 6 Nov 2002 19:40:07 -0500 (EST)
X-mProtect: <200211070040> Nokia Silicon Valley Messaging Protection
Message-ID: <3DC9B68E.AD251164@iprg.nokia.com>
Date: Wed, 06 Nov 2002 16:40:46 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Cheryl Madson <cmadson@cisco.com>
CC: Jari Arkko <jari.arkko@kolumbus.fi>, ipsec@lists.tislabs.com
Subject: Re: request to review draft in mobile IP wg
References: <4.3.2.7.2.20021105223954.16da4990@mira-sjcm-4.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi,
thanks for the comments. apologies for the lengthy mail.
Cheryl Madson wrote:
>
> Issues:
>
> a. I'd understood that MobileIP supported its own tunnels between
> a MN and an HA. Is the intent that these IPsec tunnels (which
> don't simply represent a securing of MobileIP tunnels) are
> replacing the MobileIP tunnels?
kind of/yes. as Francis Duponts would put it, MIPv6 and IPsec
should be tightly integrated :-)
> b. Sequence of events relative to changeover of addresses relative to
> changing IKE and/or IPsec endpoints. This issue is glossed over too
> much in this draft; this should be spelled out in much greater detail.
> [This is the area that makes me the most nervous, since there is so
> little detail; I can't convince myself that things will behave properly.]
>
> + When should new CoA be used? Immediately? Upon completion of the
> BU/BA exchange?
the MN starts using the new CoA as soon as it moves. it cant
use the old CoA anyway. the tunnel gateway address is also
changed immediately at the MN. at the Home Agent, the tunnel
gateway address is changed as soon as it processes a Binding
Update and updates its binding cache entry with the new CoA.
> + What happens if BU or BA is dropped?
until the binding cache entry at the home agent is updated with
the new CoA, all packets sent by the MN with newCoA are dropped.
so, till the BU reaches the home agent, MN loses packets. if BA
is dropped, no harm done.
as an aside, there is work going on in the Mobile IP WG on Fast
Handoffs for Mobile IPv6, which sets up a bi-directional tunnel
between the old access router and the new access router. the
mobile node can continue using old CoA, until the BU/BA exchange
for the new CoA is completed.
> + May need recommendations as to how to handle address change
> during a rekey -- there is a potential for higher chance of lost
> packets,
> at least in the short term. If out-of-sequence events cause more
> retransmissions in a shorter period of time, this could become
> problematic for certain types of devices in this space.
>
> + May need recommendations as to how to handle address change for
> things like dead peer detection/keepalives. [I'll ask (cringingly
> -- is that
> a word?) -- would NAT also be a possibility in this scenario?]
I will let Jari or Francis comment on this.
> c. What differences, if any, are there when a MN acts as a MR?
the MIPv6 drafts are only about mobile hosts. mobile routers are
not being considered here. infact there is another WG called NEMO
which is working on a mobility solution for a mobile router.
> d. Is it possible for a MN to have several simultaneous connections to
> different HAs? How does this scenario play out relative to this draft?
an MN can have multiple home addresses. but if all these home
addresses are from the same home link, then it has connections to
only one home agent. if the home addresses are from different
prefixes and different links, then it could have connections with
one home agent in each link. but I think the latter case does not
introduce any new issues.
> e. There is no hiding of the home address-to-COA binding. It might not hurt
> to point this out. Is this acceptable?
can you please elaborate? if the MN wants to hides its current
location from the CN, it can use reverse tunneling through the
home agent.
>
> f. Relative to packet handling for BU/BA and PD/PA messages:
> are there other scenarios where the value in the Home Address Option/
> RH2 headers should not override the address in the v6 header? If so,
> how will a node be able to distinguish?
I cant think of any scenarios. the Home Address Option and Routing
header Type 2 are always present on BU/BA and PD/PA messages if
the MN is not at home. and they should contain the correct address
at all times.
do you have a scenario in mind?
>
> Comments
>
> a. Buried amongst the discussion of manual keying, there is a
> comment about dealing with new prefixes. Why is this not
> mentioned at all until here -- why isn't this discussed earlier
> in the general processing discussions, or at least in the
> Requirements chapter? Also, it seems like the text in this section
> and the dynamic keying section could be better aligned.
> + Are all of these addresses active at once? What triggers their
> usage?
there a couple of subtle points here. the MN can have multiple
home address. it can also register the multiple home address
at the home agent by setting the 'S' bit to 0 (see base MIPv6
spec). but it need not have security associations based on
each home address, because it does not register each home
address individually.
so a new prefix on the home link does mean a new home address
for the MN. but it is not necessary for the MN to configure
a new SA.
but you are right, we should dicuss that in the requirements
section. I will do that.
regarding what triggers the MN to use a different home address,
we dont know yet.
> c. What is the granularity of a "user" relative to a MN? Can a MN support more
> than one user? (Do they get separate home addresses? Share a home
> address? ??) If so, how is that associated with traffic selectors
> (which traffic
> selectors are associated with which user)?
good question. I have to think about this a bit more before I
can answer.
regards
Vijay
From owner-ipsec@lists.tislabs.com Thu Nov 7 07:16: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 gA7FGVv02841;
Thu, 7 Nov 2002 07:16:31 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29641
Thu, 7 Nov 2002 09:42:10 -0500 (EST)
Message-Id: <200211071125.GAA10883@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-pki-profile-01.txt
Date: Thu, 07 Nov 2002 06:25:21 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : The Internet IP Security PKI Profile of ISAKMP and
PKIX
Author(s) : B. Korver, E. Rescorla
Filename : draft-ietf-ipsec-pki-profile-01.txt
Pages : 31
Date : 2002-11-6
ISAKMP and PKIX both provide frameworks that must be profiled for use
in a given application. This document provides a profile of ISAKMP
and PKIX that defines the requirements for using PKI technology in
the context of IPsec. The document compliments protocol specifica-
tions such as IKE, which assume the existence of public key certifi-
cates and related keying materials, but which do not address PKI
issues explicitly. This document addresses those issues.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-profile-01.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-pki-profile-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-pki-profile-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2002-11-6174856.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-pki-profile-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-pki-profile-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2002-11-6174856.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Thu Nov 7 07:16: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 gA7FGVv02842;
Thu, 7 Nov 2002 07:16:31 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29670
Thu, 7 Nov 2002 09:49:20 -0500 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: draft-ietf-ipsec-udp-encaps-04.txt
Date: Thu, 7 Nov 2002 15:49:41 +0100
Message-ID: <C691E039D3895C44AB8DFD006B950FB409AB38@lanmhs50.rd.francetelecom.fr>
Thread-Topic: I-D ACTION:draft-ietf-ipsec-udp-encaps-04.txt
Thread-Index: AcKFqvdbaaM9ItjaQCKtbRm7IbZfrAAwbw5g
From: "HOULLIER Francis FTRD/DMI/CAE" <francis.houllier@rd.francetelecom.com>
To: <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 07 Nov 2002 14:49:41.0984 (UTC) FILETIME=[E7975600:01C2866C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA29667
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all,
Is there any work around "TCP encapsulation of IPSec packets" ?
Thanks
From owner-ipsec@lists.tislabs.com Thu Nov 7 07:17: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 gA7FHjv02919;
Thu, 7 Nov 2002 07:17:46 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29656
Thu, 7 Nov 2002 09:45:12 -0500 (EST)
To: James Huang <james.huang@watchguard.com>
Cc: ipsec@lists.tislabs.com, "'l2tpext@ietf.org'" <l2tpext@ietf.org>
Subject: Re: UDP-encapsulated IPsec Transport mode
References: <1b5e89839d24839d709e637969682af73dc9afc1@watchguard.com>
From: Markus Stenberg <fingon@iki.fi>
Date: 07 Nov 2002 09:51:02 +0200
In-Reply-To: James Huang's message of "Wed, 6 Nov 2002 16:11:46 -0800"
Message-ID: <87bs51ddi1.fsf@navi.fingon.iki.fi>
Lines: 41
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
James Huang <james.huang@watchguard.com> writes:
> Hi all,
> In the appendix A of draft-ietf-ipsec-udp-encaps-04.txt, there is
> some discussions on the issue of multiple clients running UDP-encapsulated
> IPsec transport mode tunnels behind a NAT box. However, I did not find any
> discussion on another related issue: In the traffic selector (ID) payload
> the client sends out during quick mode exchange, should the client use its
> own private address or the public routable address (i.e. the NAT box's
> public IP address)? If it the later, how does the client know about that
> public address? This seems to be a serious issue, especially for L2TP
> voluntary tunnels secured by IPsec (in transport mode).
L2TP specific issues I am blissfully unaware of; however, because the NAT
boxes are not neccessarily even controlled by the IPsec user, sending the
public address is not really an option that can be supported everywhere.
Here's how the information flow goes as far as I see it:
Public address doesn't really need to be sent in any case as the remote
side's public address is the address we're talking IKE with (or at least
remote address+port combination, but in NAPT case you don't really have
more of an remote address in any case).
Private address that is used by the OS for actual traffic is provided
within the NAT-OA payload so the checksums et al can be corrected.
Therefore, at least as far as implementation I used to work on goes, ID
payload in transport mode case doesn't matter (I seem to recall we sent
private address, but pretty much ignored what was sent by remote).
-Markus
> Regards,
> James C. Huang
--
"Every program has (at least) two purposes: the one for which it was
written, and another for which it wasn't. "
>From ACM's SIGPLAN publication, (September, 1982), Article "Epigrams
in Programming", by Alan J. Perlis of Yale University.
From owner-ipsec@lists.tislabs.com Thu Nov 7 07:18: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 gA7FITv02971;
Thu, 7 Nov 2002 07:18:29 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29649
Thu, 7 Nov 2002 09:43:09 -0500 (EST)
Message-Id: <200211071125.GAA10870@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-nat-t-ike-04.txt
Date: Thu, 07 Nov 2002 06:25:17 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : Negotiation of NAT-Traversal in the IKE
Author(s) : T. Kivinen et al.
Filename : draft-ietf-ipsec-nat-t-ike-04.txt
Pages : 12
Date : 2002-11-6
This document describes how to detect one or more NATs between IPsec
hosts, and how to negotiate the use of UDP encapsulation of the IPsec
packets through the NAT boxes in IKE.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-04.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-nat-t-ike-04.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-04.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2002-11-6174848.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-nat-t-ike-04.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2002-11-6174848.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Thu Nov 7 10:43: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 gA7IhAv16439;
Thu, 7 Nov 2002 10:43:10 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00324
Thu, 7 Nov 2002 13:03:01 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100303b9f059fa064b@[128.89.88.34]>
In-Reply-To: <15817.23906.865682.76556@thomasm-u1.cisco.com>
References: <20021104100331.GA17307@alakoski.ton.tut.fi>
<p0510030db9ec7344cc68@[128.89.88.34]>
<15817.23906.865682.76556@thomasm-u1.cisco.com>
Date: Thu, 7 Nov 2002 12:58:59 -0500
To: Michael Thomas <mat@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: MTU considerations (was: Public key distribution methods?)
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:20 AM -0800 11/6/02, Michael Thomas wrote:
>Stephen Kent writes:
> > To be fair, there are some limitations with this approach. First, it
> > means moving more bits across the wire during SA establishment, and
> > we have seen some problems re fragmentation when the IKE UDP packets
> > get big, e.g., as a result of packing in too many certs/CRLs.
>
>Honestly, I'm sort of surprised that this wg
>hasn't been bludgeoned by the transport police
>about this. My understanding is that certs are
>quite often in and of themselves bigger than
>ethernet max MTU which means that IKE phase I is
>fragmenting in a significant set of cases.
>
>Should this have been reflected in the
>requirements? I'm not suggesting a solution here,
>but I'd think that for large VPN concentrators
>during restart conditions this may be an not
>insignificant issue.
>
The size of a cert varies depending on many things, including the
choice of name style. But in my experience it would be in accurate
to say that an individual cert is quite often bigger than the 1500
byte Ethernet MTU.
Steve
From owner-ipsec@lists.tislabs.com Thu Nov 7 11:33: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 gA7JXnv20695;
Thu, 7 Nov 2002 11:33:49 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00499
Thu, 7 Nov 2002 14:01:34 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f23b9f066010f60@[165.227.249.18]>
In-Reply-To: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Thu, 7 Nov 2002 11:01:20 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Adding revised identities to IKEv2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 3:52 PM +0100 11/6/02, Francis Dupont wrote:
> In your previous mail you wrote:
>
> Greetings again. draft-ietf-ipsec-ikev2-03 adds some new functionality
> to IKEv2, but doesn't cover better use of identities and certificates.
>
>=> I really prefer your way to deal with identities/certificates than
>the traditional IKEv[12] one with its unspecified link between identities
>and addresses.
Thank you.
>But it shows we have to understand exactly what could/should
>be the usage of addresses in key management protocols too (see after).
Why? What people have found from many years of VPN deployment is that
customers generally want one of two things:
- The ability to say "let any gateway with this identity set up any
kind of tunnel with me"
- The ability to say "let the gateway with this identity set up a
tunnel with these features"
For preshared secrets, there is no question of the identity. For PKIX
certificates, the identity problem is so convoluted, almost all
customers say "any identity is OK as long as the certificate
correctly chains to this trusted root". The identity is logged, but
the type of identity is not related to the ability to set up tunnels.
> A little point: if the URL is to the initiating machine there can be
>some bootstrap problems (to get it can need an IPsec-protected connection
>to the initiator), so this case should be added to the unresolvable URLs.
It would be silly to put your cert *behind* your gateway. But the
gateway itself might have a trivial HTTP server to allow access to
certs; in fact, this is what many people expect to happen.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Thu Nov 7 11:34: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 gA7JYbv20726;
Thu, 7 Nov 2002 11:34:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00498
Thu, 7 Nov 2002 14:01:29 -0500 (EST)
Message-ID: <b1a112598202f4c0432170cba25e2e903dcab88b@watchguard.com>
From: James Huang <james.huang@watchguard.com>
To: "'Markus Stenberg'" <fingon@iki.fi>
Cc: ipsec@lists.tislabs.com, "'l2tpext@ietf.org'" <l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Thu, 7 Nov 2002 11:01:33 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: Markus Stenberg [mailto:fingon@iki.fi]
> Sent: Wednesday, November 06, 2002 11:51 PM
> To: James Huang
> Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> Subject: Re: UDP-encapsulated IPsec Transport mode
>
>
> James Huang <james.huang@watchguard.com> writes:
> > Hi all,
> > In the appendix A of
> draft-ietf-ipsec-udp-encaps-04.txt, there is
> > some discussions on the issue of multiple clients running
> UDP-encapsulated
> > IPsec transport mode tunnels behind a NAT box. However, I
> did not find any
> > discussion on another related issue: In the traffic
> selector (ID) payload
> > the client sends out during quick mode exchange, should the
> client use its
> > own private address or the public routable address (i.e.
> the NAT box's
> > public IP address)? If it the later, how does the client
> know about that
> > public address? This seems to be a serious issue,
> especially for L2TP
> > voluntary tunnels secured by IPsec (in transport mode).
>
> L2TP specific issues I am blissfully unaware of; however,
> because the NAT
> boxes are not neccessarily even controlled by the IPsec user,
> sending the
> public address is not really an option that can be supported
> everywhere.
>
Agreed.
> Here's how the information flow goes as far as I see it:
>
> Public address doesn't really need to be sent in any case as
> the remote
> side's public address is the address we're talking IKE with
> (or at least
> remote address+port combination, but in NAPT case you don't
> really have
> more of an remote address in any case).
>
> Private address that is used by the OS for actual traffic is provided
> within the NAT-OA payload so the checksums et al can be corrected.
>
Let me describe the issue with regarding to L2TP/IPsec (voluntary L2TP) when
a NAT is present. Suppose a PC with a home network's private IP address V_1
is behind a NAT box with a public address P_1. The corporate network's
Security Gateway's IP address is P_2 and the PC wants to connect to a
corporate server with private IP address I_2. If everything goes well, this
PC will eventually obtain another private address I_1 from the corporate
network through IPCP . So the L2TP traffic sent by the PC will have the
following headers: IP/UDP/ESP/UDP/L2TP control or
IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will indicate the
traffic is sent from V_1 to P_2. The inner IP header will indicate the
traffic is sent from I_1 to I_2. The source IP address V_1 in the outer
header will be changed by the NAT box to P_1 on the way out. So the packet
received by the corporate SG is an UDP-encapsulated TRANSPORT mode IPsec
packet from P_1 to P_2 with UDP source port 1701 and UDP dest port 1701 in
the 2nd UDP header (assuming no dynamic UDP port for L2TP). To allow this
packet to pass through the SG, an inbound filter matching the packet must
exist in the SG. The inbound filter is dynamically created after a quick
mode exchange between the PC and the SG. To create such a filter in the SG,
the PC must specify < IP = P_1, proto = UDP, port = 1701> in ID_i during
the quick mode exchange. But how does this PC knows about P_1?
What I described above is a scenario specific to L2TP/IPsec. But in
general, any transport mode IPsec tunnel with a NAT box along its path will
have the same problem.
Am I right? Or I am missing something here?
- James Huang
> Therefore, at least as far as implementation I used to work
> on goes, ID
> payload in transport mode case doesn't matter (I seem to
> recall we sent
> private address, but pretty much ignored what was sent by remote).
>
> -Markus
>
> > Regards,
> > James C. Huang
>
> --
> "Every program has (at least) two purposes: the one for which it was
> written, and another for which it wasn't. "
>
> From ACM's SIGPLAN publication, (September, 1982), Article "Epigrams
> in Programming", by Alan J. Perlis of Yale University.
>
From owner-ipsec@lists.tislabs.com Thu Nov 7 12:45: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 gA7KjWv25535;
Thu, 7 Nov 2002 12:45:33 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00697
Thu, 7 Nov 2002 15:12:12 -0500 (EST)
From: Brian Korver <briank@briank.com>
Message-Id: <200211071959.gA7JxPq5008847@oe8.briank.com>
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <p05200f23b9f066010f60@[165.227.249.18]> "from Paul Hoffman / VPNC
at Nov 7, 2002 11:01:20 am"
To: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
Date: Thu, 7 Nov 2002 11:59:25 -0800 (PST)
CC: ipsec@lists.tislabs.com
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul Hoffman / VPNC writes:
> Why? What people have found from many years of VPN deployment is that
> customers generally want one of two things:
> - The ability to say "let any gateway with this identity set up any
> kind of tunnel with me"
> - The ability to say "let the gateway with this identity set up a
> tunnel with these features"
> For preshared secrets, there is no question of the identity. For PKIX
> certificates, the identity problem is so convoluted, almost all
> customers say "any identity is OK as long as the certificate
> correctly chains to this trusted root". The identity is logged, but
> the type of identity is not related to the ability to set up tunnels.
While we're on this topic, I'll interject that a reorganized but
largely the same draft-ietf-ipsec-pki-profile-01.txt is just out
and attempts to address these issues.
> It would be silly to put your cert *behind* your gateway. But the
> gateway itself might have a trivial HTTP server to allow access to
> certs; in fact, this is what many people expect to happen.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
-brian
briank@briank.com
From owner-ipsec@lists.tislabs.com Thu Nov 7 12:45: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 gA7Kjgv25562;
Thu, 7 Nov 2002 12:45:42 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00728
Thu, 7 Nov 2002 15:22:17 -0500 (EST)
From: mlafon@arkoon.net
X-Lotus-FromDomain: ARKOON
To: ipsec@lists.tislabs.com
Message-ID: <C1256C6A.006FCEE6.00@arkoon-mail.arkoon.net>
Date: Thu, 7 Nov 2002 21:21:58 +0100
Subject: Re: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>From draft-ietf-ipsec-nat-t-ike-04 :
| Keyword Decimal Description Reference
| ------- ------- ----------- ---------
| ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC XXXX]
What is this TCP port for ?
--
Mathieu Lafon - Arkoon Network Security
From owner-ipsec@lists.tislabs.com Thu Nov 7 13:21: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 gA7LLTv27260;
Thu, 7 Nov 2002 13:21:29 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00787
Thu, 7 Nov 2002 15:47:27 -0500 (EST)
Message-Id: <200211072011.PAA08965@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: "All.IETF.Working.Groups":;;;;@tislabs.com;;;
Subject: Note Well Statement
x-msg: NoteWell
Date: Thu, 07 Nov 2002 15:11:40 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================
NOTE WELL
All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.
Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to
- the IETF plenary session,
- any IETF working group or portion thereof,
- the IESG, or any member thereof on behalf of the IESG,
- the IAB or any member thereof on behalf of the IAB,
- any IETF mailing list, including the IETF list itself,
any working group or design team list, or any other list
functioning under IETF auspices,
- the RFC Editor or the Internet-Drafts function
Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.
From owner-ipsec@lists.tislabs.com Thu Nov 7 13:22: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 gA7LMcv27294;
Thu, 7 Nov 2002 13:22:38 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00839
Thu, 7 Nov 2002 15:57:36 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15818.54256.902876.454996@thomasm-u1.cisco.com>
Date: Thu, 7 Nov 2002 12:58:24 -0800 (PST)
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <p05200f23b9f066010f60@[165.227.249.18]>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05200f23b9f066010f60@[165.227.249.18]>
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 Hoffman / VPNC writes:
> At 3:52 PM +0100 11/6/02, Francis Dupont wrote:
> >But it shows we have to understand exactly what could/should
> >be the usage of addresses in key management protocols too (see after).
>
> Why? What people have found from many years of VPN deployment is that
> customers generally want one of two things:
> - The ability to say "let any gateway with this identity set up any
> kind of tunnel with me"
> - The ability to say "let the gateway with this identity set up a
> tunnel with these features"
> For preshared secrets, there is no question of the identity. For PKIX
> certificates, the identity problem is so convoluted, almost all
> customers say "any identity is OK as long as the certificate
> correctly chains to this trusted root". The identity is logged, but
> the type of identity is not related to the ability to set up tunnels.
Paul,
Allow me to rephrase this: authz with pre-shared
secrets is easy/possible and with PKIX is
hard/impossible? If so, why? Assuming you're not
talking about carrying authz information in the
certs themselves, I would think the binding of
auth to authz would be pretty much equivalent.
Mike
From owner-ipsec@lists.tislabs.com Thu Nov 7 13:37: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 gA7Lbmv29372;
Thu, 7 Nov 2002 13:37:48 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00894
Thu, 7 Nov 2002 16:08:47 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f2eb9f0865eab17@[165.227.249.18]>
In-Reply-To: <15818.54256.902876.454996@thomasm-u1.cisco.com>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05200f23b9f066010f60@[165.227.249.18]>
<15818.54256.902876.454996@thomasm-u1.cisco.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Thu, 7 Nov 2002 13:09:08 -0800
To: Michael Thomas <mat@cisco.com>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 12:58 PM -0800 11/7/02, Michael Thomas wrote:
>Paul Hoffman / VPNC writes:
> > At 3:52 PM +0100 11/6/02, Francis Dupont wrote:
> > >But it shows we have to understand exactly what could/should
> > >be the usage of addresses in key management protocols too (see after).
> >
> > Why? What people have found from many years of VPN deployment is that
> > customers generally want one of two things:
> > - The ability to say "let any gateway with this identity set up any
> > kind of tunnel with me"
> > - The ability to say "let the gateway with this identity set up a
> > tunnel with these features"
> > For preshared secrets, there is no question of the identity. For PKIX
> > certificates, the identity problem is so convoluted, almost all
> > customers say "any identity is OK as long as the certificate
> > correctly chains to this trusted root". The identity is logged, but
> > the type of identity is not related to the ability to set up tunnels.
>
>Paul,
>
>Allow me to rephrase this: authz with pre-shared
>secrets is easy/possible and with PKIX is
>hard/impossible?
No, that is a completely incorrect rephrasing of what I said. Most
VPN vendors have no problem with making IPsec work with certificates
as outlined above, and most users have no problem with using them in
that fashion.
>Assuming you're not
>talking about carrying authz information in the
>certs themselves, I would think the binding of
>auth to authz would be pretty much equivalent.
Sorry, I can't parse that last sentence. Could you restate it?
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Thu Nov 7 14:39: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 gA7MdMv03630;
Thu, 7 Nov 2002 14:39:22 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01069
Thu, 7 Nov 2002 17:02:34 -0500 (EST)
Message-ID: <008a01c286a9$c9df3a00$1e02a8c0@entrust.com>
From: "Greg Carter" <greg@carter-engineering.com>
To: <ipsec@lists.tislabs.com>
Cc: <briank@xythos.com>
References: <200211071125.GAA10883@ietf.org>
Subject: Re: I-D ACTION:draft-ietf-ipsec-pki-profile-01.txt
Date: Thu, 7 Nov 2002 17:05:31 -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.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Brian,
Looks good, some comments on the latest draft:
4.1.2.2.2. FQDN Host Names
Although clear to me, you may want to explicitly state that placing the FQDN
in the 'commonName' of the subject field does not mean that the commonName
field will or should be searched for a matching ID when binding an ID to
policy. The subject field of a certificate is treated as a whole when used
for secure policy ID mapping. You could reference section "3.2.9.2.
Identification Data other than a Single Address." Same for domain
component. You could add that 'commonName' and 'domainComponet' should be
treated as informational fields for an administrator, so that when the
certificate is viewed at an administration console it can be associated with
a particular piece of hardware, but it servers no other purpose on its own.
4.1.3.14. CRLDistributionPoint
I would add:
However receiving CRLs in band via ISAKMP does not alleviate the requirement
to process the CRLDistributionPoint if the certificate being validated
contains the extension and the CRL being used to validate the certificate
contains the IssuingDistributionPoint. Failure to validate the
CRLDistributionPoint/IssusingDistributionPoint pair can result in CRL
substitution where an entity knowingly substitutes a known good CRL for the
CRL which is supposed to be used which would show the entity as revoked.
See below for more comments.
4.2.3.5. IssuingDistributionPoint
I think you are confusing Delta CRLs with CRLDistributionPoints.
IssuingDistributionPoints should be used to verify that the
cRLDistributionPoint used to find the CRL (yes even those sent within IKE)
is the correct CRL to use to verify the certificate.
To clarify CRLDistributionPoints I'll give an example:
A CA that is using CRLDistributionPoints may do so to provide may "small"
CRLs; each only valid for a particular set of certificates issued by that
CA. To associate a CRL with a certificate the CA places the
CRLDistributionPoint extension in the certificate, and places the
IssuingDistributionPoint in the CRL. The
CRLDistributionPoint::DistributionPointName and the
IssuingDistributionPoint::DistributionPointName fields would be the same.
Lets assume that the CA has two CRLs, CRL1 and CRL2 which would be found at
cn=CRL1, ou=CA, o=SomeCompany, c=US
and
cn=CRL2, ou=CA, o=SomeCompany, c=US
CRL1 has an IssuingDistributionPoint with a value of "cn=CRL1, ou=CA,
o=SomeCompany, c=US" and CRL2 has an IssuingDistributionPoint of "cn=CRL2,
ou=CA, o=SomeCompany, c=US".
The CA issues two certificates CERT1 and CERT2, it decides that CRL1 will be
the place to find revocation information for CERT1. When issuing CERT1 the
CRLDistributionPoint extension is placed in the certificate with a value of
cn=CRL1, ou=CA, o=SomeCompany, c=US. CERT2 is issued but the
IssuingDistributionPoint for CRL2 is placed in the CRLDistributionPoint
extension.
Assuming a non IPSec environment: when an entity attempts to validate CERT1
the entity would find the CRLDistributionPoint of cn=CRL1, ou=CA,
o=SomeCompany, c=US in the certificate and fetch the CRL via LDAP from this
address. Since LDAP is not trusted, when verifying the CRL the entity must
verify that the CRL fetched from cn=CRL1, ou=CA, o=SomeCompany, c=US was in
fact delegated to hold revocation information for the certificate being
verified. To do this the IssuingDistributionPoint in the CRL is compared to
CRLDistributionPoint in the certificate. Without this comparison it is
possible to use the wrong CRL:
Given that CERT1 is revoked, and that somehow the attacker has placed CRL2
at cn=CRL1, ou=CA, o=SomeCompany, c=US in the LDAP directory. If when
validating the CRL retrieved from cn=CRL1, ou=CA, o=SomeCompany, c=US (which
is actually CRL2) the IssuingDistributionPoint is not compared to the
desired CRLDistributionPoint, the CRL will validate (signed by the same CA),
however CERT1 will not show up in the list of revoked certificates. So
CERT1 would appear valid.
How does this relate to IPSec and IKE? The only thing that is different is
the delivery mechanism for the CRL, replace LDAP with IKE. The same attack
is even easier since the peer will provide the CRLs to use to validate its
certificate. Without the CDP/IDP check it is easy to substitute one CRL for
another.
CRLDistributionPoints are desirable for IPSec/IKE environments because it
allows a subset of the revocation information to be passed to the peer.
Instead of 400k-1M+ CRLs you can have many small CRLs. If it were up to me
I might change the wording to encourage support of CRLDistributionPoints, at
least on the validation end to prevent CRL substitution when the issuing CA
is using them. I know of at least one CA that defaults to this type of CRL
use. Of course see PKIX docs for CDP intellectual rights.
Out of curiosity what CAs have you found that use Delta CRLs?
Greg
From owner-ipsec@lists.tislabs.com Thu Nov 7 14:46:02 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 gA7Mk1v03802;
Thu, 7 Nov 2002 14:46:01 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01105
Thu, 7 Nov 2002 17:13:40 -0500 (EST)
Date: 7 Nov 2002 16:53:22 -0500
Message-ID: <004901c286a8$1824fc60$1e72788a@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: "'ipsec'" <ipsec@lists.tislabs.com>
Subject: RE: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.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
Importance: Normal
In-Reply-To: <200211071125.GAA10870@ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I'm sure that a whole bunch of us are wondering: what's with the unspecified
vendor id?
Does this mean that the current draft is going to be the last one and all
further numbers will be assigned by IANA? (In that case, why would we need a
vendor id at all?)
Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.
From owner-ipsec@lists.tislabs.com Thu Nov 7 15:50:02 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 gA7No1v06856;
Thu, 7 Nov 2002 15:50:01 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01299
Thu, 7 Nov 2002 18:18:10 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Subject: RE: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.txt
Date: Thu, 7 Nov 2002 15:19:08 -0800
Message-ID: <2E33960095B58E40A4D3345AB9F65EC108388D92@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.txt
thread-index: AcKGrYKglV7viGsvSTmEPRTAnvGs0AABQ8Ww
From: "William Dixon" <wdixon@windows.microsoft.com>
To: <andrew.krywaniuk@alcatel.com>, "ipsec" <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 07 Nov 2002 23:19:03.0660 (UTC) FILETIME=[0FC502C0:01C286B4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA01296
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The authors believe this is the final version of the draft, that only
textual & format changes will be required by further IESG & RFC Editor
processing.
Could we have assigned a vendor ID that represents these that didn't
depend on the RFC number ? Yes, but then we won't know yet if this is
really final until the document is approved as an RFC which is when
these assignments from the IANA reserved range become effective. So the
hash of the RFC number seemed appropriate.
If you want to test interop with the private use range numbers, then
these have not changed, so you can use the prior hash values of draft-02
and draft-03 strings to do that.
-----Original Message-----
From: Andrew Krywaniuk [mailto:andrew.krywaniuk@alcatel.com]
Sent: Thursday, November 07, 2002 1:53 PM
To: 'ipsec'
Subject: RE: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.txt
I'm sure that a whole bunch of us are wondering: what's with the
unspecified vendor id?
Does this mean that the current draft is going to be the last one and
all further numbers will be assigned by IANA? (In that case, why would
we need a vendor id at all?)
Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.
From owner-ipsec@lists.tislabs.com Thu Nov 7 15:53: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 gA7NrBv06928;
Thu, 7 Nov 2002 15:53:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01342
Thu, 7 Nov 2002 18:23:14 -0500 (EST)
Date: 7 Nov 2002 18:02:55 -0500
Message-ID: <004a01c286b1$cfc65450$1e72788a@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: "'Niklas Hallqvist'" <niklas@appli.se>
Cc: "'ipsec'" <ipsec@lists.tislabs.com>
Subject: RE: Fwd: Re: IKEv2 Key Size Conformance Requirements
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <200211072241.gA7Mf9mG009045@ritz.appli.se>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> An RSA key is not just a bit pattern. Seeing leading zero bits
> drastically limits the search space of primes making up the key.
It's a matter of proportion. Two leading zero bits does not drastically
reduce the search space; 512 leading zero bits would.
The way the keys are constructed, for 1024 bit moduli you could use two 512
bit primes, but actually your key generation program probably chooses two
primes of slightly different lengths (e.g. a 514 bit and a 510 bit). This is
done to thwart an attack that I never really understood properly, but which
apparently makes your public key easier to crack. So a couple of bits
difference in the primes here and there clearly doesn't make that much
difference.
Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.
> -----Original Message-----
> From: Niklas Hallqvist [mailto:niklas@appli.se]
> Sent: Thursday, November 07, 2002 5:41 PM
> To: Michael Richardson
> Cc: andrew.krywaniuk@alcatel.com; 'ipsec'
> Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
>
>
> > Date: Tue, 05 Nov 2002 16:10:10 -0500
> > From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
> >
> > >>>>> "Andrew" == Andrew Krywaniuk
> <andrew.krywaniuk@alcatel.com> writes:
> > Andrew> I still haven't figured out what the big deal
> is. If someone wants to use a
> > Andrew> 1022 bit key, can't they just call it a 1024
> bit key where the 2 leading
> > Andrew> bits are zero? Is there some RSA chip/library
> out there that assumes that
> > Andrew> the high bit is a 1? The math works either way.
> >
> > Well, the OpenSSH people think that this is "broken",
> that you'd have a 1022
> > bit key. I think that this reflects a misunderstanding of
> how public key
> > cryptography works.
> >
> > I agree with you, however.
>
> Well depending on what you mean by broken, it may well be seen as
> such. The "brokenness" comes from the fact that a 1022 bit key is
> not 1024 bit "strong". If you call an RSA key of 1022 bits, a 1024
> bit key, then you are lying, and likely create sense of false safety.
> An RSA key is not just a bit pattern. Seeing leading zero bits
> drastically limits the search space of primes making up the key. Or
> am I off here, it has been a while since I read the RSA math? Would
> you call a 512-bit RSA key encapsuled in 1024 bits, a 1024
> bit RSA key?
>
> I would not, however, call it "broken" in the way that the math
> wouldn't work, it would. It just would not be as strong as you are
> trying to imply.
>
> Niklas
>
From owner-ipsec@lists.tislabs.com Thu Nov 7 18:12: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 gA82CAv12407;
Thu, 7 Nov 2002 18:12:10 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01747
Thu, 7 Nov 2002 20:38:24 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15819.5560.908560.107036@thomasm-u1.cisco.com>
Date: Thu, 7 Nov 2002 17:39:04 -0800 (PST)
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <p05200f2eb9f0865eab17@[165.227.249.18]>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05200f23b9f066010f60@[165.227.249.18]>
<15818.54256.902876.454996@thomasm-u1.cisco.com>
<p05200f2eb9f0865eab17@[165.227.249.18]>
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
OK, I'm pretty confused let me try to tease this
apart:
Paul Hoffman / VPNC writes:
> At 12:58 PM -0800 11/7/02, Michael Thomas wrote:
> >Paul Hoffman / VPNC writes:
> > > At 3:52 PM +0100 11/6/02, Francis Dupont wrote:
> > > >But it shows we have to understand exactly what could/should
> > > >be the usage of addresses in key management protocols too (see after).
> > >
> > > Why? What people have found from many years of VPN deployment is that
> > > customers generally want one of two things:
> > > - The ability to say "let any gateway with this identity set up any
> > > kind of tunnel with me"
> > > - The ability to say "let the gateway with this identity set up a
> > > tunnel with these features"
To my mind, the difference here is what a given
identity is authorized to do: "any kind :: these features".
This is regardless of how identity is established.
> > > For preshared secrets, there is no question of the identity. For PKIX
> > > certificates, the identity problem is so convoluted, almost all
> > > customers say "any identity is OK as long as the certificate
> > > correctly chains to this trusted root". The identity is logged, but
> > > the type of identity is not related to the ability to set up tunnels.
So I do not see how these two paragraphs relate to
each other. Taken at face vallue, it seems that
you might be saying that there is no way to take a
cert-based identity and use it to differentiate
authorization, where as a symmetric key based
identity is easy. This doesn't make any sense to
me unless there is some sort of difference with
authz (method of application?) because it is
incomprehensible to me that there is no clear
binding between the public key and the name
mapping the cert provides. If that were true, why
would you bother with certs at? Or are you
actually saying that the name binding provided
by the certificate is worthless??
There must be something that's missing here.
Mike
From owner-ipsec@lists.tislabs.com Thu Nov 7 18:35: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 gA82Zev14724;
Thu, 7 Nov 2002 18:35:40 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01781
Thu, 7 Nov 2002 21:07:28 -0500 (EST)
Date: Thu, 7 Nov 2002 18:07:52 -0800 (PST)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Michael Thomas <mat@cisco.com>
cc: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>, <ipsec@lists.tislabs.com>
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <15819.5560.908560.107036@thomasm-u1.cisco.com>
Message-ID: <Pine.LNX.4.33.0211071802220.26180-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I *think* what paul was saying (jump in any time, Paul ;), is that
with pre-shared keys, the identity (in MM) is clear: It's the IP
address on the IKE packet. After the exchange has completed, you know
you've given access to the peer who's identity is "IP address
X.X.X.X".
With certificates people generally don't have a clear idea who exactly
they are talking to, because the linkage between the 'key' and
something we humans can grok is (apparently) confusing.
So generally ALL you know/configure is some trusted root, and if the
certificate can be validated, we let them in. The question of "who did
we just let in" is a bit unclear, which I believe is what Paul is
trying to fix with his proposal.
It SORT of relates to authorization, I believe. In the above example,
access-control is done via the CA, i.e. ANYONE with a (valid;
non-revoked) cert from <this CA> gets access (i.e. as long as we can
validate the cert, access is granted). While that seems
semi-reasonable in some cases, I doubt it works for everyone..
Now I'm not sure I was any clearer than Paul. Sigh.
I've been meaning to read Brian Korver's draft for a few months now,
and it keeps slipping through the cracks.
jan
On Thu, 7 Nov 2002, Michael Thomas wrote:
>
> OK, I'm pretty confused let me try to tease this
> apart:
>
> Paul Hoffman / VPNC writes:
> > At 12:58 PM -0800 11/7/02, Michael Thomas wrote:
> > >Paul Hoffman / VPNC writes:
> > > > At 3:52 PM +0100 11/6/02, Francis Dupont wrote:
> > > > >But it shows we have to understand exactly what could/should
> > > > >be the usage of addresses in key management protocols too (see after).
> > > >
> > > > Why? What people have found from many years of VPN deployment is that
> > > > customers generally want one of two things:
>
> > > > - The ability to say "let any gateway with this identity set up any
> > > > kind of tunnel with me"
> > > > - The ability to say "let the gateway with this identity set up a
> > > > tunnel with these features"
>
> To my mind, the difference here is what a given
> identity is authorized to do: "any kind :: these features".
> This is regardless of how identity is established.
>
> > > > For preshared secrets, there is no question of the identity. For PKIX
> > > > certificates, the identity problem is so convoluted, almost all
> > > > customers say "any identity is OK as long as the certificate
> > > > correctly chains to this trusted root". The identity is logged, but
> > > > the type of identity is not related to the ability to set up tunnels.
>
> So I do not see how these two paragraphs relate to
> each other. Taken at face vallue, it seems that
> you might be saying that there is no way to take a
> cert-based identity and use it to differentiate
> authorization, where as a symmetric key based
> identity is easy. This doesn't make any sense to
> me unless there is some sort of difference with
> authz (method of application?) because it is
> incomprehensible to me that there is no clear
> binding between the public key and the name
> mapping the cert provides. If that were true, why
> would you bother with certs at? Or are you
> actually saying that the name binding provided
> by the certificate is worthless??
>
> There must be something that's missing here.
>
> Mike
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
THE NETWORK WORKS,
NO EXCUS NFS server mastiff-fddi not responding still trying
From owner-ipsec@lists.tislabs.com Thu Nov 7 18:58: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 gA82wIv16820;
Thu, 7 Nov 2002 18:58:18 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01839
Thu, 7 Nov 2002 21:29:37 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15819.8613.154747.926275@thomasm-u1.cisco.com>
Date: Thu, 7 Nov 2002 18:29:57 -0800 (PST)
To: Jan Vilhuber <vilhuber@cisco.com>
Cc: Michael Thomas <mat@cisco.com>,
Paul Hoffman / VPNC <paul.hoffman@vpnc.org>, <ipsec@lists.tislabs.com>
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <Pine.LNX.4.33.0211071802220.26180-100000@janpc-home.cisco.com>
References: <15819.5560.908560.107036@thomasm-u1.cisco.com>
<Pine.LNX.4.33.0211071802220.26180-100000@janpc-home.cisco.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Jan Vilhuber writes:
> I *think* what paul was saying (jump in any time, Paul ;), is that
> with pre-shared keys, the identity (in MM) is clear: It's the IP
> address on the IKE packet. After the exchange has completed, you know
> you've given access to the peer who's identity is "IP address
> X.X.X.X".
I assume we're talking about IKE identities, not
IPsec manual key "identies" where that's your only
choice... I suppose that this all depends on what
you use for the identifier for the symmetric key
identity. It could well be an IP address, but that's
rather messy and obviously would have issues with
DHCP, blah, blah, blah.
So once you change to some more abstract notion
of an identity, you end up a name/key binding which
needs to be accounted for. With symmetric keys, that's
fairly straightforward: you always have to store the tuple somewhere
and fetch it when you need to auth/authz. For public
key identities, that's not inevitable since the cert
provides a portable credential (possibly with
attributes), but it certainly doesn't *preclude*
fetching those name/key tuples in an analogous way
as one would with symmetric key identities.
So, I guess I'm lost unless there are some
assumptions about where the auth/authz
information is transported/formated. I can
easily understand how trying to encode authz
into a cert as being a huge minefield. I don't
understand it if it's only a identity and is
used in a similar way to symmetric key identities.
> With certificates people generally don't have a clear idea who exactly
> they are talking to, because the linkage between the 'key' and
> something we humans can grok is (apparently) confusing.
Er, why? If I put some x.500 version of
mat@cisco.com into the DN, or mat@cisco.com in
the subjectaltname, or whatever, it's just a
matter of agreeing which one to look up the
authz information, right? I can see how
confusion of which one to agree on might be
a bit messy, but it doesn't seem like it's
the ridiculously messy that Paul's alluding to.
> So generally ALL you know/configure is some trusted root, and if the
> certificate can be validated, we let them in. The question of "who did
> we just let in" is a bit unclear, which I believe is what Paul is
> trying to fix with his proposal.
*Only* if you don't have access to a name/key
store elsewhere (including authz info), right?
Mike
From owner-ipsec@lists.tislabs.com Thu Nov 7 19:05: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 gA835jv17667;
Thu, 7 Nov 2002 19:05:46 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01878
Thu, 7 Nov 2002 21:38:39 -0500 (EST)
Date: Thu, 7 Nov 2002 18:39:09 -0800 (PST)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Michael Thomas <mat@cisco.com>
cc: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>, <ipsec@lists.tislabs.com>
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <15819.8613.154747.926275@thomasm-u1.cisco.com>
Message-ID: <Pine.LNX.4.33.0211071831260.26180-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 7 Nov 2002, Michael Thomas wrote:
> Jan Vilhuber writes:
> > I *think* what paul was saying (jump in any time, Paul ;), is that
> > with pre-shared keys, the identity (in MM) is clear: It's the IP
> > address on the IKE packet. After the exchange has completed, you know
> > you've given access to the peer who's identity is "IP address
> > X.X.X.X".
>
> I assume we're talking about IKE identities, not
> IPsec manual key "identies" where that's your only
> choice... I suppose that this all depends on what
> you use for the identifier for the symmetric key
> identity.
Well that's why I said "(in MM)", because in main-mode you don't have
a choice for pre-shared keys: the IP address in the packet is your
identity.
And yes, as you point out, main-mode with pre-shared keys is
impossible to deploy when your peers have dynamic IP addresses, which
is why all (I think) deployments that include road-warriors or other
forms of dynamic addresses are relegated to aggressive mode, where you
CAN use the Identity Payload contents to select the keys.
Or use certificates. ;)
Or *shudder* a group-key for 0.0.0.0 (any) followed by xauth. Don't
laugh. This exists!
> It could well be an IP address, but that's
> rather messy and obviously would have issues with
> DHCP, blah, blah, blah.
>
> So once you change to some more abstract notion
> of an identity, you end up a name/key binding which
> needs to be accounted for. With symmetric keys, that's
> fairly straightforward: you always have to store the tuple somewhere
> and fetch it when you need to auth/authz. For public
> key identities, that's not inevitable since the cert
> provides a portable credential (possibly with
> attributes), but it certainly doesn't *preclude*
> fetching those name/key tuples in an analogous way
> as one would with symmetric key identities.
>
Agreed. It's not impossible. It's merely messy, as paul pointed
out.
> So, I guess I'm lost unless there are some
> assumptions about where the auth/authz
> information is transported/formated. I can
> easily understand how trying to encode authz
> into a cert as being a huge minefield. I don't
> understand it if it's only a identity and is
> used in a similar way to symmetric key identities.
>
> > With certificates people generally don't have a clear idea who exactly
> > they are talking to, because the linkage between the 'key' and
> > something we humans can grok is (apparently) confusing.
>
> Er, why? If I put some x.500 version of
> mat@cisco.com into the DN, or mat@cisco.com in
> the subjectaltname, or whatever, it's just a
> matter of agreeing which one to look up the
> authz information, right?
Yes.
> I can see how
> confusion of which one to agree on might be
> a bit messy, but it doesn't seem like it's
> the ridiculously messy that Paul's alluding to.
>
I'll step back and let Paul talk for himself again now :)
> > So generally ALL you know/configure is some trusted root, and if the
> > certificate can be validated, we let them in. The question of "who did
> > we just let in" is a bit unclear, which I believe is what Paul is
> > trying to fix with his proposal.
>
> *Only* if you don't have access to a name/key
> store elsewhere (including authz info), right?
>
Correct. Assuming you can agree with others on exactly WHICH field is
the username etc etc. For a single domain of administration, that's
trivial. But across administrative boundries, it may be rather hard.
And then I'm far from sure I got Paul's argument correct, so I'll step
back into the shadows.
jan
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
THE NETWORK WORKS,
NO EXCUS NFS server mastiff-fddi not responding still trying
From owner-ipsec@lists.tislabs.com Thu Nov 7 19:26:02 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 gA83Q1v18164;
Thu, 7 Nov 2002 19:26:01 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01900
Thu, 7 Nov 2002 21:46:42 -0500 (EST)
From: "Max Pritikin" <pritikin@cisco.com>
To: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>,
"Michael Thomas" <mat@cisco.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Adding revised identities to IKEv2
Date: Thu, 7 Nov 2002 18:45:55 -0800
Message-ID: <PKEBJBKKGOBHIJBBAGLEAELHEOAA.pritikin@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: <p05200f2eb9f0865eab17@[165.227.249.18]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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 Paul Hoffman / VPNC
> Sent: Thursday, November 07, 2002 1:09 PM
> To: Michael Thomas
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Adding revised identities to IKEv2
>
>
> At 12:58 PM -0800 11/7/02, Michael Thomas wrote:
> >Paul Hoffman / VPNC writes:
> > > At 3:52 PM +0100 11/6/02, Francis Dupont wrote:
> > > >But it shows we have to understand exactly what could/should
> > > >be the usage of addresses in key management protocols too
> (see after).
> > >
> > > Why? What people have found from many years of VPN deployment is that
> > > customers generally want one of two things:
> > > - The ability to say "let any gateway with this identity set up any
> > > kind of tunnel with me"
> > > - The ability to say "let the gateway with this identity set up a
> > > tunnel with these features"
> > > For preshared secrets, there is no question of the identity. For PKIX
> > > certificates, the identity problem is so convoluted, almost all
> > > customers say "any identity is OK as long as the certificate
> > > correctly chains to this trusted root". The identity is logged, but
> > > the type of identity is not related to the ability to set up tunnels.
> >
> >Paul,
> >
> >Allow me to rephrase this: authz with pre-shared
> >secrets is easy/possible and with PKIX is
> >hard/impossible?
>
> No, that is a completely incorrect rephrasing of what I said. Most
> VPN vendors have no problem with making IPsec work with certificates
> as outlined above, and most users have no problem with using them in
> that fashion.
>
> >Assuming you're not
> >talking about carrying authz information in the
> >certs themselves, I would think the binding of
> >auth to authz would be pretty much equivalent.
>
> Sorry, I can't parse that last sentence. Could you restate it?
Paul H. isn't proposing any fancy pkix PKI tricks. He's proposing that IKE
handle pkix PKI certificates correctly; instead of the existing poorly
stated ID mechanisms which never had a chance of working with certificates.
- Max
> --Paul Hoffman, Director
> --VPN Consortium
>
From owner-ipsec@lists.tislabs.com Thu Nov 7 20:09: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 gA8496v19468;
Thu, 7 Nov 2002 20:09:06 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02605
Thu, 7 Nov 2002 22:29:57 -0500 (EST)
Date: Thu, 7 Nov 2002 22:30:33 -0500 (Eastern Standard Time)
From: Skip Booth <ebooth@cisco.com>
To: James Huang <james.huang@watchguard.com>
cc: "'Markus Stenberg'" <fingon@iki.fi>, <ipsec@lists.tislabs.com>,
"'l2tpext@ietf.org'" <l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
In-Reply-To: <b1a112598202f4c0432170cba25e2e903dcab88b@watchguard.com>
Message-ID: <Pine.WNT.4.44.0211072227570.520-100000@EBOOTH-W2K.amer.cisco.com>
X-Warning: UNAuthenticated Sender
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
James, does the recommendation in section 3.1.2 a) answer your question? I
believe after fixing up the IP header to include the private address which was
advertised during the negotiation, the packet will pass through the SG filters.
The authors of this draft should be able to provide further clarification if
this doesn't address your concerns.
-Skip
On Thu, 7 Nov 2002, James Huang wrote:
>
>
> > -----Original Message-----
> > From: Markus Stenberg [mailto:fingon@iki.fi]
> > Sent: Wednesday, November 06, 2002 11:51 PM
> > To: James Huang
> > Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > Subject: Re: UDP-encapsulated IPsec Transport mode
> >
> >
> > James Huang <james.huang@watchguard.com> writes:
> > > Hi all,
> > > In the appendix A of
> > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > some discussions on the issue of multiple clients running
> > UDP-encapsulated
> > > IPsec transport mode tunnels behind a NAT box. However, I
> > did not find any
> > > discussion on another related issue: In the traffic
> > selector (ID) payload
> > > the client sends out during quick mode exchange, should the
> > client use its
> > > own private address or the public routable address (i.e.
> > the NAT box's
> > > public IP address)? If it the later, how does the client
> > know about that
> > > public address? This seems to be a serious issue,
> > especially for L2TP
> > > voluntary tunnels secured by IPsec (in transport mode).
> >
> > L2TP specific issues I am blissfully unaware of; however,
> > because the NAT
> > boxes are not neccessarily even controlled by the IPsec user,
> > sending the
> > public address is not really an option that can be supported
> > everywhere.
> >
>
> Agreed.
>
> > Here's how the information flow goes as far as I see it:
> >
> > Public address doesn't really need to be sent in any case as
> > the remote
> > side's public address is the address we're talking IKE with
> > (or at least
> > remote address+port combination, but in NAPT case you don't
> > really have
> > more of an remote address in any case).
> >
> > Private address that is used by the OS for actual traffic is provided
> > within the NAT-OA payload so the checksums et al can be corrected.
> >
>
> Let me describe the issue with regarding to L2TP/IPsec (voluntary L2TP) when
> a NAT is present. Suppose a PC with a home network's private IP address V_1
> is behind a NAT box with a public address P_1. The corporate network's
> Security Gateway's IP address is P_2 and the PC wants to connect to a
> corporate server with private IP address I_2. If everything goes well, this
> PC will eventually obtain another private address I_1 from the corporate
> network through IPCP . So the L2TP traffic sent by the PC will have the
> following headers: IP/UDP/ESP/UDP/L2TP control or
> IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will indicate the
> traffic is sent from V_1 to P_2. The inner IP header will indicate the
> traffic is sent from I_1 to I_2. The source IP address V_1 in the outer
> header will be changed by the NAT box to P_1 on the way out. So the packet
> received by the corporate SG is an UDP-encapsulated TRANSPORT mode IPsec
> packet from P_1 to P_2 with UDP source port 1701 and UDP dest port 1701 in
> the 2nd UDP header (assuming no dynamic UDP port for L2TP). To allow this
> packet to pass through the SG, an inbound filter matching the packet must
> exist in the SG. The inbound filter is dynamically created after a quick
> mode exchange between the PC and the SG. To create such a filter in the SG,
> the PC must specify < IP = P_1, proto = UDP, port = 1701> in ID_i during
> the quick mode exchange. But how does this PC knows about P_1?
>
> What I described above is a scenario specific to L2TP/IPsec. But in
> general, any transport mode IPsec tunnel with a NAT box along its path will
> have the same problem.
>
> Am I right? Or I am missing something here?
>
> - James Huang
>
>
>
> > Therefore, at least as far as implementation I used to work
> > on goes, ID
> > payload in transport mode case doesn't matter (I seem to
> > recall we sent
> > private address, but pretty much ignored what was sent by remote).
> >
> > -Markus
> >
> > > Regards,
> > > James C. Huang
> >
> > --
> > "Every program has (at least) two purposes: the one for which it was
> > written, and another for which it wasn't. "
> >
> > From ACM's SIGPLAN publication, (September, 1982), Article "Epigrams
> > in Programming", by Alan J. Perlis of Yale University.
> >
>
From owner-ipsec@lists.tislabs.com Thu Nov 7 20: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 gA84Rdv19849;
Thu, 7 Nov 2002 20:27:39 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03225
Thu, 7 Nov 2002 23:01:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org (Unverified)
Message-Id: <p05200f00b9f0e62aff99@[165.227.249.18]>
In-Reply-To: <PKEBJBKKGOBHIJBBAGLEAELHEOAA.pritikin@cisco.com>
References: <PKEBJBKKGOBHIJBBAGLEAELHEOAA.pritikin@cisco.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Thu, 7 Nov 2002 20:01:33 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: RE: Adding revised identities to IKEv2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 6:45 PM -0800 11/7/02, Max Pritikin wrote:
>Paul H. isn't proposing any fancy pkix PKI tricks. He's proposing that IKE
>handle pkix PKI certificates correctly; instead of the existing poorly
>stated ID mechanisms which never had a chance of working with certificates.
Exactly. For the majority of users, there is a single authorization
policy: "everyone I trust is allowed to match any traffic policy". As
Jan said, in IKEv1 with presahred keys, there is no separate ID: it
is the IP address.
With certificates, it's a mess. Is the ID the whole Subject? Any part
of the Subject? The whole SubjectAltName? Any part of the
SubjectAltName? The combination of the whole Subject *and* the whole
SubjectAltName? But the real question is, who cares? If the gateway
admin wants to trust anyone who has a certificate from the trusted
root, the ID is pretty much just there for logging. And if they do
want to differentiate by ID, they are probably smart enough to fill
in the right fields in the GUI for the ID type they care about.
(Well, I just lied there: very few IPsec GUIs allow you to
differentiate at the level needed.)
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Fri Nov 8 02:14:08 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 gA8AE8v02931;
Fri, 8 Nov 2002 02:14:08 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03876
Fri, 8 Nov 2002 04:46:05 -0500 (EST)
Message-Id: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Thu, 07 Nov 2002 11:01:20 PST.
<p05200f23b9f066010f60@[165.227.249.18]>
Date: Fri, 08 Nov 2002 10:46:47 +0100
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:
>But it shows we have to understand exactly what could/should
>be the usage of addresses in key management protocols too (see after).
Why? What people have found from many years of VPN deployment is that
customers generally want one of two things:
- The ability to say "let any gateway with this identity set up any
kind of tunnel with me"
- The ability to say "let the gateway with this identity set up a
tunnel with these features"
For preshared secrets, there is no question of the identity. For PKIX
certificates, the identity problem is so convoluted, almost all
customers say "any identity is OK as long as the certificate
correctly chains to this trusted root". The identity is logged, but
the type of identity is not related to the ability to set up tunnels.
=> there is no agreement about what checks must be done:
- common sense says the identity must be a subject of the certificate
(but this is not clearly specified in IKEv1 and perhaps some
implementations don't perform this check)
- if the identity is an address, one can verify this is the address
IKE runs over or can accept a different address. The current
specs (until your proposal) are really loose about this point.
- the lack of protection of peer addresses is a security flaw,
IMHO customers want to set up a tunnel with the gateway, not
with an unknown box (:-). I understand the need for a NAT
traversal feature but I disagree to get a security flaw even
when I know there is no NAT on the path.
> A little point: if the URL is to the initiating machine there can be
>some bootstrap problems (to get it can need an IPsec-protected connection
>to the initiator), so this case should be added to the unresolvable URLs.
It would be silly to put your cert *behind* your gateway. But the
gateway itself might have a trivial HTTP server to allow access to
certs; in fact, this is what many people expect to happen.
=> I agree this kind of bootstrap problems comes from silly configurations
but the IPv6 neighbor discovery issue showed these silly configurations
happen in the real world so they should be handled. In this case
the "unresolvable URLs" case should be extended to the inaccessible
because of IPsec cross-dependence case.
Thanks
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Fri Nov 8 07:19: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 gA8FJqv28312;
Fri, 8 Nov 2002 07:19:52 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04264
Fri, 8 Nov 2002 09:50:00 -0500 (EST)
Message-ID: <C1352E2D7153D411B83000508BD69247F0001C@CA-Mail01.CA.iPolicyNet.COM>
From: "Vohra, Meenakshi" <mvohra@iPolicyNet.COM>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: looking for VPN Clients on Linux / Solaris with X Auth
Date: Thu, 7 Nov 2002 14:52:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C286B0.666B2860"
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_01C286B0.666B2860
Content-Type: text/plain;
charset="ISO-8859-1"
Hello everyone
Can anyone suggest me the VPN Clients for Linux / Solaris with XAuth
support.
Thanks
Meenakshi
------_=_NextPart_001_01C286B0.666B2860
Content-Type: text/html;
charset="ISO-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>looking for VPN Clients on Linux / Solaris with X Auth</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2 FACE="Arial">Hello everyone</FONT>
<BR><FONT SIZE=2 FACE="Arial">Can anyone suggest me the VPN Clients for Linux / Solaris with XAuth support.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Thanks</FONT>
<BR><FONT SIZE=2 FACE="Arial">Meenakshi</FONT>
</P>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C286B0.666B2860--
From owner-ipsec@lists.tislabs.com Fri Nov 8 07:19: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 gA8FJqv28313;
Fri, 8 Nov 2002 07:19:52 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04246
Fri, 8 Nov 2002 09:47:01 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100301b9f17cdf5ea1@[128.89.88.34]>
In-Reply-To:
<Pine.LNX.4.33.0211071802220.26180-100000@janpc-home.cisco.com>
References: <Pine.LNX.4.33.0211071802220.26180-100000@janpc-home.cisco.com>
Date: Fri, 8 Nov 2002 09:44:17 -0500
To: Jan Vilhuber <vilhuber@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: <ipsec@lists.tislabs.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 6:07 PM -0800 11/7/02, Jan Vilhuber wrote:
>I *think* what paul was saying (jump in any time, Paul ;), is that
>with pre-shared keys, the identity (in MM) is clear: It's the IP
>address on the IKE packet. After the exchange has completed, you know
>you've given access to the peer who's identity is "IP address
>X.X.X.X".
>
>With certificates people generally don't have a clear idea who exactly
>they are talking to, because the linkage between the 'key' and
>something we humans can grok is (apparently) confusing.
>
>So generally ALL you know/configure is some trusted root, and if the
>certificate can be validated, we let them in. The question of "who did
>we just let in" is a bit unclear, which I believe is what Paul is
>trying to fix with his proposal.
>
>It SORT of relates to authorization, I believe. In the above example,
>access-control is done via the CA, i.e. ANYONE with a (valid;
>non-revoked) cert from <this CA> gets access (i.e. as long as we can
>validate the cert, access is granted). While that seems
>semi-reasonable in some cases, I doubt it works for everyone..
>
>Now I'm not sure I was any clearer than Paul. Sigh.
>
>I've been meaning to read Brian Korver's draft for a few months now,
>and it keeps slipping through the cracks.
>
>jan
>
The intent in 2401 is that if one wants to make fine-grained access
control decisions, the form of authentication used should not matter.
The ability to specify a source or dest IP address in symbolic form
is specifically intended to support use of certs with various name
forms, e.g., when a user has a dynamically assigned address. So, for
example, you can create and SPD entry with a DN or with a DNS name
and have it bound, dynamically, to the IP address assigned to the
named entity at the time the IKE exchange takes place.
In the course of working on 2401bis I have learned that we did not do
a good enough job of explaining this in 2401, and the intent is to
make it very clear in 2401bis. But I would hope that we do not
anticipate degrading the capability in IKE v2. There is no good
reason I can see for having coarser granularity access control
capabilities based on the use of certs vs. legacy authentication
systems.
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 8 07:22: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 gA8FMpv28396;
Fri, 8 Nov 2002 07:22:51 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04245
Fri, 8 Nov 2002 09:47:00 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100302b9f17ea5c94b@[128.89.88.34]>
In-Reply-To: <p05200f00b9f0e62aff99@[165.227.249.18]>
References: <PKEBJBKKGOBHIJBBAGLEAELHEOAA.pritikin@cisco.com>
<p05200f00b9f0e62aff99@[165.227.249.18]>
Date: Fri, 8 Nov 2002 09:48:27 -0500
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 8:01 PM -0800 11/7/02, Paul Hoffman / VPNC wrote:
>At 6:45 PM -0800 11/7/02, Max Pritikin wrote:
>>Paul H. isn't proposing any fancy pkix PKI tricks. He's proposing that IKE
>>handle pkix PKI certificates correctly; instead of the existing poorly
>>stated ID mechanisms which never had a chance of working with certificates.
>
>Exactly. For the majority of users, there is a single authorization
>policy: "everyone I trust is allowed to match any traffic policy".
>As Jan said, in IKEv1 with presahred keys, there is no separate ID:
>it is the IP address.
>
>With certificates, it's a mess. Is the ID the whole Subject? Any
>part of the Subject? The whole SubjectAltName? Any part of the
>SubjectAltName? The combination of the whole Subject *and* the whole
>SubjectAltName? But the real question is, who cares? If the gateway
>admin wants to trust anyone who has a certificate from the trusted
>root, the ID is pretty much just there for logging. And if they do
>want to differentiate by ID, they are probably smart enough to fill
>in the right fields in the GUI for the ID type they care about.
>(Well, I just lied there: very few IPsec GUIs allow you to
>differentiate at the level needed.)
Paul,
What you have identified here is a mess due to a lack of sufficiently
precise discussion in previous documents about what to do with the
info. That does not mean that we cannot provide this level of detail
now, so that people can make use of certs in a predictable,
reasonable fashion. This is what IKE v2 and a cert profile should do,
in combination. I think we do a disservice to clients if we just
through up our hands and say it's too hard. As a nominal co-author
for IKEv2, I will try to focus on that part of the doc, which I have
not done previously, and work to coordinate it with the PKI profile,
to make sure we remove the ambiguities. OK?
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 8 07:26: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 gA8FQjv28528;
Fri, 8 Nov 2002 07:26:45 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04298
Fri, 8 Nov 2002 10:02:00 -0500 (EST)
Message-Id: <200211072241.gA7Mf9mG009045@ritz.appli.se>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: andrew.krywaniuk@alcatel.com, "'ipsec'" <ipsec@lists.tislabs.com>
Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements
In-reply-to: Your message of "Tue, 05 Nov 2002 16:10:10 EST."
<200211052110.gA5LAAm3020939@marajade.sandelman.ottawa.on.ca>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Thu, 07 Nov 2002 23:40:58 +0100
From: Niklas Hallqvist <niklas@appli.se>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Date: Tue, 05 Nov 2002 16:10:10 -0500
> From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
>
> >>>>> "Andrew" == Andrew Krywaniuk <andrew.krywaniuk@alcatel.com> writes:
> Andrew> I still haven't figured out what the big deal is. If someone wants to use a
> Andrew> 1022 bit key, can't they just call it a 1024 bit key where the 2 leading
> Andrew> bits are zero? Is there some RSA chip/library out there that assumes that
> Andrew> the high bit is a 1? The math works either way.
>
> Well, the OpenSSH people think that this is "broken", that you'd have a 1022
> bit key. I think that this reflects a misunderstanding of how public key
> cryptography works.
>
> I agree with you, however.
Well depending on what you mean by broken, it may well be seen as
such. The "brokenness" comes from the fact that a 1022 bit key is
not 1024 bit "strong". If you call an RSA key of 1022 bits, a 1024
bit key, then you are lying, and likely create sense of false safety.
An RSA key is not just a bit pattern. Seeing leading zero bits
drastically limits the search space of primes making up the key. Or
am I off here, it has been a while since I read the RSA math? Would
you call a 512-bit RSA key encapsuled in 1024 bits, a 1024 bit RSA key?
I would not, however, call it "broken" in the way that the math
wouldn't work, it would. It just would not be as strong as you are
trying to imply.
Niklas
From owner-ipsec@lists.tislabs.com Fri Nov 8 09:08: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 gA8H8Jv05256;
Fri, 8 Nov 2002 09:08:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04662
Fri, 8 Nov 2002 11:42:00 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f0fb9f198f66ecc@[165.227.249.18]>
In-Reply-To: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr>
References: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Fri, 8 Nov 2002 08:42:32 -0800
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:46 AM +0100 11/8/02, Francis Dupont wrote:
>=> there is no agreement about what checks must be done:
> - common sense says the identity must be a subject of the certificate
> (but this is not clearly specified in IKEv1 and perhaps some
> implementations don't perform this check)
That does not follow. There is no standard way for the Subject to be
an email address (the way folks do it now is a non-standard hack),
there is no standard way for the Subject to be an IP address. I'm not
sure, but I think the DC method of doing domain names in the Subject
is also a non-standard hack.
>=> I agree this kind of bootstrap problems comes from silly configurations
>but the IPv6 neighbor discovery issue showed these silly configurations
>happen in the real world so they should be handled. In this case
>the "unresolvable URLs" case should be extended to the inaccessible
>because of IPsec cross-dependence case.
The error definition I proposed was:
Could not get the certificate through the URL that was given in the
FullID type 3 payload. This could be due to connectivity problems,
an error from the HTTP server, a malformed URL, or a host of other
reasons.
That last phrase should cover almost anything.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Fri Nov 8 09:08: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 gA8H8Jv05257;
Fri, 8 Nov 2002 09:08:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04598
Fri, 8 Nov 2002 11:36:59 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f0eb9f19786188d@[165.227.249.18]>
In-Reply-To: <p05100302b9f17ea5c94b@[128.89.88.34]>
References: <PKEBJBKKGOBHIJBBAGLEAELHEOAA.pritikin@cisco.com>
<p05200f00b9f0e62aff99@[165.227.249.18]>
<p05100302b9f17ea5c94b@[128.89.88.34]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Fri, 8 Nov 2002 08:36:30 -0800
To: Stephen Kent <kent@bbn.com>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: RE: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 9:48 AM -0500 11/8/02, Stephen Kent wrote:
>What you have identified here is a mess due to a lack of
>sufficiently precise discussion in previous documents about what to
>do with the info.
Yup. In fact, there was a lack of almost any discussion.
> That does not mean that we cannot provide this level of detail now,
>so that people can make use of certs in a predictable, reasonable
>fashion.
Exactly right.
> This is what IKE v2 and a cert profile should do, in combination.
Given the importance of certificates to IKEv2, the profile should be
a part of the IKEv2 document.
> I think we do a disservice to clients if we just through up our
>hands and say it's too hard.
If you are talking about IKEv2, I fully agree. If you are talking
about IKEv1, I would disagree because many vendors have in good faith
tried to interpret what little we have given them and come up with
radically different answers. It would be wrong for us to, at this
late date, say that some implementations are non-conformant.
> As a nominal co-author for IKEv2, I will try to focus on that part
>of the doc, which I have not done previously, and work to coordinate
>it with the PKI profile, to make sure we remove the ambiguities. OK?
Absolutely! Obviously, I would like to help. After Brian and Eric's
draft gets a bit of discussion on the list (ahem), I think we would
be in a good place to set down a small number of MUSTs that everyone
can understand.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Fri Nov 8 09:25: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 gA8HPAv07356;
Fri, 8 Nov 2002 09:25:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04736
Fri, 8 Nov 2002 11:57:10 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0510030bb9f19cfbe9fc@[128.89.88.34]>
In-Reply-To: <p05200f0eb9f19786188d@[165.227.249.18]>
References: <PKEBJBKKGOBHIJBBAGLEAELHEOAA.pritikin@cisco.com>
<p05200f00b9f0e62aff99@[165.227.249.18]>
<p05100302b9f17ea5c94b@[128.89.88.34]>
<p05200f0eb9f19786188d@[165.227.249.18]>
Date: Fri, 8 Nov 2002 11:56:44 -0500
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul,
>> I think we do a disservice to clients if we just through up our
>>hands and say it's too hard.
>
>If you are talking about IKEv2, I fully agree. If you are talking
>about IKEv1, I would disagree because many vendors have in good
>faith tried to interpret what little we have given them and come up
>with radically different answers. It would be wrong for us to, at
>this late date, say that some implementations are non-conformant.
Agreed. We need to distinguish between what people did previously
given the lack of guidance, and what we would like to do going
forward.
>
>> As a nominal co-author for IKEv2, I will try to focus on that part
>>of the doc, which I have not done previously, and work to
>>coordinate it with the PKI profile, to make sure we remove the
>>ambiguities. OK?
>
>Absolutely! Obviously, I would like to help. After Brian and Eric's
>draft gets a bit of discussion on the list (ahem), I think we would
>be in a good place to set down a small number of MUSTs that everyone
>can understand.
OK
From owner-ipsec@lists.tislabs.com Fri Nov 8 11:02: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 gA8J2jv14674;
Fri, 8 Nov 2002 11:02:46 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05159
Fri, 8 Nov 2002 13:30:52 -0500 (EST)
Message-ID: <97de41e0baaeb8917f5832b2faee1e633dcc02eb@watchguard.com>
From: James Huang <james.huang@watchguard.com>
To: "'Skip Booth'" <ebooth@cisco.com>
Cc: "'Markus Stenberg'" <fingon@iki.fi>, ipsec@lists.tislabs.com,
"'l2tpext@ietf.org'" <l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 10:27:39 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Skip,
If we fix up the source IP address using the private address
advertised in NAT-OA during IKE negotiation, then why should TCP/UDP
checksum be re-computed at the security gateway as was described in section
3.1.2? The checksum was originally computed by the client using its
private address. Also is this solution the same as the "built-in NAT"
solution mentioned in Appendix A of draft-ietf-ipsec-udp-encaps-04.txt to
solve the problem of multiple clients behind a NAT with overlapped traffic
specifications?
Thanks,
- James
> -----Original Message-----
> From: Skip Booth [mailto:ebooth@cisco.com]
> Sent: Thursday, November 07, 2002 7:31 PM
> To: James Huang
> Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
>
> James, does the recommendation in section 3.1.2 a) answer
> your question? I
> believe after fixing up the IP header to include the private
> address which was
> advertised during the negotiation, the packet will pass
> through the SG filters.
> The authors of this draft should be able to provide further
> clarification if
> this doesn't address your concerns.
>
> -Skip
>
> On Thu, 7 Nov 2002, James Huang wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: Markus Stenberg [mailto:fingon@iki.fi]
> > > Sent: Wednesday, November 06, 2002 11:51 PM
> > > To: James Huang
> > > Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > Subject: Re: UDP-encapsulated IPsec Transport mode
> > >
> > >
> > > James Huang <james.huang@watchguard.com> writes:
> > > > Hi all,
> > > > In the appendix A of
> > > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > > some discussions on the issue of multiple clients running
> > > UDP-encapsulated
> > > > IPsec transport mode tunnels behind a NAT box. However,
> > > did not find any
> > > > discussion on another related issue: In the traffic
> > > selector (ID) payload
> > > > the client sends out during quick mode exchange, should the
> > > client use its
> > > > own private address or the public routable address (i.e.
> > > the NAT box's
> > > > public IP address)? If it the later, how does the client
> > > know about that
> > > > public address? This seems to be a serious issue,
> > > especially for L2TP
> > > > voluntary tunnels secured by IPsec (in transport mode).
> > >
> > > L2TP specific issues I am blissfully unaware of; however,
> > > because the NAT
> > > boxes are not neccessarily even controlled by the IPsec user,
> > > sending the
> > > public address is not really an option that can be supported
> > > everywhere.
> > >
> >
> > Agreed.
> >
> > > Here's how the information flow goes as far as I see it:
> > >
> > > Public address doesn't really need to be sent in any case as
> > > the remote
> > > side's public address is the address we're talking IKE with
> > > (or at least
> > > remote address+port combination, but in NAPT case you don't
> > > really have
> > > more of an remote address in any case).
> > >
> > > Private address that is used by the OS for actual
> traffic is provided
> > > within the NAT-OA payload so the checksums et al can be
> corrected.
> > >
> >
> > Let me describe the issue with regarding to L2TP/IPsec
> (voluntary L2TP) when
> > a NAT is present. Suppose a PC with a home network's
> private IP address V_1
> > is behind a NAT box with a public address P_1. The
> corporate network's
> > Security Gateway's IP address is P_2 and the PC wants to
> connect to a
> > corporate server with private IP address I_2. If
> everything goes well, this
> > PC will eventually obtain another private address I_1 from
> the corporate
> > network through IPCP . So the L2TP traffic sent by the PC
> will have the
> > following headers: IP/UDP/ESP/UDP/L2TP control or
> > IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will
> indicate the
> > traffic is sent from V_1 to P_2. The inner IP header will
> indicate the
> > traffic is sent from I_1 to I_2. The source IP address V_1
> in the outer
> > header will be changed by the NAT box to P_1 on the way
> out. So the packet
> > received by the corporate SG is an UDP-encapsulated
> TRANSPORT mode IPsec
> > packet from P_1 to P_2 with UDP source port 1701 and UDP
> dest port 1701 in
> > the 2nd UDP header (assuming no dynamic UDP port for L2TP).
> To allow this
> > packet to pass through the SG, an inbound filter matching
> the packet must
> > exist in the SG. The inbound filter is dynamically created
> after a quick
> > mode exchange between the PC and the SG. To create such a
> filter in the SG,
> > the PC must specify < IP = P_1, proto = UDP, port = 1701>
> in ID_i during
> > the quick mode exchange. But how does this PC knows about P_1?
> >
> > What I described above is a scenario specific to L2TP/IPsec. But in
> > general, any transport mode IPsec tunnel with a NAT box
> along its path will
> > have the same problem.
> >
> > Am I right? Or I am missing something here?
> >
> > - James Huang
> >
> >
> >
> > > Therefore, at least as far as implementation I used to work
> > > on goes, ID
> > > payload in transport mode case doesn't matter (I seem to
> > > recall we sent
> > > private address, but pretty much ignored what was sent by remote).
> > >
> > > -Markus
> > >
> > > > Regards,
> > > > James C. Huang
> > >
> > > --
> > > "Every program has (at least) two purposes: the one for
> which it was
> > > written, and another for which it wasn't. "
> > >
> > > From ACM's SIGPLAN publication, (September, 1982),
> Article "Epigrams
> > > in Programming", by Alan J. Perlis of Yale University.
> > >
> >
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 12:54: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 gA8Ksbv20024;
Fri, 8 Nov 2002 12:54:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05430
Fri, 8 Nov 2002 15:08:49 -0500 (EST)
Date: Fri, 8 Nov 2002 15:08:57 -0500 (Eastern Standard Time)
From: Skip Booth <ebooth@cisco.com>
To: James Huang <james.huang@watchguard.com>
cc: "'Markus Stenberg'" <fingon@iki.fi>, <ipsec@lists.tislabs.com>,
"'l2tpext@ietf.org'" <l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
In-Reply-To: <97de41e0baaeb8917f5832b2faee1e633dcc0244@watchguard.com>
Message-ID: <Pine.WNT.4.44.0211081452040.520-100000@EBOOTH-W2K.amer.cisco.com>
X-Warning: UNAuthenticated Sender
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, 8 Nov 2002, James Huang wrote:
> Skip,
> If we fix up the source IP address using the private address
> advertised in NAT-OA during IKE negotiation, then why should TCP/UDP
> checksum be re-computed at the security gateway as was described in section
> 3.1.2?
Because the NAT would have modified the checksum as the packet passed through
the NAT. In order for it to pass the IP CRC check at the SG, you must fixup the
checksum based on the pre-NAT values.
> The checksum was originally computed by the client using its
> private address. Also is this solution the same as the "built-in NAT"
> solution mentioned in Appendix A of draft-ietf-ipsec-udp-encaps-04.txt to
> solve the problem of multiple clients behind a NAT with overlapped traffic
> specifications?
I don't the CRC fixup has anything to do with Appendix A.
-Skip
>
> Thanks,
> - James
>
>
> > -----Original Message-----
> > From: Skip Booth [mailto:ebooth@cisco.com]
> > Sent: Thursday, November 07, 2002 7:31 PM
> > To: James Huang
> > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > Subject: RE: UDP-encapsulated IPsec Transport mode
> >
> >
> >
> > James, does the recommendation in section 3.1.2 a) answer
> > your question? I
> > believe after fixing up the IP header to include the private
> > address which was
> > advertised during the negotiation, the packet will pass
> > through the SG filters.
> > The authors of this draft should be able to provide further
> > clarification if
> > this doesn't address your concerns.
> >
> > -Skip
> >
> > On Thu, 7 Nov 2002, James Huang wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Markus Stenberg [mailto:fingon@iki.fi]
> > > > Sent: Wednesday, November 06, 2002 11:51 PM
> > > > To: James Huang
> > > > Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > Subject: Re: UDP-encapsulated IPsec Transport mode
> > > >
> > > >
> > > > James Huang <james.huang@watchguard.com> writes:
> > > > > Hi all,
> > > > > In the appendix A of
> > > > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > > > some discussions on the issue of multiple clients running
> > > > UDP-encapsulated
> > > > > IPsec transport mode tunnels behind a NAT box. However,
> > > > did not find any
> > > > > discussion on another related issue: In the traffic
> > > > selector (ID) payload
> > > > > the client sends out during quick mode exchange, should the
> > > > client use its
> > > > > own private address or the public routable address (i.e.
> > > > the NAT box's
> > > > > public IP address)? If it the later, how does the client
> > > > know about that
> > > > > public address? This seems to be a serious issue,
> > > > especially for L2TP
> > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > >
> > > > L2TP specific issues I am blissfully unaware of; however,
> > > > because the NAT
> > > > boxes are not neccessarily even controlled by the IPsec user,
> > > > sending the
> > > > public address is not really an option that can be supported
> > > > everywhere.
> > > >
> > >
> > > Agreed.
> > >
> > > > Here's how the information flow goes as far as I see it:
> > > >
> > > > Public address doesn't really need to be sent in any case as
> > > > the remote
> > > > side's public address is the address we're talking IKE with
> > > > (or at least
> > > > remote address+port combination, but in NAPT case you don't
> > > > really have
> > > > more of an remote address in any case).
> > > >
> > > > Private address that is used by the OS for actual
> > traffic is provided
> > > > within the NAT-OA payload so the checksums et al can be
> > corrected.
> > > >
> > >
> > > Let me describe the issue with regarding to L2TP/IPsec
> > (voluntary L2TP) when
> > > a NAT is present. Suppose a PC with a home network's
> > private IP address V_1
> > > is behind a NAT box with a public address P_1. The
> > corporate network's
> > > Security Gateway's IP address is P_2 and the PC wants to
> > connect to a
> > > corporate server with private IP address I_2. If
> > everything goes well, this
> > > PC will eventually obtain another private address I_1 from
> > the corporate
> > > network through IPCP . So the L2TP traffic sent by the PC
> > will have the
> > > following headers: IP/UDP/ESP/UDP/L2TP control or
> > > IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will
> > indicate the
> > > traffic is sent from V_1 to P_2. The inner IP header will
> > indicate the
> > > traffic is sent from I_1 to I_2. The source IP address V_1
> > in the outer
> > > header will be changed by the NAT box to P_1 on the way
> > out. So the packet
> > > received by the corporate SG is an UDP-encapsulated
> > TRANSPORT mode IPsec
> > > packet from P_1 to P_2 with UDP source port 1701 and UDP
> > dest port 1701 in
> > > the 2nd UDP header (assuming no dynamic UDP port for L2TP).
> > To allow this
> > > packet to pass through the SG, an inbound filter matching
> > the packet must
> > > exist in the SG. The inbound filter is dynamically created
> > after a quick
> > > mode exchange between the PC and the SG. To create such a
> > filter in the SG,
> > > the PC must specify < IP = P_1, proto = UDP, port = 1701>
> > in ID_i during
> > > the quick mode exchange. But how does this PC knows about P_1?
> > >
> > > What I described above is a scenario specific to L2TP/IPsec. But in
> > > general, any transport mode IPsec tunnel with a NAT box
> > along its path will
> > > have the same problem.
> > >
> > > Am I right? Or I am missing something here?
> > >
> > > - James Huang
> > >
> > >
> > >
> > > > Therefore, at least as far as implementation I used to work
> > > > on goes, ID
> > > > payload in transport mode case doesn't matter (I seem to
> > > > recall we sent
> > > > private address, but pretty much ignored what was sent by remote).
> > > >
> > > > -Markus
> > > >
> > > > > Regards,
> > > > > James C. Huang
> > > >
> > > > --
> > > > "Every program has (at least) two purposes: the one for
> > which it was
> > > > written, and another for which it wasn't. "
> > > >
> > > > From ACM's SIGPLAN publication, (September, 1982),
> > Article "Epigrams
> > > > in Programming", by Alan J. Perlis of Yale University.
> > > >
> > >
> >
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 13:00: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 gA8L0hv20862;
Fri, 8 Nov 2002 13:00:43 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05482
Fri, 8 Nov 2002 15:36:11 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100310b9f1ce6c87aa@[128.89.88.34]>
In-Reply-To: <p05200f0fb9f198f66ecc@[165.227.249.18]>
References: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr>
<p05200f0fb9f198f66ecc@[165.227.249.18]>
Date: Fri, 8 Nov 2002 15:27:44 -0500
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 8:42 AM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>At 10:46 AM +0100 11/8/02, Francis Dupont wrote:
>>=> there is no agreement about what checks must be done:
>> - common sense says the identity must be a subject of the certificate
>> (but this is not clearly specified in IKEv1 and perhaps some
>> implementations don't perform this check)
>
>That does not follow. There is no standard way for the Subject to be
>an email address (the way folks do it now is a non-standard hack),
>there is no standard way for the Subject to be an IP address. I'm
>not sure, but I think the DC method of doing domain names in the
>Subject is also a non-standard hack.
I think the use of DC is a "standard hack," i.e., there is an RFC
defining how to represent any DNS name in this fashion, and it may
even state that this is the preferred way to do so if you use a DN
rather than the SubAltname.
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 8 13:46: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 gA8LkUv23927;
Fri, 8 Nov 2002 13:46:35 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05577
Fri, 8 Nov 2002 16:19:39 -0500 (EST)
Message-ID: <605BFAC48B20D34F8923E47EB3F8E86E02213E@trilmail.funk.com>
From: Steve Vernick <svernick@funk.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: RE: Potential bakeoff in France in 2003
Date: Fri, 8 Nov 2002 12:49:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Is there any news about this? Will there be a Bakeoff?
Thank you.
Steven Vernick, Principal Software Engineer
Funk Software, Inc.
1732 Main Street, Suite 101
Concord, MA 01742 USA
Voice: 978-371-3980 (x124) Fax: 978-371-3990
email: svernick@funk.com
http://www.funk.com
-----Original Message-----
From: Ghislaine Labouret [mailto:Ghislaine.Labouret@hsc.fr]
Sent: Thursday, September 26, 2002 3:10 AM
To: ipsec@lists.tislabs.com
Cc: Philippe Cousin
Subject: Potential bakeoff in France in 2003
At the Yokohama IETF, people asked if there were plans for a new IPsec
bakeoff. The ETSI Interoperability Service, called Plugtests (currently
organizing an IPv6 interoperability event) is willing to organize one in
France in 2003, in particular as funding support from EU can be found.
See more info on the service at www.etsi.org/plugtests
In order to determine interest for such an event, we would like to get
feedback from the members of the list:
- Would you be willing to come to such an event?
- What would you like to test?
- Which timing would be more suitable?
Please send your answer and interest for such an event to
plugtests@etsi.fr
Thank you.
--
Ghislaine Labouret, HSC (www.hsc.fr/ipsec/)
Philippe Cousin, ETSI
From owner-ipsec@lists.tislabs.com Fri Nov 8 13:54: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 gA8Ls4v24154;
Fri, 8 Nov 2002 13:54:09 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05566
Fri, 8 Nov 2002 16:18:37 -0500 (EST)
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60444B5FD@zcard0ke.ca.nortel.com>
From: "Dennis Beard" <beardd@nortelnetworks.com>
To: ipsec@lists.tislabs.com
Subject: IKE Leadership
Date: Fri, 8 Nov 2002 12:31:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C2874C.B56E4162"
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_01C2874C.B56E4162
Content-Type: text/plain
Hello,
The original intent of creating a next version of the IKE protocol was to
reduce the complexity of the first one. Most observers of the next IKE
evolution, including the principal author, Charlie Kaufman, know that the
exercise to "homogenize" IKEv2 and JFK has moved us further away from the
original goal of simplicity and completeness. We had that back in December
of last year with IKE v2, a complete protocol package with v1 complexity
removed. It was complete enough to allow for implementation trials.
Competent technical people will always find reasons to seek modifications
to any draft in an effort to make it "just right". Steve Kent offered an
excellent example today regarding revised identities to IKEv2. As a WG, we
have argued the merits of crypto suites or not, 4 messages with stateless
cookies vs. 2, and recently, key size conformance just to name a few. We
have parsed the requirements and sought more opinions as to which
requirements are most important. We have summarized those desired
requirements and discussed them again. For more than a year we have churned
like butter the next version of IKE with a multitude of "perfections" that
consumed hours of thought and countless words of opinion. In seeking
perfection and perhaps peace, we have lost the whole purpose which caused
this WG to correct IKEv1. I do not advertise myself as an expert on the
intricacies of IKE, but I do know that this perpetual churn does not
necessarily create a better protocol or satisfy all the parties involved.
One of the common complaints that permeate the IETF is that it takes too
long for drafts to come out of the WG. Often the window of opportunity is
lost because industry cannot wait for the perfect solution. This IKE
exercise is the poster child for that problem.
With all due respect to the WG chairs and the Security ADs, leadership on
this specific issue needs to be asserted and closure effected now. Closure
means that a specific version of a released draft is acknowledged as the
preferred draft and is forwarded to the IESG. Freeze that draft and do not
accept any further changes. We do not need more technical stroking, nor do
we need more discussions about making IKE better. All that has been done in
excruciating detail. Words to this effect were boldly announced by the AD
at the end of the March '02 meeting. But we keep churning and will continue
to do so until a draft is recommended and moved forward out of IPsec.
If you agree with this assessment of the IKE issue, challenge our WG Chairs
and ADs to close debate and move forward. Whatever your opinion, no one can
say that the Chairs did not allow for adequate debate.
Regards,
Dennis Beard
613-768-0323
------_=_NextPart_001_01C2874C.B56E4162
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.2655.35">
<TITLE>IKE Leadership</TITLE>
</HEAD>
<BODY>
<P><FONT FACE=3D"Arial">Hello,</FONT>
</P>
<P><FONT FACE=3D"Arial">The original intent of creating a next version =
of the IKE protocol was to reduce the complexity of the first =
one. Most observers of the next IKE evolution, including the =
principal author, Charlie Kaufman, know that the exercise to =
"homogenize" IKEv2 and JFK has moved us further away from the =
original goal of simplicity and completeness. We had that back in =
December of last year with IKE v2, a complete protocol package with v1 =
complexity removed. It was complete enough to allow for =
implementation trials.</FONT></P>
<P><FONT FACE=3D"Arial">Competent technical people will always =
find reasons to seek modifications to any draft in an effort to make it =
"just right". Steve Kent offered an excellent =
example today regarding revised identities to IKEv2. As a WG, we =
have argued the merits of crypto suites or not, 4 messages with =
stateless cookies vs. 2, and recently, key size conformance just to =
name a few. We have parsed the requirements and sought more =
opinions as to which requirements are most important. We have =
summarized those desired requirements and discussed them again. =
For more than a year we have churned like butter the next version of =
IKE with a multitude of "perfections" that consumed hours of =
thought and countless words of opinion. In seeking perfection and =
perhaps peace, we have lost the whole purpose which caused this WG to =
correct IKEv1. I do not advertise myself as an expert on the =
intricacies of IKE, but I do know that this perpetual churn does not =
necessarily create a better protocol or satisfy all the parties =
involved. One of the common complaints that permeate the IETF is =
that it takes too long for drafts to come out of the WG. Often =
the window of opportunity is lost because industry cannot wait for the =
perfect solution. This IKE exercise is the poster child for =
that problem.</FONT></P>
<P><FONT FACE=3D"Arial">With all due respect to the WG chairs and the =
Security ADs, leadership on this specific issue needs to be asserted =
and closure effected now. Closure means that a specific =
version of a released draft is acknowledged as the preferred draft and =
is forwarded to the IESG. Freeze that draft and do not accept any =
further changes. We do not need more technical stroking, nor do =
we need more discussions about making IKE better. All that has =
been done in excruciating detail. Words to this effect were =
boldly announced by the AD at the end of the March '02 meeting. =
But we keep churning and will continue to do so until a draft is =
recommended and moved forward out of IPsec.</FONT></P>
<P><FONT FACE=3D"Arial">If you agree with this assessment of the IKE =
issue, challenge our WG Chairs and ADs to close debate and move =
forward. Whatever your opinion, no one can say that the Chairs =
did not allow for adequate debate. </FONT></P>
<P><FONT FACE=3D"Arial">Regards,</FONT>
</P>
<P><FONT FACE=3D"Arial">Dennis Beard</FONT>
<BR><FONT FACE=3D"Arial">613-768-0323</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C2874C.B56E4162--
From owner-ipsec@lists.tislabs.com Fri Nov 8 13:59: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 gA8Lxiv24463;
Fri, 8 Nov 2002 13:59:49 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05609
Fri, 8 Nov 2002 16:22:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f05b9f1dafb9165@[165.227.249.18]>
In-Reply-To: <p05100310b9f1ce6c87aa@[128.89.88.34]>
References: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr>
<p05200f0fb9f198f66ecc@[165.227.249.18]>
<p05100310b9f1ce6c87aa@[128.89.88.34]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Fri, 8 Nov 2002 13:21:59 -0800
To: Stephen Kent <kent@bbn.com>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 3:27 PM -0500 11/8/02, Stephen Kent wrote:
>At 8:42 AM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>>At 10:46 AM +0100 11/8/02, Francis Dupont wrote:
>>>=> there is no agreement about what checks must be done:
>>> - common sense says the identity must be a subject of the certificate
>>> (but this is not clearly specified in IKEv1 and perhaps some
>>> implementations don't perform this check)
>>
>>That does not follow. There is no standard way for the Subject to
>>be an email address (the way folks do it now is a non-standard
>>hack), there is no standard way for the Subject to be an IP
>>address. I'm not sure, but I think the DC method of doing domain
>>names in the Subject is also a non-standard hack.
>
>I think the use of DC is a "standard hack," i.e., there is an RFC
>defining how to represent any DNS name in this fashion, and it may
>even state that this is the preferred way to do so if you use a DN
>rather than the SubAltname.
The "standard" (you can barely call it that), RFC 1274, preceded
subjectAltName by many years. It is yet another example of being able
to say two equivalent things in a PKIX certificate in two very
different ways.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Fri Nov 8 14:05: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 gA8M5ev25579;
Fri, 8 Nov 2002 14:05:45 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05674
Fri, 8 Nov 2002 16:40:55 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100313b9f1df1a72f0@[128.89.88.34]>
In-Reply-To: <p05200f05b9f1dafb9165@[165.227.249.18]>
References: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr>
<p05200f0fb9f198f66ecc@[165.227.249.18]>
<p05100310b9f1ce6c87aa@[128.89.88.34]>
<p05200f05b9f1dafb9165@[165.227.249.18]>
Date: Fri, 8 Nov 2002 16:38:51 -0500
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 1:21 PM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>At 3:27 PM -0500 11/8/02, Stephen Kent wrote:
>>At 8:42 AM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>>>At 10:46 AM +0100 11/8/02, Francis Dupont wrote:
>>>>=> there is no agreement about what checks must be done:
>>>> - common sense says the identity must be a subject of the certificate
>>>> (but this is not clearly specified in IKEv1 and perhaps some
>>>> implementations don't perform this check)
>>>
>>>That does not follow. There is no standard way for the Subject to
>>>be an email address (the way folks do it now is a non-standard
>>>hack), there is no standard way for the Subject to be an IP
>>>address. I'm not sure, but I think the DC method of doing domain
>>>names in the Subject is also a non-standard hack.
>>
>>I think the use of DC is a "standard hack," i.e., there is an RFC
>>defining how to represent any DNS name in this fashion, and it may
>>even state that this is the preferred way to do so if you use a DN
>>rather than the SubAltname.
>
>The "standard" (you can barely call it that), RFC 1274, preceded
>subjectAltName by many years. It is yet another example of being
>able to say two equivalent things in a PKIX certificate in two very
>different ways.
Agreed.
But if one had to have a DNS name in the Issuer field, e.g., because
PKIX mandates use of the Issuer DN in a CA cert, that's the only
standard game in town for a DNS representation, right?
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 8 14:19: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 gA8MJ6v27884;
Fri, 8 Nov 2002 14:19:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05706
Fri, 8 Nov 2002 16:50:05 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f0db9f1e1761609@[165.227.249.18]>
In-Reply-To: <p05100313b9f1df1a72f0@[128.89.88.34]>
References: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr>
<p05200f0fb9f198f66ecc@[165.227.249.18]>
<p05100310b9f1ce6c87aa@[128.89.88.34]>
<p05200f05b9f1dafb9165@[165.227.249.18]>
<p05100313b9f1df1a72f0@[128.89.88.34]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Fri, 8 Nov 2002 13:50:33 -0800
To: Stephen Kent <kent@bbn.com>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Adding revised identities to 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:38 PM -0500 11/8/02, Stephen Kent wrote:
>At 1:21 PM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>>At 3:27 PM -0500 11/8/02, Stephen Kent wrote:
>>>At 8:42 AM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>>>>At 10:46 AM +0100 11/8/02, Francis Dupont wrote:
>>>>>=> there is no agreement about what checks must be done:
>>>>> - common sense says the identity must be a subject of the certificate
>>>>> (but this is not clearly specified in IKEv1 and perhaps some
>>>>> implementations don't perform this check)
>>>>
>>>>That does not follow. There is no standard way for the Subject to
>>>>be an email address (the way folks do it now is a non-standard
>>>>hack), there is no standard way for the Subject to be an IP
>>>>address. I'm not sure, but I think the DC method of doing domain
>>>>names in the Subject is also a non-standard hack.
>>>
>>>I think the use of DC is a "standard hack," i.e., there is an RFC
>>>defining how to represent any DNS name in this fashion, and it may
>>>even state that this is the preferred way to do so if you use a DN
>>>rather than the SubAltname.
>>
>>The "standard" (you can barely call it that), RFC 1274, preceded
>>subjectAltName by many years. It is yet another example of being
>>able to say two equivalent things in a PKIX certificate in two very
>>different ways.
>
>Agreed.
>
>But if one had to have a DNS name in the Issuer field, e.g., because
>PKIX mandates use of the Issuer DN in a CA cert, that's the only
>standard game in town for a DNS representation, right?
No, you could use CommonName (CN). Given that name constraints
checking software is unlikely to get the hierarchy in four DC
components correct, you are better off saying "CN=www.example.com"
than "DC=www, DC=example, DC=com" because every piece of PKIX
software knows CN.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Fri Nov 8 14:51: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 gA8MpDv28744;
Fri, 8 Nov 2002 14:51:13 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05836
Fri, 8 Nov 2002 17:24:22 -0500 (EST)
Date: Fri, 8 Nov 2002 14:24:50 -0800 (PST)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
cc: <ipsec@lists.tislabs.com>
Subject: RE: Adding revised identities to IKEv2
In-Reply-To: <p05200f00b9f0e62aff99@[165.227.249.18]>
Message-ID: <Pine.LNX.4.33.0211081424230.3114-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 7 Nov 2002, Paul Hoffman / VPNC wrote:
> At 6:45 PM -0800 11/7/02, Max Pritikin wrote:
> >Paul H. isn't proposing any fancy pkix PKI tricks. He's proposing that IKE
> >handle pkix PKI certificates correctly; instead of the existing poorly
> >stated ID mechanisms which never had a chance of working with certificates.
>
> Exactly. For the majority of users, there is a single authorization
> policy: "everyone I trust is allowed to match any traffic policy". As
> Jan said, in IKEv1 with presahred keys, there is no separate ID: it
> is the IP address.
>
Correction: In IKE with MAIN MODE with pre-shared keys. Aggressive
mode opens up more options.
jan
> With certificates, it's a mess. Is the ID the whole Subject? Any part
> of the Subject? The whole SubjectAltName? Any part of the
> SubjectAltName? The combination of the whole Subject *and* the whole
> SubjectAltName? But the real question is, who cares? If the gateway
> admin wants to trust anyone who has a certificate from the trusted
> root, the ID is pretty much just there for logging. And if they do
> want to differentiate by ID, they are probably smart enough to fill
> in the right fields in the GUI for the ID type they care about.
> (Well, I just lied there: very few IPsec GUIs allow you to
> differentiate at the level needed.)
>
> --Paul Hoffman, Director
> --VPN Consortium
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
THE NETWORK WORKS,
NO EXCUS NFS server mastiff-fddi not responding still trying
From owner-ipsec@lists.tislabs.com Fri Nov 8 14:59: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 gA8MxQv29111;
Fri, 8 Nov 2002 14:59:26 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05858
Fri, 8 Nov 2002 17:30:24 -0500 (EST)
Message-Id: <200211082230.gA8MUidX032593@marajade.sandelman.ottawa.on.ca>
To: plugtests@etsi.fr
cc: ipsec@lists.tislabs.com
Subject: IPsec bakeoff in France
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 08 Nov 2002 17:30:44 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
ETSI people,
In order for me to know if I a bakeoff would be useful, I need to know
when it might happen.
If it were in the weeks after the Vienna IETF next summer, that would
be ideal.
That also gives us enough time to work on IKEv2.
] 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 Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPcw7EoqHRg3pndX9AQH9RgP/dljjeFhlUs0AGCQ7kY1V4CgPuq5jcrGk
mlssT+otD5j4rRlxSdHtmGFEC3ya37pyMjtQe0vyb+dBw/CzO0StJsFpHOP94RQy
6H564MhnR17OxtVELr91PHYsut2IqTeYRMp0dsG7PqaUsuZLvnXt6srQ2tezBVRl
A/gxUVAPsHU=
=2aix
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Fri Nov 8 14:59: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 gA8Mxrv29144;
Fri, 8 Nov 2002 14:59:53 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05876
Fri, 8 Nov 2002 17:33:25 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021108173021.020c7c40@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 08 Nov 2002 17:33:29 -0500
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <p05100310b9f1ce6c87aa@[128.89.88.34]>
References: <p05200f0fb9f198f66ecc@[165.227.249.18]>
<200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr>
<p05200f0fb9f198f66ecc@[165.227.249.18]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 03:27 PM 11/8/2002 -0500, Stephen Kent wrote:
>At 8:42 AM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>>At 10:46 AM +0100 11/8/02, Francis Dupont wrote:
>>>=> there is no agreement about what checks must be done:
>>> - common sense says the identity must be a subject of the certificate
>>> (but this is not clearly specified in IKEv1 and perhaps some
>>> implementations don't perform this check)
>>
>>That does not follow. There is no standard way for the Subject to be an
>>email address (the way folks do it now is a non-standard hack), there is
>>no standard way for the Subject to be an IP address. I'm not sure, but I
>>think the DC method of doing domain names in the Subject is also a
>>non-standard hack.
>
>I think the use of DC is a "standard hack," i.e., there is an RFC defining
>how to represent any DNS name in this fashion, and it may even state that
>this is the preferred way to do so if you use a DN rather than the SubAltname.
RFC 3280 requires support for DC. It says:
In addition, implementations of this specification MUST be prepared
to receive the domainComponent attribute, as defined in [RFC 2247].
The Domain Name System (DNS) provides a hierarchical resource
labeling system. This attribute provides a convenient mechanism for
organizations that wish to use DNs that parallel their DNS names.
This is not a replacement for the dNSName component of the
alternative name field. Implementations are not required to convert
such names into DNS names.
Russ
From owner-ipsec@lists.tislabs.com Fri Nov 8 15: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 gA8NALv29408;
Fri, 8 Nov 2002 15:10:21 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05931
Fri, 8 Nov 2002 17:45:42 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100315b9f1ec6391e5@[128.89.88.34]>
In-Reply-To: <p05200f0db9f1e1761609@[165.227.249.18]>
References: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr>
<p05200f0fb9f198f66ecc@[165.227.249.18]>
<p05100310b9f1ce6c87aa@[128.89.88.34]>
<p05200f05b9f1dafb9165@[165.227.249.18]>
<p05100313b9f1df1a72f0@[128.89.88.34]>
<p05200f0db9f1e1761609@[165.227.249.18]>
Date: Fri, 8 Nov 2002 17:37:27 -0500
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 1:50 PM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>At 4:38 PM -0500 11/8/02, Stephen Kent wrote:
>>At 1:21 PM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>>>At 3:27 PM -0500 11/8/02, Stephen Kent wrote:
>>>>At 8:42 AM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>>>>>At 10:46 AM +0100 11/8/02, Francis Dupont wrote:
>>>>>>=> there is no agreement about what checks must be done:
>>>>>> - common sense says the identity must be a subject of the certificate
>>>>>> (but this is not clearly specified in IKEv1 and perhaps some
>>>>>> implementations don't perform this check)
>>>>>
>>>>>That does not follow. There is no standard way for the Subject
>>>>>to be an email address (the way folks do it now is a
>>>>>non-standard hack), there is no standard way for the Subject to
>>>>>be an IP address. I'm not sure, but I think the DC method of
>>>>>doing domain names in the Subject is also a non-standard hack.
>>>>
>>>>I think the use of DC is a "standard hack," i.e., there is an RFC
>>>>defining how to represent any DNS name in this fashion, and it
>>>>may even state that this is the preferred way to do so if you use
>>>>a DN rather than the SubAltname.
>>>
>>>The "standard" (you can barely call it that), RFC 1274, preceded
>>>subjectAltName by many years. It is yet another example of being
>>>able to say two equivalent things in a PKIX certificate in two
>>>very different ways.
>>
>>Agreed.
>>
>>But if one had to have a DNS name in the Issuer field, e.g.,
>>because PKIX mandates use of the Issuer DN in a CA cert, that's the
>>only standard game in town for a DNS representation, right?
>
>No, you could use CommonName (CN). Given that name constraints
>checking software is unlikely to get the hierarchy in four DC
>components correct, you are better off saying "CN=www.example.com"
>than "DC=www, DC=example, DC=com" because every piece of PKIX
>software knows CN.
CN is definitely not a PKIX-endorsed way to represent a DNS name in a
DN, so I rule it out on that basis just to start. Yes, every piece of
software knows CN, but that does not make it a good choice in a
larger sense. I could use name constraints with the DC structure, but
not effectively with the CN structure, for example.
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 8 15:13: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 gA8NDVv29464;
Fri, 8 Nov 2002 15:13:31 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05967
Fri, 8 Nov 2002 17:51:47 -0500 (EST)
Message-ID: <71a0e3c9e7381b9113b0757bf8dcd93f3dcc3ff3@watchguard.com>
From: James Huang <james.huang@watchguard.com>
To: "'Skip Booth'" <ebooth@cisco.com>
Cc: "'Markus Stenberg'" <fingon@iki.fi>, ipsec@lists.tislabs.com,
"'l2tpext@ietf.org'" <l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 14:51:18 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: Skip Booth [mailto:ebooth@cisco.com]
> Sent: Friday, November 08, 2002 12:09 PM
> To: James Huang
> Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
>
>
> On Fri, 8 Nov 2002, James Huang wrote:
>
> > Skip,
> > If we fix up the source IP address using the private address
> > advertised in NAT-OA during IKE negotiation, then why should TCP/UDP
> > checksum be re-computed at the security gateway as was
> described in section
> > 3.1.2?
>
> Because the NAT would have modified the checksum as the
> packet passed through
> the NAT. In order for it to pass the IP CRC check at the SG,
> you must fixup the
> checksum based on the pre-NAT values.
>
Skip,
With UDP-encapsuilated IPsec, NAT box will only see and modify the outer UDP
header used to encapsulate the IPsec packet (in addtioanl to modify the
outer IP address). After the security gateway decapsulating an IPsec packet
in transport mode (i.e. removing the outer UDP header and the ESP header)
and modify the source IP address in the outer IP header with the address
received in the NAT-OA, the checksum in the inner TCP/UDP header should be
already correct as the client computes that checksum based on the same
address in the NAT-OA.
Am I missing something here?
Regards,
James Huang
> > The checksum was originally computed by the client using its
> > private address. Also is this solution the same as the
> "built-in NAT"
> > solution mentioned in Appendix A of
> draft-ietf-ipsec-udp-encaps-04.txt to
> > solve the problem of multiple clients behind a NAT with
> overlapped traffic
> > specifications?
>
> I don't the CRC fixup has anything to do with Appendix A.
>
> -Skip
>
> >
> > Thanks,
> > - James
> >
> >
> > > -----Original Message-----
> > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > Sent: Thursday, November 07, 2002 7:31 PM
> > > To: James Huang
> > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > >
> > >
> > >
> > > James, does the recommendation in section 3.1.2 a) answer
> > > your question? I
> > > believe after fixing up the IP header to include the private
> > > address which was
> > > advertised during the negotiation, the packet will pass
> > > through the SG filters.
> > > The authors of this draft should be able to provide further
> > > clarification if
> > > this doesn't address your concerns.
> > >
> > > -Skip
> > >
> > > On Thu, 7 Nov 2002, James Huang wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Markus Stenberg [mailto:fingon@iki.fi]
> > > > > Sent: Wednesday, November 06, 2002 11:51 PM
> > > > > To: James Huang
> > > > > Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > > Subject: Re: UDP-encapsulated IPsec Transport mode
> > > > >
> > > > >
> > > > > James Huang <james.huang@watchguard.com> writes:
> > > > > > Hi all,
> > > > > > In the appendix A of
> > > > > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > > > > some discussions on the issue of multiple clients running
> > > > > UDP-encapsulated
> > > > > > IPsec transport mode tunnels behind a NAT box. However,
> > > > > did not find any
> > > > > > discussion on another related issue: In the traffic
> > > > > selector (ID) payload
> > > > > > the client sends out during quick mode exchange, should the
> > > > > client use its
> > > > > > own private address or the public routable address (i.e.
> > > > > the NAT box's
> > > > > > public IP address)? If it the later, how does the client
> > > > > know about that
> > > > > > public address? This seems to be a serious issue,
> > > > > especially for L2TP
> > > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > > >
> > > > > L2TP specific issues I am blissfully unaware of; however,
> > > > > because the NAT
> > > > > boxes are not neccessarily even controlled by the IPsec user,
> > > > > sending the
> > > > > public address is not really an option that can be supported
> > > > > everywhere.
> > > > >
> > > >
> > > > Agreed.
> > > >
> > > > > Here's how the information flow goes as far as I see it:
> > > > >
> > > > > Public address doesn't really need to be sent in any case as
> > > > > the remote
> > > > > side's public address is the address we're talking IKE with
> > > > > (or at least
> > > > > remote address+port combination, but in NAPT case you don't
> > > > > really have
> > > > > more of an remote address in any case).
> > > > >
> > > > > Private address that is used by the OS for actual
> > > traffic is provided
> > > > > within the NAT-OA payload so the checksums et al can be
> > > corrected.
> > > > >
> > > >
> > > > Let me describe the issue with regarding to L2TP/IPsec
> > > (voluntary L2TP) when
> > > > a NAT is present. Suppose a PC with a home network's
> > > private IP address V_1
> > > > is behind a NAT box with a public address P_1. The
> > > corporate network's
> > > > Security Gateway's IP address is P_2 and the PC wants to
> > > connect to a
> > > > corporate server with private IP address I_2. If
> > > everything goes well, this
> > > > PC will eventually obtain another private address I_1 from
> > > the corporate
> > > > network through IPCP . So the L2TP traffic sent by the PC
> > > will have the
> > > > following headers: IP/UDP/ESP/UDP/L2TP control or
> > > > IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will
> > > indicate the
> > > > traffic is sent from V_1 to P_2. The inner IP header will
> > > indicate the
> > > > traffic is sent from I_1 to I_2. The source IP address V_1
> > > in the outer
> > > > header will be changed by the NAT box to P_1 on the way
> > > out. So the packet
> > > > received by the corporate SG is an UDP-encapsulated
> > > TRANSPORT mode IPsec
> > > > packet from P_1 to P_2 with UDP source port 1701 and UDP
> > > dest port 1701 in
> > > > the 2nd UDP header (assuming no dynamic UDP port for L2TP).
> > > To allow this
> > > > packet to pass through the SG, an inbound filter matching
> > > the packet must
> > > > exist in the SG. The inbound filter is dynamically created
> > > after a quick
> > > > mode exchange between the PC and the SG. To create such a
> > > filter in the SG,
> > > > the PC must specify < IP = P_1, proto = UDP, port = 1701>
> > > in ID_i during
> > > > the quick mode exchange. But how does this PC knows about P_1?
> > > >
> > > > What I described above is a scenario specific to
> L2TP/IPsec. But in
> > > > general, any transport mode IPsec tunnel with a NAT box
> > > along its path will
> > > > have the same problem.
> > > >
> > > > Am I right? Or I am missing something here?
> > > >
> > > > - James Huang
> > > >
> > > >
> > > >
> > > > > Therefore, at least as far as implementation I used to work
> > > > > on goes, ID
> > > > > payload in transport mode case doesn't matter (I seem to
> > > > > recall we sent
> > > > > private address, but pretty much ignored what was
> sent by remote).
> > > > >
> > > > > -Markus
> > > > >
> > > > > > Regards,
> > > > > > James C. Huang
> > > > >
> > > > > --
> > > > > "Every program has (at least) two purposes: the one for
> > > which it was
> > > > > written, and another for which it wasn't. "
> > > > >
> > > > > From ACM's SIGPLAN publication, (September, 1982),
> > > Article "Epigrams
> > > > > in Programming", by Alan J. Perlis of Yale University.
> > > > >
> > > >
> > >
> >
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 15:13: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 gA8NDfv29478;
Fri, 8 Nov 2002 15:13:41 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05952
Fri, 8 Nov 2002 17:50:47 -0500 (EST)
From: "Satyadeva Konduru" <skonduru@caymas.com>
To: "'James Huang'" <james.huang@watchguard.com>, <ipsec@lists.tislabs.com>,
<l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 14:51:01 -0800
Message-ID: <000401c28779$58ceb6d0$3e00010a@caymas.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, Build 10.0.3416
In-Reply-To: <1b5e89839d24839d709e637969682af73dc9afc1@watchguard.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
James,
Will there be any problem if the gateway (or any peer) treats the NATed
public address as the Phase 2 traffic selector, ignoring the private
address sent by client ? Obviously, the private address is of no use to
the gateway. Even the SPD lookup policy is based on the NATed address.
One other way the authors could have pursued is: the IKE gateway sending
the NATed address (NA) to the client in the Phase 1 as a NAT-NA payload.
This way, the client will get to know of its public address. But since
the NAT-NA can dynamically change, the gateway has to send the NAT-NA
payload every time the NATed public address changes.
-Satyadeva Konduru
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]
> On Behalf Of James Huang
> Sent: Wednesday, November 06, 2002 4:12 PM
> To: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> Subject: UDP-encapsulated IPsec Transport mode
>
> Hi all,
> In the appendix A of draft-ietf-ipsec-udp-encaps-04.txt, there
is
> some discussions on the issue of multiple clients running
UDP-encapsulated
> IPsec transport mode tunnels behind a NAT box. However, I did not
find
> any
> discussion on another related issue: In the traffic selector (ID)
payload
> the client sends out during quick mode exchange, should the client use
its
> own private address or the public routable address (i.e. the NAT box's
> public IP address)? If it the later, how does the client know about
that
> public address? This seems to be a serious issue, especially for L2TP
> voluntary tunnels secured by IPsec (in transport mode).
>
> Regards,
> James C. Huang
>
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 15:49: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 gA8Nnpv00642;
Fri, 8 Nov 2002 15:49:51 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06132
Fri, 8 Nov 2002 18:26:19 -0500 (EST)
Message-ID: <ff781f9b1e67c032feb6cf87011a4d213dcc481e@watchguard.com>
From: James Huang <james.huang@watchguard.com>
To: "'Satyadeva Konduru'" <skonduru@caymas.com>, ipsec@lists.tislabs.com,
l2tpext@ietf.org
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 15:26:19 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Satyadeva,
I thought about NAT-NA too. But I think the better idea which can
do without NAT-NA is as follows:
(1) The security gateway (SG) will insert entries into its filtering
database based on the traffic selector (ID) specified by the client during
the QM exchange.
(2) After the SG decrypted and decapsulated an UDP-encapsulated IPsec packet
in the transport mode (i.e. removing the outer UDP header and ESP header),
it will modify the source IP address in the outer IP header using the
address in the NAT-OA payload it received in the QM exchange.
With this scheme, the packet after decapsulation will pass the security
policy at the SG and the checksum in the inner UDP/TCP header no longer need
to be re-computed by the SG as was described in section 3.1.2 in the draft.
Also it will solve the issue of multiple clients behind the same NAT box
described in section 5.3.
The above is my personal opinion. I hope the authors of the draft can
provide more clarification.
Regards,
James Huang
> -----Original Message-----
> From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> Sent: Friday, November 08, 2002 2:51 PM
> To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
> James,
> Will there be any problem if the gateway (or any peer) treats
> the NATed
> public address as the Phase 2 traffic selector, ignoring the private
> address sent by client ? Obviously, the private address is of
> no use to
> the gateway. Even the SPD lookup policy is based on the NATed
> address.
>
> One other way the authors could have pursued is: the IKE
> gateway sending
> the NATed address (NA) to the client in the Phase 1 as a
> NAT-NA payload.
> This way, the client will get to know of its public address. But since
> the NAT-NA can dynamically change, the gateway has to send the NAT-NA
> payload every time the NATed public address changes.
>
> -Satyadeva Konduru
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]
> > On Behalf Of James Huang
> > Sent: Wednesday, November 06, 2002 4:12 PM
> > To: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > Subject: UDP-encapsulated IPsec Transport mode
> >
> > Hi all,
> > In the appendix A of draft-ietf-ipsec-udp-encaps-04.txt, there
> is
> > some discussions on the issue of multiple clients running
> UDP-encapsulated
> > IPsec transport mode tunnels behind a NAT box. However, I did not
> find
> > any
> > discussion on another related issue: In the traffic selector (ID)
> payload
> > the client sends out during quick mode exchange, should the
> client use
> its
> > own private address or the public routable address (i.e.
> the NAT box's
> > public IP address)? If it the later, how does the client know about
> that
> > public address? This seems to be a serious issue,
> especially for L2TP
> > voluntary tunnels secured by IPsec (in transport mode).
> >
> > Regards,
> > James C. Huang
> >
> >
>
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 16: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 gA90Tjv03532;
Fri, 8 Nov 2002 16:29:45 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06233
Fri, 8 Nov 2002 18:51:30 -0500 (EST)
From: "Satyadeva Konduru" <skonduru@caymas.com>
To: "'James Huang'" <james.huang@watchguard.com>, <ipsec@lists.tislabs.com>,
<l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 15:52:24 -0800
Message-ID: <000701c28781$e41ef440$3e00010a@caymas.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, Build 10.0.3416
In-Reply-To: <ff781f9b1e67c032feb6cf87011a4d213dcc47ff@watchguard.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
James,
Your suggestion will only "bypass" NAT but it will not "traverse" NAT.
My understanding is that the SG should see only the NATed public
address. If you take the transport mode in a larger context (not just
L2tp/ipsec), let us suppose there is a host accepting TCP connections.
As per your suggestion, if you replace the NATed address with NAT-OA,
there would be multiple TCP connections from different clients (all with
the same private address) mapping to the same socket pair.
-Satyadeva.
> -----Original Message-----
> From: James Huang [mailto:james.huang@watchguard.com]
> Sent: Friday, November 08, 2002 3:26 PM
> To: 'Satyadeva Konduru'; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
> Satyadeva,
>
> I thought about NAT-NA too. But I think the better idea which
can
> do without NAT-NA is as follows:
> (1) The security gateway (SG) will insert entries into its filtering
> database based on the traffic selector (ID) specified by the client
during
> the QM exchange.
> (2) After the SG decrypted and decapsulated an UDP-encapsulated IPsec
> packet
> in the transport mode (i.e. removing the outer UDP header and ESP
header),
> it will modify the source IP address in the outer IP header using the
> address in the NAT-OA payload it received in the QM exchange.
>
> With this scheme, the packet after decapsulation will pass the
security
> policy at the SG and the checksum in the inner UDP/TCP header no
longer
> need
> to be re-computed by the SG as was described in section 3.1.2 in the
> draft.
> Also it will solve the issue of multiple clients behind the same NAT
box
> described in section 5.3.
>
> The above is my personal opinion. I hope the authors of the draft
can
> provide more clarification.
>
> Regards,
> James Huang
>
>
>
> > -----Original Message-----
> > From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> > Sent: Friday, November 08, 2002 2:51 PM
> > To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > Subject: RE: UDP-encapsulated IPsec Transport mode
> >
> >
> > James,
> > Will there be any problem if the gateway (or any peer) treats
> > the NATed
> > public address as the Phase 2 traffic selector, ignoring the private
> > address sent by client ? Obviously, the private address is of
> > no use to
> > the gateway. Even the SPD lookup policy is based on the NATed
> > address.
> >
> > One other way the authors could have pursued is: the IKE
> > gateway sending
> > the NATed address (NA) to the client in the Phase 1 as a
> > NAT-NA payload.
> > This way, the client will get to know of its public address. But
since
> > the NAT-NA can dynamically change, the gateway has to send the
NAT-NA
> > payload every time the NATed public address changes.
> >
> > -Satyadeva Konduru
> >
> > > -----Original Message-----
> > > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]
> > > On Behalf Of James Huang
> > > Sent: Wednesday, November 06, 2002 4:12 PM
> > > To: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > Subject: UDP-encapsulated IPsec Transport mode
> > >
> > > Hi all,
> > > In the appendix A of draft-ietf-ipsec-udp-encaps-04.txt, there
> > is
> > > some discussions on the issue of multiple clients running
> > UDP-encapsulated
> > > IPsec transport mode tunnels behind a NAT box. However, I did not
> > find
> > > any
> > > discussion on another related issue: In the traffic selector (ID)
> > payload
> > > the client sends out during quick mode exchange, should the
> > client use
> > its
> > > own private address or the public routable address (i.e.
> > the NAT box's
> > > public IP address)? If it the later, how does the client know
about
> > that
> > > public address? This seems to be a serious issue,
> > especially for L2TP
> > > voluntary tunnels secured by IPsec (in transport mode).
> > >
> > > Regards,
> > > James C. Huang
> > >
> > >
> >
> >
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 17:18: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 gA91Iuv05488;
Fri, 8 Nov 2002 17:18:56 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06365
Fri, 8 Nov 2002 19:43:46 -0500 (EST)
Message-ID: <1162db20a6656dd4b091ed1d20fd95a53dcc5a3c@watchguard.com>
From: James Huang <james.huang@watchguard.com>
To: "'Satyadeva Konduru'" <skonduru@caymas.com>, ipsec@lists.tislabs.com,
l2tpext@ietf.org
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 16:44:04 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> Sent: Friday, November 08, 2002 3:52 PM
> To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
>
> James,
> Your suggestion will only "bypass" NAT but it will not "traverse" NAT.
> My understanding is that the SG should see only the NATed public
> address. If you take the transport mode in a larger context (not just
> L2tp/ipsec), let us suppose there is a host accepting TCP connections.
> As per your suggestion, if you replace the NATed address with NAT-OA,
> there would be multiple TCP connections from different
> clients (all with
> the same private address) mapping to the same socket pair.
>
Satyadeva,
If these multiple clients use the same private address, then when
the server (LNS) receives an inbound SCCRQ , it should have chosen a
distinct UDP port number for each client.
If we take a larger context as you suggested where there is a
server running in the SG listening to a well-known TCP port. If the above
multiple clients also chose the same TCP port number, then I agree doing
NAT will not be enough. In that case, the SG will have to do NAT (on the
inbound source IP address) + dynamic PAT (on the inbound TCP source port)
before passing a decapsulated inbound packet to the server.
-- James
> -Satyadeva.
>
> > -----Original Message-----
> > From: James Huang [mailto:james.huang@watchguard.com]
> > Sent: Friday, November 08, 2002 3:26 PM
> > To: 'Satyadeva Konduru'; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > Subject: RE: UDP-encapsulated IPsec Transport mode
> >
> > Satyadeva,
> >
> > I thought about NAT-NA too. But I think the better idea which
> can
> > do without NAT-NA is as follows:
> > (1) The security gateway (SG) will insert entries into its filtering
> > database based on the traffic selector (ID) specified by the client
> during
> > the QM exchange.
> > (2) After the SG decrypted and decapsulated an
> UDP-encapsulated IPsec
> > packet
> > in the transport mode (i.e. removing the outer UDP header and ESP
> header),
> > it will modify the source IP address in the outer IP header
> using the
> > address in the NAT-OA payload it received in the QM exchange.
> >
> > With this scheme, the packet after decapsulation will pass the
> security
> > policy at the SG and the checksum in the inner UDP/TCP header no
> longer
> > need
> > to be re-computed by the SG as was described in section 3.1.2 in the
> > draft.
> > Also it will solve the issue of multiple clients behind the same NAT
> box
> > described in section 5.3.
> >
> > The above is my personal opinion. I hope the authors of the draft
> can
> > provide more clarification.
> >
> > Regards,
> > James Huang
> >
> >
> >
> > > -----Original Message-----
> > > From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> > > Sent: Friday, November 08, 2002 2:51 PM
> > > To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > >
> > >
> > > James,
> > > Will there be any problem if the gateway (or any peer) treats
> > > the NATed
> > > public address as the Phase 2 traffic selector, ignoring
> the private
> > > address sent by client ? Obviously, the private address is of
> > > no use to
> > > the gateway. Even the SPD lookup policy is based on the NATed
> > > address.
> > >
> > > One other way the authors could have pursued is: the IKE
> > > gateway sending
> > > the NATed address (NA) to the client in the Phase 1 as a
> > > NAT-NA payload.
> > > This way, the client will get to know of its public address. But
> since
> > > the NAT-NA can dynamically change, the gateway has to send the
> NAT-NA
> > > payload every time the NATed public address changes.
> > >
> > > -Satyadeva Konduru
> > >
> > > > -----Original Message-----
> > > > From: owner-ipsec@lists.tislabs.com
> > > [mailto:owner-ipsec@lists.tislabs.com]
> > > > On Behalf Of James Huang
> > > > Sent: Wednesday, November 06, 2002 4:12 PM
> > > > To: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > Subject: UDP-encapsulated IPsec Transport mode
> > > >
> > > > Hi all,
> > > > In the appendix A of
> draft-ietf-ipsec-udp-encaps-04.txt, there
> > > is
> > > > some discussions on the issue of multiple clients running
> > > UDP-encapsulated
> > > > IPsec transport mode tunnels behind a NAT box.
> However, I did not
> > > find
> > > > any
> > > > discussion on another related issue: In the traffic
> selector (ID)
> > > payload
> > > > the client sends out during quick mode exchange, should the
> > > client use
> > > its
> > > > own private address or the public routable address (i.e.
> > > the NAT box's
> > > > public IP address)? If it the later, how does the client know
> about
> > > that
> > > > public address? This seems to be a serious issue,
> > > especially for L2TP
> > > > voluntary tunnels secured by IPsec (in transport mode).
> > > >
> > > > Regards,
> > > > James C. Huang
> > > >
> > > >
> > >
> > >
> >
>
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 17:19: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 gA91JAv05507;
Fri, 8 Nov 2002 17:19:10 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06387
Fri, 8 Nov 2002 19:49:49 -0500 (EST)
Date: Fri, 8 Nov 2002 19:50:16 -0500 (Eastern Standard Time)
From: Skip Booth <ebooth@cisco.com>
To: James Huang <james.huang@watchguard.com>
cc: "'Markus Stenberg'" <fingon@iki.fi>, <ipsec@lists.tislabs.com>,
"'l2tpext@ietf.org'" <l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
In-Reply-To: <71a0e3c9e7381b9113b0757bf8dcd93f3dcc3fe4@watchguard.com>
Message-ID: <Pine.WNT.4.44.0211081944450.520-100000@EBOOTH-W2K.amer.cisco.com>
X-Warning: UNAuthenticated Sender
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, 8 Nov 2002, James Huang wrote:
>
>
> > -----Original Message-----
> > From: Skip Booth [mailto:ebooth@cisco.com]
> > Sent: Friday, November 08, 2002 12:09 PM
> > To: James Huang
> > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > Subject: RE: UDP-encapsulated IPsec Transport mode
> >
> >
> >
> >
> > On Fri, 8 Nov 2002, James Huang wrote:
> >
> > > Skip,
> > > If we fix up the source IP address using the private address
> > > advertised in NAT-OA during IKE negotiation, then why should TCP/UDP
> > > checksum be re-computed at the security gateway as was
> > described in section
> > > 3.1.2?
> >
> > Because the NAT would have modified the checksum as the
> > packet passed through
> > the NAT. In order for it to pass the IP CRC check at the SG,
> > you must fixup the
> > checksum based on the pre-NAT values.
> >
>
>
> Skip,
>
> With UDP-encapsuilated IPsec, NAT box will only see and modify the outer UDP
> header used to encapsulate the IPsec packet (in addtioanl to modify the
> outer IP address). After the security gateway decapsulating an IPsec packet
> in transport mode (i.e. removing the outer UDP header and the ESP header)
> and modify the source IP address in the outer IP header with the address
> received in the NAT-OA, the checksum in the inner TCP/UDP header should be
> already correct as the client computes that checksum based on the same
> address in the NAT-OA.
>
> Am I missing something here?
I think you are confused since it appears that you believe their is an outer IP
header and an inner IP header. This is not true for the Transport Mode ESP
encap specified in the draft. The packet format for Transport Mode ESP Encap
(which is what would be used for L2TP/IPsec most likely) is specified as
follows:
3.2 Transport Mode ESP Encapsulation
BEFORE APPLYING ESP/UDP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP/UDP
-------------------------------------------------------
IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
|(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
For L2TP/IPsec, these will look like:
IP/UDP/ESP/1701/1701/[L2TP hdr/PPP]/ESP trailer/ESP Auth
As such, the outer header contains the private address. The NAT box will
perform the IP address/port translation on the outer IP/UDP header and in the
process will recompute the CRC on the outer IP header. On the SG, after
restoring the private addresses on the outer header, the CRC must be restored to
the original value prior to the NAT fixup.
-Skip
>
> Regards,
> James Huang
>
>
>
>
> > > The checksum was originally computed by the client using its
> > > private address. Also is this solution the same as the
> > "built-in NAT"
> > > solution mentioned in Appendix A of
> > draft-ietf-ipsec-udp-encaps-04.txt to
> > > solve the problem of multiple clients behind a NAT with
> > overlapped traffic
> > > specifications?
> >
> > I don't the CRC fixup has anything to do with Appendix A.
> >
> > -Skip
> >
> > >
> > > Thanks,
> > > - James
> > >
> > >
> > > > -----Original Message-----
> > > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > > Sent: Thursday, November 07, 2002 7:31 PM
> > > > To: James Huang
> > > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > >
> > > >
> > > >
> > > > James, does the recommendation in section 3.1.2 a) answer
> > > > your question? I
> > > > believe after fixing up the IP header to include the private
> > > > address which was
> > > > advertised during the negotiation, the packet will pass
> > > > through the SG filters.
> > > > The authors of this draft should be able to provide further
> > > > clarification if
> > > > this doesn't address your concerns.
> > > >
> > > > -Skip
> > > >
> > > > On Thu, 7 Nov 2002, James Huang wrote:
> > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Markus Stenberg [mailto:fingon@iki.fi]
> > > > > > Sent: Wednesday, November 06, 2002 11:51 PM
> > > > > > To: James Huang
> > > > > > Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > > > Subject: Re: UDP-encapsulated IPsec Transport mode
> > > > > >
> > > > > >
> > > > > > James Huang <james.huang@watchguard.com> writes:
> > > > > > > Hi all,
> > > > > > > In the appendix A of
> > > > > > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > > > > > some discussions on the issue of multiple clients running
> > > > > > UDP-encapsulated
> > > > > > > IPsec transport mode tunnels behind a NAT box. However,
> > > > > > did not find any
> > > > > > > discussion on another related issue: In the traffic
> > > > > > selector (ID) payload
> > > > > > > the client sends out during quick mode exchange, should the
> > > > > > client use its
> > > > > > > own private address or the public routable address (i.e.
> > > > > > the NAT box's
> > > > > > > public IP address)? If it the later, how does the client
> > > > > > know about that
> > > > > > > public address? This seems to be a serious issue,
> > > > > > especially for L2TP
> > > > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > > > >
> > > > > > L2TP specific issues I am blissfully unaware of; however,
> > > > > > because the NAT
> > > > > > boxes are not neccessarily even controlled by the IPsec user,
> > > > > > sending the
> > > > > > public address is not really an option that can be supported
> > > > > > everywhere.
> > > > > >
> > > > >
> > > > > Agreed.
> > > > >
> > > > > > Here's how the information flow goes as far as I see it:
> > > > > >
> > > > > > Public address doesn't really need to be sent in any case as
> > > > > > the remote
> > > > > > side's public address is the address we're talking IKE with
> > > > > > (or at least
> > > > > > remote address+port combination, but in NAPT case you don't
> > > > > > really have
> > > > > > more of an remote address in any case).
> > > > > >
> > > > > > Private address that is used by the OS for actual
> > > > traffic is provided
> > > > > > within the NAT-OA payload so the checksums et al can be
> > > > corrected.
> > > > > >
> > > > >
> > > > > Let me describe the issue with regarding to L2TP/IPsec
> > > > (voluntary L2TP) when
> > > > > a NAT is present. Suppose a PC with a home network's
> > > > private IP address V_1
> > > > > is behind a NAT box with a public address P_1. The
> > > > corporate network's
> > > > > Security Gateway's IP address is P_2 and the PC wants to
> > > > connect to a
> > > > > corporate server with private IP address I_2. If
> > > > everything goes well, this
> > > > > PC will eventually obtain another private address I_1 from
> > > > the corporate
> > > > > network through IPCP . So the L2TP traffic sent by the PC
> > > > will have the
> > > > > following headers: IP/UDP/ESP/UDP/L2TP control or
> > > > > IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will
> > > > indicate the
> > > > > traffic is sent from V_1 to P_2. The inner IP header will
> > > > indicate the
> > > > > traffic is sent from I_1 to I_2. The source IP address V_1
> > > > in the outer
> > > > > header will be changed by the NAT box to P_1 on the way
> > > > out. So the packet
> > > > > received by the corporate SG is an UDP-encapsulated
> > > > TRANSPORT mode IPsec
> > > > > packet from P_1 to P_2 with UDP source port 1701 and UDP
> > > > dest port 1701 in
> > > > > the 2nd UDP header (assuming no dynamic UDP port for L2TP).
> > > > To allow this
> > > > > packet to pass through the SG, an inbound filter matching
> > > > the packet must
> > > > > exist in the SG. The inbound filter is dynamically created
> > > > after a quick
> > > > > mode exchange between the PC and the SG. To create such a
> > > > filter in the SG,
> > > > > the PC must specify < IP = P_1, proto = UDP, port = 1701>
> > > > in ID_i during
> > > > > the quick mode exchange. But how does this PC knows about P_1?
> > > > >
> > > > > What I described above is a scenario specific to
> > L2TP/IPsec. But in
> > > > > general, any transport mode IPsec tunnel with a NAT box
> > > > along its path will
> > > > > have the same problem.
> > > > >
> > > > > Am I right? Or I am missing something here?
> > > > >
> > > > > - James Huang
> > > > >
> > > > >
> > > > >
> > > > > > Therefore, at least as far as implementation I used to work
> > > > > > on goes, ID
> > > > > > payload in transport mode case doesn't matter (I seem to
> > > > > > recall we sent
> > > > > > private address, but pretty much ignored what was
> > sent by remote).
> > > > > >
> > > > > > -Markus
> > > > > >
> > > > > > > Regards,
> > > > > > > James C. Huang
> > > > > >
> > > > > > --
> > > > > > "Every program has (at least) two purposes: the one for
> > > > which it was
> > > > > > written, and another for which it wasn't. "
> > > > > >
> > > > > > From ACM's SIGPLAN publication, (September, 1982),
> > > > Article "Epigrams
> > > > > > in Programming", by Alan J. Perlis of Yale University.
> > > > > >
> > > > >
> > > >
> > >
> >
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 17:31: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 gA91Vuv06103;
Fri, 8 Nov 2002 17:31:56 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06513
Fri, 8 Nov 2002 20:07:00 -0500 (EST)
From: "Satyadeva Konduru" <skonduru@caymas.com>
To: "'James Huang'" <james.huang@watchguard.com>, <ipsec@lists.tislabs.com>,
<l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 17:07:23 -0800
Message-ID: <000b01c2878c$5e69fa10$3e00010a@caymas.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, Build 10.0.3416
In-Reply-To: <1162db20a6656dd4b091ed1d20fd95a53dcc5a3a@watchguard.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> If we take a larger context as you suggested where there is
a
> server running in the SG listening to a well-known TCP port. If the
above
> multiple clients also chose the same TCP port number, then I agree
doing
> NAT will not be enough. In that case, the SG will have to do NAT (on
the
> inbound source IP address) + dynamic PAT (on the inbound TCP source
port)
> before passing a decapsulated inbound packet to the server.
I think you got me wrong here. In my example, the multiple clients with
the same private addresses lie behind "different NAT gateways with
different public addresses" and hence a single NAT done by a NAT gateway
in the middle would suffice. Now as per your earlier suggestion of
replacing the NATed public address with NAT-OA after UDP decapsulation
does not make sense here, because, all the clients could possibly have
the same private addresses and ports.
-Satyadeva
> >
> > James,
> > Your suggestion will only "bypass" NAT but it will not "traverse"
NAT.
> > My understanding is that the SG should see only the NATed public
> > address. If you take the transport mode in a larger context (not
just
> > L2tp/ipsec), let us suppose there is a host accepting TCP
connections.
> > As per your suggestion, if you replace the NATed address with
NAT-OA,
> > there would be multiple TCP connections from different
> > clients (all with
> > the same private address) mapping to the same socket pair.
> >
>
>
> > -Satyadeva.
> >
> > > -----Original Message-----
> > > From: James Huang [mailto:james.huang@watchguard.com]
> > > Sent: Friday, November 08, 2002 3:26 PM
> > > To: 'Satyadeva Konduru'; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > >
> > > Satyadeva,
> > >
> > > I thought about NAT-NA too. But I think the better idea which
> > can
> > > do without NAT-NA is as follows:
> > > (1) The security gateway (SG) will insert entries into its
filtering
> > > database based on the traffic selector (ID) specified by the
client
> > during
> > > the QM exchange.
> > > (2) After the SG decrypted and decapsulated an
> > UDP-encapsulated IPsec
> > > packet
> > > in the transport mode (i.e. removing the outer UDP header and ESP
> > header),
> > > it will modify the source IP address in the outer IP header
> > using the
> > > address in the NAT-OA payload it received in the QM exchange.
> > >
> > > With this scheme, the packet after decapsulation will pass the
> > security
> > > policy at the SG and the checksum in the inner UDP/TCP header no
> > longer
> > > need
> > > to be re-computed by the SG as was described in section 3.1.2 in
the
> > > draft.
> > > Also it will solve the issue of multiple clients behind the same
NAT
> > box
> > > described in section 5.3.
> > >
> > > The above is my personal opinion. I hope the authors of the
draft
> > can
> > > provide more clarification.
> > >
> > > Regards,
> > > James Huang
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> > > > Sent: Friday, November 08, 2002 2:51 PM
> > > > To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > >
> > > >
> > > > James,
> > > > Will there be any problem if the gateway (or any peer) treats
> > > > the NATed
> > > > public address as the Phase 2 traffic selector, ignoring
> > the private
> > > > address sent by client ? Obviously, the private address is of
> > > > no use to
> > > > the gateway. Even the SPD lookup policy is based on the NATed
> > > > address.
> > > >
> > > > One other way the authors could have pursued is: the IKE
> > > > gateway sending
> > > > the NATed address (NA) to the client in the Phase 1 as a
> > > > NAT-NA payload.
> > > > This way, the client will get to know of its public address. But
> > since
> > > > the NAT-NA can dynamically change, the gateway has to send the
> > NAT-NA
> > > > payload every time the NATed public address changes.
> > > >
> > > > -Satyadeva Konduru
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-ipsec@lists.tislabs.com
> > > > [mailto:owner-ipsec@lists.tislabs.com]
> > > > > On Behalf Of James Huang
> > > > > Sent: Wednesday, November 06, 2002 4:12 PM
> > > > > To: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > > Subject: UDP-encapsulated IPsec Transport mode
> > > > >
> > > > > Hi all,
> > > > > In the appendix A of
> > draft-ietf-ipsec-udp-encaps-04.txt, there
> > > > is
> > > > > some discussions on the issue of multiple clients running
> > > > UDP-encapsulated
> > > > > IPsec transport mode tunnels behind a NAT box.
> > However, I did not
> > > > find
> > > > > any
> > > > > discussion on another related issue: In the traffic
> > selector (ID)
> > > > payload
> > > > > the client sends out during quick mode exchange, should the
> > > > client use
> > > > its
> > > > > own private address or the public routable address (i.e.
> > > > the NAT box's
> > > > > public IP address)? If it the later, how does the client know
> > about
> > > > that
> > > > > public address? This seems to be a serious issue,
> > > > especially for L2TP
> > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > > >
> > > > > Regards,
> > > > > James C. Huang
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 17:41:08 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 gA91f7v06545;
Fri, 8 Nov 2002 17:41:07 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06537
Fri, 8 Nov 2002 20:17:00 -0500 (EST)
Message-ID: <989d9ce16ef1ef2b10afa29ecbfd9dfe3dcc61f7@watchguard.com>
From: James Huang <james.huang@watchguard.com>
To: "'Satyadeva Konduru'" <skonduru@caymas.com>, ipsec@lists.tislabs.com,
l2tpext@ietf.org
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 17:17:06 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> Sent: Friday, November 08, 2002 5:07 PM
> To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
>
>
> > If we take a larger context as you suggested
> where there is
> a
> > server running in the SG listening to a well-known TCP port. If the
> above
> > multiple clients also chose the same TCP port number, then I agree
> doing
> > NAT will not be enough. In that case, the SG will have to
> do NAT (on
> the
> > inbound source IP address) + dynamic PAT (on the inbound TCP source
> port)
> > before passing a decapsulated inbound packet to the server.
>
> I think you got me wrong here. In my example, the multiple
> clients with
> the same private addresses lie behind "different NAT gateways with
> different public addresses" and hence a single NAT done by a
> NAT gateway
> in the middle would suffice. Now as per your earlier suggestion of
> replacing the NATed public address with NAT-OA after UDP decapsulation
> does not make sense here, because, all the clients could possibly have
> the same private addresses and ports.
>
> -Satyadeva
>
No, I knew this is exactly what you are talking about. That is why I said
NAT (on the inbound source IP address) using NAT-OA + dynamic PAT (on the
inbound TCP source port) is needed at the security gateway after
decapsulating the UDP/IPsec header.
- James
>
> > >
> > > James,
> > > Your suggestion will only "bypass" NAT but it will not "traverse"
> NAT.
> > > My understanding is that the SG should see only the NATed public
> > > address. If you take the transport mode in a larger context (not
> just
> > > L2tp/ipsec), let us suppose there is a host accepting TCP
> connections.
> > > As per your suggestion, if you replace the NATed address with
> NAT-OA,
> > > there would be multiple TCP connections from different
> > > clients (all with
> > > the same private address) mapping to the same socket pair.
> > >
> >
> >
> > > -Satyadeva.
> > >
> > > > -----Original Message-----
> > > > From: James Huang [mailto:james.huang@watchguard.com]
> > > > Sent: Friday, November 08, 2002 3:26 PM
> > > > To: 'Satyadeva Konduru'; ipsec@lists.tislabs.com;
> l2tpext@ietf.org
> > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > >
> > > > Satyadeva,
> > > >
> > > > I thought about NAT-NA too. But I think the
> better idea which
> > > can
> > > > do without NAT-NA is as follows:
> > > > (1) The security gateway (SG) will insert entries into its
> filtering
> > > > database based on the traffic selector (ID) specified by the
> client
> > > during
> > > > the QM exchange.
> > > > (2) After the SG decrypted and decapsulated an
> > > UDP-encapsulated IPsec
> > > > packet
> > > > in the transport mode (i.e. removing the outer UDP
> header and ESP
> > > header),
> > > > it will modify the source IP address in the outer IP header
> > > using the
> > > > address in the NAT-OA payload it received in the QM exchange.
> > > >
> > > > With this scheme, the packet after decapsulation will pass the
> > > security
> > > > policy at the SG and the checksum in the inner UDP/TCP header no
> > > longer
> > > > need
> > > > to be re-computed by the SG as was described in section 3.1.2 in
> the
> > > > draft.
> > > > Also it will solve the issue of multiple clients behind the same
> NAT
> > > box
> > > > described in section 5.3.
> > > >
> > > > The above is my personal opinion. I hope the authors of the
> draft
> > > can
> > > > provide more clarification.
> > > >
> > > > Regards,
> > > > James Huang
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> > > > > Sent: Friday, November 08, 2002 2:51 PM
> > > > > To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > > >
> > > > >
> > > > > James,
> > > > > Will there be any problem if the gateway (or any peer) treats
> > > > > the NATed
> > > > > public address as the Phase 2 traffic selector, ignoring
> > > the private
> > > > > address sent by client ? Obviously, the private address is of
> > > > > no use to
> > > > > the gateway. Even the SPD lookup policy is based on the NATed
> > > > > address.
> > > > >
> > > > > One other way the authors could have pursued is: the IKE
> > > > > gateway sending
> > > > > the NATed address (NA) to the client in the Phase 1 as a
> > > > > NAT-NA payload.
> > > > > This way, the client will get to know of its public
> address. But
> > > since
> > > > > the NAT-NA can dynamically change, the gateway has to send the
> > > NAT-NA
> > > > > payload every time the NATed public address changes.
> > > > >
> > > > > -Satyadeva Konduru
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-ipsec@lists.tislabs.com
> > > > > [mailto:owner-ipsec@lists.tislabs.com]
> > > > > > On Behalf Of James Huang
> > > > > > Sent: Wednesday, November 06, 2002 4:12 PM
> > > > > > To: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > > > Subject: UDP-encapsulated IPsec Transport mode
> > > > > >
> > > > > > Hi all,
> > > > > > In the appendix A of
> > > draft-ietf-ipsec-udp-encaps-04.txt, there
> > > > > is
> > > > > > some discussions on the issue of multiple clients running
> > > > > UDP-encapsulated
> > > > > > IPsec transport mode tunnels behind a NAT box.
> > > However, I did not
> > > > > find
> > > > > > any
> > > > > > discussion on another related issue: In the traffic
> > > selector (ID)
> > > > > payload
> > > > > > the client sends out during quick mode exchange, should the
> > > > > client use
> > > > > its
> > > > > > own private address or the public routable address (i.e.
> > > > > the NAT box's
> > > > > > public IP address)? If it the later, how does the
> client know
> > > about
> > > > > that
> > > > > > public address? This seems to be a serious issue,
> > > > > especially for L2TP
> > > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > > > >
> > > > > > Regards,
> > > > > > James C. Huang
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 18:41: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 gA92fgv07839;
Fri, 8 Nov 2002 18:41:42 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06689
Fri, 8 Nov 2002 21:13:17 -0500 (EST)
Message-ID: <c8ef65bb020dfbe43eb127f9f18dfa263dcc6f58@watchguard.com>
From: James Huang <james.huang@watchguard.com>
To: "'Skip Booth'" <ebooth@cisco.com>
Cc: "'Markus Stenberg'" <fingon@iki.fi>, ipsec@lists.tislabs.com,
"'l2tpext@ietf.org'" <l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 18:13:56 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: Skip Booth [mailto:ebooth@cisco.com]
> Sent: Friday, November 08, 2002 4:50 PM
> To: James Huang
> Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
>
>
> On Fri, 8 Nov 2002, James Huang wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > Sent: Friday, November 08, 2002 12:09 PM
> > > To: James Huang
> > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > >
> > >
> > >
> > >
> > > On Fri, 8 Nov 2002, James Huang wrote:
> > >
> > > > Skip,
> > > > If we fix up the source IP address using the
> private address
> > > > advertised in NAT-OA during IKE negotiation, then why
> should TCP/UDP
> > > > checksum be re-computed at the security gateway as was
> > > described in section
> > > > 3.1.2?
> > >
> > > Because the NAT would have modified the checksum as the
> > > packet passed through
> > > the NAT. In order for it to pass the IP CRC check at the SG,
> > > you must fixup the
> > > checksum based on the pre-NAT values.
> > >
> >
> >
> > Skip,
> >
> > With UDP-encapsuilated IPsec, NAT box will only see and
> modify the outer UDP
> > header used to encapsulate the IPsec packet (in addtioanl
> to modify the
> > outer IP address). After the security gateway
> decapsulating an IPsec packet
> > in transport mode (i.e. removing the outer UDP header and
> the ESP header)
> > and modify the source IP address in the outer IP header
> with the address
> > received in the NAT-OA, the checksum in the inner TCP/UDP
> header should be
> > already correct as the client computes that checksum based
> on the same
> > address in the NAT-OA.
> >
> > Am I missing something here?
>
> I think you are confused since it appears that you believe
> their is an outer IP
> header and an inner IP header. This is not true for the
> Transport Mode ESP
> encap specified in the draft. The packet format for
> Transport Mode ESP Encap
> (which is what would be used for L2TP/IPsec most likely) is
> specified as
> follows:
>
> 3.2 Transport Mode ESP Encapsulation
>
> BEFORE APPLYING ESP/UDP
> ----------------------------
> IPv4 |orig IP hdr | | |
> |(any options)| TCP | Data |
> ----------------------------
>
> AFTER APPLYING ESP/UDP
> -------------------------------------------------------
> IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
> |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
> -------------------------------------------------------
> |<----- encrypted ---->|
> |<------ authenticated ----->|
>
> For L2TP/IPsec, these will look like:
>
> IP/UDP/ESP/1701/1701/[L2TP hdr/PPP]/ESP trailer/ESP Auth
>
Skip,
The L2TP/IPsec packet should look like this in more detail,
IP1/UDP/ESP/1701/1701/L2TP hdr/PPP hdr / IP2/ ... /ESP trailer/ESP Auth.
The outer IP header is the first IP header IP1 above. The inner IP header
is the second IP header IP2 that I just added. THis is the packet format
after the IPsec tunnel is set up, L2TP tunnel is set up, IPCP is completed
(e.g. for the client to obtain a private address in the corporate network),
and the real data traffic inside the L2TP tunnel starts flowing..
> As such, the outer header contains the private address. The
> NAT box will
> perform the IP address/port translation on the outer IP/UDP
> header and in the
> process will recompute the CRC on the outer IP header. On
> the SG, after
> restoring the private addresses on the outer header, the CRC
> must be restored to
> the original value prior to the NAT fixup.
>
> -Skip
Skip,
Lets take the following scenario as an example.
PC -------- NAT -------- internet --------- SG
------------ server
Suppose the PC's private address is PC1, the public address at the NAT is
P1, the public address at SG is P2, and the server has a private corporate
address S1.
Both the IPsec transport mode tunnel and the L2TP tunnel are btw the PC and
the SG.
During IKE QM exchange to set up an IPsec tunnel to protect L2TP packets,
the first packet the SG received will look like this:
ip header: P1->P2,
traffic selectors: IP: PC1<->P2, udp port: 1701 <-> 1701 (assuming LAC
chose the fixed UDP port). If the QM exchange succeeds, the SG will enter
into its inbound/outbound filtering database based on above traffic spec.
When the PC sends out a L2TP control packet, it will look like this:
IP/UDP1/ESP/UDP2/L2TP control/ESP trailer/ESP Auth. The IP header will be
from PC1 to P2 and UDP1 will be from 4500 to 4500, UDP2 will be from 1701 to
1701. The UDP checksum in UDP2 will be based on the address PC1. After
this packet passed the NAT box, the IP header will be from P1 to P2 and UDP1
may be adjusted to from port Y to 4500 and its checksum also adjusted.
Note UDP2 is not touched by the NAT box.
After the SG decrypts and decapsulats the inbound packet, it will look like
this: IP/UDP2/L2TP control. The IP header will be from P1 to P2 and UDP2
from 1701 to 1701.
The SG will then modify the IP header to PC1 -> P2. Now the packet will
pass the checking using the filtering database and the checksum in UDP2 will
also be automatically correct.
After the L2TP tunnel is set up, and IPCP is completed, the PC will obtain a
private address Vpc1 from inside the corporate network. Now the packet sent
by the PC will look like this: IP1/UDP1/ESP/UDP2/L2TP hdr/PPP hdr / IP2/
... /ESP trailer/ESP Auth.
IP1: PC1->P2
UDP1: 4500->4500
UDP2: 1701->1701 (checksum computed based on PC1)
IP2: Vpc1->S1
The rest should be very similar to what I described above.
-- James Huang
> >
> > Regards,
> > James Huang
> >
> >
> >
> >
> > > > The checksum was originally computed by the client using its
> > > > private address. Also is this solution the same as the
> > > "built-in NAT"
> > > > solution mentioned in Appendix A of
> > > draft-ietf-ipsec-udp-encaps-04.txt to
> > > > solve the problem of multiple clients behind a NAT with
> > > overlapped traffic
> > > > specifications?
> > >
> > > I don't the CRC fixup has anything to do with Appendix A.
> > >
> > > -Skip
> > >
> > > >
> > > > Thanks,
> > > > - James
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > > > Sent: Thursday, November 07, 2002 7:31 PM
> > > > > To: James Huang
> > > > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com;
> 'l2tpext@ietf.org'
> > > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > > >
> > > > >
> > > > >
> > > > > James, does the recommendation in section 3.1.2 a) answer
> > > > > your question? I
> > > > > believe after fixing up the IP header to include the private
> > > > > address which was
> > > > > advertised during the negotiation, the packet will passte
> > > > > through the SG filters.
> > > > > The authors of this draft should be able to provide further
> > > > > clarification if
> > > > > this doesn't address your concerns.
> > > > >
> > > > > -Skip
> > > > >
> > > > > On Thu, 7 Nov 2002, James Huang wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Markus Stenberg [mailto:fingon@iki.fi]
> > > > > > > Sent: Wednesday, November 06, 2002 11:51 PM
> > > > > > > To: James Huang
> > > > > > > Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > > > > Subject: Re: UDP-encapsulated IPsec Transport mode
> > > > > > >
> > > > > > >
> > > > > > > James Huang <james.huang@watchguard.com> writes:
> > > > > > > > Hi all,
> > > > > > > > In the appendix A of
> > > > > > > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > > > > > > some discussions on the issue of multiple
> clients running
> > > > > > > UDP-encapsulated
> > > > > > > > IPsec transport mode tunnels behind a NAT box. However,
> > > > > > > did not find any
> > > > > > > > discussion on another related issue: In the traffic
> > > > > > > selector (ID) payload
> > > > > > > > the client sends out during quick mode
> exchange, should the
> > > > > > > client use its
> > > > > > > > own private address or the public routable address (i.e.
> > > > > > > the NAT box's
> > > > > > > > public IP address)? If it the later, how does
> the client
> > > > > > > know about that
> > > > > > > > public address? This seems to be a serious issue,
> > > > > > > especially for L2TP
> > > > > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > > > > >
> > > > > > > L2TP specific issues I am blissfully unaware of; however,
> > > > > > > because the NAT
> > > > > > > boxes are not neccessarily even controlled by the
> IPsec user,
> > > > > > > sending the
> > > > > > > public address is not really an option that can
> be supported
> > > > > > > everywhere.
> > > > > > >
> > > > > >
> > > > > > Agreed.
> > > > > >
> > > > > > > Here's how the information flow goes as far as I see it:
> > > > > > >
> > > > > > > Public address doesn't really need to be sent in
> any case as
> > > > > > > the remote
> > > > > > > side's public address is the address we're
> talking IKE with
> > > > > > > (or at least
> > > > > > > remote address+port combination, but in NAPT
> case you don't
> > > > > > > really have
> > > > > > > more of an remote address in any case).
> > > > > > >
> > > > > > > Private address that is used by the OS for actual
> > > > > traffic is provided
> > > > > > > within the NAT-OA payload so the checksums et al can be
> > > > > corrected.
> > > > > > >
> > > > > >
> > > > > > Let me describe the issue with regarding to L2TP/IPsec
> > > > > (voluntary L2TP) when
> > > > > > a NAT is present. Suppose a PC with a home network's
> > > > > private IP address V_1
> > > > > > is behind a NAT box with a public address P_1. The
> > > > > corporate network's
> > > > > > Security Gateway's IP address is P_2 and the PC wants to
> > > > > connect to a
> > > > > > corporate server with private IP address I_2. If
> > > > > everything goes well, this
> > > > > > PC will eventually obtain another private address I_1 from
> > > > > the corporate
> > > > > > network through IPCP . So the L2TP traffic sent by the PC
> > > > > will have the
> > > > > > following headers: IP/UDP/ESP/UDP/L2TP control or
> > > > > > IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will
> > > > > indicate the
> > > > > > traffic is sent from V_1 to P_2. The inner IP header will
> > > > > indicate the
> > > > > > traffic is sent from I_1 to I_2. The source IP address V_1
> > > > > in the outer
> > > > > > header will be changed by the NAT box to P_1 on the way
> > > > > out. So the packet
> > > > > > received by the corporate SG is an UDP-encapsulated
> > > > > TRANSPORT mode IPsec
> > > > > > packet from P_1 to P_2 with UDP source port 1701 and UDP
> > > > > dest port 1701 in
> > > > > > the 2nd UDP header (assuming no dynamic UDP port for L2TP).
> > > > > To allow this
> > > > > > packet to pass through the SG, an inbound filter matching
> > > > > the packet must
> > > > > > exist in the SG. The inbound filter is dynamically created
> > > > > after a quick
> > > > > > mode exchange between the PC and the SG. To create such a
> > > > > filter in the SG,
> > > > > > the PC must specify < IP = P_1, proto = UDP, port = 1701>
> > > > > in ID_i during
> > > > > > the quick mode exchange. But how does this PC
> knows about P_1?
> > > > > >
> > > > > > What I described above is a scenario specific to
> > > L2TP/IPsec. But in
> > > > > > general, any transport mode IPsec tunnel with a NAT box
> > > > > along its path will
> > > > > > have the same problem.
> > > > > >
> > > > > > Am I right? Or I am missing something here?
> > > > > >
> > > > > > - James Huang
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Therefore, at least as far as implementation I
> used to work
> > > > > > > on goes, ID
> > > > > > > payload in transport mode case doesn't matter (I seem to
> > > > > > > recall we sent
> > > > > > > private address, but pretty much ignored what was
> > > sent by remote).
> > > > > > >
> > > > > > > -Markus
> > > > > > >
> > > > > > > > Regards,
> > > > > > > > James C. Huang
> > > > > > >
> > > > > > > --
> > > > > > > "Every program has (at least) two purposes: the one for
> > > > > which it was
> > > > > > > written, and another for which it wasn't. "
> > > > > > >
> > > > > > > From ACM's SIGPLAN publication, (September, 1982),
> > > > > Article "Epigrams
> > > > > > > in Programming", by Alan J. Perlis of Yale University.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 18:45: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 gA92jRv07951;
Fri, 8 Nov 2002 18:45:27 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06671
Fri, 8 Nov 2002 21:08:17 -0500 (EST)
From: "Satyadeva Konduru" <skonduru@caymas.com>
To: "'James Huang'" <james.huang@watchguard.com>, <ipsec@lists.tislabs.com>,
<l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 18:08:13 -0800
Message-ID: <000c01c28794$decfdff0$3e00010a@caymas.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, Build 10.0.3416
In-Reply-To: <989d9ce16ef1ef2b10afa29ecbfd9dfe3dcc61f6@watchguard.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> No, I knew this is exactly what you are talking about. That is why I
said
> NAT (on the inbound source IP address) using NAT-OA + dynamic PAT (on
the
> inbound TCP source port) is needed at the security gateway after
> decapsulating the UDP/IPsec header.
>
> - James
So, what you are suggesting is that a dynamic PAT be applied between
IP/IPSec layer and the socket layer within a host. Two things:
1) Dynamic PAT will still involve checksum recomputation (however
simple) which you wanted to avoid, right??
2) Also, I am not convinced that the solution has to be this complicated
when all you want to know is the Phase 2 traffic selector. NAT-NA
payload type solution seems simple (to me, of course :-))
Anyway, why is the draft silent on this issue?? Either, it is too
obvious to mention or didn't forsee this issue.
-Satyadeva.
> -----Original Message-----
> From: James Huang [mailto:james.huang@watchguard.com]
> Sent: Friday, November 08, 2002 5:17 PM
> To: 'Satyadeva Konduru'; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
>
> > -----Original Message-----
> > From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> > Sent: Friday, November 08, 2002 5:07 PM
> > To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > Subject: RE: UDP-encapsulated IPsec Transport mode
> >
> >
> >
> >
> > > If we take a larger context as you suggested
> > where there is
> > a
> > > server running in the SG listening to a well-known TCP port. If
the
> > above
> > > multiple clients also chose the same TCP port number, then I
agree
> > doing
> > > NAT will not be enough. In that case, the SG will have to
> > do NAT (on
> > the
> > > inbound source IP address) + dynamic PAT (on the inbound TCP
source
> > port)
> > > before passing a decapsulated inbound packet to the server.
> >
> > I think you got me wrong here. In my example, the multiple
> > clients with
> > the same private addresses lie behind "different NAT gateways with
> > different public addresses" and hence a single NAT done by a
> > NAT gateway
> > in the middle would suffice. Now as per your earlier suggestion of
> > replacing the NATed public address with NAT-OA after UDP
decapsulation
> > does not make sense here, because, all the clients could possibly
have
> > the same private addresses and ports.
> >
> > -Satyadeva
> >
>
>
>
> >
> > > >
> > > > James,
> > > > Your suggestion will only "bypass" NAT but it will not
"traverse"
> > NAT.
> > > > My understanding is that the SG should see only the NATed public
> > > > address. If you take the transport mode in a larger context (not
> > just
> > > > L2tp/ipsec), let us suppose there is a host accepting TCP
> > connections.
> > > > As per your suggestion, if you replace the NATed address with
> > NAT-OA,
> > > > there would be multiple TCP connections from different
> > > > clients (all with
> > > > the same private address) mapping to the same socket pair.
> > > >
> > >
> > >
> > > > -Satyadeva.
> > > >
> > > > > -----Original Message-----
> > > > > From: James Huang [mailto:james.huang@watchguard.com]
> > > > > Sent: Friday, November 08, 2002 3:26 PM
> > > > > To: 'Satyadeva Konduru'; ipsec@lists.tislabs.com;
> > l2tpext@ietf.org
> > > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > > >
> > > > > Satyadeva,
> > > > >
> > > > > I thought about NAT-NA too. But I think the
> > better idea which
> > > > can
> > > > > do without NAT-NA is as follows:
> > > > > (1) The security gateway (SG) will insert entries into its
> > filtering
> > > > > database based on the traffic selector (ID) specified by the
> > client
> > > > during
> > > > > the QM exchange.
> > > > > (2) After the SG decrypted and decapsulated an
> > > > UDP-encapsulated IPsec
> > > > > packet
> > > > > in the transport mode (i.e. removing the outer UDP
> > header and ESP
> > > > header),
> > > > > it will modify the source IP address in the outer IP header
> > > > using the
> > > > > address in the NAT-OA payload it received in the QM exchange.
> > > > >
> > > > > With this scheme, the packet after decapsulation will pass the
> > > > security
> > > > > policy at the SG and the checksum in the inner UDP/TCP header
no
> > > > longer
> > > > > need
> > > > > to be re-computed by the SG as was described in section 3.1.2
in
> > the
> > > > > draft.
> > > > > Also it will solve the issue of multiple clients behind the
same
> > NAT
> > > > box
> > > > > described in section 5.3.
> > > > >
> > > > > The above is my personal opinion. I hope the authors of the
> > draft
> > > > can
> > > > > provide more clarification.
> > > > >
> > > > > Regards,
> > > > > James Huang
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> > > > > > Sent: Friday, November 08, 2002 2:51 PM
> > > > > > To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > > > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > > > >
> > > > > >
> > > > > > James,
> > > > > > Will there be any problem if the gateway (or any peer)
treats
> > > > > > the NATed
> > > > > > public address as the Phase 2 traffic selector, ignoring
> > > > the private
> > > > > > address sent by client ? Obviously, the private address is
of
> > > > > > no use to
> > > > > > the gateway. Even the SPD lookup policy is based on the
NATed
> > > > > > address.
> > > > > >
> > > > > > One other way the authors could have pursued is: the IKE
> > > > > > gateway sending
> > > > > > the NATed address (NA) to the client in the Phase 1 as a
> > > > > > NAT-NA payload.
> > > > > > This way, the client will get to know of its public
> > address. But
> > > > since
> > > > > > the NAT-NA can dynamically change, the gateway has to send
the
> > > > NAT-NA
> > > > > > payload every time the NATed public address changes.
> > > > > >
> > > > > > -Satyadeva Konduru
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: owner-ipsec@lists.tislabs.com
> > > > > > [mailto:owner-ipsec@lists.tislabs.com]
> > > > > > > On Behalf Of James Huang
> > > > > > > Sent: Wednesday, November 06, 2002 4:12 PM
> > > > > > > To: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > > > > Subject: UDP-encapsulated IPsec Transport mode
> > > > > > >
> > > > > > > Hi all,
> > > > > > > In the appendix A of
> > > > draft-ietf-ipsec-udp-encaps-04.txt, there
> > > > > > is
> > > > > > > some discussions on the issue of multiple clients running
> > > > > > UDP-encapsulated
> > > > > > > IPsec transport mode tunnels behind a NAT box.
> > > > However, I did not
> > > > > > find
> > > > > > > any
> > > > > > > discussion on another related issue: In the traffic
> > > > selector (ID)
> > > > > > payload
> > > > > > > the client sends out during quick mode exchange, should
the
> > > > > > client use
> > > > > > its
> > > > > > > own private address or the public routable address (i.e.
> > > > > > the NAT box's
> > > > > > > public IP address)? If it the later, how does the
> > client know
> > > > about
> > > > > > that
> > > > > > > public address? This seems to be a serious issue,
> > > > > > especially for L2TP
> > > > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > > > > >
> > > > > > > Regards,
> > > > > > > James C. Huang
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 18:48: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 gA92mLv08048;
Fri, 8 Nov 2002 18:48:21 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06704
Fri, 8 Nov 2002 21:20:19 -0500 (EST)
Message-ID: <c29832adc700b8ad10df2f13224d8e383dcc70ca@watchguard.com>
From: James Huang <james.huang@watchguard.com>
To: "'Satyadeva Konduru'" <skonduru@caymas.com>, ipsec@lists.tislabs.com,
l2tpext@ietf.org
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Fri, 8 Nov 2002 18:20:22 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> Sent: Friday, November 08, 2002 6:08 PM
> To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
>
>
>
> > No, I knew this is exactly what you are talking about.
> That is why I
> said
> > NAT (on the inbound source IP address) using NAT-OA +
> dynamic PAT (on
> the
> > inbound TCP source port) is needed at the security gateway after
> > decapsulating the UDP/IPsec header.
> >
> > - James
>
> So, what you are suggesting is that a dynamic PAT be applied between
> IP/IPSec layer and the socket layer within a host. Two things:
> 1) Dynamic PAT will still involve checksum recomputation (however
> simple) which you wanted to avoid, right??
> 2) Also, I am not convinced that the solution has to be this
> complicated
> when all you want to know is the Phase 2 traffic selector. NAT-NA
> payload type solution seems simple (to me, of course :-))
>
> Anyway, why is the draft silent on this issue?? Either, it is too
> obvious to mention or didn't forsee this issue.
>
> -Satyadeva.
>
Satyadeva,
I am not sure. But in Appendix A of the draft, it did mention a
"build-in NAT/NAPT" soultion to solve the multiple clients behind a NAT box
issue. The draft said that SSH/Microsoft has intellectual property rights
to the solution. I am not sure whether the "build-in NAT/NAPT" soultion is
the same as what I described in my previous emails.
- James Huang
>
> > -----Original Message-----
> > From: James Huang [mailto:james.huang@watchguard.com]
> > Sent: Friday, November 08, 2002 5:17 PM
> > To: 'Satyadeva Konduru'; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > Subject: RE: UDP-encapsulated IPsec Transport mode
> >
> >
> >
> > > -----Original Message-----
> > > From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> > > Sent: Friday, November 08, 2002 5:07 PM
> > > To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > >
> > >
> > >
> > >
> > > > If we take a larger context as you suggested
> > > where there is
> > > a
> > > > server running in the SG listening to a well-known TCP port. If
> the
> > > above
> > > > multiple clients also chose the same TCP port number, then I
> agree
> > > doing
> > > > NAT will not be enough. In that case, the SG will have to
> > > do NAT (on
> > > the
> > > > inbound source IP address) + dynamic PAT (on the inbound TCP
> source
> > > port)
> > > > before passing a decapsulated inbound packet to the server.
> > >
> > > I think you got me wrong here. In my example, the multiple
> > > clients with
> > > the same private addresses lie behind "different NAT gateways with
> > > different public addresses" and hence a single NAT done by a
> > > NAT gateway
> > > in the middle would suffice. Now as per your earlier suggestion of
> > > replacing the NATed public address with NAT-OA after UDP
> decapsulation
> > > does not make sense here, because, all the clients could possibly
> have
> > > the same private addresses and ports.
> > >
> > > -Satyadeva
> > >
> >
> >
> >
> > >
> > > > >
> > > > > James,
> > > > > Your suggestion will only "bypass" NAT but it will not
> "traverse"
> > > NAT.
> > > > > My understanding is that the SG should see only the
> NATed public
> > > > > address. If you take the transport mode in a larger
> context (not
> > > just
> > > > > L2tp/ipsec), let us suppose there is a host accepting TCP
> > > connections.
> > > > > As per your suggestion, if you replace the NATed address with
> > > NAT-OA,
> > > > > there would be multiple TCP connections from different
> > > > > clients (all with
> > > > > the same private address) mapping to the same socket pair.
> > > > >
> > > >
> > > >
> > > > > -Satyadeva.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: James Huang [mailto:james.huang@watchguard.com]
> > > > > > Sent: Friday, November 08, 2002 3:26 PM
> > > > > > To: 'Satyadeva Konduru'; ipsec@lists.tislabs.com;
> > > l2tpext@ietf.org
> > > > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > > > >
> > > > > > Satyadeva,
> > > > > >
> > > > > > I thought about NAT-NA too. But I think the
> > > better idea which
> > > > > can
> > > > > > do without NAT-NA is as follows:
> > > > > > (1) The security gateway (SG) will insert entries into its
> > > filtering
> > > > > > database based on the traffic selector (ID) specified by the
> > > client
> > > > > during
> > > > > > the QM exchange.
> > > > > > (2) After the SG decrypted and decapsulated an
> > > > > UDP-encapsulated IPsec
> > > > > > packet
> > > > > > in the transport mode (i.e. removing the outer UDP
> > > header and ESP
> > > > > header),
> > > > > > it will modify the source IP address in the outer IP header
> > > > > using the
> > > > > > address in the NAT-OA payload it received in the QM
> exchange.
> > > > > >
> > > > > > With this scheme, the packet after decapsulation
> will pass the
> > > > > security
> > > > > > policy at the SG and the checksum in the inner
> UDP/TCP header
> no
> > > > > longer
> > > > > > need
> > > > > > to be re-computed by the SG as was described in
> section 3.1.2
> in
> > > the
> > > > > > draft.
> > > > > > Also it will solve the issue of multiple clients behind the
> same
> > > NAT
> > > > > box
> > > > > > described in section 5.3.
> > > > > >
> > > > > > The above is my personal opinion. I hope the
> authors of the
> > > draft
> > > > > can
> > > > > > provide more clarification.
> > > > > >
> > > > > > Regards,
> > > > > > James Huang
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> > > > > > > Sent: Friday, November 08, 2002 2:51 PM
> > > > > > > To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> > > > > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > > > > >
> > > > > > >
> > > > > > > James,
> > > > > > > Will there be any problem if the gateway (or any peer)
> treats
> > > > > > > the NATed
> > > > > > > public address as the Phase 2 traffic selector, ignoring
> > > > > the private
> > > > > > > address sent by client ? Obviously, the private address is
> of
> > > > > > > no use to
> > > > > > > the gateway. Even the SPD lookup policy is based on the
> NATed
> > > > > > > address.
> > > > > > >
> > > > > > > One other way the authors could have pursued is: the IKE
> > > > > > > gateway sending
> > > > > > > the NATed address (NA) to the client in the Phase 1 as a
> > > > > > > NAT-NA payload.
> > > > > > > This way, the client will get to know of its public
> > > address. But
> > > > > since
> > > > > > > the NAT-NA can dynamically change, the gateway has to send
> the
> > > > > NAT-NA
> > > > > > > payload every time the NATed public address changes.
> > > > > > >
> > > > > > > -Satyadeva Konduru
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: owner-ipsec@lists.tislabs.com
> > > > > > > [mailto:owner-ipsec@lists.tislabs.com]
> > > > > > > > On Behalf Of James Huang
> > > > > > > > Sent: Wednesday, November 06, 2002 4:12 PM
> > > > > > > > To: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > > > > > Subject: UDP-encapsulated IPsec Transport mode
> > > > > > > >
> > > > > > > > Hi all,
> > > > > > > > In the appendix A of
> > > > > draft-ietf-ipsec-udp-encaps-04.txt, there
> > > > > > > is
> > > > > > > > some discussions on the issue of multiple
> clients running
> > > > > > > UDP-encapsulated
> > > > > > > > IPsec transport mode tunnels behind a NAT box.
> > > > > However, I did not
> > > > > > > find
> > > > > > > > any
> > > > > > > > discussion on another related issue: In the traffic
> > > > > selector (ID)
> > > > > > > payload
> > > > > > > > the client sends out during quick mode exchange, should
> the
> > > > > > > client use
> > > > > > > its
> > > > > > > > own private address or the public routable address (i.e.
> > > > > > > the NAT box's
> > > > > > > > public IP address)? If it the later, how does the
> > > client know
> > > > > about
> > > > > > > that
> > > > > > > > public address? This seems to be a serious issue,
> > > > > > > especially for L2TP
> > > > > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > James C. Huang
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
From owner-ipsec@lists.tislabs.com Fri Nov 8 20:18: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 gA94Isv14577;
Fri, 8 Nov 2002 20:18:55 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07038
Fri, 8 Nov 2002 22:39:46 -0500 (EST)
Date: Fri, 8 Nov 2002 22:40:17 -0500 (Eastern Standard Time)
From: Skip Booth <ebooth@cisco.com>
To: James Huang <james.huang@watchguard.com>
cc: "'Markus Stenberg'" <fingon@iki.fi>, <ipsec@lists.tislabs.com>,
"'l2tpext@ietf.org'" <l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
In-Reply-To: <c8ef65bb020dfbe43eb127f9f18dfa263dcc6f4d@watchguard.com>
Message-ID: <Pine.WNT.4.44.0211082225580.520-100000@EBOOTH-W2K.amer.cisco.com>
X-Warning: UNAuthenticated Sender
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, 8 Nov 2002, James Huang wrote:
>
>
> > -----Original Message-----
> > From: Skip Booth [mailto:ebooth@cisco.com]
> > Sent: Friday, November 08, 2002 4:50 PM
> > To: James Huang
> > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > Subject: RE: UDP-encapsulated IPsec Transport mode
> >
> >
> >
> >
> > On Fri, 8 Nov 2002, James Huang wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > > Sent: Friday, November 08, 2002 12:09 PM
> > > > To: James Huang
> > > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, 8 Nov 2002, James Huang wrote:
> > > >
> > > > > Skip,
> > > > > If we fix up the source IP address using the
> > private address
> > > > > advertised in NAT-OA during IKE negotiation, then why
> > should TCP/UDP
> > > > > checksum be re-computed at the security gateway as was
> > > > described in section
> > > > > 3.1.2?
> > > >
> > > > Because the NAT would have modified the checksum as the
> > > > packet passed through
> > > > the NAT. In order for it to pass the IP CRC check at the SG,
> > > > you must fixup the
> > > > checksum based on the pre-NAT values.
> > > >
> > >
> > >
> > > Skip,
> > >
> > > With UDP-encapsuilated IPsec, NAT box will only see and
> > modify the outer UDP
> > > header used to encapsulate the IPsec packet (in addtioanl
> > to modify the
> > > outer IP address). After the security gateway
> > decapsulating an IPsec packet
> > > in transport mode (i.e. removing the outer UDP header and
> > the ESP header)
> > > and modify the source IP address in the outer IP header
> > with the address
> > > received in the NAT-OA, the checksum in the inner TCP/UDP
> > header should be
> > > already correct as the client computes that checksum based
> > on the same
> > > address in the NAT-OA.
> > >
> > > Am I missing something here?
> >
> > I think you are confused since it appears that you believe
> > their is an outer IP
> > header and an inner IP header. This is not true for the
> > Transport Mode ESP
> > encap specified in the draft. The packet format for
> > Transport Mode ESP Encap
> > (which is what would be used for L2TP/IPsec most likely) is
> > specified as
> > follows:
> >
> > 3.2 Transport Mode ESP Encapsulation
> >
> > BEFORE APPLYING ESP/UDP
> > ----------------------------
> > IPv4 |orig IP hdr | | |
> > |(any options)| TCP | Data |
> > ----------------------------
> >
> > AFTER APPLYING ESP/UDP
> > -------------------------------------------------------
> > IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
> > |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
> > -------------------------------------------------------
> > |<----- encrypted ---->|
> > |<------ authenticated ----->|
> >
> > For L2TP/IPsec, these will look like:
> >
> > IP/UDP/ESP/1701/1701/[L2TP hdr/PPP]/ESP trailer/ESP Auth
> >
>
>
>
> Skip,
> The L2TP/IPsec packet should look like this in more detail,
>
> IP1/UDP/ESP/1701/1701/L2TP hdr/PPP hdr / IP2/ ... /ESP trailer/ESP Auth.
> The outer IP header is the first IP header IP1 above. The inner IP header
> is the second IP header IP2 that I just added. THis is the packet format
> after the IPsec tunnel is set up, L2TP tunnel is set up, IPCP is completed
> (e.g. for the client to obtain a private address in the corporate network),
> and the real data traffic inside the L2TP tunnel starts flowing..
>
>
>
>
> > As such, the outer header contains the private address. The
> > NAT box will
> > perform the IP address/port translation on the outer IP/UDP
> > header and in the
> > process will recompute the CRC on the outer IP header. On
> > the SG, after
> > restoring the private addresses on the outer header, the CRC
> > must be restored to
> > the original value prior to the NAT fixup.
> >
> > -Skip
>
>
> Skip,
>
> Lets take the following scenario as an example.
>
>
> PC -------- NAT -------- internet --------- SG
> ------------ server
>
>
> Suppose the PC's private address is PC1, the public address at the NAT is
> P1, the public address at SG is P2, and the server has a private corporate
> address S1.
> Both the IPsec transport mode tunnel and the L2TP tunnel are btw the PC and
> the SG.
>
> During IKE QM exchange to set up an IPsec tunnel to protect L2TP packets,
> the first packet the SG received will look like this:
>
> ip header: P1->P2,
> traffic selectors: IP: PC1<->P2, udp port: 1701 <-> 1701 (assuming LAC
> chose the fixed UDP port). If the QM exchange succeeds, the SG will enter
> into its inbound/outbound filtering database based on above traffic spec.
>
> When the PC sends out a L2TP control packet, it will look like this:
> IP/UDP1/ESP/UDP2/L2TP control/ESP trailer/ESP Auth. The IP header will be
> from PC1 to P2 and UDP1 will be from 4500 to 4500, UDP2 will be from 1701 to
> 1701. The UDP checksum in UDP2 will be based on the address PC1. After
> this packet passed the NAT box, the IP header will be from P1 to P2 and UDP1
> may be adjusted to from port Y to 4500 and its checksum also adjusted.
> Note UDP2 is not touched by the NAT box.
>
> After the SG decrypts and decapsulats the inbound packet, it will look like
> this: IP/UDP2/L2TP control. The IP header will be from P1 to P2 and UDP2
> from 1701 to 1701.
> The SG will then modify the IP header to PC1 -> P2. Now the packet will
> pass the checking using the filtering database and the checksum in UDP2 will
> also be automatically correct.
I'm not sure that the checksum in the outer IP header is valid at this point
though. The IP header's CRC will be based on the P1 to P2 addresses, however
once IPsec finishes manipulating the packet, the IP addresses will be PC1->P2
and the IP CRC will need to be adjusted to reflect that. I agree with you
though that the UDP2 checksum should be correct.
>
> After the L2TP tunnel is set up, and IPCP is completed, the PC will obtain a
> private address Vpc1 from inside the corporate network. Now the packet sent
> by the PC will look like this: IP1/UDP1/ESP/UDP2/L2TP hdr/PPP hdr / IP2/
> ... /ESP trailer/ESP Auth.
>
> IP1: PC1->P2
> UDP1: 4500->4500
> UDP2: 1701->1701 (checksum computed based on PC1)
> IP2: Vpc1->S1
>
> The rest should be very similar to what I described above.
That's all correct and hopefully we've now answered you original question about
how the packet passes the SG filter checks. I'll defer any further checksum
questions to the authors of the draft :)
-Skip
>
>
>
> -- James Huang
>
>
> > >
> > > Regards,
> > > James Huang
> > >
> > >
> > >
> > >
> > > > > The checksum was originally computed by the client using its
> > > > > private address. Also is this solution the same as the
> > > > "built-in NAT"
> > > > > solution mentioned in Appendix A of
> > > > draft-ietf-ipsec-udp-encaps-04.txt to
> > > > > solve the problem of multiple clients behind a NAT with
> > > > overlapped traffic
> > > > > specifications?
> > > >
> > > > I don't the CRC fixup has anything to do with Appendix A.
> > > >
> > > > -Skip
> > > >
> > > > >
> > > > > Thanks,
> > > > > - James
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > > > > Sent: Thursday, November 07, 2002 7:31 PM
> > > > > > To: James Huang
> > > > > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com;
> > 'l2tpext@ietf.org'
> > > > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > > > >
> > > > > >
> > > > > >
> > > > > > James, does the recommendation in section 3.1.2 a) answer
> > > > > > your question? I
> > > > > > believe after fixing up the IP header to include the private
> > > > > > address which was
> > > > > > advertised during the negotiation, the packet will passte
> > > > > > through the SG filters.
> > > > > > The authors of this draft should be able to provide further
> > > > > > clarification if
> > > > > > this doesn't address your concerns.
> > > > > >
> > > > > > -Skip
> > > > > >
> > > > > > On Thu, 7 Nov 2002, James Huang wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Markus Stenberg [mailto:fingon@iki.fi]
> > > > > > > > Sent: Wednesday, November 06, 2002 11:51 PM
> > > > > > > > To: James Huang
> > > > > > > > Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > > > > > Subject: Re: UDP-encapsulated IPsec Transport mode
> > > > > > > >
> > > > > > > >
> > > > > > > > James Huang <james.huang@watchguard.com> writes:
> > > > > > > > > Hi all,
> > > > > > > > > In the appendix A of
> > > > > > > > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > > > > > > > some discussions on the issue of multiple
> > clients running
> > > > > > > > UDP-encapsulated
> > > > > > > > > IPsec transport mode tunnels behind a NAT box. However,
> > > > > > > > did not find any
> > > > > > > > > discussion on another related issue: In the traffic
> > > > > > > > selector (ID) payload
> > > > > > > > > the client sends out during quick mode
> > exchange, should the
> > > > > > > > client use its
> > > > > > > > > own private address or the public routable address (i.e.
> > > > > > > > the NAT box's
> > > > > > > > > public IP address)? If it the later, how does
> > the client
> > > > > > > > know about that
> > > > > > > > > public address? This seems to be a serious issue,
> > > > > > > > especially for L2TP
> > > > > > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > > > > > >
> > > > > > > > L2TP specific issues I am blissfully unaware of; however,
> > > > > > > > because the NAT
> > > > > > > > boxes are not neccessarily even controlled by the
> > IPsec user,
> > > > > > > > sending the
> > > > > > > > public address is not really an option that can
> > be supported
> > > > > > > > everywhere.
> > > > > > > >
> > > > > > >
> > > > > > > Agreed.
> > > > > > >
> > > > > > > > Here's how the information flow goes as far as I see it:
> > > > > > > >
> > > > > > > > Public address doesn't really need to be sent in
> > any case as
> > > > > > > > the remote
> > > > > > > > side's public address is the address we're
> > talking IKE with
> > > > > > > > (or at least
> > > > > > > > remote address+port combination, but in NAPT
> > case you don't
> > > > > > > > really have
> > > > > > > > more of an remote address in any case).
> > > > > > > >
> > > > > > > > Private address that is used by the OS for actual
> > > > > > traffic is provided
> > > > > > > > within the NAT-OA payload so the checksums et al can be
> > > > > > corrected.
> > > > > > > >
> > > > > > >
> > > > > > > Let me describe the issue with regarding to L2TP/IPsec
> > > > > > (voluntary L2TP) when
> > > > > > > a NAT is present. Suppose a PC with a home network's
> > > > > > private IP address V_1
> > > > > > > is behind a NAT box with a public address P_1. The
> > > > > > corporate network's
> > > > > > > Security Gateway's IP address is P_2 and the PC wants to
> > > > > > connect to a
> > > > > > > corporate server with private IP address I_2. If
> > > > > > everything goes well, this
> > > > > > > PC will eventually obtain another private address I_1 from
> > > > > > the corporate
> > > > > > > network through IPCP . So the L2TP traffic sent by the PC
> > > > > > will have the
> > > > > > > following headers: IP/UDP/ESP/UDP/L2TP control or
> > > > > > > IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will
> > > > > > indicate the
> > > > > > > traffic is sent from V_1 to P_2. The inner IP header will
> > > > > > indicate the
> > > > > > > traffic is sent from I_1 to I_2. The source IP address V_1
> > > > > > in the outer
> > > > > > > header will be changed by the NAT box to P_1 on the way
> > > > > > out. So the packet
> > > > > > > received by the corporate SG is an UDP-encapsulated
> > > > > > TRANSPORT mode IPsec
> > > > > > > packet from P_1 to P_2 with UDP source port 1701 and UDP
> > > > > > dest port 1701 in
> > > > > > > the 2nd UDP header (assuming no dynamic UDP port for L2TP).
> > > > > > To allow this
> > > > > > > packet to pass through the SG, an inbound filter matching
> > > > > > the packet must
> > > > > > > exist in the SG. The inbound filter is dynamically created
> > > > > > after a quick
> > > > > > > mode exchange between the PC and the SG. To create such a
> > > > > > filter in the SG,
> > > > > > > the PC must specify < IP = P_1, proto = UDP, port = 1701>
> > > > > > in ID_i during
> > > > > > > the quick mode exchange. But how does this PC
> > knows about P_1?
> > > > > > >
> > > > > > > What I described above is a scenario specific to
> > > > L2TP/IPsec. But in
> > > > > > > general, any transport mode IPsec tunnel with a NAT box
> > > > > > along its path will
> > > > > > > have the same problem.
> > > > > > >
> > > > > > > Am I right? Or I am missing something here?
> > > > > > >
> > > > > > > - James Huang
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Therefore, at least as far as implementation I
> > used to work
> > > > > > > > on goes, ID
> > > > > > > > payload in transport mode case doesn't matter (I seem to
> > > > > > > > recall we sent
> > > > > > > > private address, but pretty much ignored what was
> > > > sent by remote).
> > > > > > > >
> > > > > > > > -Markus
> > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > James C. Huang
> > > > > > > >
> > > > > > > > --
> > > > > > > > "Every program has (at least) two purposes: the one for
> > > > > > which it was
> > > > > > > > written, and another for which it wasn't. "
> > > > > > > >
> > > > > > > > From ACM's SIGPLAN publication, (September, 1982),
> > > > > > Article "Epigrams
> > > > > > > > in Programming", by Alan J. Perlis of Yale University.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
From owner-ipsec@lists.tislabs.com Sat Nov 9 13:51: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 gA9LpWv08531;
Sat, 9 Nov 2002 13:51:32 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08701
Sat, 9 Nov 2002 16:16:22 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Cc: ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021109161112.02d5e5b0@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 09 Nov 2002 16:12:13 -0500
Subject: RE: Adding revised identities to IKEv2
In-Reply-To: <p05200f0eb9f19786188d@[165.227.249.18]>
References: <p05100302b9f17ea5c94b@[128.89.88.34]>
<PKEBJBKKGOBHIJBBAGLEAELHEOAA.pritikin@cisco.com>
<p05200f00b9f0e62aff99@[165.227.249.18]>
<p05100302b9f17ea5c94b@[128.89.88.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul:
>> This is what IKE v2 and a cert profile should do, in combination.
>
>Given the importance of certificates to IKEv2, the profile should be a
>part of the IKEv2 document.
Why do you think it needs to be one document? I think maintenance would be
easier if it was a separate document.
Russ
From owner-ipsec@lists.tislabs.com Sun Nov 10 07:14: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 gAAFEdv19604;
Sun, 10 Nov 2002 07:14:40 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09769
Sun, 10 Nov 2002 09:22:53 -0500 (EST)
Message-Id: <200211101423.gAAEN3te091015@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Fri, 08 Nov 2002 08:42:32 PST.
<p05200f0fb9f198f66ecc@[165.227.249.18]>
Date: Sun, 10 Nov 2002 15:23:03 +0100
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:
At 10:46 AM +0100 11/8/02, Francis Dupont wrote:
>=> there is no agreement about what checks must be done:
> - common sense says the identity must be a subject of the certificate
> (but this is not clearly specified in IKEv1 and perhaps some
> implementations don't perform this check)
That does not follow. There is no standard way for the Subject to be
an email address (the way folks do it now is a non-standard hack),
there is no standard way for the Subject to be an IP address. I'm not
sure, but I think the DC method of doing domain names in the Subject
is also a non-standard hack.
=> I agree but I wrote "a subject" in place of "the Subject" in order
to take account of subject alternative names (RFC 3280 4.2.1.7) which
include email and IP addresses... I didn't assume than IPsec users are
X.500 experts (:-).
>=> I agree this kind of bootstrap problems comes from silly configurations
>but the IPv6 neighbor discovery issue showed these silly configurations
>happen in the real world so they should be handled. In this case
>the "unresolvable URLs" case should be extended to the inaccessible
>because of IPsec cross-dependence case.
The error definition I proposed was:
Could not get the certificate through the URL that was given in the
FullID type 3 payload. This could be due to connectivity problems,
an error from the HTTP server, a malformed URL, or a host of other
reasons.
That last phrase should cover almost anything.
=> fine! So the only missing things are three points in the informal
text introducing the error.
Thanks
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Mon Nov 11 00:35: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 gAB8ZEv00884;
Mon, 11 Nov 2002 00:35:14 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11013
Mon, 11 Nov 2002 02:49:49 -0500 (EST)
Reply-To: <awank@future.futsoft.com>
From: "Awan Kumar Sharma" <awank@future.futsoft.com>
To: "'Skip Booth'" <ebooth@cisco.com>,
"'James Huang'" <james.huang@watchguard.com>
Cc: "'Markus Stenberg'" <fingon@iki.fi>, <ipsec@lists.tislabs.com>,
<l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Mon, 11 Nov 2002 13:21:37 +0530
Message-Id: <001501c28957$2aa1c4c0$0702060a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
In-Reply-To: <Pine.WNT.4.44.0211082225580.520-100000@EBOOTH-W2K.amer.cisco.com>
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi James and Skip,
Initially the idea for re-computation for TCP/UDP Checksums was confusing me
too. But now I feel that whatever has been mentioned in the draft is
correct. I am putting my opinion regarding that here and please correct me
if I am wrong anywhere. Incidentally, I would like to clarify that the
checksum that needs to be updated (as specified in the draft) is the TCP/UDP
checksum and not the IP Checksum (as Skip had quoted in one of his
clarifications).
There is no need to take an example of L2TP for finding the need for
checksum re-computation. Any data traffic example in transport mode is
enough. So, I am taking an example of a TCP traffic (between H1 and H2)
being protected using IPSec in transport mode.
Set-Up:
SG1/Host1 ---------NAT(N1)------------- INTERNET ---------SG2/Host2.
In this set-up, the hosts H1 and H2 are the SG's as well, since the traffic
is protected in transport mode.
A TCP packet going out of H1 (without IPSec) would look like:
IPh1h2 | TCPh1h2 | Data,
where TCPh1h2 is the TCP header that uses H1 and H2 as the IP addresses
for checksum computation.
When IPSec is applied in transport mode with NAT traversal, the packet would
look like,
IPh1h2 | UDP <4500,4500>| ESP | encrypted (TCPh1h2 | Data ).
When this packet traverses through a NAT device, the packet gets altered to
IPn1h2 | UDP <x,4500>| ESP | encrypted (TCPh1h2 | Data).
After this packet reaches SG2 (i.e. H2), after the normal IPsec processing
and decapusulation as mentioned in the draft, the TCPh1h2 needs to be
modified to TCPn1h2 (Why?). This is because, as far as TCP connection is
concerned, after NAT H2 can only send data with Destination IP address as N1
and not H1. So, the data going UP(to TCP/HL) after IPSec decapsulation at
SG2 should have the IP address as N1 and H2 and not H1 and H2. Now here is
the point you were confused (I think). Instead of changing the IP address
from N1 to H1, we need to change the checksum to adapt to N1 as source. As
far as my knowledge goes, the draft nowhere suggests to change the IP
address from N1 to H1. It suggests only change in checksum. To change the
checksum we need the IP address recieved through NAT-OA.
Similar would be the case for L2TP.
Hope that this clarifies your doubt . Please let me know if I am wrong at
any place.
Regards,
Awan
-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Skip Booth
Sent: Saturday, November 09, 2002 9:10 AM
To: James Huang
Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
Subject: RE: UDP-encapsulated IPsec Transport mode
On Fri, 8 Nov 2002, James Huang wrote:
>
>
> > -----Original Message-----
> > From: Skip Booth [mailto:ebooth@cisco.com]
> > Sent: Friday, November 08, 2002 4:50 PM
> > To: James Huang
> > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > Subject: RE: UDP-encapsulated IPsec Transport mode
> >
> >
> >
> >
> > On Fri, 8 Nov 2002, James Huang wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > > Sent: Friday, November 08, 2002 12:09 PM
> > > > To: James Huang
> > > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, 8 Nov 2002, James Huang wrote:
> > > >
> > > > > Skip,
> > > > > If we fix up the source IP address using the
> > private address
> > > > > advertised in NAT-OA during IKE negotiation, then why
> > should TCP/UDP
> > > > > checksum be re-computed at the security gateway as was
> > > > described in section
> > > > > 3.1.2?
> > > >
> > > > Because the NAT would have modified the checksum as the
> > > > packet passed through
> > > > the NAT. In order for it to pass the IP CRC check at the SG,
> > > > you must fixup the
> > > > checksum based on the pre-NAT values.
> > > >
> > >
> > >
> > > Skip,
> > >
> > > With UDP-encapsuilated IPsec, NAT box will only see and
> > modify the outer UDP
> > > header used to encapsulate the IPsec packet (in addtioanl
> > to modify the
> > > outer IP address). After the security gateway
> > decapsulating an IPsec packet
> > > in transport mode (i.e. removing the outer UDP header and
> > the ESP header)
> > > and modify the source IP address in the outer IP header
> > with the address
> > > received in the NAT-OA, the checksum in the inner TCP/UDP
> > header should be
> > > already correct as the client computes that checksum based
> > on the same
> > > address in the NAT-OA.
> > >
> > > Am I missing something here?
> >
> > I think you are confused since it appears that you believe
> > their is an outer IP
> > header and an inner IP header. This is not true for the
> > Transport Mode ESP
> > encap specified in the draft. The packet format for
> > Transport Mode ESP Encap
> > (which is what would be used for L2TP/IPsec most likely) is
> > specified as
> > follows:
> >
> > 3.2 Transport Mode ESP Encapsulation
> >
> > BEFORE APPLYING ESP/UDP
> > ----------------------------
> > IPv4 |orig IP hdr | | |
> > |(any options)| TCP | Data |
> > ----------------------------
> >
> > AFTER APPLYING ESP/UDP
> > -------------------------------------------------------
> > IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
> > |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
> > -------------------------------------------------------
> > |<----- encrypted ---->|
> > |<------ authenticated ----->|
> >
> > For L2TP/IPsec, these will look like:
> >
> > IP/UDP/ESP/1701/1701/[L2TP hdr/PPP]/ESP trailer/ESP Auth
> >
>
>
>
> Skip,
> The L2TP/IPsec packet should look like this in more detail,
>
> IP1/UDP/ESP/1701/1701/L2TP hdr/PPP hdr / IP2/ ... /ESP trailer/ESP Auth.
> The outer IP header is the first IP header IP1 above. The inner IP
header
> is the second IP header IP2 that I just added. THis is the packet format
> after the IPsec tunnel is set up, L2TP tunnel is set up, IPCP is completed
> (e.g. for the client to obtain a private address in the corporate
network),
> and the real data traffic inside the L2TP tunnel starts flowing..
>
>
>
>
> > As such, the outer header contains the private address. The
> > NAT box will
> > perform the IP address/port translation on the outer IP/UDP
> > header and in the
> > process will recompute the CRC on the outer IP header. On
> > the SG, after
> > restoring the private addresses on the outer header, the CRC
> > must be restored to
> > the original value prior to the NAT fixup.
> >
> > -Skip
>
>
> Skip,
>
> Lets take the following scenario as an example.
>
>
> PC -------- NAT -------- internet --------- SG
> ------------ server
>
>
> Suppose the PC's private address is PC1, the public address at the NAT is
> P1, the public address at SG is P2, and the server has a private corporate
> address S1.
> Both the IPsec transport mode tunnel and the L2TP tunnel are btw the PC
and
> the SG.
>
> During IKE QM exchange to set up an IPsec tunnel to protect L2TP packets,
> the first packet the SG received will look like this:
>
> ip header: P1->P2,
> traffic selectors: IP: PC1<->P2, udp port: 1701 <-> 1701 (assuming LAC
> chose the fixed UDP port). If the QM exchange succeeds, the SG will enter
> into its inbound/outbound filtering database based on above traffic spec.
>
> When the PC sends out a L2TP control packet, it will look like this:
> IP/UDP1/ESP/UDP2/L2TP control/ESP trailer/ESP Auth. The IP header will be
> from PC1 to P2 and UDP1 will be from 4500 to 4500, UDP2 will be from 1701
to
> 1701. The UDP checksum in UDP2 will be based on the address PC1. After
> this packet passed the NAT box, the IP header will be from P1 to P2 and
UDP1
> may be adjusted to from port Y to 4500 and its checksum also adjusted.
> Note UDP2 is not touched by the NAT box.
>
> After the SG decrypts and decapsulats the inbound packet, it will look
like
> this: IP/UDP2/L2TP control. The IP header will be from P1 to P2 and
UDP2
> from 1701 to 1701.
> The SG will then modify the IP header to PC1 -> P2. Now the packet will
> pass the checking using the filtering database and the checksum in UDP2
will
> also be automatically correct.
I'm not sure that the checksum in the outer IP header is valid at this point
though. The IP header's CRC will be based on the P1 to P2 addresses,
however
once IPsec finishes manipulating the packet, the IP addresses will be
PC1->P2
and the IP CRC will need to be adjusted to reflect that. I agree with you
though that the UDP2 checksum should be correct.
>
> After the L2TP tunnel is set up, and IPCP is completed, the PC will obtain
a
> private address Vpc1 from inside the corporate network. Now the packet
sent
> by the PC will look like this: IP1/UDP1/ESP/UDP2/L2TP hdr/PPP hdr / IP2/
> ... /ESP trailer/ESP Auth.
>
> IP1: PC1->P2
> UDP1: 4500->4500
> UDP2: 1701->1701 (checksum computed based on PC1)
> IP2: Vpc1->S1
>
> The rest should be very similar to what I described above.
That's all correct and hopefully we've now answered you original question
about
how the packet passes the SG filter checks. I'll defer any further checksum
questions to the authors of the draft :)
-Skip
>
>
>
> -- James Huang
>
>
> > >
> > > Regards,
> > > James Huang
> > >
> > >
> > >
> > >
> > > > > The checksum was originally computed by the client using its
> > > > > private address. Also is this solution the same as the
> > > > "built-in NAT"
> > > > > solution mentioned in Appendix A of
> > > > draft-ietf-ipsec-udp-encaps-04.txt to
> > > > > solve the problem of multiple clients behind a NAT with
> > > > overlapped traffic
> > > > > specifications?
> > > >
> > > > I don't the CRC fixup has anything to do with Appendix A.
> > > >
> > > > -Skip
> > > >
> > > > >
> > > > > Thanks,
> > > > > - James
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > > > > Sent: Thursday, November 07, 2002 7:31 PM
> > > > > > To: James Huang
> > > > > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com;
> > 'l2tpext@ietf.org'
> > > > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > > > >
> > > > > >
> > > > > >
> > > > > > James, does the recommendation in section 3.1.2 a) answer
> > > > > > your question? I
> > > > > > believe after fixing up the IP header to include the private
> > > > > > address which was
> > > > > > advertised during the negotiation, the packet will passte
> > > > > > through the SG filters.
> > > > > > The authors of this draft should be able to provide further
> > > > > > clarification if
> > > > > > this doesn't address your concerns.
> > > > > >
> > > > > > -Skip
> > > > > >
> > > > > > On Thu, 7 Nov 2002, James Huang wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Markus Stenberg [mailto:fingon@iki.fi]
> > > > > > > > Sent: Wednesday, November 06, 2002 11:51 PM
> > > > > > > > To: James Huang
> > > > > > > > Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > > > > > Subject: Re: UDP-encapsulated IPsec Transport mode
> > > > > > > >
> > > > > > > >
> > > > > > > > James Huang <james.huang@watchguard.com> writes:
> > > > > > > > > Hi all,
> > > > > > > > > In the appendix A of
> > > > > > > > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > > > > > > > some discussions on the issue of multiple
> > clients running
> > > > > > > > UDP-encapsulated
> > > > > > > > > IPsec transport mode tunnels behind a NAT box. However,
> > > > > > > > did not find any
> > > > > > > > > discussion on another related issue: In the traffic
> > > > > > > > selector (ID) payload
> > > > > > > > > the client sends out during quick mode
> > exchange, should the
> > > > > > > > client use its
> > > > > > > > > own private address or the public routable address (i.e.
> > > > > > > > the NAT box's
> > > > > > > > > public IP address)? If it the later, how does
> > the client
> > > > > > > > know about that
> > > > > > > > > public address? This seems to be a serious issue,
> > > > > > > > especially for L2TP
> > > > > > > > > voluntary tunnels secured by IPsec (in transport mode).
> > > > > > > >
> > > > > > > > L2TP specific issues I am blissfully unaware of; however,
> > > > > > > > because the NAT
> > > > > > > > boxes are not neccessarily even controlled by the
> > IPsec user,
> > > > > > > > sending the
> > > > > > > > public address is not really an option that can
> > be supported
> > > > > > > > everywhere.
> > > > > > > >
> > > > > > >
> > > > > > > Agreed.
> > > > > > >
> > > > > > > > Here's how the information flow goes as far as I see it:
> > > > > > > >
> > > > > > > > Public address doesn't really need to be sent in
> > any case as
> > > > > > > > the remote
> > > > > > > > side's public address is the address we're
> > talking IKE with
> > > > > > > > (or at least
> > > > > > > > remote address+port combination, but in NAPT
> > case you don't
> > > > > > > > really have
> > > > > > > > more of an remote address in any case).
> > > > > > > >
> > > > > > > > Private address that is used by the OS for actual
> > > > > > traffic is provided
> > > > > > > > within the NAT-OA payload so the checksums et al can be
> > > > > > corrected.
> > > > > > > >
> > > > > > >
> > > > > > > Let me describe the issue with regarding to L2TP/IPsec
> > > > > > (voluntary L2TP) when
> > > > > > > a NAT is present. Suppose a PC with a home network's
> > > > > > private IP address V_1
> > > > > > > is behind a NAT box with a public address P_1. The
> > > > > > corporate network's
> > > > > > > Security Gateway's IP address is P_2 and the PC wants to
> > > > > > connect to a
> > > > > > > corporate server with private IP address I_2. If
> > > > > > everything goes well, this
> > > > > > > PC will eventually obtain another private address I_1 from
> > > > > > the corporate
> > > > > > > network through IPCP . So the L2TP traffic sent by the PC
> > > > > > will have the
> > > > > > > following headers: IP/UDP/ESP/UDP/L2TP control or
> > > > > > > IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will
> > > > > > indicate the
> > > > > > > traffic is sent from V_1 to P_2. The inner IP header will
> > > > > > indicate the
> > > > > > > traffic is sent from I_1 to I_2. The source IP address V_1
> > > > > > in the outer
> > > > > > > header will be changed by the NAT box to P_1 on the way
> > > > > > out. So the packet
> > > > > > > received by the corporate SG is an UDP-encapsulated
> > > > > > TRANSPORT mode IPsec
> > > > > > > packet from P_1 to P_2 with UDP source port 1701 and UDP
> > > > > > dest port 1701 in
> > > > > > > the 2nd UDP header (assuming no dynamic UDP port for L2TP).
> > > > > > To allow this
> > > > > > > packet to pass through the SG, an inbound filter matching
> > > > > > the packet must
> > > > > > > exist in the SG. The inbound filter is dynamically created
> > > > > > after a quick
> > > > > > > mode exchange between the PC and the SG. To create such a
> > > > > > filter in the SG,
> > > > > > > the PC must specify < IP = P_1, proto = UDP, port = 1701>
> > > > > > in ID_i during
> > > > > > > the quick mode exchange. But how does this PC
> > knows about P_1?
> > > > > > >
> > > > > > > What I described above is a scenario specific to
> > > > L2TP/IPsec. But in
> > > > > > > general, any transport mode IPsec tunnel with a NAT box
> > > > > > along its path will
> > > > > > > have the same problem.
> > > > > > >
> > > > > > > Am I right? Or I am missing something here?
> > > > > > >
> > > > > > > - James Huang
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Therefore, at least as far as implementation I
> > used to work
> > > > > > > > on goes, ID
> > > > > > > > payload in transport mode case doesn't matter (I seem to
> > > > > > > > recall we sent
> > > > > > > > private address, but pretty much ignored what was
> > > > sent by remote).
> > > > > > > >
> > > > > > > > -Markus
> > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > James C. Huang
> > > > > > > >
> > > > > > > > --
> > > > > > > > "Every program has (at least) two purposes: the one for
> > > > > > which it was
> > > > > > > > written, and another for which it wasn't. "
> > > > > > > >
> > > > > > > > From ACM's SIGPLAN publication, (September, 1982),
> > > > > > Article "Epigrams
> > > > > > > > in Programming", by Alan J. Perlis of Yale University.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.
If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
From owner-ipsec@lists.tislabs.com Mon Nov 11 01:10: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 gAB9Aev06680;
Mon, 11 Nov 2002 01:10:40 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11164
Mon, 11 Nov 2002 03:44:03 -0500 (EST)
Message-ID: <001901c2895e$a54c3000$640572d4@trustworks.com>
From: "Valery Smyslov" <svan@trustworks.com>
To: <ipsec@lists.tislabs.com>
Subject: Authentication methods in IKEv2
Date: Mon, 11 Nov 2002 11:45:11 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
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 have some doubts about using of authentication methods in IKEv2.
In IKEv2 negotiation of authentication methods was completely
removed - each side simply uses his/her favourite method.
I think this may lead to the lack of interoperability and extensibility
in case one of the endpoints supports more than one method of
authentication.
For example. Let's initiator support RSA and DSS and has certificates
of the both types. Let's responder support only RSA. In this case,
responder has no means in the protocol to explicitly indicate,
that it will accept only RSA certificates. Even if we require
all implementations to support all three authentication methods
- RSA, DSS and preshared keys (that is definitely unrealistic,
at least for DSS), what about future authentication methods?
Another thing that makes me feeling uncomfortable is that even
type of key an enpoint uses for her own signature is not always explicitely
indicated in the protocol. It can easily be learned if certificate
is present in exchange, but certificate payload is optional...
Regards,
Valery Smyslov.
From owner-ipsec@lists.tislabs.com Mon Nov 11 02:55: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 gABAtJv19191;
Mon, 11 Nov 2002 02:55:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA11407
Mon, 11 Nov 2002 05:31:25 -0500 (EST)
Message-ID: <3DCF872E.50204@F-Secure.com>
Date: Mon, 11 Nov 2002 12:32:14 +0200
From: Ari Huttunen <Ari.Huttunen@f-secure.com>
Organization: F-Secure Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: HOULLIER Francis FTRD/DMI/CAE <francis.houllier@rd.francetelecom.com>
CC: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-udp-encaps-04.txt
References: <C691E039D3895C44AB8DFD006B950FB409AB38@lanmhs50.rd.francetelecom.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Nov 2002 10:32:17.0313 (UTC) FILETIME=[9B809110:01C2896D]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
HOULLIER Francis FTRD/DMI/CAE wrote:
> Hi all,
>
> Is there any work around "TCP encapsulation of IPSec packets" ?
> Thanks
No. It doesn't buy you anything, just adds complexity.
Ari
--
I play it cool and dig all jive,
that's the reason I stay alive.
My motto as I live and learn,
is dig and be dug in return. <Langston Hughes>
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 Nov 11 09:55: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 gABHtgg13640;
Mon, 11 Nov 2002 09:55:43 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12272
Mon, 11 Nov 2002 12:28:08 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f09b9f5981853bf@[165.227.249.18]>
In-Reply-To: <001901c2895e$a54c3000$640572d4@trustworks.com>
References: <001901c2895e$a54c3000$640572d4@trustworks.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Mon, 11 Nov 2002 09:28:47 -0800
To: "Valery Smyslov" <svan@trustworks.com>, <ipsec@lists.tislabs.com>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Authentication methods in IKEv2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 11:45 AM +0300 11/11/02, Valery Smyslov wrote:
>I have some doubts about using of authentication methods in IKEv2.
>In IKEv2 negotiation of authentication methods was completely
>removed - each side simply uses his/her favourite method.
>I think this may lead to the lack of interoperability and extensibility
>in case one of the endpoints supports more than one method of
>authentication.
Two endpoints that trust each other need to know *how* they trust
each other before setting up a secure channel. IKEv1 blurred this
rule by giving the option of saying how each side was going to
authenticate. IKEv2 tightens this up.
>For example. Let's initiator support RSA and DSS and has certificates
>of the both types. Let's responder support only RSA. In this case,
>responder has no means in the protocol to explicitly indicate,
>that it will accept only RSA certificates.
Exactly right. The two sides must know in advance why they trust each other.
The worst-case scenario is that the responder tells the initiator "I
don't trust you", and the initiator tries again with a different
authentication mechanism.
For the rare case where the two endpoints don't really know each
other *and* are going to trust each other *and* have multiple
authentication mechanisms, we have eliminated a confusing option from
IKEv1. That's exactly what IKEv2 was designed to do.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Mon Nov 11 09:55: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 gABHtgg13641;
Mon, 11 Nov 2002 09:55:43 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12258
Mon, 11 Nov 2002 12:25:09 -0500 (EST)
Message-Id: <5.1.0.14.2.20021110124741.020c4858@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 11 Nov 2002 12:25:19 -0500
To: ipsec@lists.tislabs.com
From: "Housley, Russ" <rhousley@rsasecurity.com>
Subject: draft-ietf-ipsec-pki-profile-01.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Brian & Eric:
Thanks for pushing this work forward. I think that it is important if we
are ever going to achieve interoperability with certificate-based key
management.
In section 2, you define "Root CA". How is this different than "trust
anchor" as defined in RFC 3280?
In section 3.2.2, please reword. It says: "When comparing the contents of
ID with the dNSName field in the subjectAltName extension for equality,
caseless string comparison is performed." I believe this sentence should
contain a MUST. Also, section 3.2.3 contains the same sentence, and it
should also contain a MUST.
In section 3.2.4, says that address blocks are not supported as name
forms. This is true, but some work in this area has been done in
conjunction with SBGP. Please review the certificate extension identified by:
id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
In section 3.3.8.1, I suggest rewording that avoids the term "trusted
root," which is not defined. Again, I suggest the term "trust anchor" as
defined in RFC 3280.
In sections 3.3.8.2 and 3.3.9.2, you should point out that RFC 3280
prohibits certificates and CRLs with an empty issuer name field.
In section 3.3.9.1, it assumes that the party has ready access to the most
recent CRLs, and any certificates needed to validate the CRLs. In a road
warrior scenario, one of the peers is in a much better situation to obtain
these than the other. Should this be discussed?
Please adjust the example description in section 3.3.11.3. There is no
requirement that a trust anchor be specified by a self-signed
certificate. The peer should never be asked to provide a certificate
associated with a trust anchor.
In section 3.4.2, should the list also include CRL signatures by CRL issuers?
Shouldn't 3.4.5 be parallel to 3.3.5? I expected it to recommend against
the use of ARL.
In section 3.4.10.5, you say: "Implementations MUST be prepared to receive
certificates and CRLs which are not relevant to the current exchange.
Implementations MAY discard such keying materials." I agree, but I think
that the last sentence potentially confusing. An implementation should
disregard the extraneous certificates and CRLs, not the symmetric keying
material that was generated.
In section 4.1.1, I agree that v3 certificates should be required for end
entity and CA certificates. However, the same code will likely be used for
several purposes, and one of them is trust anchors. Self-signed v1
certificates are often used to establish trust anchors.
In section 4.1.2.2.2, describing conventions for FQDN Host Names, I think
that the SHOULD and MAY are backwards. When a DQDN is carried in the
subject field of a certificate, the domainComponent attribute SHOULD be
used. The commonName attribute MAY be used instead. I prefer dNSName in
the SubjectAltName extension to both of these!
In section 4.1.3, I do not understand the second paragraph on the
criticality bit. Implementation MUST reject a certificate if it contains
an extension that it does not know how to handle with the criticality bit
set to TRUE.
In sections 4.1.3.1, 4.1.3.2, and 4.2.3.1, on the AuthorityKeyIdentifier
(for certificates and CRLs) and SubjectKeyIdentifier extensions, please
change "and thus should generate" to "and thus should not generate"
In section 4.1.3.3, I suggest that signature validation operations should
proceed if either the nonRepudiation or the digitalSignature key usage bit
is set in an end entity certificate. In my opinion, digitalSignature is
preferred, but nonRepudiation should be allowed.
In section 4.1.3.7.1.2, on the iPAddress subjectAltName, a disconnect
between PKIX and IPsec is pointed out. You say what MUST NOT be done, but
you do not say what ought to be done.
Note that the CIDR [CIDR] notation permitted in the "Name Con-
straints" section of PKIX is explicitly not permitted by that speci-
fication for conveying identity information. In other words, the CIDR
notation MUST NOT be used in the subjectAltName extension.
In section 4.1.3.10, more needs to be said. Microsoft has received a lot
of criticism for treating certificates without the basicConstraints
extension as a CA certificate. This section permits this behavior.
In section 4.1.3.13, you say that no IPsec extended key usage values have
been registered. This is incorrect. Three extended key usage values for
use with IPsec have been registered. Do you propose to deprecate their use?
id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
In section 4.1.3.16, you should state that most implementations do not
support delta CRLs.
In section 4.2.3.5, discussing IssuingDistributionPoint, you incorrectly
discuss the uses of this extension in support of delta CRLs. When a CRL is
not a "full CRL," this extension identifies the subset of information that
is present. It also flags indirect CRLs. I believe that this profile
should advocate support for "full CRLs," and it should warn that many
implementations do not support indirect CRLs.
In section 6.1.2.1, I suggest that signature validation operations should
proceed if either the nonRepudiation or the digitalSignature key usage bit
is set in an end entity certificate. In my opinion, digitalSignature is
preferred, but nonRepudiation should be allowed.
In the References section. please add a reference for PKCS#10.
Russ
From owner-ipsec@lists.tislabs.com Mon Nov 11 10:30: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 gABIU6g14871;
Mon, 11 Nov 2002 10:30:06 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12366
Mon, 11 Nov 2002 13:01:19 -0500 (EST)
Message-ID: <0809b33dff4a46db44ac4cee0dbbad493dcff08d@watchguard.com>
From: James Huang <james.huang@watchguard.com>
To: "'awank@future.futsoft.com'" <awank@future.futsoft.com>,
"'Skip Booth'"
<ebooth@cisco.com>
Cc: "'Markus Stenberg'" <fingon@iki.fi>, ipsec@lists.tislabs.com,
l2tpext@ietf.org
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Mon, 11 Nov 2002 10:01:15 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> -----Original Message-----
> From: Awan Kumar Sharma [mailto:awank@future.futsoft.com]
> Sent: Sunday, November 10, 2002 11:52 PM
> To: 'Skip Booth'; James Huang
> Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
> Hi James and Skip,
>
> Initially the idea for re-computation for TCP/UDP Checksums
> was confusing me
> too. But now I feel that whatever has been mentioned in the draft is
> correct. I am putting my opinion regarding that here and
> please correct me
> if I am wrong anywhere. Incidentally, I would like to clarify that the
> checksum that needs to be updated (as specified in the draft)
> is the TCP/UDP
> checksum and not the IP Checksum (as Skip had quoted in one of his
> clarifications).
>
> There is no need to take an example of L2TP for finding the need for
> checksum re-computation. Any data traffic example in transport mode is
> enough. So, I am taking an example of a TCP traffic (between
> H1 and H2)
> being protected using IPSec in transport mode.
>
> Set-Up:
>
> SG1/Host1 ---------NAT(N1)------------- INTERNET ---------SG2/Host2.
>
> In this set-up, the hosts H1 and H2 are the SG's as well,
> since the traffic
> is protected in transport mode.
> A TCP packet going out of H1 (without IPSec) would look like:
> IPh1h2 | TCPh1h2 | Data,
> where TCPh1h2 is the TCP header that uses H1
> and H2 as the IP addresses
> for checksum computation.
> When IPSec is applied in transport mode with NAT traversal,
> the packet would
> look like,
> IPh1h2 | UDP <4500,4500>| ESP | encrypted (TCPh1h2 | Data ).
>
> When this packet traverses through a NAT device, the packet
> gets altered to
> IPn1h2 | UDP <x,4500>| ESP | encrypted (TCPh1h2 | Data).
>
> After this packet reaches SG2 (i.e. H2), after the normal
> IPsec processing
> and decapusulation as mentioned in the draft, the TCPh1h2 needs to be
> modified to TCPn1h2 (Why?). This is because, as far as TCP
> connection is
> concerned, after NAT H2 can only send data with Destination
> IP address as N1
> and not H1.
If we perfrom reverse NAT operation for outbound traffic at SG2, what you
just said should not be an issue.
>So, the data going UP(to TCP/HL) after IPSec
> decapsulation at
> SG2 should have the IP address as N1 and H2 and not H1 and
> H2. Now here is
> the point you were confused (I think). Instead of changing
> the IP address
> from N1 to H1, we need to change the checksum to adapt to N1
> as source. As
> far as my knowledge goes, the draft nowhere suggests to change the IP
> address from N1 to H1. It suggests only change in checksum.
> To change the
> checksum we need the IP address recieved through NAT-OA.
>
The problem with what you described above is that the packet will
have trouble passing the filtering database check at SG2. This is because
the traffic spec negotiated during IKE QM exchange is for traffics btw h1
and h2 (not N1 and h2).
One good side effect of changing the address from N1 back to h1 at
SG2 as I described in my previous emails is that the issue of "multiple
clients behind a NAT" described in the draft will no longer exist.
Regards,
James HUang
> Similar would be the case for L2TP.
> Hope that this clarifies your doubt . Please let me know if I
> am wrong a
> any place.
>
> Regards,
> Awan
>
>
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Skip Booth
> Sent: Saturday, November 09, 2002 9:10 AM
> To: James Huang
> Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
>
>
> On Fri, 8 Nov 2002, James Huang wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > Sent: Friday, November 08, 2002 4:50 PM
> > > To: James Huang
> > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > >
> > >
> > >
> > >
> > > On Fri, 8 Nov 2002, James Huang wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > > > Sent: Friday, November 08, 2002 12:09 PM
> > > > > To: James Huang
> > > > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com;
> 'l2tpext@ietf.org'
> > > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, 8 Nov 2002, James Huang wrote:
> > > > >
> > > > > > Skip,
> > > > > > If we fix up the source IP address using the
> > > private address
> > > > > > advertised in NAT-OA during IKE negotiation, then why
> > > should TCP/UDP
> > > > > > checksum be re-computed at the security gateway as was
> > > > > described in section
> > > > > > 3.1.2?
> > > > >
> > > > > Because the NAT would have modified the checksum as the
> > > > > packet passed through
> > > > > the NAT. In order for it to pass the IP CRC check at the SG,
> > > > > you must fixup the
> > > > > checksum based on the pre-NAT values.
> > > > >
> > > >
> > > >
> > > > Skip,
> > > >
> > > > With UDP-encapsuilated IPsec, NAT box will only see and
> > > modify the outer UDP
> > > > header used to encapsulate the IPsec packet (in addtioanl
> > > to modify the
> > > > outer IP address). After the security gateway
> > > decapsulating an IPsec packet
> > > > in transport mode (i.e. removing the outer UDP header and
> > > the ESP header)
> > > > and modify the source IP address in the outer IP header
> > > with the address
> > > > received in the NAT-OA, the checksum in the inner TCP/UDP
> > > header should be
> > > > already correct as the client computes that checksum based
> > > on the same
> > > > address in the NAT-OA.
> > > >
> > > > Am I missing something here?
> > >
> > > I think you are confused since it appears that you believe
> > > their is an outer IP
> > > header and an inner IP header. This is not true for the
> > > Transport Mode ESP
> > > encap specified in the draft. The packet format for
> > > Transport Mode ESP Encap
> > > (which is what would be used for L2TP/IPsec most likely) is
> > > specified as
> > > follows:
> > >
> > > 3.2 Transport Mode ESP Encapsulation
> > >
> > > BEFORE APPLYING ESP/UDP
> > > ----------------------------
> > > IPv4 |orig IP hdr | | |
> > > |(any options)| TCP | Data |
> > > ----------------------------
> > >
> > > AFTER APPLYING ESP/UDP
> > > -------------------------------------------------------
> > > IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
> > > |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
> > > -------------------------------------------------------
> > > |<----- encrypted ---->|
> > > |<------ authenticated ----->|
> > >
> > > For L2TP/IPsec, these will look like:
> > >
> > > IP/UDP/ESP/1701/1701/[L2TP hdr/PPP]/ESP trailer/ESP Auth
> > >
> >
> >
> >
> > Skip,
> > The L2TP/IPsec packet should look like this in more detail,
> >
> > IP1/UDP/ESP/1701/1701/L2TP hdr/PPP hdr / IP2/ ... /ESP
> trailer/ESP Auth.
> > The outer IP header is the first IP header IP1 above. The inner IP
> header
> > is the second IP header IP2 that I just added. THis is
> the packet format
> > after the IPsec tunnel is set up, L2TP tunnel is set up,
> IPCP is completed
> > (e.g. for the client to obtain a private address in the corporate
> network),
> > and the real data traffic inside the L2TP tunnel starts flowing..
> >
> >
> >
> >
> > > As such, the outer header contains the private address. The
> > > NAT box will
> > > perform the IP address/port translation on the outer IP/UDP
> > > header and in the
> > > process will recompute the CRC on the outer IP header. On
> > > the SG, after
> > > restoring the private addresses on the outer header, the CRC
> > > must be restored to
> > > the original value prior to the NAT fixup.
> > >
> > > -Skip
> >
> >
> > Skip,
> >
> > Lets take the following scenario as an example.
> >
> >
> > PC -------- NAT -------- internet --------- SG
> > ------------ server
> >
> >
> > Suppose the PC's private address is PC1, the public address
> at the NAT is
> > P1, the public address at SG is P2, and the server has a
> private corporate
> > address S1.
> > Both the IPsec transport mode tunnel and the L2TP tunnel
> are btw the PC
> and
> > the SG.
> >
> > During IKE QM exchange to set up an IPsec tunnel to protect
> L2TP packets,
> > the first packet the SG received will look like this:
> >
> > ip header: P1->P2,
> > traffic selectors: IP: PC1<->P2, udp port: 1701 <-> 1701
> (assuming LAC
> > chose the fixed UDP port). If the QM exchange succeeds,
> the SG will enter
> > into its inbound/outbound filtering database based on above
> traffic spec.
> >
> > When the PC sends out a L2TP control packet, it will look like this:
> > IP/UDP1/ESP/UDP2/L2TP control/ESP trailer/ESP Auth. The IP
> header will be
> > from PC1 to P2 and UDP1 will be from 4500 to 4500, UDP2
> will be from 1701
> to
> > 1701. The UDP checksum in UDP2 will be based on the
> address PC1. After
> > this packet passed the NAT box, the IP header will be from
> P1 to P2 and
> UDP1
> > may be adjusted to from port Y to 4500 and its checksum
> also adjusted.
> > Note UDP2 is not touched by the NAT box.
> >
> > After the SG decrypts and decapsulats the inbound packet,
> it will look
> like
> > this: IP/UDP2/L2TP control. The IP header will be from
> P1 to P2 and
> UDP2
> > from 1701 to 1701.
> > The SG will then modify the IP header to PC1 -> P2. Now
> the packet will
> > pass the checking using the filtering database and the
> checksum in UDP2
> will
> > also be automatically correct.
>
> I'm not sure that the checksum in the outer IP header is
> valid at this point
> though. The IP header's CRC will be based on the P1 to P2 addresses,
> however
> once IPsec finishes manipulating the packet, the IP addresses will be
> PC1->P2
> and the IP CRC will need to be adjusted to reflect that. I
> agree with you
> though that the UDP2 checksum should be correct.
>
> >
> > After the L2TP tunnel is set up, and IPCP is completed, the
> PC will obtain
> a
> > private address Vpc1 from inside the corporate network.
> Now the packet
> sent
> > by the PC will look like this: IP1/UDP1/ESP/UDP2/L2TP
> hdr/PPP hdr / IP2/
> > ... /ESP trailer/ESP Auth.
> >
> > IP1: PC1->P2
> > UDP1: 4500->4500
> > UDP2: 1701->1701 (checksum computed based on PC1)
> > IP2: Vpc1->S1
> >
> > The rest should be very similar to what I described above.
>
> That's all correct and hopefully we've now answered you
> original question
> about
> how the packet passes the SG filter checks. I'll defer any
> further checksum
> questions to the authors of the draft :)
>
> -Skip
>
> >
> >
> >
> > -- James Huang
> >
> >
> > > >
> > > > Regards,
> > > > James Huang
> > > >
> > > >
> > > >
> > > >
> > > > > > The checksum was originally computed by the client using its
> > > > > > private address. Also is this solution the same as the
> > > > > "built-in NAT"
> > > > > > solution mentioned in Appendix A of
> > > > > draft-ietf-ipsec-udp-encaps-04.txt to
> > > > > > solve the problem of multiple clients behind a NAT with
> > > > > overlapped traffic
> > > > > > specifications?
> > > > >
> > > > > I don't the CRC fixup has anything to do with Appendix A.
> > > > >
> > > > > -Skip
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > - James
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Skip Booth [mailto:ebooth@cisco.com]
> > > > > > > Sent: Thursday, November 07, 2002 7:31 PM
> > > > > > > To: James Huang
> > > > > > > Cc: 'Markus Stenberg'; ipsec@lists.tislabs.com;
> > > 'l2tpext@ietf.org'
> > > > > > > Subject: RE: UDP-encapsulated IPsec Transport mode
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > James, does the recommendation in section 3.1.2 a) answer
> > > > > > > your question? I
> > > > > > > believe after fixing up the IP header to include
> the private
> > > > > > > address which was
> > > > > > > advertised during the negotiation, the packet will passte
> > > > > > > through the SG filters.
> > > > > > > The authors of this draft should be able to
> provide further
> > > > > > > clarification if
> > > > > > > this doesn't address your concerns.
> > > > > > >
> > > > > > > -Skip
> > > > > > >
> > > > > > > On Thu, 7 Nov 2002, James Huang wrote:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Markus Stenberg [mailto:fingon@iki.fi]
> > > > > > > > > Sent: Wednesday, November 06, 2002 11:51 PM
> > > > > > > > > To: James Huang
> > > > > > > > > Cc: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> > > > > > > > > Subject: Re: UDP-encapsulated IPsec Transport mode
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > James Huang <james.huang@watchguard.com> writes:
> > > > > > > > > > Hi all,
> > > > > > > > > > In the appendix A of
> > > > > > > > > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > > > > > > > > some discussions on the issue of multiple
> > > clients running
> > > > > > > > > UDP-encapsulated
> > > > > > > > > > IPsec transport mode tunnels behind a NAT
> box. However,
> > > > > > > > > did not find any
> > > > > > > > > > discussion on another related issue: In the traffic
> > > > > > > > > selector (ID) payload
> > > > > > > > > > the client sends out during quick mode
> > > exchange, should the
> > > > > > > > > client use its
> > > > > > > > > > own private address or the public routable
> address (i.e.
> > > > > > > > > the NAT box's
> > > > > > > > > > public IP address)? If it the later, how does
> > > the client
> > > > > > > > > know about that
> > > > > > > > > > public address? This seems to be a serious issue,
> > > > > > > > > especially for L2TP
> > > > > > > > > > voluntary tunnels secured by IPsec (in
> transport mode).
> > > > > > > > >
> > > > > > > > > L2TP specific issues I am blissfully unaware
> of; however,
> > > > > > > > > because the NAT
> > > > > > > > > boxes are not neccessarily even controlled by the
> > > IPsec user,
> > > > > > > > > sending the
> > > > > > > > > public address is not really an option that can
> > > be supported
> > > > > > > > > everywhere.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Agreed.
> > > > > > > >
> > > > > > > > > Here's how the information flow goes as far
> as I see it:
> > > > > > > > >
> > > > > > > > > Public address doesn't really need to be sent in
> > > any case as
> > > > > > > > > the remote
> > > > > > > > > side's public address is the address we're
> > > talking IKE with
> > > > > > > > > (or at least
> > > > > > > > > remote address+port combination, but in NAPT
> > > case you don't
> > > > > > > > > really have
> > > > > > > > > more of an remote address in any case).
> > > > > > > > >
> > > > > > > > > Private address that is used by the OS for actual
> > > > > > > traffic is provided
> > > > > > > > > within the NAT-OA payload so the checksums
> et al can be
> > > > > > > corrected.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Let me describe the issue with regarding to L2TP/IPsec
> > > > > > > (voluntary L2TP) when
> > > > > > > > a NAT is present. Suppose a PC with a home network's
> > > > > > > private IP address V_1
> > > > > > > > is behind a NAT box with a public address P_1. The
> > > > > > > corporate network's
> > > > > > > > Security Gateway's IP address is P_2 and the PC wants to
> > > > > > > connect to a
> > > > > > > > corporate server with private IP address I_2. If
> > > > > > > everything goes well, this
> > > > > > > > PC will eventually obtain another private
> address I_1 from
> > > > > > > the corporate
> > > > > > > > network through IPCP . So the L2TP traffic
> sent by the PC
> > > > > > > will have the
> > > > > > > > following headers: IP/UDP/ESP/UDP/L2TP control or
> > > > > > > > IP/UDP/ESP/UDP/L2TP/PPP/IP/.... The outer IP header will
> > > > > > > indicate the
> > > > > > > > traffic is sent from V_1 to P_2. The inner IP
> header will
> > > > > > > indicate the
> > > > > > > > traffic is sent from I_1 to I_2. The source IP
> address V_1
> > > > > > > in the outer
> > > > > > > > header will be changed by the NAT box to P_1 on the way
> > > > > > > out. So the packet
> > > > > > > > received by the corporate SG is an UDP-encapsulated
> > > > > > > TRANSPORT mode IPsec
> > > > > > > > packet from P_1 to P_2 with UDP source port 1701 and UDP
> > > > > > > dest port 1701 in
> > > > > > > > the 2nd UDP header (assuming no dynamic UDP
> port for L2TP).
> > > > > > > To allow this
> > > > > > > > packet to pass through the SG, an inbound
> filter matching
> > > > > > > the packet must
> > > > > > > > exist in the SG. The inbound filter is
> dynamically created
> > > > > > > after a quick
> > > > > > > > mode exchange between the PC and the SG. To
> create such a
> > > > > > > filter in the SG,
> > > > > > > > the PC must specify < IP = P_1, proto = UDP,
> port = 1701>
> > > > > > > in ID_i during
> > > > > > > > the quick mode exchange. But how does this PC
> > > knows about P_1?
> > > > > > > >
> > > > > > > > What I described above is a scenario specific to
> > > > > L2TP/IPsec. But in
> > > > > > > > general, any transport mode IPsec tunnel with a NAT box
> > > > > > > along its path will
> > > > > > > > have the same problem.
> > > > > > > >
> > > > > > > > Am I right? Or I am missing something here?
> > > > > > > >
> > > > > > > > - James Huang
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > Therefore, at least as far as implementation I
> > > used to work
> > > > > > > > > on goes, ID
> > > > > > > > > payload in transport mode case doesn't matter
> (I seem to
> > > > > > > > > recall we sent
> > > > > > > > > private address, but pretty much ignored what was
> > > > > sent by remote).
> > > > > > > > >
> > > > > > > > > -Markus
> > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > James C. Huang
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > "Every program has (at least) two purposes:
> the one for
> > > > > > > which it was
> > > > > > > > > written, and another for which it wasn't. "
> > > > > > > > >
> > > > > > > > > From ACM's SIGPLAN publication, (September, 1982),
> > > > > > > Article "Epigrams
> > > > > > > > > in Programming", by Alan J. Perlis of Yale University.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> **************************************************************
> *************
> This message is proprietary to Future Software Limited (FSL)
> and is intended solely for the use of the individual to whom it
> is addressed. It may contain privileged or confidential information
> and should not be circulated or used for any purpose other than for
> what it is intended.
>
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient,
> you are notified that you are strictly prohibited from using,
> copying, altering, or disclosing the contents of this message.
> FSL accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including
> damage from virus.
> **************************************************************
> *************
>
From owner-ipsec@lists.tislabs.com Mon Nov 11 11:36: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 gABJa4g19526;
Mon, 11 Nov 2002 11:36:05 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12604
Mon, 11 Nov 2002 13:45:44 -0500 (EST)
Message-ID: <00b601c289b3$1f3abe50$93f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: "Valery Smyslov" <svan@trustworks.com>, <ipsec@lists.tislabs.com>,
"Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
References: <001901c2895e$a54c3000$640572d4@trustworks.com> <p05200f09b9f5981853bf@[165.227.249.18]>
Subject: Re: Authentication methods in IKEv2
Date: Mon, 11 Nov 2002 12:49:47 -0600
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Even in the absence of negotiating the authentication
method I think there is value in specifying which method
an endpoint has used, rather than leaving it up to the
receiving end to determine the structure of the "auth"
blob of data.
----- Original Message -----
From: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
To: "Valery Smyslov" <svan@trustworks.com>; <ipsec@lists.tislabs.com>
Sent: Monday, November 11, 2002 11:28 AM
Subject: Re: Authentication methods in IKEv2
| At 11:45 AM +0300 11/11/02, Valery Smyslov wrote:
| >I have some doubts about using of authentication methods in IKEv2.
| >In IKEv2 negotiation of authentication methods was completely
| >removed - each side simply uses his/her favourite method.
| >I think this may lead to the lack of interoperability and extensibility
| >in case one of the endpoints supports more than one method of
| >authentication.
|
| Two endpoints that trust each other need to know *how* they trust
| each other before setting up a secure channel. IKEv1 blurred this
| rule by giving the option of saying how each side was going to
| authenticate. IKEv2 tightens this up.
|
| >For example. Let's initiator support RSA and DSS and has certificates
| >of the both types. Let's responder support only RSA. In this case,
| >responder has no means in the protocol to explicitly indicate,
| >that it will accept only RSA certificates.
|
| Exactly right. The two sides must know in advance why they trust each
other.
|
| The worst-case scenario is that the responder tells the initiator "I
| don't trust you", and the initiator tries again with a different
| authentication mechanism.
|
| For the rare case where the two endpoints don't really know each
| other *and* are going to trust each other *and* have multiple
| authentication mechanisms, we have eliminated a confusing option from
| IKEv1. That's exactly what IKEv2 was designed to do.
|
| --Paul Hoffman, Director
| --VPN Consortium
From owner-ipsec@lists.tislabs.com Mon Nov 11 11:56: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 gABJuLg21954;
Mon, 11 Nov 2002 11:56:21 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12695
Mon, 11 Nov 2002 14:15:01 -0500 (EST)
Date: Mon, 11 Nov 2002 11:13:41 -0800 (PST)
From: Jan Vilhuber <vilhuber@cisco.com>
To: "Housley, Russ" <rhousley@rsasecurity.com>
cc: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>, <ipsec@lists.tislabs.com>
Subject: RE: Adding revised identities to IKEv2
In-Reply-To: <5.1.0.14.2.20021109161112.02d5e5b0@exna07.securitydynamics.com>
Message-ID: <Pine.LNX.4.33.0211111112270.31731-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 Sat, 9 Nov 2002, Housley, Russ wrote:
> Paul:
>
> >> This is what IKE v2 and a cert profile should do, in combination.
> >
> >Given the importance of certificates to IKEv2, the profile should be a
> >part of the IKEv2 document.
>
> Why do you think it needs to be one document?
Presumably for the same reason we decided to fold the IKE, ISAKMP,
IPDOI etc drafts into a single document.
jan
> I think maintenance would be
> easier if it was a separate document.
>
> Russ
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
THE NETWORK WORKS,
NO EXCUS NFS server mastiff-fddi not responding still trying
From owner-ipsec@lists.tislabs.com Mon Nov 11 14:07: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 gABM7eg28545;
Mon, 11 Nov 2002 14:07:40 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13055
Mon, 11 Nov 2002 16:32:47 -0500 (EST)
Date: 11 Nov 2002 16:11:51 -0500
Message-ID: <006101c289c6$f57d8890$1e72788a@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: "'Ari Huttunen'" <Ari.Huttunen@f-secure.com>,
" 'HOULLIER Francis FTRD/DMI/CAE'" <francis.houllier@rd.francetelecom.com>
Cc: "'ipsec'" <ipsec@lists.tislabs.com>
Subject: RE: draft-ietf-ipsec-udp-encaps-04.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: <3DCF872E.50204@F-Secure.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Also, note that TCP-in-TCP encapsulation has very poor performance
characteristics. Since the original packet is very likely to be TCP,
attempts to wrap the IPsec-encapsulated packet in TCP are likely to lead to
disaster.
Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ari Huttunen
> Sent: Monday, November 11, 2002 5:32 AM
> To: HOULLIER Francis FTRD/DMI/CAE
> Cc: ipsec@lists.tislabs.com
> Subject: Re: draft-ietf-ipsec-udp-encaps-04.txt
>
>
> HOULLIER Francis FTRD/DMI/CAE wrote:
> > Hi all,
> >
> > Is there any work around "TCP encapsulation of IPSec packets" ?
> > Thanks
>
> No. It doesn't buy you anything, just adds complexity.
>
> Ari
>
>
> --
> I play it cool and dig all jive,
> that's the reason I stay alive.
> My motto as I live and learn,
> is dig and be dug in return. <Langston Hughes>
>
> 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 Nov 11 14:22: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 gABMMog29596;
Mon, 11 Nov 2002 14:22:50 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13135
Mon, 11 Nov 2002 16:54:00 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Cc: ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021111165258.03997788@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 11 Nov 2002 16:54:07 -0500
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
In-Reply-To: <p05200f1cb9f5d6b6e5bd@[165.227.249.18]>
References: < <5.1.0.14.2.20021110124741.020c4858@exna07.securitydynamics.com>
<5.1.0.14.2.20021110124741.020c4858@exna07.securitydynamics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul:
>>Thanks for pushing this work forward. I think that it is important if we
>>are ever going to achieve interoperability with certificate-based key
>>management.
>
>Russ, are you saying that you think this document is good for IKEv1, or
>IKEv2, or both? Changing the ground rules for IKEv1 implementations at
>this late date seems like a bad idea.
I think that the IPsec WG should be putting its energy into IKEv2.
Russ
From owner-ipsec@lists.tislabs.com Mon Nov 11 14: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 gABMMsg29609;
Mon, 11 Nov 2002 14:22:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13114
Mon, 11 Nov 2002 16:51:58 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f1cb9f5d6b6e5bd@[165.227.249.18]>
In-Reply-To:
<5.1.0.14.2.20021110124741.020c4858@exna07.securitydynamics.com>
References:
<5.1.0.14.2.20021110124741.020c4858@exna07.securitydynamics.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Mon, 11 Nov 2002 13:52:02 -0800
To: "Housley, Russ" <rhousley@rsasecurity.com>, ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 12:25 PM -0500 11/11/02, Housley, Russ wrote:
>Thanks for pushing this work forward. I think that it is important
>if we are ever going to achieve interoperability with
>certificate-based key management.
Russ, are you saying that you think this document is good for IKEv1,
or IKEv2, or both? Changing the ground rules for IKEv1
implementations at this late date seems like a bad idea.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Mon Nov 11 17:39:43 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id gAC1dgg09258;
Mon, 11 Nov 2002 17:39:42 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA13649
Mon, 11 Nov 2002 20:10:30 -0500 (EST)
Message-ID: <00a201c289e8$cd6791d0$0602a8c0@TRLDSK3>
From: "John Lindal" <jafl@trlokom.com>
To: <ipsec@lists.tislabs.com>
Cc: <jafl@trlokom.com>
Subject: RE: UDP-encapsulated IPsec Transport mode
Date: Mon, 11 Nov 2002 17:13:57 -0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> (1) The security gateway (SG) will insert entries into its filtering
> database based on the traffic selector (ID) specified by the client
> during the QM exchange.
>
> (2) After the SG decrypted and decapsulated an UDP-encapsulated IPsec
> packet in the transport mode (i.e. removing the outer UDP header and ESP
> header), it will modify the source IP address in the outer IP header
> using the address in the NAT-OA payload it received in the QM exchange.
>
> With this scheme, the packet after decapsulation will pass the security
> policy at the SG and the checksum in the inner UDP/TCP header no longer
> need to be re-computed by the SG as was described in section 3.1.2 in the
> draft. Also it will solve the issue of multiple clients behind the same
> NAT box described in section 5.3.
So far, we at Trlokom have contented ourselves with pointing out the myriad
problems with the various versions of the existing draft.
However, the above proposal (specifically item #2 and all that it implies)
is so similar to what we have patented that we feel that we must raise the
IPR issue. If this proposal or anything like it ends up in a future
version of the NAT traversal draft, it will violate our patents. The same
goes for any implementation (independent of the draft) of the above
suggestion.
--
Sincerely,
John Lindal
Chief Software Architect, Trlokom, Inc.
http://www.trlokom.com/
From owner-ipsec@lists.tislabs.com Mon Nov 11 23:01: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 gAC71Hg28272;
Mon, 11 Nov 2002 23:01:17 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14154
Tue, 12 Nov 2002 01:32:38 -0500 (EST)
Message-ID: <000801c28a15$701f9720$640572d4@trustworks.com>
From: "Valery Smyslov" <svan@trustworks.com>
To: "David Faucher" <dfaucher@lucent.com>, <ipsec@lists.tislabs.com>,
"Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
References: <001901c2895e$a54c3000$640572d4@trustworks.com> <p05200f09b9f5981853bf@[165.227.249.18]> <00b601c289b3$1f3abe50$93f22b42@mv.lucent.com>
Subject: Re: Authentication methods in IKEv2
Date: Tue, 12 Nov 2002 09:33:39 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
----- Original Message -----
From: "David Faucher" <dfaucher@lucent.com>
To: "Valery Smyslov" <svan@trustworks.com>; <ipsec@lists.tislabs.com>; "Paul
Hoffman / VPNC" <paul.hoffman@vpnc.org>
Sent: Monday, November 11, 2002 9:49 PM
Subject: Re: Authentication methods in IKEv2
> Even in the absence of negotiating the authentication
> method I think there is value in specifying which method
> an endpoint has used, rather than leaving it up to the
> receiving end to determine the structure of the "auth"
> blob of data.
Exactly. It can be achived, for example, by adding field "Authentication
Data Type"
into Authentication Payload.
Regards,
Valery Smyslov.
> ----- Original Message -----
> From: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
> To: "Valery Smyslov" <svan@trustworks.com>; <ipsec@lists.tislabs.com>
> Sent: Monday, November 11, 2002 11:28 AM
> Subject: Re: Authentication methods in IKEv2
>
>
> | At 11:45 AM +0300 11/11/02, Valery Smyslov wrote:
> | >I have some doubts about using of authentication methods in IKEv2.
> | >In IKEv2 negotiation of authentication methods was completely
> | >removed - each side simply uses his/her favourite method.
> | >I think this may lead to the lack of interoperability and extensibility
> | >in case one of the endpoints supports more than one method of
> | >authentication.
> |
> | Two endpoints that trust each other need to know *how* they trust
> | each other before setting up a secure channel. IKEv1 blurred this
> | rule by giving the option of saying how each side was going to
> | authenticate. IKEv2 tightens this up.
> |
> | >For example. Let's initiator support RSA and DSS and has certificates
> | >of the both types. Let's responder support only RSA. In this case,
> | >responder has no means in the protocol to explicitly indicate,
> | >that it will accept only RSA certificates.
> |
> | Exactly right. The two sides must know in advance why they trust each
> other.
> |
> | The worst-case scenario is that the responder tells the initiator "I
> | don't trust you", and the initiator tries again with a different
> | authentication mechanism.
> |
> | For the rare case where the two endpoints don't really know each
> | other *and* are going to trust each other *and* have multiple
> | authentication mechanisms, we have eliminated a confusing option from
> | IKEv1. That's exactly what IKEv2 was designed to do.
> |
> | --Paul Hoffman, Director
> | --VPN Consortium
>
>
From owner-ipsec@lists.tislabs.com Mon Nov 11 23:38: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 gAC7cvg05692;
Mon, 11 Nov 2002 23:38:57 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA14212
Tue, 12 Nov 2002 02:13:58 -0500 (EST)
Message-ID: <001201c28a1b$3870ecb0$640572d4@trustworks.com>
From: "Valery Smyslov" <svan@trustworks.com>
To: <ipsec@lists.tislabs.com>, "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
References: <001901c2895e$a54c3000$640572d4@trustworks.com> <p05200f09b9f5981853bf@[165.227.249.18]>
Subject: Re: Authentication methods in IKEv2
Date: Tue, 12 Nov 2002 10:15:03 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
----- Original Message -----
From: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
To: "Valery Smyslov" <svan@trustworks.com>; <ipsec@lists.tislabs.com>
Sent: Monday, November 11, 2002 8:28 PM
Subject: Re: Authentication methods in IKEv2
> At 11:45 AM +0300 11/11/02, Valery Smyslov wrote:
> >I have some doubts about using of authentication methods in IKEv2.
> >In IKEv2 negotiation of authentication methods was completely
> >removed - each side simply uses his/her favourite method.
> >I think this may lead to the lack of interoperability and extensibility
> >in case one of the endpoints supports more than one method of
> >authentication.
>
> Two endpoints that trust each other need to know *how* they trust
> each other before setting up a secure channel. IKEv1 blurred this
> rule by giving the option of saying how each side was going to
> authenticate. IKEv2 tightens this up.
I've been thinking that they trust each other because they both trust the
same CA.
But that CA may easily issue certificates of both types, RSA and DSS.
Imagine the situation: security gateway serves as access point for
two distinct groups of clients. One group of clients supports only RSA,
while the other - only DSS. All clients have certificates issued by the same
CA
(of course, of different types). Gateway supports both RSA and DSS and
trusts the same CA. Situation probably a bit weird, but not unrealistic.
The question: how gateway would unambiguously determine in every particular
case
which of his certificates (RSA or DSS) to use (apart from heuristic
methods)?
By client's ID? Possible, but not scaleble - he must keep and
maitain database of all client IDs. By client's certificate? Possible,
but a bit heuristic and precludes asymmetric authentication,
that could be useful sometimes (legacy authentication, for example).
> >For example. Let's initiator support RSA and DSS and has certificates
> >of the both types. Let's responder support only RSA. In this case,
> >responder has no means in the protocol to explicitly indicate,
> >that it will accept only RSA certificates.
>
> Exactly right. The two sides must know in advance why they trust each
other.
>
> The worst-case scenario is that the responder tells the initiator "I
> don't trust you", and the initiator tries again with a different
> authentication mechanism.
By the way, notification AUTHENTICATION-FAILED is missing
in the document...
> For the rare case where the two endpoints don't really know each
> other *and* are going to trust each other *and* have multiple
> authentication mechanisms, we have eliminated a confusing option from
> IKEv1. That's exactly what IKEv2 was designed to do.
The problem is that protocol seems to become less robust in that - it will
sometimes fail when it may (and should) succeed. The problem is relatively
easy
to fix - let each party include a list of supported authentication
mechanisms
into his/her first message, so that the other side may choose among them.
> --Paul Hoffman, Director
> --VPN Consortium
Regards,
Valery Smyslov.
From owner-ipsec@lists.tislabs.com Tue Nov 12 10:19: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 gACIJOg12229;
Tue, 12 Nov 2002 10:19:24 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15330
Tue, 12 Nov 2002 12:39:02 -0500 (EST)
To: jis@mit.edu, smb@research.att.com
cc: ipsec@lists.tislabs.com, secretariat@ietf.org, byfraser@cisco.com,
tytso@mit.edu
Subject: IPSEC MIB documents ready for IETF last call
From: tytso@mit.edu
Message-Id: <E18Bf0d-0005vW-00@snap.thunk.org>
Date: Tue, 12 Nov 2002 12:39:31 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Jeff, Steve,
The following documents:
draft-ietf-ipsec-doi-tc-mib-06.txt
draft-ietf-ipsec-flow-monitoring-mib-02.txt
draft-ietf-ipsec-ike-monitor-mib-04.txt
draft-ietf-ipsec-isakmp-di-mon-mib-05.txt
draft-ietf-ipsec-monitor-mib-06.txt
Have been through wg last call and are ready for IETF last call. Could
you please ask the secretariat to issue that last call and put them on
the IESG queue? Many thanks!!
- Ted and Barbara
From owner-ipsec@lists.tislabs.com Tue Nov 12 10:20: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 gACIKtg12482;
Tue, 12 Nov 2002 10:20:55 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15316
Tue, 12 Nov 2002 12:34:57 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f3bb9f6eb7be9a0@[165.227.249.18]>
In-Reply-To: <001201c28a1b$3870ecb0$640572d4@trustworks.com>
References: <001901c2895e$a54c3000$640572d4@trustworks.com>
<p05200f09b9f5981853bf@[165.227.249.18]>
<001201c28a1b$3870ecb0$640572d4@trustworks.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 12 Nov 2002 09:35:23 -0800
To: "Valery Smyslov" <svan@trustworks.com>, <ipsec@lists.tislabs.com>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Authentication methods in IKEv2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:15 AM +0300 11/12/02, Valery Smyslov wrote:
>I've been thinking that they trust each other because they both trust the
>same CA.
>But that CA may easily issue certificates of both types, RSA and DSS.
>Imagine the situation: security gateway serves as access point for
>two distinct groups of clients. One group of clients supports only RSA,
>while the other - only DSS. All clients have certificates issued by the same
>CA
>(of course, of different types). Gateway supports both RSA and DSS and
>trusts the same CA. Situation probably a bit weird, but not unrealistic.
Exactly right. One of the goals of IKEv2 is to reduce the number of
options that were only put in for situations that were "a bit weird".
>The question: how gateway would unambiguously determine in every particular
>case
>which of his certificates (RSA or DSS) to use (apart from heuristic
>methods)?
By trying one and, if it fails, trying again with the other.
>By the way, notification AUTHENTICATION-FAILED is missing
>in the document...
That's a problem! In fact, it is mentioned in section 5.8, but fell
off the list of notifications.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Tue Nov 12 10:34: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 gACIYDg13218;
Tue, 12 Nov 2002 10:34:13 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15315
Tue, 12 Nov 2002 12:34:57 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f3ab9f6eb22d4b5@[165.227.249.18]>
In-Reply-To: <000801c28a15$701f9720$640572d4@trustworks.com>
References: <001901c2895e$a54c3000$640572d4@trustworks.com>
<p05200f09b9f5981853bf@[165.227.249.18]>
<00b601c289b3$1f3abe50$93f22b42@mv.lucent.com>
<000801c28a15$701f9720$640572d4@trustworks.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 12 Nov 2002 09:31:28 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Authentication methods in IKEv2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 9:33 AM +0300 11/12/02, Valery Smyslov wrote:
>----- Original Message -----
>From: "David Faucher" <dfaucher@lucent.com>
>To: "Valery Smyslov" <svan@trustworks.com>; <ipsec@lists.tislabs.com>; "Paul
>Hoffman / VPNC" <paul.hoffman@vpnc.org>
>Sent: Monday, November 11, 2002 9:49 PM
>Subject: Re: Authentication methods in IKEv2
>
>
>> Even in the absence of negotiating the authentication
>> method I think there is value in specifying which method
>> an endpoint has used, rather than leaving it up to the
>> receiving end to determine the structure of the "auth"
>> blob of data.
>
>Exactly. It can be achived, for example, by adding field "Authentication
>Data Type"
>into Authentication Payload.
Fully agree. This is an easy addition and it prevents the receiving
party to have to figure it out from the ID. The cost is only two
octets.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Tue Nov 12 11:34: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 gACJYog17300;
Tue, 12 Nov 2002 11:34:50 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15543
Tue, 12 Nov 2002 13:49:31 -0500 (EST)
Message-Id: <4.3.2.7.2.20021112095441.056d0238@mira-sjc5-4.cisco.com>
X-Sender: byfraser@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 12 Nov 2002 09:57:44 -0800
To: "Geoffrey Huang" <ghuang@cisco.com>
From: Barbara Fraser <byfraser@cisco.com>
Subject: RE: Dead peer detection
Cc: "Edward Wilkinson" <ewilkinson@efficient.com>, <ipsec@lists.tislabs.com>,
tytso@mit.edu
In-Reply-To: <MEEJLOJCKGGPCNBGDIJACEAHCBAA.ghuang@cisco.com>
References: <36C2EB69D2F9D411A9AB00D0B7200334F81E17@eniwest.inside.efficient.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_336000793==_.ALT"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--=====================_336000793==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi,
Can you resubmit the draft to Internet Drafts and we will issue the last
call as soon as it re-appears.
Thanks,
Barb
At 01:36 PM 11/1/2002, Geoffrey Huang wrote:
>Hi Ed,
>
>The draft has expired, but I've attached a copy of it. I'd like to move the
>draft forward (wherever that might be), but the focus in the WG lately has
>been on IKEv2.
>
> > I have wondered around the working groups site and could not find the
> > draft-ietf-ipsec-dpd-00.txt any longer nor could I find any on going
> > conversations on the subject. Was this draft allowed to expire
> > without any
> > further discussions, or was another draft started.
> > I understand that some products do "dead peer detection" and was wondering
> > if this draft was how it was to be done or if the use of lower
> > re-key timer
>
>This is the method that Cisco devices use.
>
> > (say 600 seconds) in phase one would have the same effect, if one was to
> > delete the phase 2 sa's if the phase one negotiations failed.
>
>It depends on your implementation. If you always maintain a Phase 1 SA
>("Continuous Channel Mode") when there are Phase 2 SAs, then doing as you
>propose might be one solution. Keep in mind, however, that it won't scale
>well if you have to frequently rekey. Essentially, you'd be using a Phase 1
>negotiation to do the DPD; the difference is that DPD involves 2 notify
>messages (a "hello" and an ACK). Using a Phase 1 for DPD requires at least
>3 messages, plus a DH...Added to this is the concern that 600 seconds might
>be too coarse an interval before detecting a black hole.
>
>-g
>
> > Thanks
> > Ed Wilkinson
> >
--=====================_336000793==_.ALT
Content-Type: text/html; charset="us-ascii"
Hi,
Can you resubmit the draft to Internet Drafts and we will issue the last call as soon as it re-appears.
Thanks,
Barb
At 01:36 PM 11/1/2002, Geoffrey Huang wrote:
>Hi Ed,
>
>The draft has expired, but I've attached a copy of it. I'd like to move the
>draft forward (wherever that might be), but the focus in the WG lately has
>been on IKEv2.
>
>> I have wondered around the working groups site and could not find the
>> draft-ietf-ipsec-dpd-00.txt any longer nor could I find any on going
>> conversations on the subject. Was this draft allowed to expire
>> without any
>> further discussions, or was another draft started.
>> I understand that some products do "dead peer detection" and was wondering
>> if this draft was how it was to be done or if the use of lower
>> re-key timer
>
>This is the method that Cisco devices use.
>
>> (say 600 seconds) in phase one would have the same effect, if one was to
>> delete the phase 2 sa's if the phase one negotiations failed.
>
>It depends on your implementation. If you always maintain a Phase 1 SA
>("Continuous Channel Mode") when there are Phase 2 SAs, then doing as you
>propose might be one solution. Keep in mind, however, that it won't scale
>well if you have to frequently rekey. Essentially, you'd be using a Phase 1
>negotiation to do the DPD; the difference is that DPD involves 2 notify
>messages (a "hello" and an ACK). Using a Phase 1 for DPD requires at least
>3 messages, plus a DH...Added to this is the concern that 600 seconds might
>be too coarse an interval before detecting a black hole.
>
>-g
>
>> Thanks
>> Ed Wilkinson
>>
--=====================_336000793==_.ALT--
From owner-ipsec@lists.tislabs.com Tue Nov 12 11:34: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 gACJYog17299;
Tue, 12 Nov 2002 11:34:50 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15537
Tue, 12 Nov 2002 13:48:30 -0500 (EST)
Message-Id: <4.3.2.7.2.20021112093309.056d0008@mira-sjc5-4.cisco.com>
X-Sender: byfraser@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 12 Nov 2002 10:32:33 -0800
To: ipsec@lists.tislabs.com
From: Barbara Fraser <byfraser@cisco.com>
Subject: Fwd: Re: status of aes-cbc and sha-256 drafts?
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_336000753==_.ALT"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--=====================_336000753==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
I meant to cc the mailing list when I made this reply.
Barb
>Date: Sun, 29 Sep 2002 09:19:17 -0700
>To: "Scott G. Kelly" <scott@bstormnetworks.com>
>From: Barbara Fraser <byfraser@cisco.com>
>Subject: Re: status of aes-cbc and sha-256 drafts?
>Cc: tytso@mit.edu, Sheila Frankel <sheila.frankel@nist.gov>
>
>Hi,
>
>You're right about the CBC draft. It slipped between the cracks and Ted
>and I caught it later. It has been submitted for last call. The SHA256 doc
>is a different matter. We discussed it after the conversations in Yokohama
>and decided that we would not push it toward a standard from the wg. The
>discussions are archived and I have an action to send a note to the list
>(I'm late). If you feel we do really need to forward this as a standards
>track doc please let us know asap.
>
>Barb
>
>
>
>
>At 09:32 AM 9/20/2002, Scott G. Kelly wrote:
>>Hi Barb and Ted,
>>
>>At the Yokohama meeting, the aes cbc and sha drafts were listed as being
>>in wg last call, but I haven't seen this occur. What's the status of
>>these drafts?
>>
>>Thanks,
>>
>>Scott
--=====================_336000753==_.ALT
Content-Type: text/html; charset="us-ascii"
I meant to cc the mailing list when I made this reply.
Barb
>Date: Sun, 29 Sep 2002 09:19:17 -0700
>To: "Scott G. Kelly" <scott@bstormnetworks.com>
>From: Barbara Fraser <byfraser@cisco.com>
>Subject: Re: status of aes-cbc and sha-256 drafts?
>Cc: tytso@mit.edu, Sheila Frankel <sheila.frankel@nist.gov>
>
>Hi,
>
>You're right about the CBC draft. It slipped between the cracks and Ted and I caught it later. It has been submitted for last call. The SHA256 doc is a different matter. We discussed it after the conversations in Yokohama and decided that we would not push it toward a standard from the wg. The discussions are archived and I have an action to send a note to the list (I'm late). If you feel we do really need to forward this as a standards track doc please let us know asap.
>
>Barb
>
>
>
>
>At 09:32 AM 9/20/2002, Scott G. Kelly wrote:
>>Hi Barb and Ted,
>>
>>At the Yokohama meeting, the aes cbc and sha drafts were listed as being
>>in wg last call, but I haven't seen this occur. What's the status of
>>these drafts?
>>
>>Thanks,
>>
>>Scott
--=====================_336000753==_.ALT--
From owner-ipsec@lists.tislabs.com Tue Nov 12 12:24: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 gACKOCg20329;
Tue, 12 Nov 2002 12:24:12 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15745
Tue, 12 Nov 2002 14:46:51 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100313b9f702dfa49d@[128.89.88.34]>
In-Reply-To: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
Date: Tue, 12 Nov 2002 14:43:22 -0500
To: ipsec@lists.tislabs.com
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
As many of you know, I try to avoid the T-word (trust) in almost all
security technology discussions. I'd like to suggest that it is
inappropriate in this discussion as well. Let me explain:
- two IPsec peers do not necessarily trust one another. they
need to communicate securely, but that does not equate to trust in a
broader sense. the access controls in IPsec permit each peer to
limit the part of the address space to which the other is granted
access, and to constrain the protocols that are employed.
- with regard to identities, IPsec supports two basic types
of identities: addresses and symbolic names. IP addresses are easy to
understand and to use but don't work well for a growing number of
circumstances where addresses are assigned dynamically. Names are
also easy to understand, should be easier to manage, but require more
infrastructure support. the SPD accommodates use of symbolic names in
lieu of IP addresses to accommodate dynamic address assignment, or
just for ease of access control management.
- when names are used as identities, we need to be able to
map the name to a current address (during SA establishment) so that
we can make later decisions on a per-packet basis using the current
address. in this case, we verify that the named entity is at whatever
address is asserted by it in real time, and just use that address
going forward.
- we don't have to trust an IPsec peer to assert the right
name for itself or an entity behind it. we need to have an
authentication mechanism that allows us to verify that the asserted
name is valid relative to some framework for names. for example, two
organizations, a.com and b.com could each issue certs to their users
and embed the DNS names of user machine in the certs. (One could use
the DC convention to embed a DNS name in the Subject field, or use
dNSName type in the SubAltName extension.) I'd rather not say that
the CA for each organization is "trusted" by the other organization,
but rather that each organization acknowledges that the CA for the
other is authorized to name entities in its part of the DNS name
space. By using the NameConstraints extension in cross-certs, a.com
can make sure that certs issued by the CA for b.com (and validated by
users within a.com) all name entities under b.com, and not in a.com
or c.com etc. thus cross-certification is not a blanket statement of
trust, but just an acknowledgement that the CA for an organization is
authorized to issue certs for entities associated with that
organization.
I suggest that we better document these notions, and offer as
examples, the sort of identification and authentication processes I
note above as we go forward with IKE v2.
Comments?
Steve
From owner-ipsec@lists.tislabs.com Tue Nov 12 12: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 gACKttg21485;
Tue, 12 Nov 2002 12:55:55 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15874
Tue, 12 Nov 2002 15:22:37 -0500 (EST)
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: <15825.25361.887103.61323@ryijy.hel.fi.ssh.com>
Date: Tue, 12 Nov 2002 22:22:41 +0200
From: Tero Kivinen <kivinen@ssh.fi>
To: ipsec@lists.tislabs.com
CC: paul.hoffman@vpnc.org (Paul Hoffman / VPNC)
Subject: Re: Adding revised identities to IKEv2
References: <p05200f06b9edf48ac57b@[165.227.249.18]>
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 21 min
X-Total-Time: 21 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes:
> Greetings again. draft-ietf-ipsec-ikev2-03 adds some new functionality
> to IKEv2, but doesn't cover better use of identities and certificates.
> This idea got some support on the list a while ago, but it might have
> been hard for people to see how it would affect IKEv2. I propose the
> following changes to draft-ietf-ipsec-ikev2-03; do others agree?
The changes seems quite ok, but I think they are too complicated.
> PKIX certificate 1
> A standalone PKIX certificate.
> Certificate bundle 2
> A simple ASN.1 sequence of PKIX certificates. A bundle can have
> end-entity certificates and/or certificates from a chain to a
> root. The first certificate in the bundle is the sender's
> preferred identity certificate, but beyond that there is no
> meaning to the ordering.
Is there any need to have both? Isn't the PKIX certificate just
certificate bundle with one entry? Also I don't think simple ASN.1
sequence of PKIX certificate is good way to transmit bundles, better
use something like 16-bit length of certificate, certificate date,
16-bit length of certificate, certificate data.... (16-bits is enough
as the maximum payload length is 16-bits).
> Hash-and-URL of PKIX certificate 3
> The first 20 octets are the SHA-1 hash of a certificate; the
> rest is a URL that resolves to the certificate. This is
> described in more detail below.
> URL to a PKIX certificate bundle 4
> This is described in more detail below.
Same here, why both bundle and single certiicate. Also I would thing
instead of SHA-1 hash of the certificate it would be better to use
SHA-1 hash of the public key as used already in the trustedroot
payload. The other end doesn't really need a certificate it needs a
public key and it needs it to be trusted somehow. If used hash of the
public key, then the same method can be used to identify raw public
keys (with minimal asn.1 code to encode the public key to same format
used in pkix key identifier).
Also there might be multiple certificates for the same public key (old
certificate and new certificate) thus the url would return similar
bundle of certificates as in first section in all cases (i.e the first
certificate in the bundle would be the preferred identity
certificate).
> PKIX keyIdentifier 5
> Identifies a self-signed certificate that the receiver has
> already pre-loaded. Note that this is only useful when using
> self-signed certificates.
This would be redundant and better to use the keyidentifier + url
format above, but leave the url empty.
> For FullID types 3 and 4, the URL scheme must be "http", although it can
> be on any port number. The URL can be to a persistent repository, or it
> might be to the initiating machine (such as for a remote access client).
There should propably be note, here saying that if the initiator is
behind NAT then it cannot really use the url pointing to itself, as
the connection from the responder will not get through to the
initiator.
> If a system that is using certificates knows that it cannot resolve URLs
> (for example, because it is not yet on the Internet), it SHOULD use
> FullID types 1 and 2 in its IDAccepted payload. If a system can resolve
> URLs, it SHOULD use type 3 and 4 unless it is sure that it does not have
> the certificate of the other side, such as if it has just recovered from
> a crash and its cache is empty. All systems should be able to handle
> certificate bundles because the other party might have multiple
> identities which have different certificates.
With those modifications we would only have two different types of
FullID types for certificates, use type 1 if not connected to network
and type 2 if you are connected to network and can fetch urls.
One thing missing that was in the IKEv1 is the transfering of the
CRLs, but when considering the size of them it is better to leave them
out.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
From owner-ipsec@lists.tislabs.com Tue Nov 12 13:15: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 gACLFgg23049;
Tue, 12 Nov 2002 13:15:42 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15925
Tue, 12 Nov 2002 15:46:57 -0500 (EST)
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: <15825.26835.556407.251926@ryijy.hel.fi.ssh.com>
Date: Tue, 12 Nov 2002 22:47:15 +0200
From: Tero Kivinen <kivinen@ssh.fi>
To: <ipsec@lists.tislabs.com>
CC: andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk")
Subject: Re: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.txt
References: <004901c286a8$1824fc60$1e72788a@ca.alcatel.com>
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 3 min
X-Total-Time: 2 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk") writes:
> I'm sure that a whole bunch of us are wondering: what's with the unspecified
> vendor id?
> Does this mean that the current draft is going to be the last one and all
> further numbers will be assigned by IANA? (In that case, why would we need a
> vendor id at all?)
Yes, we do belive that this is the final version, as I wanted to
remove those XXX change later texts from the document, I replaced them
with proper numbers. Anyways I do not want anybody to implement
anything based on those numbers before we get this out as RFC I left
out the one piece i.e the vendor-ID.
We do need the vendor ID after we have the RFC too, as otherwise we
cannot detect if the other end supports the NAT-T at all (and sending
new payload numbers etc before getting information if the other end
supports them would be very good for interoperability).
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
From owner-ipsec@lists.tislabs.com Tue Nov 12 13:21: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 gACLLUg23887;
Tue, 12 Nov 2002 13:21:30 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15946
Tue, 12 Nov 2002 15:56:14 -0500 (EST)
From: chris stillson <stillson@stillson.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15825.27406.288047.386551@gargle.gargle.HOWL>
Date: Tue, 12 Nov 2002 12:56:46 -0800
To: ipsec@lists.tislabs.com
Subject: Connectathon 2003 announcement
X-Mailer: VM 7.07 under 21.1 (patch 3) "Acadia" XEmacs Lucid
X-Face: ;>?o+t66!z`OvpX.6T'j.4l4Gi+L*?8ZnU3L[G/^R,ELl3.Stln=12L+t|hsa*<{/D<{OS(
ybD%5<p1k'KWu~2`ggA_L%P.80xTxo5E[(Co7E2b{4tMN[z59GT8woI?%`|<N_#Hbbq=g?Czs;CGv
`KH(`'4?OWT.ENXkD6]nt=k)b9pb!Mx<0OJ!l&'SK_@/F]L3-KPn`RvR*Na'T;w;}uk2y`
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Yep, it's time again to start thinking abount connectathon. As the
coordinator for IPsec, I'm also interested in hearing what new
techologies people would be interested in testing for
interoperability. You can email me if you have any ideas.
Chris Stillson
Solaris IPsec
Official announcement follows:
Get ready for Connectathon 2003! The 17th annual interoperability
testing event for engineers only will be held Feb. 27-March 6, 2003 in
San Jose, California. For the past 2 years, Connectathon booth space
has sold out! Get your registration forms and fees in early and take
advantage of registration discounts available through December 31st.
Connectathon, sponsored by Sun Microsystems, Inc., hosts over 50
companies annually in an effort to test and debug source code which
utilize the following technologies and protocols:
NFS versions 2, 3 and 4
NFS over RDMA
NFSv4 replication and migration
Lock Manager
Kerberos
Automounter
IPv6
IPsec
NDMP
Mobile IPv6
Secure Shell
CIFS
Based on demand, in addition we are considering to offer:
Diameter/AAA
SCTP
LDAP
DHCPv6
If you are interested in testing any of the above 4 protocols, please
send a note to Cthon@sun.com and we'll gauge interest. Or if you have a
suggestion for another technology, feel free to contact us as well.
Testing continues 24 hours per day. Technology testing coordinators
will organize testing procedures and test suite material. In addition,
there will be seminars and speakers addressing various topics.
The registration deadline is February 7, 2003. But don't wait that
long! And Early Bird Discount on booth fees is available to those who
register and pay by December 31, 2002. For the past 2 years,
Connectathon has sold out of booth space. Please get your registration
materials in quickly to avoid disappointment. Go to
http://www.connectathon.org to download all forms and information.
If you have any questions, please feel free to contact Audrey Van
Belleghem at audrey@vanb.com or (408) 358-9598.
We look forward to seeing you at the 17th annual Connectathon event!
Audrey Van Belleghem
Connectathon Manager
From owner-ipsec@lists.tislabs.com Tue Nov 12 13:26: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 gACLQBg24679;
Tue, 12 Nov 2002 13:26:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15965
Tue, 12 Nov 2002 15:59:23 -0500 (EST)
Date: Tue, 12 Nov 2002 13:00:01 -0800 (PST)
From: Jan Vilhuber <vilhuber@cisco.com>
To: Valery Smyslov <svan@trustworks.com>
cc: <ipsec@lists.tislabs.com>, Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Authentication methods in IKEv2
In-Reply-To: <001201c28a1b$3870ecb0$640572d4@trustworks.com>
Message-ID: <Pine.LNX.4.33.0211121253250.15555-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Tue, 12 Nov 2002, Valery Smyslov wrote:
> ----- Original Message -----
> From: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
> To: "Valery Smyslov" <svan@trustworks.com>; <ipsec@lists.tislabs.com>
> Sent: Monday, November 11, 2002 8:28 PM
> Subject: Re: Authentication methods in IKEv2
>
>
> > At 11:45 AM +0300 11/11/02, Valery Smyslov wrote:
> > >I have some doubts about using of authentication methods in IKEv2.
> > >In IKEv2 negotiation of authentication methods was completely
> > >removed - each side simply uses his/her favourite method.
I think I'm missing something. I quoth section 5.3 from the -03 draft:
5.3 Security Association Payload
The Security Association Payload, denoted SA in this memo, is used
to negotiate attributes of a security association. An SA may
contain multiple proposals. Each proposal may propose multiple
protocols (where a protocol is IKE, ESP, AH, or IPcomp), along with
a suite of cryptographic algorithms to be used by the protocols.
So, in theory anyway, authentication methods need to be negotiated via
cipher-suites within the SA payload, and thus the AUTH payload is
well-defined by nature of the cipher-suite both agreed to (rather than
adding another 2 bytes of 'type' to the AUTH payload).
he cipher-suites not contain the authentication type?
I would argue that cipher-suites (if we decide to stick with them)
must contain information about the authentication used for phase1
(which may be another nail in the coffin for cipher-suites'
combinatorial explosion). In fact, I'd say the defined cipher-suites
are a bit light and more discussion is surely in order. Do we really
just need two?
If we want to support legacy authentication in IKEv2, we definitely
need to be able to tell the 'client' that she's supposed to do legacy
authentication (at least in my idea of how legacy authentication needs
to work). So authentication-parameters for phase 1 need to be part of
the SA payload in some way (as part of the cipher suite or as an extra
value somewhere or whatever).
jan
> > >I think this may lead to the lack of interoperability and extensibility
> > >in case one of the endpoints supports more than one method of
> > >authentication.
> >
> > Two endpoints that trust each other need to know *how* they trust
> > each other before setting up a secure channel. IKEv1 blurred this
> > rule by giving the option of saying how each side was going to
> > authenticate. IKEv2 tightens this up.
>
> I've been thinking that they trust each other because they both trust the
> same CA.
> But that CA may easily issue certificates of both types, RSA and DSS.
> Imagine the situation: security gateway serves as access point for
> two distinct groups of clients. One group of clients supports only RSA,
> while the other - only DSS. All clients have certificates issued by the same
> CA
> (of course, of different types). Gateway supports both RSA and DSS and
> trusts the same CA. Situation probably a bit weird, but not unrealistic.
>
> The question: how gateway would unambiguously determine in every particular
> case
> which of his certificates (RSA or DSS) to use (apart from heuristic
> methods)?
> By client's ID? Possible, but not scaleble - he must keep and
> maitain database of all client IDs. By client's certificate? Possible,
> but a bit heuristic and precludes asymmetric authentication,
> that could be useful sometimes (legacy authentication, for example).
>
> > >For example. Let's initiator support RSA and DSS and has certificates
> > >of the both types. Let's responder support only RSA. In this case,
> > >responder has no means in the protocol to explicitly indicate,
> > >that it will accept only RSA certificates.
> >
> > Exactly right. The two sides must know in advance why they trust each
> other.
> >
> > The worst-case scenario is that the responder tells the initiator "I
> > don't trust you", and the initiator tries again with a different
> > authentication mechanism.
>
> By the way, notification AUTHENTICATION-FAILED is missing
> in the document...
>
> > For the rare case where the two endpoints don't really know each
> > other *and* are going to trust each other *and* have multiple
> > authentication mechanisms, we have eliminated a confusing option from
> > IKEv1. That's exactly what IKEv2 was designed to do.
>
> The problem is that protocol seems to become less robust in that - it will
> sometimes fail when it may (and should) succeed. The problem is relatively
> easy
> to fix - let each party include a list of supported authentication
> mechanisms
> into his/her first message, so that the other side may choose among them.
>
> > --Paul Hoffman, Director
> > --VPN Consortium
>
> Regards,
> Valery Smyslov.
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
THE NETWORK WORKS,
NO EXCUS NFS server mastiff-fddi not responding still trying
From owner-ipsec@lists.tislabs.com Tue Nov 12 13:27: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 gACLRAg24725;
Tue, 12 Nov 2002 13:27:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15979
Tue, 12 Nov 2002 16:00:25 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: tytso@mit.edu
Cc: jis@mit.edu, ipsec@lists.tislabs.com, byfraser@cisco.com
Subject: Re: IPSEC MIB documents ready for IETF last call
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 12 Nov 2002 16:01:11 -0500
Message-Id: <20021112210111.2C84D7B68@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <E18Bf0d-0005vW-00@snap.thunk.org>, tytso@mit.edu writes:
>Hi Jeff, Steve,
>
>The following documents:
>
> draft-ietf-ipsec-doi-tc-mib-06.txt
> draft-ietf-ipsec-flow-monitoring-mib-02.txt
> draft-ietf-ipsec-ike-monitor-mib-04.txt
> draft-ietf-ipsec-isakmp-di-mon-mib-05.txt
> draft-ietf-ipsec-monitor-mib-06.txt
>
>Have been through wg last call and are ready for IETF last call. Could
>you please ask the secretariat to issue that last call and put them on
>the IESG queue? Many thanks!!
OK -- they've been added to draft-tracker as "publication requested".
We'll get to them soon.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
From owner-ipsec@lists.tislabs.com Tue Nov 12 13:33: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 gACLXAg24899;
Tue, 12 Nov 2002 13:33:10 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16013
Tue, 12 Nov 2002 16:07:41 -0500 (EST)
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: <15825.28089.77817.221412@ryijy.hel.fi.ssh.com>
Date: Tue, 12 Nov 2002 23:08:09 +0200
From: Tero Kivinen <kivinen@ssh.fi>
To: ipsec@lists.tislabs.com
Subject: Suites vs a-la-carte
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 9 min
X-Total-Time: 9 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I didn't receive any comments of my previous mail about this issue, I
think it was too long or something.
Anyways I think the IKEv2 has way too many dimensions to negotiate
for suite style negotiation. For IKE SA creation there is 5 different
dimensions, and some of them are open ended numbers. For IPsec SA we
have about 6 and then at least 2 new extensions.
We cannot realisticly encode all that informatin to one single number.
This means that we propably need to have some of those parameters
negotiated as a-la-carte style negotiation (Diffie-Hellman group,
window size, extension options in IPsec (extended sequence numbers,
ECN) etc). If we are going to add the a-la-carte negotiation then I
think it is better to everything in same way not to mix them, thus use
the a-la-carte completely.
We can have gui-suites for the commonly used parameters, but in that
case too we might want to include all information to those numbers
(like window size).
Just for the reminder here is the list of things we need to encode as
one single number in IKE SA:
1) authentication algorihtm
- rsa signatures, dsa signatures?, pre-shared keys?
2) encryption algorithm
- 3des, aes-128, aes-192?, aes-256?
3) hash/prf algorithm
- sha1, md5?, sha2-256?, sha2-384?, sha2-512?
4) Diffie-Hellman group
- group 2, group 5, ec-groups?, bigger (2048, 3096, 4096, 6144,
8192 bit) groups
5) Window size fof IKE
- 1, 10? ???
And for the IPsec SA there would be:
1) encryption algorithm for the ESP
- 3DES, AES, NULL
2) authentication algorithm for the ESP
- no auth, MD5, SHA
3) authentication algorithm for the AH
- no AH, MD5, SHA
4) IPComp algorithm
- Deflate, LZS?, OUI?
5) Diffie-Hellman group for PFS (if we do support PFS)
- group 2, group 5, ec-groups?, bigger (2048, 3072, 4096, 6144,
8192 bit) groups
6) Tunnel / transport / UDP-tunnel / UDP-transport
- Tunnel mode / transport mode and NAT-T udp encapsulations
7) Use of extended sequence numbers
- on/off
8) ECN
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
From owner-ipsec@lists.tislabs.com Tue Nov 12 14:20: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 gACMKAg27330;
Tue, 12 Nov 2002 14:20:10 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16198
Tue, 12 Nov 2002 16:42:44 -0500 (EST)
Date: 12 Nov 2002 16:22:21 -0500
Message-ID: <008b01c28a91$96b28c90$1e72788a@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: "'Tero Kivinen'" <kivinen@ssh.fi>, " 'ipsec'" <ipsec@lists.tislabs.com>
Subject: RE: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.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: <15825.26835.556407.251926@ryijy.hel.fi.ssh.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> We do need the vendor ID after we have the RFC too, as otherwise we
> cannot detect if the other end supports the NAT-T at all (and sending
> new payload numbers etc before getting information if the other end
> supports them would be very good for interoperability).
In other words, updating the minor version would be the appropriate
solution, but chances are this will break a whole bunch of implementations,
so keeping the vendor id will be simpler. I concur.
One more issue that I just noticed. When rekeying a phase 1 w/ NAT-T, you
automatically send packets to port 4500. Does this mean that we shouldn't
include the NAT-D payloads during the phase 1 rekey? What about the vendor
ids?
Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.
> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Tuesday, November 12, 2002 3:47 PM
> To: ipsec@lists.tislabs.com
> Cc: "Andrew Krywaniuk"
> Subject: Re: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.txt
>
>
> andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk") writes:
> > I'm sure that a whole bunch of us are wondering: what's
> with the unspecified
> > vendor id?
> > Does this mean that the current draft is going to be the
> last one and all
> > further numbers will be assigned by IANA? (In that case,
> why would we need a
> > vendor id at all?)
>
> Yes, we do belive that this is the final version, as I wanted to
> remove those XXX change later texts from the document, I replaced them
> with proper numbers. Anyways I do not want anybody to implement
> anything based on those numbers before we get this out as RFC I left
> out the one piece i.e the vendor-ID.
>
> We do need the vendor ID after we have the RFC too, as otherwise we
> cannot detect if the other end supports the NAT-T at all (and sending
> new payload numbers etc before getting information if the other end
> supports them would be very good for interoperability).
> --
> kivinen@ssh.fi
> SSH Communications Security http://www.ssh.fi/
> SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
>
From owner-ipsec@lists.tislabs.com Tue Nov 12 14:45: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 gACMjAg28455;
Tue, 12 Nov 2002 14:45:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16244
Tue, 12 Nov 2002 17:02:08 -0500 (EST)
Message-ID: <3DD17A5E.E2C8B38A@lucent.com>
Date: Tue, 12 Nov 2002 17:02:06 -0500
From: Uri Blumenthal <uri@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr> <p05100313b9f702dfa49d@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent wrote:
>
> As many of you know, I try to avoid the T-word (trust) in almost all
> security technology discussions. I'd like to suggest that it is
> inappropriate in this discussion as well.
Fully agree. Trust is about authorization, which is not IPsec's
domain (IMHO).
> - two IPsec peers do not necessarily trust one another. they
> need to communicate securely, but that does not equate to
> trust in a broader sense.
Agreed.
> - with regard to identities, IPsec supports two basic types
> of identities: addresses and symbolic names.
And symbolic names IMHO is the only way to establish/authenticate
a secure connection in a dynamic environment.
> - when names are used as identities, we need to be able to
> map the name to a current address (during SA establishment) so that
> we can make later decisions on a per-packet basis using the current
> address.
Absolutely. But start from symbolic names, and map them to IP address
for Phase 2. Seems easy/trivial to implement.
> - we don't have to trust an IPsec peer to assert the right
> name for itself or an entity behind it. we need to have an
> authentication mechanism that allows us to verify that the asserted
> name is valid relative to some framework for names.
Oh sure. If I say the entity name is "Uri Blumenthal" - then there
has to be a key/cert associated with that name. As it only matters
for signing the Phase 1 exchange to validate IP address from which
the traffic is originating, for subsequent Phase 2 things.
> I suggest that we better document these notions, and offer as
> examples, the sort of identification and authentication processes
> I note above as we go forward with IKE v2.
> Comments?
I strongly support.
And I want a relaxed identification - something like "as long as
I can associate a key with the identity, the identity is OK".
From owner-ipsec@lists.tislabs.com Tue Nov 12 15:03: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 gACN36g29092;
Tue, 12 Nov 2002 15:03:07 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16367
Tue, 12 Nov 2002 17:26:43 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100317b9f72ff63ca1@[128.89.88.34]>
In-Reply-To: <3DD17A5E.E2C8B38A@lucent.com>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]> <3DD17A5E.E2C8B38A@lucent.com>
Date: Tue, 12 Nov 2002 17:27:47 -0500
To: Uri Blumenthal <uri@lucent.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 5:02 PM -0500 11/12/02, Uri Blumenthal wrote:
>Stephen Kent wrote:
>>
>> As many of you know, I try to avoid the T-word (trust) in almost all
>> security technology discussions. I'd like to suggest that it is
>> inappropriate in this discussion as well.
>
>Fully agree. Trust is about authorization, which is not IPsec's
>domain (IMHO).
well, access control is an intrinsic feature of IPsec, so we may
disagree on that point. also, I don't believe that trust and
authorization are really linked as tightly as you suggest. the whole
notion of "trust management" that has arisen over the last few years
seems to be largely a function of a view that does not acknowledge
the existence of authoritative sources of authentication data. in the
physical world we have many such sources, and in cyberspace we have
several predominant ones, the DNS being the most common example.
>
><SNIP?
>
>And I want a relaxed identification - something like "as long as
>I can associate a key with the identity, the identity is OK".
are you looking for the SPKI WG mailing list?
I think it died along with the WG :-)
Steve
From owner-ipsec@lists.tislabs.com Tue Nov 12 15:15: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 gACNExg29515;
Tue, 12 Nov 2002 15:14:59 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16407
Tue, 12 Nov 2002 17:41:56 -0500 (EST)
Cc: ipsec@lists.tislabs.com
Message-ID: <3DD183E6.6B899050@lucent.com>
Date: Tue, 12 Nov 2002 17:42:46 -0500
From: Uri Blumenthal <uri@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
Original-CC: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]> <3DD17A5E.E2C8B38A@lucent.com> <p05100317b9f72ff63ca1@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent wrote:
> well, access control is an intrinsic feature of IPsec, so we may
> disagree on that point. also, I don't believe that trust and
> authorization are really linked as tightly as you suggest.
Well... There's not much of authorization or trust on IP level,
I think. So the issue is moot for IPsec. But on higher layers?
Say a request (not a packet!) comes from "John Doe". I
authenticated it and am certain it came form him. Now he
is requesting {put your favorite here - a $1M loan, a
peek through the company strategy document, a "format c:"
operation, whatever :-}.
Should the request be granted? How do I decide, based on what?
This is the authorization issue to me. I don't believe it
belongs to IP level.
> the whole
> notion of "trust management" that has arisen over the last few years
> seems to be largely a function of a view that does not acknowledge
> the existence of authoritative sources of authentication data. in the
> physical world we have many such sources, and in cyberspace we have
> several predominant ones, the DNS being the most common example.
I think it came from the desire to proceed from authentication to the
purpose for which the authentication was carried on: what do I do with
this request, now that I know the identity of its initiator?
And again to repeat myself - in IPsec the decision (probably) is very
trivial: if I recognized the key and authenticated the traffic, I can
allow it to enter my box, the rest is an application-level problem.
> are you looking for the SPKI WG mailing list?
>
> I think it died along with the WG :-)
SPKI? What's that? (:-)
But seriously, how do you identify a key on a borrowed laptop roaming
through a foreign domain? [not by IP address and probably not by FQDN]
From owner-ipsec@lists.tislabs.com Tue Nov 12 15:28: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 gACNS9g29897;
Tue, 12 Nov 2002 15:28:09 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16489
Tue, 12 Nov 2002 17:56:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100319b9f735e7a1f2@[128.89.88.34]>
In-Reply-To: <3DD183E6.6B899050@lucent.com>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]> <3DD17A5E.E2C8B38A@lucent.com>
<p05100317b9f72ff63ca1@[128.89.88.34]> <3DD183E6.6B899050@lucent.com>
Date: Tue, 12 Nov 2002 17:56:41 -0500
To: Uri Blumenthal <uri@lucent.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 5:42 PM -0500 11/12/02, Uri Blumenthal wrote:
>Stephen Kent wrote:
>> well, access control is an intrinsic feature of IPsec, so we may
>> disagree on that point. also, I don't believe that trust and
>> authorization are really linked as tightly as you suggest.
>
>Well... There's not much of authorization or trust on IP level,
>I think. So the issue is moot for IPsec. But on higher layers?
>
>Say a request (not a packet!) comes from "John Doe". I
>authenticated it and am certain it came form him. Now he
>is requesting {put your favorite here - a $1M loan, a
>peek through the company strategy document, a "format c:"
>operation, whatever :-}.
>
>Should the request be granted? How do I decide, based on what?
>This is the authorization issue to me. I don't believe it
>belongs to IP level.
In your example I agree that the authorization is an application
layer issues, not an IP layer issue.
>
>
>> the whole
>> notion of "trust management" that has arisen over the last few years
>> seems to be largely a function of a view that does not acknowledge
>> the existence of authoritative sources of authentication data. in the
>> physical world we have many such sources, and in cyberspace we have
>> several predominant ones, the DNS being the most common example.
>
>I think it came from the desire to proceed from authentication to the
>purpose for which the authentication was carried on: what do I do with
>this request, now that I know the identity of its initiator?
authorization does that, but the role of "trust" in authorization
seems questionable at this layer, which is the focus of this WG's
discussion.
>And again to repeat myself - in IPsec the decision (probably) is very
>trivial: if I recognized the key and authenticated the traffic, I can
>allow it to enter my box, the rest is an application-level problem.
I thik we generally agree here.
>
>> are you looking for the SPKI WG mailing list?
>>
>> I think it died along with the WG :-)
>
>SPKI? What's that? (:-)
>
>But seriously, how do you identify a key on a borrowed laptop roaming
>through a foreign domain? [not by IP address and probably not by FQDN]
First, I don't want to identify keys in most cases (I don't see them
as principals), and this would be one of them.
If I am responsible for access control for some resources, I want to
know who's requesting access, and for that I want a name or at least
an organizational affiliation. So, the issue here might be how the
user manages to assert his identity when he is using the borrowed
laptop, in a fashion that minimizes the risk to his secrets. (The
issue also might be whether I want to let the known, authorized user
into my environment given that he is using a borrowed laptop ...)
There are various ways to address the problem, depending on the
technology available to the user, whether the user was prepared to
employ a borrowed laptop, etc. Use of crypto tokens, one-time keys,
etc. all come to mind and all have limitations based on the
circumstances.
Of course, as a Mac user I rarely have this problem because I would
not want to borrow a PC laptop anyway :-)
Steve
From owner-ipsec@lists.tislabs.com Tue Nov 12 16:24: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 gAD0OTg03203;
Tue, 12 Nov 2002 16:24:29 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16724
Tue, 12 Nov 2002 18:57:22 -0500 (EST)
Message-ID: <3DD1954E.BB608E7E@bstormnetworks.com>
Date: Tue, 12 Nov 2002 15:57:02 -0800
From: "Scott G. Kelly" <scott@bstormnetworks.com>
Organization: BlackStorm Networks
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tero Kivinen <kivinen@ssh.fi>
CC: ipsec@lists.tislabs.com
Subject: Re: Suites vs a-la-carte
References: <15825.28089.77817.221412@ryijy.hel.fi.ssh.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I agree that suites seem overwhelming when considered from this
perspective. However, there is another way to look at this. Before going
into that, I should point out that we don't have to support every
esoteric combination anyone could dream up. If we provide numbers for
all mainstream combinations and then provide for vendor IDs and private
numbers, folks wanting unusual combinations can define them privately.
It's been my experience that most implementations don't make use of more
than a few combinations in practice.
Instead of thinking in terms of one number which encodes everything, we
could view it in terms of phase 1 suites and phase 2 general parameters
*and* suites. This does require support for a la carte selection of
phase 2 general parameters, but that doesn't look so horrible at first
glance (there aren't that many of them).
Phase 1 suites are composed of crypto-hash-auth-dhgroup. Phase 2 general
parameters include tunnel/transport/udp-tunnel/extended-seq/ecn (we can
deprecate key pfs, and negotiate new p1 instead). Phase 2 suites
comprise a bundle of one or more security protocols and their attrs. If
we deprecate AH, this reduces the space somewhat, but even if we don't,
it doesn't add all that much. Here's an example encoding:
Phase 1 suites: crypto-hash-auth-dhgroup
crypto
------
3DES
AES_CBC
AES_CTR
hash
-----
MD5
SHA1
auth
-----
RSA
PSK
(deprecate DSS, since nobody but redcreek ever admitted to implementing
it)
DHGROUP
------
2
5
(deprecate 1 since it's weak, ignore 3,4 since they are not widely used;
folks wanting private groups define vendor-ids and private suite
numbers)
Phase 1 Suites:
----------------
3DES-MD5-RSA-2
3DES-MD5-RSA-5
3DES-MD5-PSK-2
3DES-MD5-PSK-5
3DES-SHA1-RSA-2
3DES-SHA1-RSA-5
3DES-SHA1-PSK-2
3DES-SHA1-PSK-5
AES_CBC-MD5-RSA-2
AES_CBC-MD5-RSA-5
AES_CBC-MD5-PSK-2
AES_CBC-MD5-PSK-5
AES_CBC-SHA1-RSA-2
AES_CBC-SHA1-RSA-5
AES_CBC-SHA1-PSK-2
AES_CBC-SHA1-PSK-5
AES_CTR-MD5-RSA-2
AES_CTR-MD5-RSA-5
AES_CTR-MD5-PSK-2
AES_CTR-MD5-PSK-5
AES_CTR-SHA1-RSA-2
AES_CTR-SHA1-RSA-5
AES_CTR-SHA1-PSK-2
AES_CTR-SHA1-PSK-5
Phase 2 suites: [alg-1:params|alg-2:params...|alg-n:params]
general parms: tunnel/transport/udp-tunnel/extended-seq/ecn
(deprecate key pfs - negotiate new p1 instead)
Esp: crypto-integrity
E1: ESP-3DES-SHA1
E2: ESP-3DES-MD5
E3: ESP-AES_CBC-SHA1
E4: ESP-AES_CBC-MD5
E5: ESP-AES_CTR-SHA1
E6: ESP-AES_CTR-MD5
E7: ESP-NONE-SHA1
E8: ESP-NONE-MD5
(crypto with no integrity is not allowed)
AH: (deprecate)
IPCOMP: compress-alg
I1: DEFLATE
I2: OUI
I3: LZS
Suites definitions (alg combinations):
E1
E2
E3
E4
E5
E6
E1-I1
E2-I1
E3-I1
E4-I1
E5-I1
E6-I1
E1-I2
E2-I2
E3-I2
E4-I2
E5-I2
E6-I2
E1-I3
E2-I3
E3-I3
E4-I3
E5-I3
E6-I3
I1
I2
I3
I admit that listing and numbering these is somewhat tedious, but it's
certainly do-able, and doesn't explode combinatorially as long as we
don't go nuts and try to support everything.
Scott
Tero Kivinen wrote:
>
> I didn't receive any comments of my previous mail about this issue, I
> think it was too long or something.
>
> Anyways I think the IKEv2 has way too many dimensions to negotiate
> for suite style negotiation. For IKE SA creation there is 5 different
> dimensions, and some of them are open ended numbers. For IPsec SA we
> have about 6 and then at least 2 new extensions.
>
> We cannot realisticly encode all that informatin to one single number.
>
> This means that we propably need to have some of those parameters
> negotiated as a-la-carte style negotiation (Diffie-Hellman group,
> window size, extension options in IPsec (extended sequence numbers,
> ECN) etc). If we are going to add the a-la-carte negotiation then I
> think it is better to everything in same way not to mix them, thus use
> the a-la-carte completely.
>
> We can have gui-suites for the commonly used parameters, but in that
> case too we might want to include all information to those numbers
> (like window size).
>
> Just for the reminder here is the list of things we need to encode as
> one single number in IKE SA:
>
> 1) authentication algorihtm
> - rsa signatures, dsa signatures?, pre-shared keys?
> 2) encryption algorithm
> - 3des, aes-128, aes-192?, aes-256?
> 3) hash/prf algorithm
> - sha1, md5?, sha2-256?, sha2-384?, sha2-512?
> 4) Diffie-Hellman group
> - group 2, group 5, ec-groups?, bigger (2048, 3096, 4096, 6144,
> 8192 bit) groups
> 5) Window size fof IKE
> - 1, 10? ???
>
> And for the IPsec SA there would be:
>
> 1) encryption algorithm for the ESP
> - 3DES, AES, NULL
> 2) authentication algorithm for the ESP
> - no auth, MD5, SHA
> 3) authentication algorithm for the AH
> - no AH, MD5, SHA
> 4) IPComp algorithm
> - Deflate, LZS?, OUI?
> 5) Diffie-Hellman group for PFS (if we do support PFS)
> - group 2, group 5, ec-groups?, bigger (2048, 3072, 4096, 6144,
> 8192 bit) groups
> 6) Tunnel / transport / UDP-tunnel / UDP-transport
> - Tunnel mode / transport mode and NAT-T udp encapsulations
> 7) Use of extended sequence numbers
> - on/off
> 8) ECN
> --
> kivinen@ssh.fi
> SSH Communications Security http://www.ssh.fi/
> SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
From owner-ipsec@lists.tislabs.com Tue Nov 12 16:24: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 gAD0Omg03253;
Tue, 12 Nov 2002 16:24:48 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16752
Tue, 12 Nov 2002 19:00:23 -0500 (EST)
Cc: ipsec@lists.tislabs.com
Message-ID: <3DD1963A.4D09021E@lucent.com>
Date: Tue, 12 Nov 2002 19:00:58 -0500
From: Uri Blumenthal <uri@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
Original-CC: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]> <3DD17A5E.E2C8B38A@lucent.com>
<p05100317b9f72ff63ca1@[128.89.88.34]> <3DD183E6.6B899050@lucent.com> <p05100319b9f735e7a1f2@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent wrote:
> >......how do you identify a key................
>
> First, I don't want to identify keys in most cases (I don't see them
> as principals), and this would be one of them.
Touche (:-).
> If I am responsible for access control for some resources, I want to
> know who's requesting access, and for that I want a name or at least
> an organizational affiliation........Use of crypto tokens, one-time
> keys, etc. all come to mind and all have limitations...........
Sure. What I'm driving at - FQDN may not be applicable for
identifying the requestor. So a symbolic string with wider
semantic than FQDN should be allowed as an "identity tag"
on the key.
> (The issue also might be whether I want to let the known, authorized
> user into my environment given that he is using a borrowed laptop ...)
(:-) A totally different angle and issue.
> Of course, as a Mac user I rarely have this problem because I would
> not want to borrow a PC laptop anyway :-)
Ah, do you have to salt our wounds? (:-)
From owner-ipsec@lists.tislabs.com Tue Nov 12 16:38: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 gAD0cWg04030;
Tue, 12 Nov 2002 16:38:32 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16809
Tue, 12 Nov 2002 19:11:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0510031ab9f748bf0f79@[128.89.88.34]>
In-Reply-To: <3DD1963A.4D09021E@lucent.com>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]> <3DD17A5E.E2C8B38A@lucent.com>
<p05100317b9f72ff63ca1@[128.89.88.34]> <3DD183E6.6B899050@lucent.com>
<p05100319b9f735e7a1f2@[128.89.88.34]> <3DD1963A.4D09021E@lucent.com>
Date: Tue, 12 Nov 2002 19:11:58 -0500
To: Uri Blumenthal <uri@lucent.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 7:00 PM -0500 11/12/02, Uri Blumenthal wrote:
>Stephen Kent wrote:
>> >......how do you identify a key................
>>
>> First, I don't want to identify keys in most cases (I don't see them
>> as principals), and this would be one of them.
>
>Touche (:-).
>
>> If I am responsible for access control for some resources, I want to
>> know who's requesting access, and for that I want a name or at least
>> an organizational affiliation........Use of crypto tokens, one-time
>> keys, etc. all come to mind and all have limitations...........
>
>Sure. What I'm driving at - FQDN may not be applicable for
>identifying the requestor. So a symbolic string with wider
>semantic than FQDN should be allowed as an "identity tag"
>on the key.
I agree that an FQDN is not always the rigth answer, but in the
interest of interoperability and simplicity, I would like to define
what the allowed names forms are, since IKE must be prepared to deal
with them and the SPD interface must deal with them. I was assuming
we would have FQDNs, RFC822 addresses as user names, DNs, and IP
addresses. Anything else you think we should include?
Steve
From owner-ipsec@lists.tislabs.com Tue Nov 12 18:06: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 gAD26rg07088;
Tue, 12 Nov 2002 18:06:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA17085
Tue, 12 Nov 2002 20:26:20 -0500 (EST)
Message-Id: <200211130126.gAD1QcSq008561@kebe.east.sun.com>
Subject: Re: Suites vs a-la-carte
In-Reply-To: <15825.28089.77817.221412@ryijy.hel.fi.ssh.com> from Tero Kivinen
at "Nov 12, 2002 11:08:09 pm"
To: Tero Kivinen <kivinen@ssh.fi>
Date: Tue, 12 Nov 2002 20:26:38 -0500 (EST)
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
I violently agree with you, except for one small bit...
> And for the IPsec SA there would be:
>
> 1) encryption algorithm for the ESP
> - 3DES, AES, NULL
> 2) authentication algorithm for the ESP
> - no auth, MD5, SHA
> 3) authentication algorithm for the AH
> - no AH, MD5, SHA
> 4) IPComp algorithm
> - Deflate, LZS?, OUI?
> 5) Diffie-Hellman group for PFS (if we do support PFS)
> - group 2, group 5, ec-groups?, bigger (2048, 3072, 4096, 6144,
> 8192 bit) groups
> 6) Tunnel / transport / UDP-tunnel / UDP-transport
> - Tunnel mode / transport mode and NAT-T udp encapsulations
> 7) Use of extended sequence numbers
> - on/off
> 8) ECN
You forgot (or maybe it's implicit?):
9) Key size for algorithm(s).
I already support all three sizes of AES, and plan on letting people exploit
them.
Dan
From owner-ipsec@lists.tislabs.com Wed Nov 13 04:13: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 gADCDBg02337;
Wed, 13 Nov 2002 04:13:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18215
Wed, 13 Nov 2002 06:43:37 -0500 (EST)
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: <15826.15125.820584.312127@ryijy.hel.fi.ssh.com>
Date: Wed, 13 Nov 2002 13:44:21 +0200
From: Tero Kivinen <kivinen@ssh.fi>
To: andrew.krywaniuk@alcatel.com
Cc: " 'ipsec'" <ipsec@lists.tislabs.com>
Subject: RE: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.txt
In-Reply-To: <008b01c28a91$96b28c90$1e72788a@ca.alcatel.com>
References: <15825.26835.556407.251926@ryijy.hel.fi.ssh.com>
<008b01c28a91$96b28c90$1e72788a@ca.alcatel.com>
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 5 min
X-Total-Time: 6 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Andrew Krywaniuk writes:
> One more issue that I just noticed. When rekeying a phase 1 w/ NAT-T, you
> automatically send packets to port 4500. Does this mean that we shouldn't
> include the NAT-D payloads during the phase 1 rekey? What about the vendor
> ids?
The NAT-T protocol stuff does not change even if you start directly on
port 4500 (rekey or preconfiguration), i.e you send normal Vendor-ID,
NAT-D etc stuff and detect NAT normally. Only thing that is left out
is the changing of the port if NAT is detected.
There is also possibility that some clients start directly to port
4500 instead of 500 if they know that the other end support NAT-T (i.e
preconfigured). They will do that before they know if there is NAT
between. If the NAT is then detected they will use the UDP
encapsulation otherwise they will use normal IPsec transport / tunnel
mode.
----------------------------------------------------------------------
...
Similarly, if the responder needs to rekey the phase 1 SA, then he MUST
start the negotiation using UDP(4500,Y). Any implementation that
supports NAT traversal, MUST support negotiations that begin on port
4500. If a negotiation starts on 4500, then it doesn't need to change
anywhere else in the exchange.
...
--
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 Nov 13 05:53: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 gADDrOg08421;
Wed, 13 Nov 2002 05:53:24 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18393
Wed, 13 Nov 2002 08:24:28 -0500 (EST)
From: juha.ollila@nokia.com
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Subject: RE: I-D ACTION:draft-ietf-ipsec-sctp-04.txt
Date: Wed, 13 Nov 2002 15:24:43 +0200
Message-ID: <B49318639A71D3418DC1005FD40B3610E02952@ouebe005.ntc.nokia.com>
Thread-Topic: I-D ACTION:draft-ietf-ipsec-sctp-04.txt
Thread-Index: AcJ6neFf3yKtSPMXTReY+QYkDzAN0wQdj+VA
To: <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 13 Nov 2002 13:24:43.0736 (UTC) FILETIME=[0746ED80:01C28B18]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA18390
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi!
I'm sorry about the late response, but I have a couple of comments.
Usage of ID_LIST has not been defined explicitly:
Define a new type of ID, ID_LIST, that allows for recursive
inclusion of IDs. Thus, the IKE Phase 2 Initiator ID for an SCTP
association MAY be of type ID_LIST, which would in turn contain as
many ID_IPV4_ADDR IDs as necessary to describe Initiator addresses;
likewise for Responder IDs. Note that other selector types MAY be
used when establishing SAs for use with SCTP, if there is no need
to use negotiate multiple addresses for each SCTP endpoint (i.e.,
if only one address is used by each peer of an SCTP flow).
Implementations MUST support this new ID type.
I think that use of ID_LIST must be required if a SCTP endpoint uses
multiple addresses. This could be more explicit definition:
Implementations MUST support a new type of ID, ID_LIST, that allows
for recursive inclusion of IDs. The IKE Phase 2 Initiator ID for
an SCTP association MUST be of type ID_LIST, if there is need to
negotiate multiple addresses for each SCTP endpoint (i.e., if multiple
addresses are used by each peer of an SCTP flow). Note that other
selector types MAY be used when establishing SAs for use with SCTP,
if there is no need to use negotiate multiple addresses for each
SCTP endpoint. ID_LIST contains as many ID types (e.g. ID_IPV4_ADDR)
necessary to describe Initiator addresses; likewise for Responder
IDs.
I would like to ask about the required ID types. The draft specifies:
ID_LIST IDs cannot appear inside ID_LIST ID payloads. Any of the
ID types defined in [RFC2407] can be included inside an ID_LIST ID.
Each of the IDs contained in the ID_LIST ID must include a complete
Identification Payload header.
What are the required ID types? Is it necessary to support all or some
of the ID types, which are listed in [RFC2407]?
/Juha Ollila
From owner-ipsec@lists.tislabs.com Wed Nov 13 05:59: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 gADDxLg08966;
Wed, 13 Nov 2002 05:59:21 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18424
Wed, 13 Nov 2002 08:31:37 -0500 (EST)
Date: Tue, 12 Nov 2002 15:42:52 -0800
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ipsec@lists.tislabs.com
To: "Housley, Russ" <rhousley@rsasecurity.com>
From: Brian Korver <briank@xythos.com>
In-Reply-To: <5.1.0.14.2.20021110124741.020c4858@exna07.securitydynamics.com>
Message-Id: <75D21100-F698-11D6-A746-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-Envelope-To: ipsec@lists.tislabs.com,
rhousley@rsasecurity.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> In section 4.1.3.13, you say that no IPsec extended key usage values
> have been registered. This is incorrect. Three extended key usage
> values for use with IPsec have been registered. Do you propose to
> deprecate their use?
>
> id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
> id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
> id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
What spec do these appear in?
-brian
briank@xythos.com
From owner-ipsec@lists.tislabs.com Wed Nov 13 05:59: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 gADDxbg09011;
Wed, 13 Nov 2002 05:59:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18426
Wed, 13 Nov 2002 08:31:40 -0500 (EST)
Date: Tue, 12 Nov 2002 15:42:09 -0800
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ipsec@lists.tislabs.com
To: "Housley, Russ" <rhousley@rsasecurity.com>
From: Brian Korver <briank@xythos.com>
In-Reply-To: <5.1.0.14.2.20021110124741.020c4858@exna07.securitydynamics.com>
Message-Id: <5BD7E008-F698-11D6-A746-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-Envelope-To: ipsec@lists.tislabs.com,
rhousley@rsasecurity.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Russ,
Thanks for all the useful feedback. Comments below....
On Monday, November 11, 2002, at 09:25 AM, Housley, Russ wrote:
> Brian & Eric:
>
> Thanks for pushing this work forward. I think that it is important if
> we are ever going to achieve interoperability with certificate-based
> key management.
>
> In section 2, you define "Root CA". How is this different than "trust
> anchor" as defined in RFC 3280?
None, and perhaps--given the confusion over what "root" means--
it would be best to use the terminology from 3280.
>
> In section 3.2.2, please reword. It says: "When comparing the
> contents of ID with the dNSName field in the subjectAltName extension
> for equality, caseless string comparison is performed." I believe
> this sentence should contain a MUST. Also, section 3.2.3 contains the
> same sentence, and it should also contain a MUST.
No argument here.
>
> In section 3.2.4, says that address blocks are not supported as name
> forms. This is true, but some work in this area has been done in
> conjunction with SBGP. Please review the certificate extension
> identified by:
> id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
>
> In section 3.3.8.1, I suggest rewording that avoids the term "trusted
> root," which is not defined. Again, I suggest the term "trust anchor"
> as defined in RFC 3280.
>
> In sections 3.3.8.2 and 3.3.9.2, you should point out that RFC 3280
> prohibits certificates and CRLs with an empty issuer name field.
Ok.
>
> In section 3.3.9.1, it assumes that the party has ready access to the
> most recent CRLs, and any certificates needed to validate the CRLs.
> In a road warrior scenario, one of the peers is in a much better
> situation to obtain these than the other. Should this be discussed?
I thought that 3.4.9 "Using local keying materials" covered this base
by stating that if you've got better keymat around, use it. Perhaps
a pointer from 3.3.9.1 to 3.4.9 would be sufficient, or are you
suggesting something more would be good?
>
> Please adjust the example description in section 3.3.11.3. There is
> no requirement that a trust anchor be specified by a self-signed
> certificate. The peer should never be asked to provide a certificate
> associated with a trust anchor.
3.3.11.3 doesn't state that R is a self-signed certificate. I'm
also not sure that Trust Anchor is what most people will think of
when they think of certificates for which they have cached the
validity status. I see what you're saying, but I'm not sure
how best to say it.
>
> In section 3.4.2, should the list also include CRL signatures by CRL
> issuers?
Yes.
>
> Shouldn't 3.4.5 be parallel to 3.3.5? I expected it to recommend
> against the use of ARL.
Ok, I see where the text in 3.3.5 isn't clear. I meant to say that
you request CRLs, but you should be capable of receiving CRL and
ARL payloads back, although CRL is preferable as ARL doesn't
provide any real value over CRL. I'll make that clearer.
>
> In section 3.4.10.5, you say: "Implementations MUST be prepared to
> receive certificates and CRLs which are not relevant to the current
> exchange. Implementations MAY discard such keying materials." I agree,
> but I think that the last sentence potentially confusing. An
> implementation should disregard the extraneous certificates and CRLs,
> not the symmetric keying material that was generated.
>
> In section 4.1.1, I agree that v3 certificates should be required for
> end entity and CA certificates. However, the same code will likely be
> used for several purposes, and one of them is trust anchors.
> Self-signed v1 certificates are often used to establish trust anchors.
3280 mandates that BasicConstraints appear in CA certificates, but
doesn't appear to state that a self-signed trust anchor can
be treated differently. 3280 does state the following:
When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path.
However, without going back and examining the validation algorithm,
it's difficult to know what this means with regards to BC.
In the context of IPsec, do we see many v1 certificates used for this
purpose? I kinda thought that v1 certificates were a dying breed.
>
> In section 4.1.2.2.2, describing conventions for FQDN Host Names, I
> think that the SHOULD and MAY are backwards. When a DQDN is carried
> in the subject field of a certificate, the domainComponent attribute
> SHOULD be used. The commonName attribute MAY be used instead. I
> prefer dNSName in the SubjectAltName extension to both of these!
>
> In section 4.1.3, I do not understand the second paragraph on the
> criticality bit. Implementation MUST reject a certificate if it
> contains an extension that it does not know how to handle with the
> criticality bit set to TRUE.
Yes, that text is confusing, and has been rewritten a number
of unsatisfactory times. The point was that if you support
(and thus are going to process) a given extension, then it
isn't necessary to fail if the criticality bit is different
from what PKIX states it must be. If you don't support an
extension you MUST be critical if PKIX says it must, and
thus you must fail.
recognized
extension? bit in cert PKIX mandate what to do
YES TRUE TRUE ok
YES TRUE FALSE ok
YES FALSE TRUE ok
YES FALSE FALSE ok
NO TRUE TRUE fail
NO TRUE FALSE fail
NO FALSE TRUE fail
NO FALSE FALSE ok
When the bit in the cert matches the PKIX mandate, what
to do should be obvious. I don't recall to what extent
3280 addresses the others.
>
> In sections 4.1.3.1, 4.1.3.2, and 4.2.3.1, on the
> AuthorityKeyIdentifier (for certificates and CRLs) and
> SubjectKeyIdentifier extensions, please change "and thus should
> generate" to "and thus should not generate"
Doh!
>
> In section 4.1.3.3, I suggest that signature validation operations
> should proceed if either the nonRepudiation or the digitalSignature
> key usage bit is set in an end entity certificate. In my opinion,
> digitalSignature is preferred, but nonRepudiation should be allowed.
Uh oh, you don't really want to start another NR debate, do you? ;)
>
> In section 4.1.3.7.1.2, on the iPAddress subjectAltName, a disconnect
> between PKIX and IPsec is pointed out. You say what MUST NOT be done,
> but you do not say what ought to be done.
>
> Note that the CIDR [CIDR] notation permitted in the "Name Con-
> straints" section of PKIX is explicitly not permitted by that speci-
> fication for conveying identity information. In other words, the
> CIDR
> notation MUST NOT be used in the subjectAltName extension.
Actually, this text is supposed to underscore what PKIX states.
That is, PKIX prohibits CIDR notation in this context but allows CIDR
in some other context. The text here is attempting to keep
people from confusing those two contexts (given they both use
the name Name Constraints syntax). I'll put in better pointers
to see if that clears up the confusion.
>
> In section 4.1.3.10, more needs to be said. Microsoft has received a
> lot of criticism for treating certificates without the
> basicConstraints extension as a CA certificate. This section permits
> this behavior.
Right, this text was written before the Microsoft/SSL issue.
Updating this section might be a good idea.
>
> In section 4.1.3.13, you say that no IPsec extended key usage values
> have been registered. This is incorrect. Three extended key usage
> values for use with IPsec have been registered. Do you propose to
> deprecate their use?
>
> id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
> id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
> id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
>
> In section 4.1.3.16, you should state that most implementations do not
> support delta CRLs.
>
> In section 4.2.3.5, discussing IssuingDistributionPoint, you
> incorrectly discuss the uses of this extension in support of delta
> CRLs. When a CRL is not a "full CRL," this extension identifies the
> subset of information that is present. It also flags indirect CRLs.
> I believe that this profile should advocate support for "full CRLs,"
> and it should warn that many implementations do not support indirect
> CRLs.
Agreed.
>
> In section 6.1.2.1, I suggest that signature validation operations
> should proceed if either the nonRepudiation or the digitalSignature
> key usage bit is set in an end entity certificate. In my opinion,
> digitalSignature is preferred, but nonRepudiation should be allowed.
>
> In the References section. please add a reference for PKCS#10.
>
> Russ
>
-brian
briank@xythos.com
From owner-ipsec@lists.tislabs.com Wed Nov 13 06:00: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 gADE01g09093;
Wed, 13 Nov 2002 06:00:01 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18447
Wed, 13 Nov 2002 08:32:43 -0500 (EST)
X-Originating-IP: [63.99.114.2]
From: "Padmapriya Parthasarathy" <padmapriyap@hotmail.com>
To: uri@lucent.com
Cc: ipsec@lists.tislabs.com, padmapriyap@hotmail.com
Subject: Re: Adding revised identities to IKEv2
Date: Wed, 13 Nov 2002 01:43:14 +0000
Mime-Version: 1.0
Content-Type: text/html
Message-ID: <F25gzDgtZKpjE5aHaZV00000208@hotmail.com>
X-OriginalArrivalTime: 13 Nov 2002 01:43:14.0903 (UTC) FILETIME=[0860AE70:01C28AB6]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>
> > - with regard to identities, IPsec supports two basic types of
> > identities: addresses and symbolic names.
>
>And symbolic names IMHO is the only way to establish/authenticate a
>secure connection in a dynamic environment.
>
> > - when names are used as identities, we need to be able to map the
> > name to a current address (during SA establishment) so that we can
> > make later decisions on a per-packet basis using the current address.
>
>Absolutely. But start from symbolic names, and map them to IP address
>for Phase 2. Seems easy/trivial to implement.
Do we really do this mapping ? We either get separate ID payload in phase II or the ip headers implicitly carry the phase II identity. Do we ever try to validate this with the phase I identity e.g. mapping the FQDN in Phase I to the IP address in Phase II (or reverse lookup of IP address to phase I identity) or checking with the address in certificate with the one in Phase II.
thanks
priya
> > - we don't have to trust an IPsec peer to assert the right name for
> > itself or an entity behind it. we need to have an authentication
> > mechanism that allows us to verify that the asserted name is valid
> > relative to some framework for names.
>
>Oh sure. If I say the entity name is "Uri Blumenthal" - then there has
>to be a key/cert associated with that name. As it only matters for
>signing the Phase 1 exchange to validate IP address from which the
>traffic is originating, for subsequent Phase 2 things.
>
> > I suggest that we better document these notions, and offer as
> > examples, the sort of identification and authentication processes I
> > note above as we go forward with IKE v2. Comments?
>
>I strongly support.
>
>And I want a relaxed identification - something like "as long as
>I can associate a key with the identity, the identity is OK".
----------
MSN 8 helps <http://g.msn.com/8HMUEN/2023>ELIMINATE E-MAIL VIRUSES. Get 2 months FREE*.
From owner-ipsec@lists.tislabs.com Wed Nov 13 06:19: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 gADEJmg11460;
Wed, 13 Nov 2002 06:19:48 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18425
Wed, 13 Nov 2002 08:31:38 -0500 (EST)
Date: Tue, 12 Nov 2002 14:46:03 -0800
Subject: Re: I-D ACTION:draft-ietf-ipsec-pki-profile-01.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: <ipsec@lists.tislabs.com>
To: "Greg Carter" <greg@carter-engineering.com>
From: Brian Korver <briank@xythos.com>
In-Reply-To: <008a01c286a9$c9df3a00$1e02a8c0@entrust.com>
Message-Id: <860E0362-F690-11D6-9D3D-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-Envelope-To: ipsec@lists.tislabs.com,
greg@carter-engineering.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thursday, November 7, 2002, at 02:05 PM, Greg Carter wrote:
> Hi Brian,
> Looks good, some comments on the latest draft:
>
> 4.1.2.2.2. FQDN Host Names
>
> Although clear to me, you may want to explicitly state that placing
> the FQDN
> in the 'commonName' of the subject field does not mean that the
> commonName
> field will or should be searched for a matching ID when binding an ID
> to
> policy. The subject field of a certificate is treated as a whole when
> used
> for secure policy ID mapping. You could reference section "3.2.9.2.
> Identification Data other than a Single Address." Same for domain
> component. You could add that 'commonName' and 'domainComponet'
> should be
> treated as informational fields for an administrator, so that when the
> certificate is viewed at an administration console it can be
> associated with
> a particular piece of hardware, but it servers no other purpose on its
> own.
Agreed. I'll add this to the draft.
>
> 4.1.3.14. CRLDistributionPoint
>
> I would add:
> However receiving CRLs in band via ISAKMP does not alleviate the
> requirement
> to process the CRLDistributionPoint if the certificate being validated
> contains the extension and the CRL being used to validate the
> certificate
> contains the IssuingDistributionPoint. Failure to validate the
> CRLDistributionPoint/IssusingDistributionPoint pair can result in CRL
> substitution where an entity knowingly substitutes a known good CRL
> for the
> CRL which is supposed to be used which would show the entity as
> revoked.
> See below for more comments.
Ok.
>
> 4.2.3.5. IssuingDistributionPoint
> I think you are confusing Delta CRLs with CRLDistributionPoints.
I was thinking that CRLDistributionPoints was primarily a feature
of Delta CRLs, but there's no need for that to be the case.
Thanks for the clarification.
> IssuingDistributionPoints should be used to verify that the
> cRLDistributionPoint used to find the CRL (yes even those sent within
> IKE)
> is the correct CRL to use to verify the certificate.
>
> To clarify CRLDistributionPoints I'll give an example:
>
> A CA that is using CRLDistributionPoints may do so to provide may
> "small"
> CRLs; each only valid for a particular set of certificates issued by
> that
> CA. To associate a CRL with a certificate the CA places the
> CRLDistributionPoint extension in the certificate, and places the
> IssuingDistributionPoint in the CRL. The
> CRLDistributionPoint::DistributionPointName and the
> IssuingDistributionPoint::DistributionPointName fields would be the
> same.
> Lets assume that the CA has two CRLs, CRL1 and CRL2 which would be
> found at
>
> cn=CRL1, ou=CA, o=SomeCompany, c=US
> and
> cn=CRL2, ou=CA, o=SomeCompany, c=US
>
> CRL1 has an IssuingDistributionPoint with a value of "cn=CRL1, ou=CA,
> o=SomeCompany, c=US" and CRL2 has an IssuingDistributionPoint of
> "cn=CRL2,
> ou=CA, o=SomeCompany, c=US".
>
> The CA issues two certificates CERT1 and CERT2, it decides that CRL1
> will be
> the place to find revocation information for CERT1. When issuing
> CERT1 the
> CRLDistributionPoint extension is placed in the certificate with a
> value of
> cn=CRL1, ou=CA, o=SomeCompany, c=US. CERT2 is issued but the
> IssuingDistributionPoint for CRL2 is placed in the CRLDistributionPoint
> extension.
>
> Assuming a non IPSec environment: when an entity attempts to validate
> CERT1
> the entity would find the CRLDistributionPoint of cn=CRL1, ou=CA,
> o=SomeCompany, c=US in the certificate and fetch the CRL via LDAP from
> this
> address. Since LDAP is not trusted, when verifying the CRL the entity
> must
> verify that the CRL fetched from cn=CRL1, ou=CA, o=SomeCompany, c=US
> was in
> fact delegated to hold revocation information for the certificate being
> verified. To do this the IssuingDistributionPoint in the CRL is
> compared to
> CRLDistributionPoint in the certificate. Without this comparison it is
> possible to use the wrong CRL:
>
> Given that CERT1 is revoked, and that somehow the attacker has placed
> CRL2
> at cn=CRL1, ou=CA, o=SomeCompany, c=US in the LDAP directory. If when
> validating the CRL retrieved from cn=CRL1, ou=CA, o=SomeCompany, c=US
> (which
> is actually CRL2) the IssuingDistributionPoint is not compared to the
> desired CRLDistributionPoint, the CRL will validate (signed by the
> same CA),
> however CERT1 will not show up in the list of revoked certificates. So
> CERT1 would appear valid.
>
> How does this relate to IPSec and IKE? The only thing that is
> different is
> the delivery mechanism for the CRL, replace LDAP with IKE. The same
> attack
> is even easier since the peer will provide the CRLs to use to validate
> its
> certificate. Without the CDP/IDP check it is easy to substitute one
> CRL for
> another.
>
> CRLDistributionPoints are desirable for IPSec/IKE environments because
> it
> allows a subset of the revocation information to be passed to the peer.
> Instead of 400k-1M+ CRLs you can have many small CRLs. If it were up
> to me
> I might change the wording to encourage support of
> CRLDistributionPoints, at
> least on the validation end to prevent CRL substitution when the
> issuing CA
> is using them. I know of at least one CA that defaults to this type
> of CRL
> use. Of course see PKIX docs for CDP intellectual rights.
I'm starting to agree with you on this, especially on the validation
end.
>
> Out of curiosity what CAs have you found that use Delta CRLs?
I've never seen one. Has anyone on the list seen one in the context of
IPsec or otherwise?
-brian
briank@xythos.com
From owner-ipsec@lists.tislabs.com Wed Nov 13 07:25: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 gADFPHg16042;
Wed, 13 Nov 2002 07:25:17 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18722
Wed, 13 Nov 2002 09:44:08 -0500 (EST)
Message-Id: <5.1.1.6.0.20021113083709.02d57ad0@pophost.gte.com>
X-Sender: sjj0@pophost.gte.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Wed, 13 Nov 2002 08:44:56 -0500
To: ipsec@lists.tislabs.com
From: Stuart Jacobs <stu.jacobs@labs.gte.com>
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <p0510031ab9f748bf0f79@[128.89.88.34]>
References: <3DD1963A.4D09021E@lucent.com>
<200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]>
<3DD17A5E.E2C8B38A@lucent.com>
<p05100317b9f72ff63ca1@[128.89.88.34]>
<3DD183E6.6B899050@lucent.com>
<p05100319b9f735e7a1f2@[128.89.88.34]>
<3DD1963A.4D09021E@lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 11/12/02 07:11 PM, you wrote:
>At 7:00 PM -0500 11/12/02, Uri Blumenthal wrote:
>>Stephen Kent wrote:
>>> >......how do you identify a key................
>>>
>>> First, I don't want to identify keys in most cases (I don't see them
>>> as principals), and this would be one of them.
>>
>>Touche (:-).
>>
>>> If I am responsible for access control for some resources, I want to
>>> know who's requesting access, and for that I want a name or at least
>>> an organizational affiliation........Use of crypto tokens, one-time
>>> keys, etc. all come to mind and all have limitations...........
>>
>>Sure. What I'm driving at - FQDN may not be applicable for
>>identifying the requestor. So a symbolic string with wider
>>semantic than FQDN should be allowed as an "identity tag"
>>on the key.
>
>I agree that an FQDN is not always the rigth answer, but in the interest
>of interoperability and simplicity, I would like to define what the
>allowed names forms are, since IKE must be prepared to deal with them and
>the SPD interface must deal with them. I was assuming we would have
>FQDNs, RFC822 addresses as user names, DNs, and IP addresses. Anything
>else you think we should include?
I would suggest that we use Network Access Identifiers as per RFC 2486
>Steve
==========================
Stuart Jacobs CISSP
PMTS - Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128 USA
telephone: (781) 466-3076 fax: (781) 466-2838
stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com
==========================
From owner-ipsec@lists.tislabs.com Wed Nov 13 08:19: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 gADGJcg19432;
Wed, 13 Nov 2002 08:19:38 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18938
Wed, 13 Nov 2002 10:36:59 -0500 (EST)
Message-Id: <5.1.1.6.0.20021113101554.02d59c40@pophost.gte.com>
X-Sender: sjj0@pophost.gte.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Wed, 13 Nov 2002 10:16:35 -0500
To: ipsec@lists.tislabs.com
From: Stuart Jacobs <stu.jacobs@labs.gte.com>
Subject: Fwd: Re: Adding revised identities to IKEv2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>Date: Wed, 13 Nov 2002 10:07:22 -0500
>From: Uri Blumenthal <uri@lucent.com>
>Organization: Lucent Technologies
>X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U)
>X-Accept-Language: en,pdf
>To: Stuart Jacobs <stu.jacobs@labs.gte.com>
>Subject: Re: Adding revised identities to IKEv2
>
>Stuart,
>
>Your e-mail went only to me. So if you want it to
>be seen by the IPsec mailing list - you'd have to
>forward it there.
>
>Thanks!
>
>Stuart Jacobs wrote:
> >
> > I like what Uri is suggesting, namely:
> > "And I want a relaxed identification - something like "as long as
> > >I can associate a key with the identity, the identity is OK"."
> >
> > This approach could allow ESP protected packets to easily traverse NAT
> > since the Destination IP address in the responder's SA table is only used
> > as an address for sending packets back to the initiator and would be the
> > NAT public IP address and NAT assigned port number that the NAT will map
> > back to the actual private IP address of the recipient. What this would
> > necessitate is that during IKE, once the identity of the initiator is
> > authenticated, the source IP address and port number of the responder
> > received packet is stored and used when the responder wants to send a
> > packet to the initiator.
> >
> > At 11/12/02 05:02 PM, you wrote:
> > >Stephen Kent wrote:
> > > >
> > > > As many of you know, I try to avoid the T-word (trust) in almost all
> > > > security technology discussions. I'd like to suggest that it is
> > > > inappropriate in this discussion as well.
> > >
> > >Fully agree. Trust is about authorization, which is not IPsec's
> > >domain (IMHO).
> > >
> > > > - two IPsec peers do not necessarily trust one another. they
> > > > need to communicate securely, but that does not equate to
> > > > trust in a broader sense.
> > >
> > >Agreed.
> > >
> > > > - with regard to identities, IPsec supports two basic types
> > > > of identities: addresses and symbolic names.
> > >
> > >And symbolic names IMHO is the only way to establish/authenticate
> > >a secure connection in a dynamic environment.
> > >
> > > > - when names are used as identities, we need to be able to
> > > > map the name to a current address (during SA establishment) so that
> > > > we can make later decisions on a per-packet basis using the current
> > > > address.
> > >
> > >Absolutely. But start from symbolic names, and map them to IP address
> > >for Phase 2. Seems easy/trivial to implement.
> > >
> > > > - we don't have to trust an IPsec peer to assert the right
> > > > name for itself or an entity behind it. we need to have an
> > > > authentication mechanism that allows us to verify that the asserted
> > > > name is valid relative to some framework for names.
> > >
> > >Oh sure. If I say the entity name is "Uri Blumenthal" - then there
> > >has to be a key/cert associated with that name. As it only matters
> > >for signing the Phase 1 exchange to validate IP address from which
> > >the traffic is originating, for subsequent Phase 2 things.
> > >
> > > > I suggest that we better document these notions, and offer as
> > > > examples, the sort of identification and authentication processes
> > > > I note above as we go forward with IKE v2.
> > > > Comments?
> > >
> > >I strongly support.
> > >
> > >And I want a relaxed identification - something like "as long as
> > >I can associate a key with the identity, the identity is OK".
> >
> > ==========================
> > Stuart Jacobs CISSP
> > PMTS - Sr. Technologist
> > Verizon Laboratories
> > 40 Sylvan Road Waltham, MA 02451-1128 USA
> > telephone: (781) 466-3076 fax: (781) 466-2838
> > stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com
> > ==========================
==========================
Stuart Jacobs CISSP
PMTS - Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128 USA
telephone: (781) 466-3076 fax: (781) 466-2838
stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com
==========================
From owner-ipsec@lists.tislabs.com Wed Nov 13 09:16: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 gADHG1g22029;
Wed, 13 Nov 2002 09:16:01 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19128
Wed, 13 Nov 2002 11:40:43 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100303b9f83012108e@[128.89.88.34]>
In-Reply-To: <F25gzDgtZKpjE5aHaZV00000208@hotmail.com>
References: <F25gzDgtZKpjE5aHaZV00000208@hotmail.com>
Date: Wed, 13 Nov 2002 11:37:04 -0500
To: "Padmapriya Parthasarathy" <padmapriyap@hotmail.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> > > > - with regard to identities, IPsec supports two basic types
>of > > identities: addresses and symbolic names. > >And symbolic
>names IMHO is the only way to establish/authenticate a >secure
>connection in a dynamic environment. > > > - when names are used as
>identities, we need to be able to map the > > name to a current
>address (during SA establishment) so that we can > > make later
>decisions on a per-packet basis using the current
>address. > >Absolutely. But start from symbolic names, and map them
>to IP address >for Phase 2. Seems easy/trivial to implement. Do we
>really do this mapping ? We either get separate ID payload in phase
>II or the ip headers implicitly carry the phase II identity. Do we
>ever try to validate this with the phase I identity e.g. mapping the
>FQDN in Phase I to the IP address in Phase II (or reverse lookup of
>IP address to phase I identity) or checking with the address in
>certificate with the one in Phase II. thanks priya > > - we don't
>have to trust an IPsec peer to assert the right name for > > itself
>or an entity behind it. we need to have an authentication > >
>mechanism that allows us to verify that the asserted name is
>valid > > relative to some framework for names. > >Oh sure. If I say
>the entity name is "Uri Blumenthal" - then there has >to be a
>key/cert associated with that name. As it only matters for >signing
>the Phase 1 exchange to validate IP address from which the >traffic
>is originating, for subsequent Phase 2 things. > > > I suggest that
>we better document these notions, and offer as > > examples, the
>sort of identification and authentication processes I > > note above
>as we go forward with IKE v2. Comments? > >I strongly
>support. > >And I want a relaxed identification - something like "as
>long as >I can associate a key with the identity, the identity is
>OK". ---------- MSN 8 helps ELIMINATE E-MAIL VIRUSES. Get 2 months
>FREE*.
this message is essentially unreadable. please try again if you want
a response.
Steve
From owner-ipsec@lists.tislabs.com Wed Nov 13 09:18: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 gADHIXg22380;
Wed, 13 Nov 2002 09:18:33 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19129
Wed, 13 Nov 2002 11:40:44 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Brian Korver <briank@xythos.com>
Cc: ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021113111442.0343e4a0@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 13 Nov 2002 11:41:23 -0500
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
In-Reply-To: <5BD7E008-F698-11D6-A746-000393751598@xythos.com>
References: <5.1.0.14.2.20021110124741.020c4858@exna07.securitydynamics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Brian:
I dropped the sections where we have agreement.
>>In section 3.3.9.1, it assumes that the party has ready access to the
>>most recent CRLs, and any certificates needed to validate the CRLs.
>>In a road warrior scenario, one of the peers is in a much better
>>situation to obtain these than the other. Should this be discussed?
>
>I thought that 3.4.9 "Using local keying materials" covered this base
>by stating that if you've got better keymat around, use it. Perhaps
>a pointer from 3.3.9.1 to 3.4.9 would be sufficient, or are you
>suggesting something more would be good?
A forward pointer would be fine, if the referenced section id beefed
up. Here is my issue. Consider two peers with certificates from the same
CA. One is a laptop being used in a hotel room on a dial-up line. The
other is a server at the corporate HQ, and it has a multi-mega-bit
connection. Both devices should not fetch the most recent CRL from the
CA's repository just to send it along to the peer. The server should fetch
it, and pass it along to the laptop in the IPsec key management exchange.
>>Please adjust the example description in section 3.3.11.3. There is no
>>requirement that a trust anchor be specified by a self-signed
>>certificate. The peer should never be asked to provide a certificate
>>associated with a trust anchor.
>
>3.3.11.3 doesn't state that R is a self-signed certificate. I'm
>also not sure that Trust Anchor is what most people will think of
>when they think of certificates for which they have cached the
>validity status. I see what you're saying, but I'm not sure
>how best to say it.
The example should refer to an intermediate certificate (like CA1), not the
trust anchor (R).
>>In section 3.4.10.5, you say: "Implementations MUST be prepared to
>>receive certificates and CRLs which are not relevant to the current
>>exchange. Implementations MAY discard such keying materials." I agree,
>>but I think that the last sentence potentially confusing. An
>>implementation should disregard the extraneous certificates and CRLs, not
>>the symmetric keying material that was generated.
You did not respond to this comment.
>>In section 4.1.1, I agree that v3 certificates should be required for end
>>entity and CA certificates. However, the same code will likely be used
>>for several purposes, and one of them is trust anchors.
>>Self-signed v1 certificates are often used to establish trust anchors.
>
>3280 mandates that BasicConstraints appear in CA certificates, but
>doesn't appear to state that a self-signed trust anchor can
>be treated differently. 3280 does state the following:
>
> When the trust anchor is provided in the form of a self-signed
> certificate, this self-signed certificate is not included as part of
> the prospective certification path.
>
>However, without going back and examining the validation algorithm,
>it's difficult to know what this means with regards to BC.
>
>In the context of IPsec, do we see many v1 certificates used for this
>purpose? I kinda thought that v1 certificates were a dying breed.
Management of trust anchors is outside the scope of the validation
algorithm in RFC 3280. If self-signed certificates are used, the algorithm
will not validate them. They are not part of the certification path.
I would like to see v1 certificates go away too. I do not think it will
happen soon. For example, there are several v1 certificates built in to
Internet Explorer that will not expire until 2018. Others will not expire
until 2028. So, if the IPsec certificates chain to these trust anchors,
one can expect to encounter the situation that I raised.
>>In section 4.1.2.2.2, describing conventions for FQDN Host Names, I think
>>that the SHOULD and MAY are backwards. When a DQDN is carried in the
>>subject field of a certificate, the domainComponent attribute SHOULD be
>>used. The commonName attribute MAY be used instead. I prefer dNSName in
>>the SubjectAltName extension to both of these!
You did not comment on this one.
>>In section 4.1.3, I do not understand the second paragraph on the
>>criticality bit. Implementation MUST reject a certificate if it contains
>>an extension that it does not know how to handle with the criticality bit
>>set to TRUE.
>
>Yes, that text is confusing, and has been rewritten a number
>of unsatisfactory times. The point was that if you support
>(and thus are going to process) a given extension, then it
>isn't necessary to fail if the criticality bit is different
>from what PKIX states it must be. If you don't support an
>extension you MUST be critical if PKIX says it must, and
>thus you must fail.
>
> recognized
> extension? bit in cert PKIX mandate what to do
> YES TRUE TRUE ok
> YES TRUE FALSE ok
> YES FALSE TRUE ok
> YES FALSE FALSE ok
> NO TRUE TRUE fail
> NO TRUE FALSE fail
> NO FALSE TRUE fail
> NO FALSE FALSE ok
>
>When the bit in the cert matches the PKIX mandate, what
>to do should be obvious. I don't recall to what extent
>3280 addresses the others.
The truth table makes your intent clear. I suggest you use it in the document.
>>In section 4.1.3.3, I suggest that signature validation operations should
>>proceed if either the nonRepudiation or the digitalSignature key usage
>>bit is set in an end entity certificate. In my opinion, digitalSignature
>>is preferred, but nonRepudiation should be allowed.
>
>Uh oh, you don't really want to start another NR debate, do you? ;)
No, I do not want to start another NR debate. That is why I think that DS
and NR should both be accepted.
>>In section 4.1.3.13, you say that no IPsec extended key usage values have
>>been registered. This is incorrect. Three extended key usage values for
>>use with IPsec have been registered. Do you propose to deprecate their use?
>>
>> id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
>> id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
>> id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
No response to this comment?
>>In section 4.1.3.16, you should state that most implementations do not
>>support delta CRLs.
Do you agree?
>>In section 6.1.2.1, I suggest that signature validation operations should
>>proceed if either the nonRepudiation or the digitalSignature key usage
>>bit is set in an end entity certificate. In my opinion, digitalSignature
>>is preferred, but nonRepudiation should be allowed.
This is related to the NR vs DS discussion above.
Russ
From owner-ipsec@lists.tislabs.com Wed Nov 13 09:24: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 gADHOsg22649;
Wed, 13 Nov 2002 09:24:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19154
Wed, 13 Nov 2002 11:50:52 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Brian Korver <briank@xythos.com>
Cc: ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021113114325.03433cf0@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 13 Nov 2002 11:44:28 -0500
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
In-Reply-To: <75D21100-F698-11D6-A746-000393751598@xythos.com>
References: <5.1.0.14.2.20021110124741.020c4858@exna07.securitydynamics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Brian:
>>In section 4.1.3.13, you say that no IPsec extended key usage values have
>>been registered. This is incorrect. Three extended key usage values for
>>use with IPsec have been registered. Do you propose to deprecate their use?
>>
>> id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
>> id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
>> id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
>
>What spec do these appear in?
I do not know. I was asked to register them many years ago. If they are
not being used, we should mark them as obsolete in the registry.
Russ
From owner-ipsec@lists.tislabs.com Wed Nov 13 09:29: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 gADHTKg22936;
Wed, 13 Nov 2002 09:29:21 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19202
Wed, 13 Nov 2002 12:00:21 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100306b9f8341301a2@[128.89.88.34]>
In-Reply-To: <5.1.1.6.0.20021113083709.02d57ad0@pophost.gte.com>
References: <3DD1963A.4D09021E@lucent.com>
<200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]> <3DD17A5E.E2C8B38A@lucent.com>
<p05100317b9f72ff63ca1@[128.89.88.34]> <3DD183E6.6B899050@lucent.com>
<p05100319b9f735e7a1f2@[128.89.88.34]> <3DD1963A.4D09021E@lucent.com>
<5.1.1.6.0.20021113083709.02d57ad0@pophost.gte.com>
Date: Wed, 13 Nov 2002 11:56:58 -0500
To: Stuart Jacobs <stu.jacobs@labs.gte.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stu,
> <SNIP>
>I would suggest that we use Network Access Identifiers as per RFC 2486
>
As I understand it, an NAI is designed to identify a roaming user to
a service provider, not to a target system to which the user
connects. So, this would be an appropriate form of ID only when a
roaming user established an SA to the service provider as part of ???
I think I need to better understand the model in which IPsec is used
for what seems like an AAA problem.
Steve
From owner-ipsec@lists.tislabs.com Wed Nov 13 11:29: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 gADJTOg02583;
Wed, 13 Nov 2002 11:29:25 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19429
Wed, 13 Nov 2002 13:34:23 -0500 (EST)
Message-Id: <5.1.1.5.2.20021113103341.09814178@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Wed, 13 Nov 2002 10:34:44 -0800
To: ipsec@lists.tislabs.com
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <p05100303b9f83012108e@[128.89.88.34]>
References: <F25gzDgtZKpjE5aHaZV00000208@hotmail.com>
<F25gzDgtZKpjE5aHaZV00000208@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
It seems that this problem started right about the time that NAI moved to a
new location.
At 11:37 AM 11/13/2002 -0500, Stephen Kent wrote:
>> > > > - with regard to identities, IPsec supports two basic types
>> of > > identities: addresses and symbolic names. > >And symbolic names
>> IMHO is the only way to establish/authenticate a >secure connection in a
>> dynamic environment. > > > - when names are used as identities, we need
>> to be able to map the > > name to a current address (during SA
>> establishment) so that we can > > make later decisions on a per-packet
>> basis using the current address. > >Absolutely. But start from symbolic
>> names, and map them to IP address >for Phase 2. Seems easy/trivial to
>> implement. Do we really do this mapping ? We either get separate ID
>> payload in phase II or the ip headers implicitly carry the phase II
>> identity. Do we ever try to validate this with the phase I identity e.g.
>> mapping the FQDN in Phase I to the IP address in Phase II (or reverse
>> lookup of IP address to phase I identity) or checking with the address
>> in certificate with the one in Phase II. thanks priya > > - we don't
>> have to trust an IPsec peer to assert the right name for > > itself or
>> an entity behind it. we need to have an authentication > > mechanism
>> that allows us to verify that the asserted name is valid > > relative to
>> some framework for names. > >Oh sure. If I say the entity name is "Uri
>> Blumenthal" - then there has >to be a key/cert associated with that
>> name. As it only matters for >signing the Phase 1 exchange to validate
>> IP address from which the >traffic is originating, for subsequent Phase
>> 2 things. > > > I suggest that we better document these notions, and
>> offer as > > examples, the sort of identification and authentication
>> processes I > > note above as we go forward with IKE v2. Comments? > >I
>> strongly support. > >And I want a relaxed identification - something
>> like "as long as >I can associate a key with the identity, the identity
>> is OK". ---------- MSN 8 helps ELIMINATE E-MAIL VIRUSES. Get 2 months FREE*.
>
>this message is essentially unreadable. please try again if you want a
>response.
>
>Steve
From owner-ipsec@lists.tislabs.com Wed Nov 13 13:24: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 gADLOmg09621;
Wed, 13 Nov 2002 13:24:48 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19817
Wed, 13 Nov 2002 15:56:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f15b9f8358faca8@[165.227.249.18]>
In-Reply-To: <p05100313b9f702dfa49d@[128.89.88.34]>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Wed, 13 Nov 2002 09:13:01 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Adding revised identities to IKEv2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 2:43 PM -0500 11/12/02, Stephen Kent wrote:
>As many of you know, I try to avoid the T-word (trust) in almost all
>security technology discussions. I'd like to suggest that it is
>inappropriate in this discussion as well. Let me explain:
>
> - two IPsec peers do not necessarily trust one another. they
>need to communicate securely, but that does not equate to trust in a
>broader sense. the access controls in IPsec permit each peer to
>limit the part of the address space to which the other is granted
>access, and to constrain the protocols that are employed.
Assume you have someone who doesn't let most people communicate with
them in a particular way, but does let some people communicate with
them in that particular way after verifying their identity. You are
saying that that is not "trust"? If so, then we are splitting hairs.
"I authorize you to do X" means that I trust my method of being sure
that you are you, and that I trust you to do X correctly and safely.
>I suggest that we better document these notions, and offer as
>examples, the sort of identification and authentication processes I
>note above as we go forward with IKE v2.
It doesn't look like this any different than what we have in IKEv1
today: it just looks like different nomenclature. Unless this would
make IKEv2 more secure, or would make it easier for administrators to
understand what it is they are doing, it doesn't seem like changing
the nomenclature from IKEv1 would be a good idea.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Wed Nov 13 13:26: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 gADLQHg09651;
Wed, 13 Nov 2002 13:26:18 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19819
Wed, 13 Nov 2002 15:56:33 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15826.46957.751142.521870@thomasm-u1.cisco.com>
Date: Wed, 13 Nov 2002 12:34:53 -0800 (PST)
To: Uri Blumenthal <uri@lucent.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <3DD17A5E.E2C8B38A@lucent.com>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]>
<3DD17A5E.E2C8B38A@lucent.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
Uri Blumenthal writes:
> Stephen Kent wrote:
> >
> > As many of you know, I try to avoid the T-word (trust) in almost all
> > security technology discussions. I'd like to suggest that it is
> > inappropriate in this discussion as well.
>
> Fully agree. Trust is about authorization, which is not IPsec's
> domain (IMHO).
This statement really bothers me. Authorization is
clearly a part of IPsec. Just because I'm
authenticated should not a priori get
authorization for any filtering I desire on the
remote end. That seems like the heart of the IPsec
qua access control mechanism. We need a clean
separation both in IPsec and keying of those two
concepts.
That said, I'm pretty sympathetic to banishing the
T-word from the lexicon too.
Mike
From owner-ipsec@lists.tislabs.com Wed Nov 13 13:26: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 gADLQJg09660;
Wed, 13 Nov 2002 13:26:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19818
Wed, 13 Nov 2002 15:56:33 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f16b9f838ba6acf@[165.227.249.18]>
In-Reply-To: <15825.25361.887103.61323@ryijy.hel.fi.ssh.com>
References: <p05200f06b9edf48ac57b@[165.227.249.18]>
<15825.25361.887103.61323@ryijy.hel.fi.ssh.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Wed, 13 Nov 2002 09:29:09 -0800
To: Tero Kivinen <kivinen@ssh.fi>, ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Adding revised identities to IKEv2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:22 PM +0200 11/12/02, Tero Kivinen wrote:
>The changes seems quite ok, but I think they are too complicated.
Quite possibly true.
> > PKIX certificate 1
>> A standalone PKIX certificate.
>> Certificate bundle 2
>> A simple ASN.1 sequence of PKIX certificates. A bundle can have
>> end-entity certificates and/or certificates from a chain to a
>> root. The first certificate in the bundle is the sender's
>> preferred identity certificate, but beyond that there is no
>> meaning to the ordering.
>
>Is there any need to have both? Isn't the PKIX certificate just
>certificate bundle with one entry?
The reason I proposed two was that some gateways would only want the
certificate of the other party because they would do all the
additional validation themselves. If you just say "I want a cert
bundle", the other party will always need to send the whole chain.
> Also I don't think simple ASN.1
>sequence of PKIX certificate is good way to transmit bundles, better
>use something like 16-bit length of certificate, certificate date,
>16-bit length of certificate, certificate data.... (16-bits is enough
>as the maximum payload length is 16-bits).
Either format seems fine. Every time I propose wrapping ASN.1 objects
like PKIX certs in non-ASN.1 wrappers, I catch grief. Every time I
create a new ASN.1 structure, I catch grief.
> > Hash-and-URL of PKIX certificate 3
>> The first 20 octets are the SHA-1 hash of a certificate; the
>> rest is a URL that resolves to the certificate. This is
>> described in more detail below.
>> URL to a PKIX certificate bundle 4
>> This is described in more detail below.
>
>Same here, why both bundle and single certiicate.
Same as above.
> Also I would thing
>instead of SHA-1 hash of the certificate it would be better to use
>SHA-1 hash of the public key as used already in the trustedroot
>payload. The other end doesn't really need a certificate it needs a
>public key and it needs it to be trusted somehow. If used hash of the
>public key, then the same method can be used to identify raw public
>keys (with minimal asn.1 code to encode the public key to same format
>used in pkix key identifier).
Probably disagree. If I have two certs for the same public key that
lead to different trust anchors, you wouldn't be able to tell which I
was proposing to you. By using just the public key, you are forcing
the receiving party to search all paths for certs that match the
public key.
Having just said that, I admit that this is an edge case and that it
isn't that onerous.
>Also there might be multiple certificates for the same public key (old
>certificate and new certificate) thus the url would return similar
>bundle of certificates as in first section in all cases (i.e the first
>certificate in the bundle would be the preferred identity
>certificate).
Good point.
> > PKIX keyIdentifier 5
>> Identifies a self-signed certificate that the receiver has
>> already pre-loaded. Note that this is only useful when using
>> self-signed certificates.
>
>This would be redundant and better to use the keyidentifier + url
>format above, but leave the url empty.
Good idea!
> > For FullID types 3 and 4, the URL scheme must be "http", although it can
>> be on any port number. The URL can be to a persistent repository, or it
>> might be to the initiating machine (such as for a remote access client).
>
>There should propably be note, here saying that if the initiator is
>behind NAT then it cannot really use the url pointing to itself, as
>the connection from the responder will not get through to the
>initiator.
Yup.
> > If a system that is using certificates knows that it cannot resolve URLs
>> (for example, because it is not yet on the Internet), it SHOULD use
>> FullID types 1 and 2 in its IDAccepted payload. If a system can resolve
> > URLs, it SHOULD use type 3 and 4 unless it is sure that it does not have
>> the certificate of the other side, such as if it has just recovered from
>> a crash and its cache is empty. All systems should be able to handle
>> certificate bundles because the other party might have multiple
>> identities which have different certificates.
>
>With those modifications we would only have two different types of
>FullID types for certificates, use type 1 if not connected to network
>and type 2 if you are connected to network and can fetch urls.
Yes, if we make all the requests for bundles.
>One thing missing that was in the IKEv1 is the transfering of the
>CRLs, but when considering the size of them it is better to leave them
>out.
Exactly.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Wed Nov 13 13:26: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 gADLQbg09678;
Wed, 13 Nov 2002 13:26:38 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19814
Wed, 13 Nov 2002 15:56:29 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f13b9f83202d7bc@[165.227.249.18]>
In-Reply-To: <3DD1954E.BB608E7E@bstormnetworks.com>
References: <15825.28089.77817.221412@ryijy.hel.fi.ssh.com>
<3DD1954E.BB608E7E@bstormnetworks.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Wed, 13 Nov 2002 08:51:42 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Suites vs a-la-carte
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 3:57 PM -0800 11/12/02, Scott G. Kelly wrote:
>I agree that suites seem overwhelming when considered from this
>perspective. However, there is another way to look at this. Before going
>into that, I should point out that we don't have to support every
>esoteric combination anyone could dream up. If we provide numbers for
>all mainstream combinations and then provide for vendor IDs and private
>numbers, folks wanting unusual combinations can define them privately.
>It's been my experience that most implementations don't make use of more
>than a few combinations in practice.
IKEv2 should be simpler for the implementer so that we feel better
about its security. Just as important to the VPN industry, however,
is that IKEv2 be simpler for the gateway administrator. Few
adminstrators need to know the difference between Phase 1 and Phase
2; in fact, given that the first child-SA is now negotiated in Phase
1, we will be hard-pressed to clearly explain why the difference
matters at all.
>Instead of thinking in terms of one number which encodes everything, we
>could view it in terms of phase 1 suites and phase 2 general parameters
>*and* suites.
This doesn't sound simpler. :-)
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Wed Nov 13 13:27: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 gADLRbg09696;
Wed, 13 Nov 2002 13:27:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19809
Wed, 13 Nov 2002 15:56:29 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f12b9f82fcd533a@[165.227.249.18]>
In-Reply-To: <15825.28089.77817.221412@ryijy.hel.fi.ssh.com>
References: <15825.28089.77817.221412@ryijy.hel.fi.ssh.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Wed, 13 Nov 2002 08:43:53 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Suites vs a-la-carte
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 11:08 PM +0200 11/12/02, Tero Kivinen wrote:
>I didn't receive any comments of my previous mail about this issue, I
>think it was too long or something.
>
>Anyways I think the IKEv2 has way too many dimensions to negotiate
>for suite style negotiation. For IKE SA creation there is 5 different
>dimensions, and some of them are open ended numbers. For IPsec SA we
>have about 6 and then at least 2 new extensions.
>
>We cannot realisticly encode all that informatin to one single number.
Sure we can; we just can't agree to the limited number of numbers
that we would encode. That is, we can easily say "If you see suite
#1, it means phase 1 {rsa signature of at least 1024 bits, aes-128,
sha1, d-h group 2, IKE window size of 5} and phase 2 { aes-128, sha
auth, no ah, no compression, pfs using d-h group 2, tunnel with
NAT-T, extended sequence numbers, ECN}". The hard question is how
many more numbers do we need to allocate to key all IPsec scenarios
using IKEv2.
>This means that we propably need to have some of those parameters
>negotiated as a-la-carte style negotiation (Diffie-Hellman group,
>window size, extension options in IPsec (extended sequence numbers,
>ECN) etc). If we are going to add the a-la-carte negotiation then I
>think it is better to everything in same way not to mix them, thus use
>the a-la-carte completely.
Agree.
>We can have gui-suites for the commonly used parameters, but in that
>case too we might want to include all information to those numbers
>(like window size).
Agree. The GUI-suites would only be a short-hand for common
scenarios, and we could probably come to agreement on a set of five
or so.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Wed Nov 13 13:55: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 gADLtKg10065;
Wed, 13 Nov 2002 13:55:20 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19938
Wed, 13 Nov 2002 16:29:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100315b9f871e2872d@[128.89.88.34]>
In-Reply-To: <p05200f15b9f8358faca8@[165.227.249.18]>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]>
<p05200f15b9f8358faca8@[165.227.249.18]>
Date: Wed, 13 Nov 2002 16:25:46 -0500
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 9:13 AM -0800 11/13/02, Paul Hoffman / VPNC wrote:
>At 2:43 PM -0500 11/12/02, Stephen Kent wrote:
>>As many of you know, I try to avoid the T-word (trust) in almost
>>all security technology discussions. I'd like to suggest that it is
>>inappropriate in this discussion as well. Let me explain:
>>
>> - two IPsec peers do not necessarily trust one another. they
>>need to communicate securely, but that does not equate to trust in
>>a broader sense. the access controls in IPsec permit each peer to
>>limit the part of the address space to which the other is granted
>>access, and to constrain the protocols that are employed.
>
>Assume you have someone who doesn't let most people communicate with
>them in a particular way, but does let some people communicate with
>them in that particular way after verifying their identity. You are
>saying that that is not "trust"? If so, then we are splitting hairs.
>"I authorize you to do X" means that I trust my method of being sure
>that you are you, and that I trust you to do X correctly and safely.
In your example, I rely on my enforcement mechanisms to allow you to
access only what we agree you should access. You could call that
trusting my enforcement mechanisms, but that's not the way the term
"trust" is usually employed here.
The term trust might be better applied to the second aspect of your
example, but again we are much better off from a security
perspective if we put in place mechanisms to constrain the damage
that can be done by the entity who is authorized to "do X." I think
that is how we tend to engineer many systems, although with varying
degrees of success. A security administrator does not trust all the
folks authorized to access a system to do the right thing; he uses
all available mechanisms to constrain their behavior as well as
possible, just in case they don't do the right thing.
>>I suggest that we better document these notions, and offer as
>>examples, the sort of identification and authentication processes I
>>note above as we go forward with IKE v2.
>
>It doesn't look like this any different than what we have in IKEv1
>today: it just looks like different nomenclature. Unless this would
>make IKEv2 more secure, or would make it easier for administrators
>to understand what it is they are doing, it doesn't seem like
>changing the nomenclature from IKEv1 would be a good idea.
I don't recall the extent to which the T-word is used in existing IKE
v1 documents, and I don't mean to suggest changes of terms just for
the hell of it, but as we go forward creating new documents,
including ones that try to better explain how to deal with IKE v1 and
PKI, I'd suggest we avoid undue use of "trust."
Steve
From owner-ipsec@lists.tislabs.com Wed Nov 13 14:25: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 gADMPAg11422;
Wed, 13 Nov 2002 14:25:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20039
Wed, 13 Nov 2002 16:45:24 -0500 (EST)
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: <15826.51228.546106.342625@ryijy.hel.fi.ssh.com>
Date: Wed, 13 Nov 2002 23:46:04 +0200
From: Tero Kivinen <kivinen@ssh.fi>
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <p05200f16b9f838ba6acf@[165.227.249.18]>
References: <p05200f06b9edf48ac57b@[165.227.249.18]>
<15825.25361.887103.61323@ryijy.hel.fi.ssh.com>
<p05200f16b9f838ba6acf@[165.227.249.18]>
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 10 min
X-Total-Time: 10 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul Hoffman / VPNC writes:
> >> Certificate bundle 2
> >> A simple ASN.1 sequence of PKIX certificates. A bundle can have
> >> end-entity certificates and/or certificates from a chain to a
> >> root. The first certificate in the bundle is the sender's
> >> preferred identity certificate, but beyond that there is no
> >> meaning to the ordering.
> The reason I proposed two was that some gateways would only want the
> certificate of the other party because they would do all the
> additional validation themselves. If you just say "I want a cert
> bundle", the other party will always need to send the whole chain.
True. Actually I think bundle should be defined not to include the
root, so in normal case bundle and single cert will be same.
Also I think the SGW will always be using the url version, as it can
find, load and cache all those certificates quite easily.
> Either format seems fine. Every time I propose wrapping ASN.1 objects
> like PKIX certs in non-ASN.1 wrappers, I catch grief. Every time I
> create a new ASN.1 structure, I catch grief.
I was just worried about creating new ASN.1 structure, and I think
creating non-ASN.1 wrapper is easier for most of the people (i.e if
the encoding is some standard ASN.1 encoding (pkcs7) then it is easier
to just give that whole stuff to certificate manager library, but if
you need to manually parse that ASN.1 before giving the certificates
to the certificate manager library then it is easier to use non ASN.1
encoding).
> Probably disagree. If I have two certs for the same public key that
> lead to different trust anchors, you wouldn't be able to tell which I
> was proposing to you.
And what difference does it make? You are going to use the public key
to verify my signature and it really doesn't matter which certificate
you used.
> By using just the public key, you are forcing the receiving party to
> search all paths for certs that match the public key.
It needs to do the same thing anyway. It needs to find the path from
the certificate to the some trusted root, and it doesn't really matter
if it does that based on the public key instead of certificate.
--
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 Nov 13 15:54: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 gADNsKg15623;
Wed, 13 Nov 2002 15:54:20 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20350
Wed, 13 Nov 2002 18:25:32 -0500 (EST)
Date: 13 Nov 2002 18:05:00 -0500
Message-ID: <00b501c28b69$185c14f0$1e72788a@ca.alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
Reply-To: andrew.krywaniuk@alcatel.com
To: "'Paul Hoffman / VPNC'" <paul.hoffman@vpnc.org>,
" 'ipsec'" <ipsec@lists.tislabs.com>
Subject: RE: Suites vs a-la-carte
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: <p05200f12b9f82fcd533a@[165.227.249.18]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Sure we can; we just can't agree to the limited number of numbers
> that we would encode.
I agree with this. One of the reasons I have endorsed GUI suites all along
is that I felt we would be much more likely to get consensus on the base
suites if it were easy to create your own private suites.
Let's say that some company (let's call them IPsecCorp) decides they don't
like the default suite and they want to roll their own. Of course they still
have the mandatory to implement suite, but the default configuration uses
the suite "IPsecCorp2002". If IPsecCorp is the market leader then everyone
is going to want to be compatible with them out of the box. In the
configuration GUI, they will want a droplist of suites where one of the
options is IPsecCorp2002.
If IPsecCorp2002 is using a private ciphersuite number, I would have to go
and figure out what this number is. Then I would probably also have to spoof
their vendor id, which might have unintended consequences. Alternatively, we
could try to create an IANA registry for private ciphersuites. But IANA
would probably deny this request (if I'm not mistaken, they denied a similar
request from the TLS WG). If this was a GUI ciphersuite then there would be
no problem.
Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC
> Sent: Wednesday, November 13, 2002 11:44 AM
> To: ipsec@lists.tislabs.com
> Subject: Re: Suites vs a-la-carte
>
>
> At 11:08 PM +0200 11/12/02, Tero Kivinen wrote:
> >I didn't receive any comments of my previous mail about this issue, I
> >think it was too long or something.
> >
> >Anyways I think the IKEv2 has way too many dimensions to negotiate
> >for suite style negotiation. For IKE SA creation there is 5 different
> >dimensions, and some of them are open ended numbers. For IPsec SA we
> >have about 6 and then at least 2 new extensions.
> >
> >We cannot realisticly encode all that informatin to one
> single number.
>
> Sure we can; we just can't agree to the limited number of numbers
> that we would encode. That is, we can easily say "If you see suite
> #1, it means phase 1 {rsa signature of at least 1024 bits, aes-128,
> sha1, d-h group 2, IKE window size of 5} and phase 2 { aes-128, sha
> auth, no ah, no compression, pfs using d-h group 2, tunnel with
> NAT-T, extended sequence numbers, ECN}". The hard question is how
> many more numbers do we need to allocate to key all IPsec scenarios
> using IKEv2.
>
> >This means that we propably need to have some of those parameters
> >negotiated as a-la-carte style negotiation (Diffie-Hellman group,
> >window size, extension options in IPsec (extended sequence numbers,
> >ECN) etc). If we are going to add the a-la-carte negotiation then I
> >think it is better to everything in same way not to mix
> them, thus use
> >the a-la-carte completely.
>
> Agree.
>
> >We can have gui-suites for the commonly used parameters, but in that
> >case too we might want to include all information to those numbers
> >(like window size).
>
> Agree. The GUI-suites would only be a short-hand for common
> scenarios, and we could probably come to agreement on a set of five
> or so.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
From owner-ipsec@lists.tislabs.com Wed Nov 13 16:07: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 gAE076g16009;
Wed, 13 Nov 2002 16:07:07 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20425
Wed, 13 Nov 2002 18:44:05 -0500 (EST)
Message-ID: <3DD2E3CB.852202CA@bstormnetworks.com>
Date: Wed, 13 Nov 2002 15:44:11 -0800
From: "Scott G. Kelly" <scott@bstormnetworks.com>
Organization: BlackStorm Networks
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Re: Suites vs a-la-carte
References: <15825.28089.77817.221412@ryijy.hel.fi.ssh.com>
<3DD1954E.BB608E7E@bstormnetworks.com> <p05200f13b9f83202d7bc@[165.227.249.18]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Nov 2002 23:44:11.0568 (UTC) FILETIME=[91080300:01C28B6E]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul Hoffman / VPNC wrote:
> IKEv2 should be simpler for the implementer so that we feel better
> about its security. Just as important to the VPN industry, however,
> is that IKEv2 be simpler for the gateway administrator. Few
> adminstrators need to know the difference between Phase 1 and Phase
> 2; in fact, given that the first child-SA is now negotiated in Phase
> 1, we will be hard-pressed to clearly explain why the difference
> matters at all.
>
> >Instead of thinking in terms of one number which encodes everything, we
> >could view it in terms of phase 1 suites and phase 2 general parameters
> >*and* suites.
>
> This doesn't sound simpler. :-)
>
Yes, I agree, but I don't know if there's anything we can do to make it
*really* simple. I agree that compressing phase 1 and 2 algs into one
number seems to make it simpler, but then Tero's argument surfaces - how
many combinations is that? And no matter what, there are other
parameters that are somewhat open-ended, as Tero noted.
I originally thought suites were the answer, but now I'm thinking that
*the* answer doesn't exist. On the other hand, this needs resolution.
Maybe Tero is right, and the best choice is to support a la carte
selection. If we reduce the number of supported algs to a minimum, maybe
that's the best we can do.
Scott
From owner-ipsec@lists.tislabs.com Wed Nov 13 18:06: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 gAE26qg20738;
Wed, 13 Nov 2002 18:06:52 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20691
Wed, 13 Nov 2002 20:35:22 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15826.59111.187888.42022@thomasm-u1.cisco.com>
Date: Wed, 13 Nov 2002 15:57:27 -0800 (PST)
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <p05200f15b9f8358faca8@[165.227.249.18]>
References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr>
<p05100313b9f702dfa49d@[128.89.88.34]>
<p05200f15b9f8358faca8@[165.227.249.18]>
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 Hoffman / VPNC writes:
> At 2:43 PM -0500 11/12/02, Stephen Kent wrote:
> > - two IPsec peers do not necessarily trust one another. they
> >need to communicate securely, but that does not equate to trust in a
> >broader sense. the access controls in IPsec permit each peer to
> >limit the part of the address space to which the other is granted
> >access, and to constrain the protocols that are employed.
>
> Assume you have someone who doesn't let most people communicate with
> them in a particular way, but does let some people communicate with
> them in that particular way after verifying their identity. You are
> saying that that is not "trust"? If so, then we are splitting hairs.
> "I authorize you to do X" means that I trust my method of being sure
> that you are you, and that I trust you to do X correctly and safely.
Paul,
I think the point here is that "trust" doesn't
really bring much to the table in terms of
understanding what's going on, and has a good
potential for muddying the waters. It's a machine
making machine decisions based on its
programming. It doesn't "trust", it makes
decisions based upon cryptographically provable
identity and programmed policy. It's certainly not
making any value judgements like "correctly" or
"safely".
Mike
From owner-ipsec@lists.tislabs.com Wed Nov 13 20:11: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 gAE4Bhg27000;
Wed, 13 Nov 2002 20:11:43 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20953
Wed, 13 Nov 2002 22:46:36 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f1eb9f882e32827@[165.227.249.18]>
In-Reply-To:
<5.1.0.14.2.20021113114325.03433cf0@exna07.securitydynamics.com>
References:
<5.1.0.14.2.20021110124741.020c4858@exna07.securitydynamics.com>
<5.1.0.14.2.20021113114325.03433cf0@exna07.securitydynamics.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Wed, 13 Nov 2002 17:30:55 -0500
To: "Housley, Russ" <rhousley@rsasecurity.com>,
Brian Korver <briank@xythos.com>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 11:44 AM -0500 11/13/02, Housley, Russ wrote:
>Brian:
>
>>>In section 4.1.3.13, you say that no IPsec extended key usage
>>>values have been registered. This is incorrect. Three extended
>>>key usage values for use with IPsec have been registered. Do you
>>>propose to deprecate their use?
>>>
>>> id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
>>> id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
>>> id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
>>
>>What spec do these appear in?
>
>I do not know. I was asked to register them many years ago. If
>they are not being used, we should mark them as obsolete in the
>registry.
I *think* they first appeared in the now-dead IPsec PKI document of
which I became an editor in later days. I have been told that some
implementations use them.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Thu Nov 14 03:47: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 gAEBlHg24516;
Thu, 14 Nov 2002 03:47:17 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA21860
Thu, 14 Nov 2002 06:16:33 -0500 (EST)
Subject: RFC2407: ID Payload Field ("DOI Specific ID Data")
From: venkat <venkat@dexceldesigns.com>
To: IPSec Mail Group <ipsec@lists.tislabs.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Date: 14 Nov 2002 16:55:08 +0530
Message-Id: <1037273110.3226.44.camel@venkat>
Mime-Version: 1.0
X-Mailserver: Sent using PostMaster (v4.1.13)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all,
IKE -> Identification Payload
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! DOI Specific ID Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
What is this "DOI Specific ID Data" used for, and why is it 24 bits in
size, could anyone tell me what exactly has to be filled here, and where
can I find this information.
RFC 2401 to 2412, none of these provide details about this, is there any
proper documentation on this topic, or have I not read the RFC's
properly.
Thanks in advance
- Venkat
--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
From owner-ipsec@lists.tislabs.com Thu Nov 14 07:35: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 gAEFZ2g11648;
Thu, 14 Nov 2002 07:35:03 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22522
Thu, 14 Nov 2002 10:05:58 -0500 (EST)
To: ipsec@lists.tislabs.com
cc: agenda@ietf.org
Subject: IPSEC-WG agenda for IETF 55 (Atlanta)
From: tytso@mit.edu
Message-Id: <E18CLZU-0006Lj-00@snap.thunk.org>
Date: Thu, 14 Nov 2002 10:06:20 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
IPSEC WG agenda:
Date: Monday, November 18, 2002
Time: 1930-2200 (7:30pm -- 10:00pm)
Room: Salon B
* Status of I-D's
* Hugo Krawczyk - cryptographic rationale of the signature modes of IKE and
the current cyptographic exchange in ikev2 (announcement of results)
* Brian Korver - Update of PKI Profile I-D
* Tomoaki KOBAYAKAWA - IPv6 and IPsec deployment issues
* Brian Weis - RSA digital signatures on ESP and AH for authentication.
* Charlie Kaufman - Son-of-IKE
----
If anyone else would like time on the IPSEC agenda, please send e-mail
to tytso@mit.edu and bfraser@cisco.com.
From owner-ipsec@lists.tislabs.com Thu Nov 14 07:52: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 gAEFqBg12574;
Thu, 14 Nov 2002 07:52:12 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22658
Thu, 14 Nov 2002 10:26:48 -0500 (EST)
From: Black_David@emc.com
Message-ID: <277DD60FB639D511AC0400B0D068B71E0814BA54@CORPMX14>
To: kivinen@ssh.fi, ipsec@lists.tislabs.com
Subject: RE: Suites vs a-la-carte
Date: Thu, 14 Nov 2002 10:27:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
And Tero thought he'd listed everything ... not quite - add
9) DSCP (DiffServ Code Point) handling at tunnel egress (discard
outer vs. copy outer-to-inner).
Explanation and rationale should be coming in a
rfc2401bis draft at some point. I agree with Tero that
a single number to encode everything won't work, but would
like to see combination of related options into a singly
negotiable elements in order to exclude incompatible or
otherwise ridiculous combinations and simplify the
resulting negotiation. This should also provide the
desired resistance to "vanity crypto".
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786
black_david@emc.com Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Tuesday, November 12, 2002 4:08 PM
> To: ipsec@lists.tislabs.com
> Subject: Suites vs a-la-carte
>
>
> I didn't receive any comments of my previous mail about this issue, I
> think it was too long or something.
>
> Anyways I think the IKEv2 has way too many dimensions to negotiate
> for suite style negotiation. For IKE SA creation there is 5 different
> dimensions, and some of them are open ended numbers. For IPsec SA we
> have about 6 and then at least 2 new extensions.
>
> We cannot realisticly encode all that informatin to one single number.
>
> This means that we propably need to have some of those parameters
> negotiated as a-la-carte style negotiation (Diffie-Hellman group,
> window size, extension options in IPsec (extended sequence numbers,
> ECN) etc). If we are going to add the a-la-carte negotiation then I
> think it is better to everything in same way not to mix them, thus use
> the a-la-carte completely.
>
> We can have gui-suites for the commonly used parameters, but in that
> case too we might want to include all information to those numbers
> (like window size).
>
> Just for the reminder here is the list of things we need to encode as
> one single number in IKE SA:
>
> 1) authentication algorihtm
> - rsa signatures, dsa signatures?, pre-shared keys?
> 2) encryption algorithm
> - 3des, aes-128, aes-192?, aes-256?
> 3) hash/prf algorithm
> - sha1, md5?, sha2-256?, sha2-384?, sha2-512?
> 4) Diffie-Hellman group
> - group 2, group 5, ec-groups?, bigger (2048, 3096, 4096, 6144,
> 8192 bit) groups
> 5) Window size fof IKE
> - 1, 10? ???
>
> And for the IPsec SA there would be:
>
> 1) encryption algorithm for the ESP
> - 3DES, AES, NULL
> 2) authentication algorithm for the ESP
> - no auth, MD5, SHA
> 3) authentication algorithm for the AH
> - no AH, MD5, SHA
> 4) IPComp algorithm
> - Deflate, LZS?, OUI?
> 5) Diffie-Hellman group for PFS (if we do support PFS)
> - group 2, group 5, ec-groups?, bigger (2048, 3072, 4096, 6144,
> 8192 bit) groups
> 6) Tunnel / transport / UDP-tunnel / UDP-transport
> - Tunnel mode / transport mode and NAT-T udp encapsulations
> 7) Use of extended sequence numbers
> - on/off
> 8) ECN
> --
> 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 Nov 14 08:17: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 gAEGHWg15699;
Thu, 14 Nov 2002 08:17:32 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22818
Thu, 14 Nov 2002 10:48:18 -0500 (EST)
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: <15827.50651.419222.213487@ryijy.hel.fi.ssh.com>
Date: Thu, 14 Nov 2002 17:48:43 +0200
From: Tero Kivinen <kivinen@ssh.fi>
To: Black_David@emc.com
Cc: ipsec@lists.tislabs.com
Subject: RE: Suites vs a-la-carte
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0814BA54@CORPMX14>
References: <277DD60FB639D511AC0400B0D068B71E0814BA54@CORPMX14>
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 2 min
X-Total-Time: 1 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Black_David@emc.com writes:
> rfc2401bis draft at some point. I agree with Tero that
> a single number to encode everything won't work, but would
> like to see combination of related options into a singly
> negotiable elements in order to exclude incompatible or
> otherwise ridiculous combinations and simplify the
> resulting negotiation. This should also provide the
> desired resistance to "vanity crypto".
I.e add complexity of both suites and a-la-carte... I think only
a-la-carte is better...
--
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 Nov 14 12:37: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 gAEKbBg02051;
Thu, 14 Nov 2002 12:37:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23404
Thu, 14 Nov 2002 14:54:15 -0500 (EST)
From: "Max Pritikin" <pritikin@cisco.com>
To: "Tero Kivinen" <kivinen@ssh.fi>,
"Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Adding revised identities to IKEv2
Date: Thu, 14 Nov 2002 11:52:58 -0800
Message-ID: <PKEBJBKKGOBHIJBBAGLEMELPEPAA.pritikin@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: <15826.51228.546106.342625@ryijy.hel.fi.ssh.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
From: owner-ipsec@lists.tislabs.com <>
> Subject: Re: Adding revised identities to IKEv2
>
>
> Paul Hoffman / VPNC writes:
>>>> Certificate bundle 2
>>>> A simple ASN.1 sequence of PKIX certificates. A bundle
>>>> can have end-entity certificates and/or certificates
>>>> from a chain to a root. The first certificate in the
>>>> bundle is the sender's preferred identity certificate,
>>>> but beyond that there is no meaning to the ordering.
>> The reason I proposed two was that some gateways would only want the
>> certificate of the other party because they would do all the
>> additional validation themselves. If you just say "I want a cert
>> bundle", the other party will always need to send the whole chain.
>
> True. Actually I think bundle should be defined not to include the
> root, so in normal case bundle and single cert will be same.
>
> Also I think the SGW will always be using the url version, as it can
> find, load and cache all those certificates quite easily.
>
>> Either format seems fine. Every time I propose wrapping ASN.1 objects
>> like PKIX certs in non-ASN.1 wrappers, I catch grief. Every time I
>> create a new ASN.1 structure, I catch grief.
>
> I was just worried about creating new ASN.1 structure, and I think
> creating non-ASN.1 wrapper is easier for most of the people (i.e if
> the encoding is some standard ASN.1 encoding (pkcs7) then it is easier
> to just give that whole stuff to certificate manager library, but if
> you need to manually parse that ASN.1 before giving the certificates
> to the certificate manager library then it is easier to use non ASN.1
> encoding).
>
>> Probably disagree. If I have two certs for the same public key that
>> lead to different trust anchors, you wouldn't be able to tell which I
>> was proposing to you.
>
> And what difference does it make? You are going to use the public key
> to verify my signature and it really doesn't matter which certificate
> you used.
Your previous statement,
>>> The other end doesn't really need a certificate it needs a public key
and it needs it to be trusted somehow.
^^^^^^^
is the difference. The particular certificate matters because the 'somehow'
is to use the binding and identifying information in the certificate to
determine the appropriate policy.
- max
>> By using just the public key, you are forcing the receiving party to
>> search all paths for certs that match the public key.
>
> It needs to do the same thing anyway. It needs to find the path from
> the certificate to the some trusted root, and it doesn't really matter
> if it does that based on the public key instead of certificate. --
> 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 Nov 14 21:21:39 2002
Received: from lists.tislabs.com ([192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id gAF5Lcg29516;
Thu, 14 Nov 2002 21:21:39 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24374
Thu, 14 Nov 2002 23:49:16 -0500 (EST)
Reply-To: <awank@future.futsoft.com>
From: "Awan Kumar Sharma" <awank@future.futsoft.com>
To: "'venkat'" <venkat@dexceldesigns.com>,
"'IPSec Mail Group'" <ipsec@lists.tislabs.com>
Subject: RE: RFC2407: ID Payload Field ("DOI Specific ID Data")
Date: Fri, 15 Nov 2002 10:02:18 +0530
Message-Id: <000201c28c5f$fc1c73a0$0702060a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <1037273110.3226.44.camel@venkat>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Venkat,
The DOI specific data is specified in section 4.6.2 of RFC 2407.
Regards,
Awan
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of venkat
> Sent: Thursday, November 14, 2002 4:55 PM
> To: IPSec Mail Group
> Subject: RFC2407: ID Payload Field ("DOI Specific ID Data")
>
>
> Hi all,
> IKE -> Identification Payload
>
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ! ID Type ! DOI Specific ID Data !
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> What is this "DOI Specific ID Data" used for, and why is it 24 bits in
> size, could anyone tell me what exactly has to be filled
> here, and where
> can I find this information.
>
> RFC 2401 to 2412, none of these provide details about this,
> is there any
> proper documentation on this topic, or have I not read the RFC's
> properly.
>
> Thanks in advance
> - Venkat
>
>
> --------------------------------------------------------------
> Dexcel Electronics Designs (P) Ltd., Bangalore, India
>
>
***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.
If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
From owner-ipsec@lists.tislabs.com Thu Nov 14 22:00: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 gAF60Qg00903;
Thu, 14 Nov 2002 22:00:26 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA24471
Fri, 15 Nov 2002 00:38:29 -0500 (EST)
Subject: Cookie Generation Logic
From: venkat <venkat@dexceldesigns.com>
To: IPSec Mail Group <ipsec@lists.tislabs.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Date: 15 Nov 2002 11:03:20 +0530
Message-Id: <1037338400.1010.55.camel@venkat>
Mime-Version: 1.0
X-Mailserver: Sent using PostMaster (v4.1.13)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all,
Someone please help me out with the cookie implementation
I create a cookie using the following logic
FAST_HASH(
IP Source Address,
IP Destination Address,
Source Port,
Destination Port,
My Local Secret
);
I thought my implementation was good enough for a cookie until someone
told me, to look into the FreeSWAN's Pluto Code which says
if ( it is a initiator cookie )
get_64_random_bits();
if ( it is a responder cookie )
FASH_HASH( ip_addr, local_secret );
I don't get it, why is the initiator cookie only 64 random bits and
responder cookie the actual 64 bit logic. To my understanding, initiator
cookie is created by the initiator and the responder cookie by
responder. What is the responder cookie creation doing at the initiator
end and vice-versa.
Thanks in Advance
- Venkat
--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
From owner-ipsec@lists.tislabs.com Thu Nov 14 23:24: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 gAF7Oig09642;
Thu, 14 Nov 2002 23:24:45 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA24641
Fri, 15 Nov 2002 01:59:56 -0500 (EST)
Message-Id: <5.1.0.14.0.20021115120149.023d1ec0@172.16.1.10>
X-Sender: lokeshnb@172.16.1.10
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Nov 2002 12:28:05 +0530
To: ipsec@lists.tislabs.com
From: Lokesh <lokeshnb@intotoinc.com>
Subject: padding in ESP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all
One questions each on ESP and AH protocols:
1] why do we need to adjust ESP packet size by padding to be aligned to 4
byte boundary in case of
null encryption? can we bypass padding for null encryption?
2] AH RFC says ICV can be of variable size, and is normally taken as 12
bytes, in case if someone
wants > 12 bytes of ICV how he/she can intimate other party of new size of
the ICV?
Thanks
Lokesh
From owner-ipsec@lists.tislabs.com Fri Nov 15 02:37:50 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id gAFAbng11652;
Fri, 15 Nov 2002 02:37:49 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25130
Fri, 15 Nov 2002 05:12:02 -0500 (EST)
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: <15828.51331.433922.465765@ryijy.hel.fi.ssh.com>
Date: Fri, 15 Nov 2002 12:12:19 +0200
From: Tero Kivinen <kivinen@ssh.fi>
To: "Max Pritikin" <pritikin@cisco.com>
Cc: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>, <ipsec@lists.tislabs.com>
Subject: RE: Adding revised identities to IKEv2
In-Reply-To: <PKEBJBKKGOBHIJBBAGLEMELPEPAA.pritikin@cisco.com>
References: <15826.51228.546106.342625@ryijy.hel.fi.ssh.com>
<PKEBJBKKGOBHIJBBAGLEMELPEPAA.pritikin@cisco.com>
X-Mailer: VM 6.89 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 2 min
X-Total-Time: 2 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Max Pritikin writes:
> Your previous statement,
> >>> The other end doesn't really need a certificate it needs a public key
> and it needs it to be trusted somehow.
> ^^^^^^^
> is the difference. The particular certificate matters because the 'somehow'
> is to use the binding and identifying information in the certificate to
> determine the appropriate policy.
Certificate is not the only way the public key can be trusted. For
example you could preconfigure the public key to the system (i.e the
sgw have database of all public keys and what they are authorized to
do with those keys). Or it might be internally use pgp-keys, dns
record or ...
--
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 Nov 15 05:58: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 gAFDwSg11075;
Fri, 15 Nov 2002 05:58:29 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25484
Fri, 15 Nov 2002 08:30:13 -0500 (EST)
Date: Thu, 14 Nov 2002 18:52:04 -0800
Subject: support for v1 certificates?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ipsec@lists.tislabs.com
To: "Housley, Russ" <rhousley@rsasecurity.com>
From: Brian Korver <briank@xythos.com>
Content-Transfer-Encoding: 7bit
Message-Id: <38CDEEF6-F845-11D6-A746-000393751598@xythos.com>
X-Mailer: Apple Mail (2.546)
X-Envelope-To: ipsec@lists.tislabs.com,
rhousley@rsasecurity.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Re: draft-ietf-ipsec-pki-profile-01.txt
On Wednesday, November 13, 2002, at 08:41 AM, Housley, Russ wrote:
>>> In section 4.1.1, I agree that v3 certificates should be required
>>> for end entity and CA certificates. However, the same code will
>>> likely be used for several purposes, and one of them is trust
>>> anchors.
>>> Self-signed v1 certificates are often used to establish trust
>>> anchors.
>>
>> 3280 mandates that BasicConstraints appear in CA certificates, but
>> doesn't appear to state that a self-signed trust anchor can
>> be treated differently. 3280 does state the following:
>>
>> When the trust anchor is provided in the form of a self-signed
>> certificate, this self-signed certificate is not included as part
>> of
>> the prospective certification path.
>>
>> However, without going back and examining the validation algorithm,
>> it's difficult to know what this means with regards to BC.
>>
>> In the context of IPsec, do we see many v1 certificates used for this
>> purpose? I kinda thought that v1 certificates were a dying breed.
>
> Management of trust anchors is outside the scope of the validation
> algorithm in RFC 3280. If self-signed certificates are used, the
> algorithm will not validate them. They are not part of the
> certification path.
>
> I would like to see v1 certificates go away too. I do not think it
> will happen soon. For example, there are several v1 certificates
> built in to Internet Explorer that will not expire until 2018. Others
> will not expire until 2028. So, if the IPsec certificates chain to
> these trust anchors, one can expect to encounter the situation that I
> raised.
I'm not sure it is a good thing to be chaining to the v1
certificates in Internet Explorer, but that's perhaps a
different issue. :)
That said, if someone supports v3, v1 basically comes
for free.
Does anyone care whether support for v1 is optional
vs. mandatory?
-brian
briank@xythos.com
From owner-ipsec@lists.tislabs.com Fri Nov 15 05:58: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 gAFDwVg11092;
Fri, 15 Nov 2002 05:58:31 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25483
Fri, 15 Nov 2002 08:30:07 -0500 (EST)
Date: Thu, 14 Nov 2002 18:52:49 -0800
Subject: FQDN goes in commonName or domainComponent?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ipsec@lists.tislabs.com
To: "Housley, Russ" <rhousley@rsasecurity.com>
From: Brian Korver <briank@xythos.com>
Content-Transfer-Encoding: 7bit
Message-Id: <53E04FFA-F845-11D6-A746-000393751598@xythos.com>
X-Mailer: Apple Mail (2.546)
X-Envelope-To: ipsec@lists.tislabs.com,
rhousley@rsasecurity.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Re: draft-ietf-ipsec-pki-profile-01.txt
On Wednesday, November 13, 2002, at 08:41 AM, Housley, Russ wrote:
>>> In section 4.1.2.2.2, describing conventions for FQDN Host Names, I
>>> think that the SHOULD and MAY are backwards. When a DQDN is carried
>>> in the subject field of a certificate, the domainComponent attribute
>>> SHOULD be used. The commonName attribute MAY be used instead. I
>>> prefer dNSName in the SubjectAltName extension to both of these!
Your final statement agrees with the draft's SHOULD NOT.
On the other hand, domainComponent isn't nearly as standard
as commonName for containing FQDNs. In fact, I'd be surprised
if much software could even process that attribute type and
display it to a user.
Question to the list: How common is support domainComponent?
Which should be preferred?
-brian
briank@xythos.com
From owner-ipsec@lists.tislabs.com Fri Nov 15 05:58: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 gAFDwWg11098;
Fri, 15 Nov 2002 05:58:32 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25465
Fri, 15 Nov 2002 08:29:06 -0500 (EST)
Date: Thu, 14 Nov 2002 18:51:56 -0800
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ipsec@lists.tislabs.com
To: "Housley, Russ" <rhousley@rsasecurity.com>
From: Brian Korver <briank@xythos.com>
In-Reply-To: <5.1.0.14.2.20021113111442.0343e4a0@exna07.securitydynamics.com>
Message-Id: <340081CC-F845-11D6-A746-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-Envelope-To: ipsec@lists.tislabs.com,
rhousley@rsasecurity.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Russ,
I'll send issues I'd like to see more discussion of
to the list as new threads.
On Wednesday, November 13, 2002, at 08:41 AM, Housley, Russ wrote:
> Brian:
>
> I dropped the sections where we have agreement.
>
>>> In section 3.3.9.1, it assumes that the party has ready access to
>>> the most recent CRLs, and any certificates needed to validate the
>>> CRLs.
>>> In a road warrior scenario, one of the peers is in a much better
>>> situation to obtain these than the other. Should this be discussed?
>>
>> I thought that 3.4.9 "Using local keying materials" covered this base
>> by stating that if you've got better keymat around, use it. Perhaps
>> a pointer from 3.3.9.1 to 3.4.9 would be sufficient, or are you
>> suggesting something more would be good?
>
> A forward pointer would be fine, if the referenced section id beefed
> up. Here is my issue. Consider two peers with certificates from the
> same CA. One is a laptop being used in a hotel room on a dial-up
> line. The other is a server at the corporate HQ, and it has a
> multi-mega-bit connection. Both devices should not fetch the most
> recent CRL from the CA's repository just to send it along to the peer.
> The server should fetch it, and pass it along to the laptop in the
> IPsec key management exchange.
How about if I put in your example here along with the
suggestion that the gateway can elide CRL CERTREQs
to save the road warrior from possibly having to
obtain the most up-to-date CRLs from the CA. I think
the example would be best put in 3.3.7.
>
>>> Please adjust the example description in section 3.3.11.3. There is
>>> no requirement that a trust anchor be specified by a self-signed
>>> certificate. The peer should never be asked to provide a
>>> certificate associated with a trust anchor.
>>
>> 3.3.11.3 doesn't state that R is a self-signed certificate. I'm
>> also not sure that Trust Anchor is what most people will think of
>> when they think of certificates for which they have cached the
>> validity status. I see what you're saying, but I'm not sure
>> how best to say it.
>
> The example should refer to an intermediate certificate (like CA1),
> not the trust anchor (R).
I'll change R to CA3 and add ", which can be a self-signed root
or any other trust anchor".
>
>>> In section 3.4.10.5, you say: "Implementations MUST be prepared to
>>> receive certificates and CRLs which are not relevant to the current
>>> exchange. Implementations MAY discard such keying materials." I
>>> agree, but I think that the last sentence potentially confusing. An
>>> implementation should disregard the extraneous certificates and
>>> CRLs, not the symmetric keying material that was generated.
>
> You did not respond to this comment.
I agree with you.
>>> In section 4.1.3, I do not understand the second paragraph on the
>>> criticality bit. Implementation MUST reject a certificate if it
>>> contains an extension that it does not know how to handle with the
>>> criticality bit set to TRUE.
>>
>> Yes, that text is confusing, and has been rewritten a number
>> of unsatisfactory times. The point was that if you support
>> (and thus are going to process) a given extension, then it
>> isn't necessary to fail if the criticality bit is different
>> from what PKIX states it must be. If you don't support an
>> extension you MUST be critical if PKIX says it must, and
>> thus you must fail.
>>
>> recognized
>> extension? bit in cert PKIX mandate what to do
>> YES TRUE TRUE ok
>> YES TRUE FALSE ok
>> YES FALSE TRUE ok
>> YES FALSE FALSE ok
>> NO TRUE TRUE fail
>> NO TRUE FALSE fail
>> NO FALSE TRUE fail
>> NO FALSE FALSE ok
>>
>> When the bit in the cert matches the PKIX mandate, what
>> to do should be obvious. I don't recall to what extent
>> 3280 addresses the others.
>
> The truth table makes your intent clear. I suggest you use it in the
> document.
Agreed, and if you suddenly think of a really good way to
explain this in the text, let me know.
>
>>> In section 4.1.3.3, I suggest that signature validation operations
>>> should proceed if either the nonRepudiation or the digitalSignature
>>> key usage bit is set in an end entity certificate. In my opinion,
>>> digitalSignature is preferred, but nonRepudiation should be allowed.
>>
>> Uh oh, you don't really want to start another NR debate, do you? ;)
>
> No, I do not want to start another NR debate. That is why I think
> that DS and NR should both be accepted.
Let's talk about this in Atlanta. I'm surprised the NR bit is
being used this way and so a little explanation is probably
in order.
>>> In section 4.1.3.13, you say that no IPsec extended key usage values
>>> have been registered. This is incorrect. Three extended key usage
>>> values for use with IPsec have been registered. Do you propose to
>>> deprecate their use?
>>>
>>> id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
>>> id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
>>> id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
>
> No response to this comment?
I don't have any problem with deprecating this. I just didn't
think it was necessary. Done.
>
>>> In section 4.1.3.16, you should state that most implementations do
>>> not support delta CRLs.
>
> Do you agree?
Yes.
>
>>> In section 6.1.2.1, I suggest that signature validation operations
>>> should proceed if either the nonRepudiation or the digitalSignature
>>> key usage bit is set in an end entity certificate. In my opinion,
>>> digitalSignature is preferred, but nonRepudiation should be allowed.
>
> This is related to the NR vs DS discussion above.
Right.
-brian
briank@xythos.com
From owner-ipsec@lists.tislabs.com Fri Nov 15 06:08: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 gAFE8Gg11532;
Fri, 15 Nov 2002 06:08:16 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25537
Fri, 15 Nov 2002 08:47:15 -0500 (EST)
Message-Id: <200211151347.gAFDlQte016623@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Stephen Kent <kent@bbn.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Tue, 12 Nov 2002 14:43:22 EST.
<p05100313b9f702dfa49d@[128.89.88.34]>
Date: Fri, 15 Nov 2002 14:47:26 +0100
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:
...
- when names are used as identities, we need to be able to
map the name to a current address (during SA establishment) so that
we can make later decisions on a per-packet basis using the current
address. in this case, we verify that the named entity is at whatever
address is asserted by it in real time, and just use that address
going forward.
=> this mapping from names to addresses is in this statement done
by looking the source address of received messages (i.e., address
IKE runs over). This cannot provide in all cases the needed flexibility
and safety. For instance the address can be changed "en route",
the peer can put a rogue address (a real concern for 1+1 exchanges),
etc. And if another mapping mechanism is used (IPaddress alternate
Subject names in certificates, DNS/DNSsec, etc) the balance between
flexibility and safety is not the same.
But my main concern is that this balance is not controled: this is just
the result of never documented implementation choices...
Thanks
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Fri Nov 15 06:11: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 gAFEBRg11711;
Fri, 15 Nov 2002 06:11:27 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25559
Fri, 15 Nov 2002 08:52:18 -0500 (EST)
Message-Id: <200211151352.gAFDqite016645@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Uri Blumenthal <uri@lucent.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Tue, 12 Nov 2002 17:02:06 EST.
<3DD17A5E.E2C8B38A@lucent.com>
Date: Fri, 15 Nov 2002 14:52:44 +0100
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:
Oh sure. If I say the entity name is "Uri Blumenthal" - then there
has to be a key/cert associated with that name. As it only matters
for signing the Phase 1 exchange to validate IP address from which
the traffic is originating, for subsequent Phase 2 things.
=> this is a typical example of statements I disagree with: in fact
signing the Phase 1 exchange doesn't validate IP address. IMHO
you should agree the level of trust in this "validation" is *not*
at the level of trust of cryptographic signatures!
Regards
Francis.Dupont@enst-bretagne.fr
PS: this is not directed against you (or someone else), I just need
some good start points for an IPsec/addresses discussion.
From owner-ipsec@lists.tislabs.com Fri Nov 15 07:18: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 gAFFIug17092;
Fri, 15 Nov 2002 07:18:57 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25828
Fri, 15 Nov 2002 09:53:10 -0500 (EST)
Cc: ipsec@lists.tislabs.com
Message-ID: <3DD50A5B.25A2F5FF@lucent.com>
Date: Fri, 15 Nov 2002 09:53:15 -0500
From: Uri Blumenthal <uri@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Original-CC: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
References: <200211151352.gAFDqite016645@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Francis Dupont wrote:
> Oh sure. If I say the entity name is "Uri Blumenthal" - then there
> has to be a key/cert associated with that name. As it only matters
> for signing the Phase 1 exchange to validate IP address from which
> the traffic is originating, for subsequent Phase 2 things.
>
> => this is a typical example of statements I disagree with: in fact
> signing the Phase 1 exchange doesn't validate IP address.
Why doesn't it? In your opinion,what is missing and how would you
prefer to validate IP address?
> IMHO
> you should agree the level of trust in this "validation" is *not*
> at the level of trust of cryptographic signatures!
Perhaps I should - but I don't. Try to convince me first, then we'll
see.
> PS: this is not directed against you (or someone else), I just need
> some good start points for an IPsec/addresses discussion.
(:-) Accepted.
From owner-ipsec@lists.tislabs.com Fri Nov 15 07:33: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 gAFFXmg17411;
Fri, 15 Nov 2002 07:33:49 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25889
Fri, 15 Nov 2002 10:09:16 -0500 (EST)
Message-Id: <200211151445.gAFEjkaZ016986@ritz.appli.se>
To: Brian Korver <briank@xythos.com>
cc: "Housley, Russ" <rhousley@rsasecurity.com>, ipsec@lists.tislabs.com
Subject: Re: FQDN goes in commonName or domainComponent?
In-reply-to: Your message of "Thu, 14 Nov 2002 18:52:49 PST."
<53E04FFA-F845-11D6-A746-000393751598@xythos.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Fri, 15 Nov 2002 15:45:45 +0100
From: Niklas Hallqvist <niklas@appli.se>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Date: Thu, 14 Nov 2002 18:52:49 -0800
> From: Brian Korver <briank@xythos.com>
>
> Question to the list: How common is support domainComponent?
I have no idea, but as an implementor, I have used it in a few
semi-official projects when looking up certificate chains in DNS
(using DNSSEC of course); isakmpd, konqueror and lynx. I'd expect
anyone wanting to do the same would have found the info in the
suitable standard documents. I preferred dNSName in subjectAltName,
had DC as ary choice, and as fallback, CN. I had no idea CN would be
*more* standard than DC. How are you to find that out? It seemed
more ad-hoc to me.
Niklas
From owner-ipsec@lists.tislabs.com Fri Nov 15 08:06: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 gAFG6jg18296;
Fri, 15 Nov 2002 08:06:45 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26026
Fri, 15 Nov 2002 10:40:47 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15829.5552.280167.504156@pkoning.dev.equallogic.com>
Date: Fri, 15 Nov 2002 10:41:36 -0500
From: Paul Koning <pkoning@equallogic.com>
To: lokeshnb@intotoinc.com
Cc: ipsec@lists.tislabs.com
Subject: Re: padding in ESP
References: <5.1.0.14.0.20021115120149.023d1ec0@172.16.1.10>
X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "lokeshnb" == lokeshnb <Lokesh> writes:
lokeshnb> Hi all One questions each on ESP and AH protocols:
lokeshnb> 1] why do we need to adjust ESP packet size by padding to
lokeshnb> be aligned to 4 byte boundary in case of null encryption?
I'm not sure why that was put in the spec. But the current answer is
"because it's in the spec". :-)
lokeshnb> can we bypass padding for null encryption?
NO. You'd be violating a mandatory requirement of the spec if you do
that.
lokeshnb> 2] AH RFC says ICV can be of variable size, and is normally
lokeshnb> taken as 12 bytes, in case if someone wants > 12 bytes of
lokeshnb> ICV how he/she can intimate other party of new size of the
lokeshnb> ICV?
The ICV size is defined by the authentication transform used. For
example, if you use HMAC-MD5-96, that means that the ICV is 96 bits,
or 12 bytes.
So if you want a different ICV size for some reason, you'd have to use
a different transform, one that is defined to use a different size
ICV.
Before you do this, you might review the HMAC RFC to see the
explanation of why the 12 byte size is used. With the possible
exception of SHA2, there's no clear reason why you'd want to change
the 12 byte ICV size.
paul
From owner-ipsec@lists.tislabs.com Fri Nov 15 08:52: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 gAFGqag22285;
Fri, 15 Nov 2002 08:52:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26193
Fri, 15 Nov 2002 11:26:19 -0500 (EST)
Message-Id: <200211151626.gAFGQXte017259@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Uri Blumenthal <uri@lucent.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Fri, 15 Nov 2002 09:53:15 EST.
<3DD50A5B.25A2F5FF@lucent.com>
Date: Fri, 15 Nov 2002 17:26:33 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
<short answer>
In your previous mail you wrote:
Francis Dupont wrote:
> Oh sure. If I say the entity name is "Uri Blumenthal" - then there
> has to be a key/cert associated with that name. As it only matters
> for signing the Phase 1 exchange to validate IP address from which
> the traffic is originating, for subsequent Phase 2 things.
>
> => this is a typical example of statements I disagree with: in fact
> signing the Phase 1 exchange doesn't validate IP address.
Why doesn't it? In your opinion,what is missing and how would you
prefer to validate IP address?
> IMHO
> you should agree the level of trust in this "validation" is *not*
> at the level of trust of cryptographic signatures!
Perhaps I should - but I don't. Try to convince me first, then we'll
see.
=> simple: the address is not covered by the signature, in fact, the
address is not inside any messages so it is not cryptographically
protected.
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Fri Nov 15 08:54: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 gAFGsLg22505;
Fri, 15 Nov 2002 08:54:22 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26179
Fri, 15 Nov 2002 11:22:16 -0500 (EST)
Message-Id: <200211151623.gAFGNBte017233@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Uri Blumenthal <uri@lucent.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Fri, 15 Nov 2002 09:53:15 EST.
<3DD50A5B.25A2F5FF@lucent.com>
Date: Fri, 15 Nov 2002 17:23:11 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
<long answer>
In your previous mail you wrote:
Francis Dupont wrote:
> Oh sure. If I say the entity name is "Uri Blumenthal" - then there
> has to be a key/cert associated with that name. As it only matters
> for signing the Phase 1 exchange to validate IP address from which
> the traffic is originating, for subsequent Phase 2 things.
>
> => this is a typical example of statements I disagree with: in fact
> signing the Phase 1 exchange doesn't validate IP address.
Why doesn't it? In your opinion,what is missing and how would you
prefer to validate IP address?
=> the IP address can be changed "en route" by an attacker in the path
or the peer can put a rogue IP address. What you validate by the
signature is the name, not the address. Stephen Kent in his message
used the expression "whatever address is asserted by it (the peer)"...
To illustrate the two attacks:
- for the first one a box placed on the path between peers by an attacker
maps the peer address in IKE messages to another address, this gives
three bad effects:
* someone can illegitimately received the protected traffic
(usually not a real issue because the traffic is protected)
* the peer doesn't receive the protected traffic (first DoS issue)
* a victim can be overloaded by the protected traffic redirected to it
(second DoS issue).
- for the second one the peer can usurp the address of another box which
is, for instance, booting, just for the IKE exchange. After you can
get any of the previous three effects.
> IMHO
> you should agree the level of trust in this "validation" is *not*
> at the level of trust of cryptographic signatures!
Perhaps I should - but I don't. Try to convince me first, then we'll
see.
=> the address is validated because the exchange is not one-one so
if the peer doesn't receive all the messages it cannot finish the exchange (1)
and of course the peer uses the same address in all messages (2).
(2) is a side effect of the UDP usage (TCP gives this check built-in)
(1) is a "return routability" check which is very weak compared to
a cryptographic signature.
Of course, this comes in addition to the first attack (what I called
"transient pseudo-NAT attack"), so:
- in some cases, the address should be protected (this is easy to do
if the address is in a payload covered by integrity check). Note this
disables the NAT-traversal feature, i.e., we can get either "en route"
address protection or NAT-traversal, not both.
- in some cases, the peer should be trusted to have used one of its own
addresses. IMHO this is not a big issue but if we add a readdressing
one-one exchange to IKE, we'll get the choice between a full trust
to the peer about its addresses or a longer exchange with a "return
routability" check. Same for any kind of readdressing feature in
rekeying.
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Fri Nov 15 09: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 gAFHN0g24313;
Fri, 15 Nov 2002 09:23:01 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26346
Fri, 15 Nov 2002 12:00:01 -0500 (EST)
From: khaja.ahmed@attbi.com
Message-Id: <200211151701.MAA01152@sentry.gw.tislabs.com>
To: Brian Korver <briank@xythos.com>
Cc: "Housley, Russ" <rhousley@rsasecurity.com>, ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
Date: Fri, 15 Nov 2002 17:00:34 +0000
X-Mailer: AT&T Message Center Version 1 (Nov 5 2002)
X-Authenticated-Sender: a2hhamEuYWhtZWRAYXR0YmkuY29t
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Brian,
In section 4.1.3 the propsed truth table would be even clearer if you could
use some verb in the "What to do column" instead of the 'ok'. Something as
clear as the 'fail'.
In the road warrior scenario discussed WRT to section 3.3.9.1, are there any
disadvantages to prescribing/recommending something lighter and real time like
OCSP?
Khaja
> Russ,
>
> I'll send issues I'd like to see more discussion of
> to the list as new threads.
>
>
> On Wednesday, November 13, 2002, at 08:41 AM, Housley, Russ wrote:
> > Brian:
> >
> > I dropped the sections where we have agreement.
> >
> >>> In section 3.3.9.1, it assumes that the party has ready access to
> >>> the most recent CRLs, and any certificates needed to validate the
> >>> CRLs.
> >>> In a road warrior scenario, one of the peers is in a much better
> >>> situation to obtain these than the other. Should this be discussed?
> >>
> >> I thought that 3.4.9 "Using local keying materials" covered this base
> >> by stating that if you've got better keymat around, use it. Perhaps
> >> a pointer from 3.3.9.1 to 3.4.9 would be sufficient, or are you
> >> suggesting something more would be good?
> >
> > A forward pointer would be fine, if the referenced section id beefed
> > up. Here is my issue. Consider two peers with certificates from the
> > same CA. One is a laptop being used in a hotel room on a dial-up
> > line. The other is a server at the corporate HQ, and it has a
> > multi-mega-bit connection. Both devices should not fetch the most
> > recent CRL from the CA's repository just to send it along to the peer.
> > The server should fetch it, and pass it along to the laptop in the
> > IPsec key management exchange.
>
> How about if I put in your example here along with the
> suggestion that the gateway can elide CRL CERTREQs
> to save the road warrior from possibly having to
> obtain the most up-to-date CRLs from the CA. I think
> the example would be best put in 3.3.7.
>
>
> >
> >>> Please adjust the example description in section 3.3.11.3. There is
> >>> no requirement that a trust anchor be specified by a self-signed
> >>> certificate. The peer should never be asked to provide a
> >>> certificate associated with a trust anchor.
> >>
> >> 3.3.11.3 doesn't state that R is a self-signed certificate. I'm
> >> also not sure that Trust Anchor is what most people will think of
> >> when they think of certificates for which they have cached the
> >> validity status. I see what you're saying, but I'm not sure
> >> how best to say it.
> >
> > The example should refer to an intermediate certificate (like CA1),
> > not the trust anchor (R).
>
> I'll change R to CA3 and add ", which can be a self-signed root
> or any other trust anchor".
>
>
> >
> >>> In section 3.4.10.5, you say: "Implementations MUST be prepared to
> >>> receive certificates and CRLs which are not relevant to the current
> >>> exchange. Implementations MAY discard such keying materials." I
> >>> agree, but I think that the last sentence potentially confusing. An
> >>> implementation should disregard the extraneous certificates and
> >>> CRLs, not the symmetric keying material that was generated.
> >
> > You did not respond to this comment.
>
> I agree with you.
>
>
>
> >>> In section 4.1.3, I do not understand the second paragraph on the
> >>> criticality bit. Implementation MUST reject a certificate if it
> >>> contains an extension that it does not know how to handle with the
> >>> criticality bit set to TRUE.
> >>
> >> Yes, that text is confusing, and has been rewritten a number
> >> of unsatisfactory times. The point was that if you support
> >> (and thus are going to process) a given extension, then it
> >> isn't necessary to fail if the criticality bit is different
> >> from what PKIX states it must be. If you don't support an
> >> extension you MUST be critical if PKIX says it must, and
> >> thus you must fail.
> >>
> >> recognized
> >> extension? bit in cert PKIX mandate what to do
> >> YES TRUE TRUE ok
> >> YES TRUE FALSE ok
> >> YES FALSE TRUE ok
> >> YES FALSE FALSE ok
> >> NO TRUE TRUE fail
> >> NO TRUE FALSE fail
> >> NO FALSE TRUE fail
> >> NO FALSE FALSE ok
> >>
> >> When the bit in the cert matches the PKIX mandate, what
> >> to do should be obvious. I don't recall to what extent
> >> 3280 addresses the others.
> >
> > The truth table makes your intent clear. I suggest you use it in the
> > document.
>
> Agreed, and if you suddenly think of a really good way to
> explain this in the text, let me know.
>
>
> >
> >>> In section 4.1.3.3, I suggest that signature validation operations
> >>> should proceed if either the nonRepudiation or the digitalSignature
> >>> key usage bit is set in an end entity certificate. In my opinion,
> >>> digitalSignature is preferred, but nonRepudiation should be allowed.
> >>
> >> Uh oh, you don't really want to start another NR debate, do you? ;)
> >
> > No, I do not want to start another NR debate. That is why I think
> > that DS and NR should both be accepted.
>
> Let's talk about this in Atlanta. I'm surprised the NR bit is
> being used this way and so a little explanation is probably
> in order.
>
>
> >>> In section 4.1.3.13, you say that no IPsec extended key usage values
> >>> have been registered. This is incorrect. Three extended key usage
> >>> values for use with IPsec have been registered. Do you propose to
> >>> deprecate their use?
> >>>
> >>> id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
> >>> id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
> >>> id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
> >
> > No response to this comment?
>
> I don't have any problem with deprecating this. I just didn't
> think it was necessary. Done.
>
>
> >
> >>> In section 4.1.3.16, you should state that most implementations do
> >>> not support delta CRLs.
> >
> > Do you agree?
>
> Yes.
>
>
> >
> >>> In section 6.1.2.1, I suggest that signature validation operations
> >>> should proceed if either the nonRepudiation or the digitalSignature
> >>> key usage bit is set in an end entity certificate. In my opinion,
> >>> digitalSignature is preferred, but nonRepudiation should be allowed.
> >
> > This is related to the NR vs DS discussion above.
>
> Right.
>
> -brian
> briank@xythos.com
>
From owner-ipsec@lists.tislabs.com Fri Nov 15 09:28: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 gAFHSbg24499;
Fri, 15 Nov 2002 09:28:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26399
Fri, 15 Nov 2002 12:08:10 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Brian Korver <briank@xythos.com>
Cc: ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021115115152.03435ac8@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Nov 2002 11:54:09 -0500
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
In-Reply-To: <340081CC-F845-11D6-A746-000393751598@xythos.com>
References: <5.1.0.14.2.20021113111442.0343e4a0@exna07.securitydynamics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Brian:
>>>>Please adjust the example description in section 3.3.11.3. There is no
>>>>requirement that a trust anchor be specified by a self-signed
>>>>certificate. The peer should never be asked to provide a certificate
>>>>associated with a trust anchor.
>>>
>>>3.3.11.3 doesn't state that R is a self-signed certificate. I'm
>>>also not sure that Trust Anchor is what most people will think of
>>>when they think of certificates for which they have cached the
>>>validity status. I see what you're saying, but I'm not sure
>>>how best to say it.
>>
>>The example should refer to an intermediate certificate (like CA1), not
>>the trust anchor (R).
>
>I'll change R to CA3 and add ", which can be a self-signed root
>or any other trust anchor".
The example should not discuss the self-signed certificate! The example
should discuss an intermediate certificate (like CA1) which is clearly part
of the certification path. The trust anchor, regardless of how it is
represented, is not part of the certification path that an implementation
sends to its peer.
Russ
From owner-ipsec@lists.tislabs.com Fri Nov 15 10:27: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 gAFIRUg00749;
Fri, 15 Nov 2002 10:27:30 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26542
Fri, 15 Nov 2002 12:49:57 -0500 (EST)
From: Charlie_Kaufman@notesdev.ibm.com
In-Reply-To: <001901c2895e$a54c3000$640572d4@trustworks.com>
Subject: Re: Authentication methods in IKEv2
To: "Valery Smyslov" <svan@trustworks.com>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002
Message-ID: <OFC021FFEC.BC4D49E7-ON85256C72.000FF9FD-85256C72.001325A1@iris.com>
Date: Thu, 14 Nov 2002 22:29:08 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 11/15/2002
12:50:39 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 11:45 AM +0300 11/11/02, Valery Smyslov wrote:
>I have some doubts about using of authentication methods in IKEv2.
>In IKEv2 negotiation of authentication methods was completely
>removed - each side simply uses his/her favourite method.
>I think this may lead to the lack of interoperability and extensibility
>in case one of the endpoints supports more than one method of
>authentication.
A problem only occurs when one or both sides have multiple different keys
(or different ways of using the keys) with which they could authenticate. I
would expect this case to be unusual, but it certainly could happen. If it
did, I think it would be more natural to encode "what kind of
authentication information I will accept" not in the SA negotiation but
rather in the CERTREQ payload (which would have to be extended) or another
payload like it. I don't think it belongs in the SA negotiation because the
two sides don't have to agree on it. But as with telling you my list of
trusted roots, I might want to tell you what mechanisms I can accept. Also
a natural for this space would be information like the names of Kerberos
realms from which I can accept tickets (for some hypothetical future
extended version of the protocol).
> Another thing that makes me feeling uncomfortable is that even
> type of key an enpoint uses for her own signature is not always
explicitely
> indicated in the protocol. It can easily be learned if certificate
> is present in exchange, but certificate payload is optional...
This is an oversight dating back to when there was only certificate based
authentication. Unless someone objects, I'll add a specifier of the
authentication data type, of which we currently have 3: RSA signature, DSA
signature, and shared key HMAC.
Paul Hoffman writes:
> The worst-case scenario is that the responder tells the initiator "I
> don't trust you", and the initiator tries again with a different
> authentication mechanism.
>
I don't buy this.
This works if it's the initiator who has multiple mechanisms. It
doesn't help the responder with multiple mechanisms.
> For the rare case where the two endpoints don't really know each
> other *and* are going to trust each other *and* have multiple
> authentication mechanisms, we have eliminated a confusing option from
> IKEv1. That's exactly what IKEv2 was designed to do.
>
I might buy this. It is an uncommon circumstance. It will add
complexity to IKEv2 to handle it. If we decide to allow this, I
believe we could best do it with an optional payload - perhaps
CERTREQ, in which case we could add it later without backwards
compatibility problems. I could go either way... what do others
think?
If we are going to let the endpoints indicate their capabilities,
I would think we would allow them to specify RSA and/or DSA key
sizes (which brings back the 1023 vs 1024 bit issues) as well as
shared key HMAC.
Jan Vilhuber wrote:
> So, in theory anyway, authentication methods need to be negotiated via
> cipher-suites within the SA payload, and thus the AUTH payload is
> well-defined by nature of the cipher-suite both agreed to (rather than
> adding another 2 bytes of 'type' to the AUTH payload).
>
> he cipher-suites not contain the authentication type?
No, the cipher-suites do not currently contain the authentication type.
> If we want to support legacy authentication in IKEv2, we definitely
> need to be able to tell the 'client' that she's supposed to do legacy
> authentication (at least in my idea of how legacy authentication needs
> to work). So authentication-parameters for phase 1 need to be part of
> the SA payload in some way (as part of the cipher suite or as an extra
> value somewhere or whatever).
Yes, one of the issues with legacy authentication is how to negotiate
it in the case where it's one of several possible forms of authentication
an endpoint has "keys" for (again a fringe case). If we've going to
negotiate it, my preference would be to see it in an optional payload.
--Charlie Kaufman
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
From owner-ipsec@lists.tislabs.com Fri Nov 15 10:30: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 gAFIUug00882;
Fri, 15 Nov 2002 10:30:56 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26592
Fri, 15 Nov 2002 13:07:43 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Brian Korver <briank@xythos.com>
Cc: ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021115115605.02114618@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Nov 2002 12:00:38 -0500
Subject: Re: support for v1 certificates?
In-Reply-To: <38CDEEF6-F845-11D6-A746-000393751598@xythos.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>Re: draft-ietf-ipsec-pki-profile-01.txt
Brian:
>>>>In section 4.1.1, I agree that v3 certificates should be required for
>>>>end entity and CA certificates. However, the same code will likely be
>>>>used for several purposes, and one of them is trust anchors.
>>>>Self-signed v1 certificates are often used to establish trust anchors.
>>>
>>>3280 mandates that BasicConstraints appear in CA certificates, but
>>>doesn't appear to state that a self-signed trust anchor can
>>>be treated differently. 3280 does state the following:
>>>
>>> When the trust anchor is provided in the form of a self-signed
>>> certificate, this self-signed certificate is not included as part of
>>> the prospective certification path.
>>>
>>>However, without going back and examining the validation algorithm,
>>>it's difficult to know what this means with regards to BC.
>>>
>>>In the context of IPsec, do we see many v1 certificates used for this
>>>purpose? I kinda thought that v1 certificates were a dying breed.
>>
>>Management of trust anchors is outside the scope of the validation
>>algorithm in RFC 3280. If self-signed certificates are used, the
>>algorithm will not validate them. They are not part of the certification path.
>>
>>I would like to see v1 certificates go away too. I do not think it will
>>happen soon. For example, there are several v1 certificates built in to
>>Internet Explorer that will not expire until 2018. Others will not
>>expire until 2028. So, if the IPsec certificates chain to these trust
>>anchors, one can expect to encounter the situation that I raised.
>
>I'm not sure it is a good thing to be chaining to the v1
>certificates in Internet Explorer, but that's perhaps a
>different issue. :)
>
>That said, if someone supports v3, v1 basically comes
>for free.
Not really. With v1 certificates, you cannot have the basic constraints
extension. That was the point that started this thread.
>Does anyone care whether support for v1 is optional
>vs. mandatory?
I do not see a need for v1 certificates in general. That is why I
suggested breaking the discussion into two parts. One part should address
trust anchors. In this area, v1 should be permitted. The other part
should address the certification path, which terminates at the trust
anchor, but does not include the trust anchor itself. In this area, v3
should be mandated.
Russ
From owner-ipsec@lists.tislabs.com Fri Nov 15 11:45: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 gAFJjBg05484;
Fri, 15 Nov 2002 11:45:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26823
Fri, 15 Nov 2002 14:10:19 -0500 (EST)
Message-Id: <5.1.0.14.2.20021115140052.05523450@exna07.securitydynamics.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Nov 2002 14:06:48 -0500
To: Tero Kivinen <kivinen@ssh.fi>
From: Russ Housley <housley@vigilsec.com>
Subject: RE: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
In-Reply-To: <15828.51331.433922.465765@ryijy.hel.fi.ssh.com>
References: <PKEBJBKKGOBHIJBBAGLEMELPEPAA.pritikin@cisco.com>
<15826.51228.546106.342625@ryijy.hel.fi.ssh.com>
<PKEBJBKKGOBHIJBBAGLEMELPEPAA.pritikin@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>Max Pritikin writes:
> > Your previous statement,
> > >>> The other end doesn't really need a certificate it needs a public key
> > and it needs it to be trusted somehow.
> > ^^^^^^^
> > is the difference. The particular certificate matters because the 'somehow'
> > is to use the binding and identifying information in the certificate to
> > determine the appropriate policy.
>Tero Kivinen wrote:
>Certificate is not the only way the public key can be trusted. For
>example you could preconfigure the public key to the system (i.e the
>sgw have database of all public keys and what they are authorized to
>do with those keys). Or it might be internally use pgp-keys, dns
>record or ...
Tero, I agree. I will limit my comments to the X.509 case. Self-signed
certificates are one way to establish trust anchors. This approach is the
one that is talked about the most because the major browser vendors use
it. RFC 3280 defines the minimum requirements for a trust anchor. It says:
The trust anchor information includes:
(1) the trusted issuer name,
(2) the trusted public key algorithm,
(3) the trusted public key, and
(4) optionally, the trusted public key parameters associated
with the public key.
This information can be installed in any secure manner.
Russ
From owner-ipsec@lists.tislabs.com Fri Nov 15 11:45: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 gAFJjRg05504;
Fri, 15 Nov 2002 11:45:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26822
Fri, 15 Nov 2002 14:10:18 -0500 (EST)
To: Michael Thomas <mat@cisco.com>,
Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Message-Id: <5.2.0.9.0.20021115140010.00a97298@nwimap.wh.lucent.com>
X-Sender: uri@nwimap.wh.lucent.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 15 Nov 2002 14:10:45 -0500
Original-To: Michael Thomas <mat@cisco.com>,
Francis Dupont <Francis.Dupont@enst-bretagne.fr>
From: Uri Blumenthal <uri@lucent.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
In-Reply-To: <15829.16006.663304.736259@thomasm-u1.cisco.com>
References: <200211151352.gAFDqite016645@givry.rennes.enst-bretagne.fr>
<3DD17A5E.E2C8B38A@lucent.com>
<200211151352.gAFDqite016645@givry.rennes.enst-bretagne.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:35 11/15/2002 -0800, Michael Thomas wrote:
> > this is a typical example of statements I disagree with: in fact
> > signing the Phase 1 exchange doesn't validate IP address. IMHO
> > you should agree the level of trust in this "validation" is *not*
> > at the level of trust of cryptographic signatures!
>
>If I'm understanding Francis correctly, I think I
>agree. Identity should not be bound up with IP
>addresses where the credential does not otherwise
>require it:
>1) Credentials are verified, 2) Authorization is applied given the policy in
>the SPD -- for IPsec, this means setting up ... parameters on the receiver
> side...*may* or *may* *not* have anything to do with the source IP address
>3) packets are ....checked, classified and run through ......#2........
>
>All of this should be *independent* of the IP address the key management
>protocol is being run on, and in fact should be completely separable.
Ah, with this I agree. I think you mean: not IP address but SA itself is
validated
by crypto signatures. That's fine.
Except that to the best of my knowledge, IP addresses are part of SA
information,
i.e. filtering is done NOT based solely on SPI...
And replying to Francis - I'm too lazy to check myself, but wasn't cookie
(which is
IP address-based) used then as a part of signed contents in IKEv1 exchange?
>It's really important that we keep this sort of separation as the ability
>to have SA's
>which are not tangled up with the current IP address is extremely useful
>for mobility
>and multihoming. More specifically, the ability to "project" SA's for
>mobility could be
>extremely handy.
I agree with this 100% and more. Strongly.
From owner-ipsec@lists.tislabs.com Fri Nov 15 11:58: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 gAFJwPg05864;
Fri, 15 Nov 2002 11:58:26 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26910
Fri, 15 Nov 2002 14:27:28 -0500 (EST)
Message-ID: <3DD5444F.D07FE7@briank.com>
Date: Fri, 15 Nov 2002 11:00:31 -0800
From: Brian Korver <briank@briank.com>
Reply-To: Brian Korver <briank@xythos.com>
X-Mailer: Mozilla 4.78 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Niklas Hallqvist <niklas@appli.se>
CC: ipsec@lists.tislabs.com
Subject: Re: FQDN goes in commonName or domainComponent?
References: <200211151445.gAFEjkaZ016986@ritz.appli.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Niklas Hallqvist wrote:
>
> I have no idea, but as an implementor, I have used it in a few
> semi-official projects when looking up certificate chains in DNS
> (using DNSSEC of course); isakmpd, konqueror and lynx. I'd expect
> anyone wanting to do the same would have found the info in the
> suitable standard documents. I preferred dNSName in subjectAltName,
> had DC as ary choice, and as fallback, CN. I had no idea CN would be
> *more* standard than DC. How are you to find that out? It seemed
> more ad-hoc to me.
>
> Niklas
It's more-or-less standard in several protocols (SSL for instance),
but I didn't mean standard in the sense of appearing in some
document (although that might be true too).
The issue isn't whether to use subjectAltName. That is the right thing
to do. The issue is: if someone is going to place a domain name in
SubjectName (perhaps because it's a v1 certificate? :), then what
attribute should be used?
-brian
briank@briank.com
From owner-ipsec@lists.tislabs.com Fri Nov 15 12:07: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 gAFK73g06479;
Fri, 15 Nov 2002 12:07:03 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26896
Fri, 15 Nov 2002 14:26:29 -0500 (EST)
Message-ID: <3DD5433C.1FECA244@briank.com>
Date: Fri, 15 Nov 2002 10:55:56 -0800
From: Brian Korver <briank@briank.com>
Reply-To: briank@xythos.com
X-Mailer: Mozilla 4.78 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <rhousley@rsasecurity.com>
CC: ipsec@lists.tislabs.com
Subject: Re: support for v1 certificates?
References: <5.1.0.14.2.20021115115605.02114618@exna07.securitydynamics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
"Housley, Russ" wrote:
> >That said, if someone supports v3, v1 basically comes
> >for free.
>
> Not really. With v1 certificates, you cannot have the basic constraints
> extension. That was the point that started this thread.
I meant "basically free" in the sense that very little additional
implementation work necessary.
> >Does anyone care whether support for v1 is optional
> >vs. mandatory?
>
> I do not see a need for v1 certificates in general. That is why I
> suggested breaking the discussion into two parts. One part should address
> trust anchors. In this area, v1 should be permitted. The other part
> should address the certification path, which terminates at the trust
> anchor, but does not include the trust anchor itself. In this area, v3
> should be mandated.
I'm not sure how that differs from saying that possibly any
CA certificate -- any that is a trust anchor by local policy --
can be a v1 certificate.
Let's say host A has chain CA1->CA2->EEA while host B
has chain CA2->EEB (CA2 is the trust anchor for B).
If CA2 is a trust anchor, then are you saying that CA2
should be permitted to be a v1 cert?
-brian
briank@xythos.com
From owner-ipsec@lists.tislabs.com Fri Nov 15 12: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 gAFKggg10189;
Fri, 15 Nov 2002 12:42:43 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27105
Fri, 15 Nov 2002 15:02:12 -0500 (EST)
Date: Fri, 15 Nov 2002 11:59:09 -0800
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ipsec@lists.tislabs.com
To: "Housley, Russ" <rhousley@rsasecurity.com>
From: Brian Korver <briank@xythos.com>
In-Reply-To: <5.1.0.14.2.20021115115152.03435ac8@exna07.securitydynamics.com>
Message-Id: <B482E888-F8D4-11D6-A746-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-Envelope-To: ipsec@lists.tislabs.com,
rhousley@rsasecurity.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Friday, November 15, 2002, at 08:54 AM, Housley, Russ wrote:
> Brian:
>
>>>>> Please adjust the example description in section 3.3.11.3. There
>>>>> is no requirement that a trust anchor be specified by a
>>>>> self-signed certificate. The peer should never be asked to
>>>>> provide a certificate associated with a trust anchor.
>>>>
>>>> 3.3.11.3 doesn't state that R is a self-signed certificate. I'm
>>>> also not sure that Trust Anchor is what most people will think of
>>>> when they think of certificates for which they have cached the
>>>> validity status. I see what you're saying, but I'm not sure
>>>> how best to say it.
>>>
>>> The example should refer to an intermediate certificate (like CA1),
>>> not the trust anchor (R).
>>
>> I'll change R to CA3 and add ", which can be a self-signed root
>> or any other trust anchor".
>
> The example should not discuss the self-signed certificate! The
> example should discuss an intermediate certificate (like CA1) which is
> clearly part of the certification path. The trust anchor, regardless
> of how it is represented, is not part of the certification path that
> an implementation sends to its peer.
>
Russ,
If trust anchors can be self-signed, what is wrong with
pointing this out? IMHO it makes the example clearer,
as I'm pointing out that CA3 may actually NOT be
self-signed.
-brian
briank@xythos.com
From owner-ipsec@lists.tislabs.com Fri Nov 15 12:42: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 gAFKgjg10209;
Fri, 15 Nov 2002 12:42:45 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27216
Fri, 15 Nov 2002 15:13:31 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15829.16006.663304.736259@thomasm-u1.cisco.com>
Date: Fri, 15 Nov 2002 10:35:50 -0800 (PST)
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: Uri Blumenthal <uri@lucent.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <200211151352.gAFDqite016645@givry.rennes.enst-bretagne.fr>
References: <3DD17A5E.E2C8B38A@lucent.com>
<200211151352.gAFDqite016645@givry.rennes.enst-bretagne.fr>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Francis Dupont writes:
> In your previous mail you wrote:
>
> Oh sure. If I say the entity name is "Uri Blumenthal" - then there
> has to be a key/cert associated with that name. As it only matters
> for signing the Phase 1 exchange to validate IP address from which
> the traffic is originating, for subsequent Phase 2 things.
>
> => this is a typical example of statements I disagree with: in fact
> signing the Phase 1 exchange doesn't validate IP address. IMHO
> you should agree the level of trust in this "validation" is *not*
> at the level of trust of cryptographic signatures!
If I'm understanding Francis correctly, I think I
agree. Identity should not be bound up with IP
addresses where the credential does not otherwise
require it, cf x.509, kerberos, etc. The general
flow on the incoming side should be:
1) Credentials are verified
2) Authorization is applied given the policy in
the SPD -- for IPsec, this means setting up filtering
parameters on the receiver side... this *may*
or *may* *not* have anything to do with the
source IP address
3) packets are integrity checked, classified and
run through the filters established in #2 for
the enforcement
All of this should be *independent* of the IP
address the key management protocol is being run
on, and in fact should be completely separable.
It's really important that we keep this sort of
separation as the ability to have SA's which are
not tangled up with the current IP address is
extremely useful for mobility and multihoming.
More specifically, the ability to "project" SA's
for mobility could be extremely handy.
Mike
From owner-ipsec@lists.tislabs.com Fri Nov 15 12: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 gAFKghg10190;
Fri, 15 Nov 2002 12:42:43 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27194
Fri, 15 Nov 2002 15:11:28 -0500 (EST)
Message-ID: <015301c28ce3$d8697550$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Subject: Generating Keying Material
Date: Fri, 15 Nov 2002 13:54:28 -0600
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Section 4.3 of draft-ietf-ipsec-ikev2-03.txt states
"Keying material will always be derived as the output of the
negotiated prf algorithm. If the amount of keying material is greater
than the size of the output of the prf algorithm, we will use the prf
iteratively..."
Rather than having two methods for generating key material (based on the
size of key material needed vs. the size of the prf output), wouldn't it
easier to have prf+ generate a pseudo-random stream from which all key
material is taken?
Keeps it simple and straight forward.
David
From owner-ipsec@lists.tislabs.com Fri Nov 15 12:42: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 gAFKgmg10221;
Fri, 15 Nov 2002 12:42:48 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27153
Fri, 15 Nov 2002 15:07:22 -0500 (EST)
Date: Fri, 15 Nov 2002 12:04:28 -0800
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ipsec@lists.tislabs.com
To: khaja.ahmed@attbi.com
From: Brian Korver <briank@xythos.com>
In-Reply-To: <E18CjvF-0005w5-00@mail.xythos.com>
Message-Id: <7221BE96-F8D5-11D6-A746-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-Envelope-To: ipsec@lists.tislabs.com,
khaja.ahmed@attbi.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Friday, November 15, 2002, at 09:00 AM, khaja.ahmed@attbi.com wrote:
> Brian,
>
> In section 4.1.3 the propsed truth table would be even clearer if you
> could
> use some verb in the "What to do column" instead of the 'ok'.
> Something as
> clear as the 'fail'.
Absolutely.
>
> In the road warrior scenario discussed WRT to section 3.3.9.1, are
> there any
> disadvantages to prescribing/recommending something lighter and real
> time like
> OCSP?
I don't believe there is any standard for doing so for IPsec.
-brian
briank@xythos.com
From owner-ipsec@lists.tislabs.com Fri Nov 15 12:47: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 gAFKlPg10286;
Fri, 15 Nov 2002 12:47:26 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27201
Fri, 15 Nov 2002 15:11:32 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15829.19435.623711.682955@thomasm-u1.cisco.com>
Date: Fri, 15 Nov 2002 11:32:59 -0800 (PST)
To: Uri Blumenthal <uri@lucent.com>
Cc: Michael Thomas <mat@cisco.com>,
Francis Dupont <Francis.Dupont@enst-bretagne.fr>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <5.2.0.9.0.20021115140010.00a97298@nwimap.wh.lucent.com>
References: <200211151352.gAFDqite016645@givry.rennes.enst-bretagne.fr>
<3DD17A5E.E2C8B38A@lucent.com>
<5.2.0.9.0.20021115140010.00a97298@nwimap.wh.lucent.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
Uri Blumenthal writes:
> At 10:35 11/15/2002 -0800, Michael Thomas wrote:
> >1) Credentials are verified, 2) Authorization is applied given the policy in
> >the SPD -- for IPsec, this means setting up ... parameters on the receiver
> > side...*may* or *may* *not* have anything to do with the source IP address
> >3) packets are ....checked, classified and run through ......#2........
> >
> >All of this should be *independent* of the IP address the key management
> >protocol is being run on, and in fact should be completely separable.
>
> Ah, with this I agree. I think you mean: not IP address but SA itself is
> validated
> by crypto signatures. That's fine.
>
> Except that to the best of my knowledge, IP addresses are part of SA
> information,
> i.e. filtering is done NOT based solely on SPI...
To be pedantic...
There are two things going on: first is SADB
lookup for the incoming packet. I believe that
Steve a while back said that it is currently
SPI+DSTaddr, but that in revisions it would only
be SPI unless DSTaddr is a multicast address in
which case it would be SPI+DSTaddr as now. There's
never been a requirement for SRCaddr that I'm
aware of if implementations (mistakenly, IMO)
often do use it as part of the lookup operation.
The second is the classification/filtering
operation after the packet is integrity checked.
This is just the normal 5-tuple filtering which
may or may not pay attention to the source address
(ie, it could be wildcarded).
> And replying to Francis - I'm too lazy to check myself, but wasn't cookie
> (which is
> IP address-based) used then as a part of signed contents in IKEv1 exchange?
Right... if it's true, we really need to fix this
in IKEv2 (if it's not already fixed). IKE qua
protocol should be completely independent of which
src address the message originated from. Anything
that breaks that requirement needs to be fixed.
Mike
From owner-ipsec@lists.tislabs.com Fri Nov 15 12:47: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 gAFKlsg10301;
Fri, 15 Nov 2002 12:47:55 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27200
Fri, 15 Nov 2002 15:11:31 -0500 (EST)
Message-ID: <015401c28ce3$d9223e00$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Subject: Traffic Selectors
Date: Fri, 15 Nov 2002 14:15:43 -0600
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
draft-ietf-ipsec-ikev2-03.txt:
Due to the fact that TS payloads allow multiple traffic
selectors and because each direction has its own payload,
it is possible to specify some very strange (and difficult
to interpret) traffic selectors. For instance, what does
it mean when TSi has 3 traffic selectors while TSr has 2.
I would guess that some implementations would have trouble
handling asymmetric traffic selectors?
Is there too much flexibility here? Does there need to
be some restrictions on what can be sent?
David
From owner-ipsec@lists.tislabs.com Fri Nov 15 13:04: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 gAFL49g10662;
Fri, 15 Nov 2002 13:04:09 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27367
Fri, 15 Nov 2002 15:41:59 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Brian Korver <briank@xythos.com>
Cc: ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021115153451.03449648@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Nov 2002 15:38:54 -0500
Subject: Re: draft-ietf-ipsec-pki-profile-01.txt
In-Reply-To: <B482E888-F8D4-11D6-A746-000393751598@xythos.com>
References: <5.1.0.14.2.20021115115152.03435ac8@exna07.securitydynamics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Brian:
Ref: section 3.3.11.3
>If trust anchors can be self-signed, what is wrong with
>pointing this out? IMHO it makes the example clearer,
>as I'm pointing out that CA3 may actually NOT be
>self-signed.
The document says:
Imagine that an implementation has previously received and cached the
peer certificate chain R->CA1->CA2->EE. If during a subsequent
exchange this implementation sends a CERTREQ containing the Subject
Name in certificate R, this implementation is requesting that the
peer send at least 3 certificates: CA1, CA2, and EE. On the other
hand, if this implementation also sends a CERTREQ containing the Sub-
ject Name of CA2, the implementation is providing a hint that only 1
certificate needs to be sent: EE.
This is fine. For some reason, I misread it, and thought that in the first
case the certificate for R was being transmitted. Upon rereading it, I see
otherwise. My objections dealt with the transmission of the certificate for R.
Sorry for the confusion,
Russ
From owner-ipsec@lists.tislabs.com Fri Nov 15 13:43: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 gAFLhYg11889;
Fri, 15 Nov 2002 13:43:35 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27646
Fri, 15 Nov 2002 16:17:02 -0500 (EST)
Message-Id: <200211152117.gAFLHTJ29190@sydney.East.Sun.COM>
Date: Fri, 15 Nov 2002 16:17:29 -0500 (EST)
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: Traffic Selectors
To: ipsec@lists.tislabs.com
Cc: ckaufman@notesdev.ibm.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: XaXzhE2CXyvEtt5YWfKqxg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Although I have to admit I get confused if I haven't read the text
about selectors within the last day or so, and text like:
"TSi specifies the source address of traffic forwarded from (or the
destination address of traffic forwarded to) the initiator of the
child-SA pair."
gives me a headache, I haven't proposed alternative text because once
I read it carefully it starts making sense to me again, and I can't
think of a better way to say it.
But at any rate, I think it is correct. Let's look at traffic
from Alice to Bob, where Alice has proposed 3 selectors for TSi and
2 selectors for TSr. For instance, address ranges {51*, 892*, and 44*}
for TSi and address ranges {99*, 12*} for TSr.
That would mean that for traffic from Alice to Bob, the source address
can be anything starting with 51, 892, or 44, and the destination can
be anything starting with 99 or 12.
It does NOT mean that the traffic selectors are paired, in the sense
that traffic has to be (Source=51*, Dest=99*) OR (Source=892*, dest=12*)...
If that were the case, you're right...there would need to be the same
number of selectors in TSi and TSr.
But the way it's specified, as long as the source on traffic
from Alice to Bob is included in ANY of the traffic selectors in TSi,
and the destination is included in ANY of the traffic selectors in TSr,
then it's legal.
Radia
From: "David Faucher" <dfaucher@lucent.com>
draft-ietf-ipsec-ikev2-03.txt:
Due to the fact that TS payloads allow multiple traffic
selectors and because each direction has its own payload,
it is possible to specify some very strange (and difficult
to interpret) traffic selectors. For instance, what does
it mean when TSi has 3 traffic selectors while TSr has 2.
I would guess that some implementations would have trouble
handling asymmetric traffic selectors?
Is there too much flexibility here? Does there need to
be some restrictions on what can be sent?
David
From owner-ipsec@lists.tislabs.com Fri Nov 15 14:41: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 gAFMfPg16620;
Fri, 15 Nov 2002 14:41:25 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27801
Fri, 15 Nov 2002 17:13:17 -0500 (EST)
From: "David A. Mcgrew" <mcgrew@cisco.com>
To: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>, <ipsec@lists.tislabs.com>
Subject: Counter Mode Security: Analysis and Recommendations
Date: Fri, 15 Nov 2002 14:10:12 -0800
Message-ID: <FPELKLHKCBJLMMMNOGDFIEKKEIAA.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)
Importance: Normal
In-Reply-To: <FPELKLHKCBJLMMMNOGDFKEHDDMAA.mcgrew@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul,
a couple of months ago I offered to write up an analysis of counter mode
security after you had pointed out a need for this kind of overview. I've
finally wrapped it up, and put it online at
http://www.mindspring.com/~dmcgrew/ctr-security.pdf
Here's the abstract:
In this document we describe Counter Mode (CM) and its security properties,
reviewing relevant cryptographic attacks and system security aspects. This mode
is well understood and can be implemented securely. However, we show that
attacks using precomputation can be used to lower the security level of AES-128
CM below the recommended strength for ciphers if the initial counter value is
predictable. For this reason, AES-128 CM counter values should contain a 64-bit
unpredictable field. We describe how this can be easily done, and make other
implementation recommendations.
From owner-ipsec@lists.tislabs.com Fri Nov 15 15:26: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 gAFNQWg23459;
Fri, 15 Nov 2002 15:26:32 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27931
Fri, 15 Nov 2002 18:00:51 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100309b9fb2c4bc7e9@[128.89.88.34]>
In-Reply-To: <5.1.0.14.0.20021115120149.023d1ec0@172.16.1.10>
References: <5.1.0.14.0.20021115120149.023d1ec0@172.16.1.10>
Date: Fri, 15 Nov 2002 17:59:25 -0500
To: Lokesh <lokeshnb@intotoinc.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: padding in ESP
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 12:28 PM +0530 11/15/02, Lokesh wrote:
>Hi all
>One questions each on ESP and AH protocols:
>
>1] why do we need to adjust ESP packet size by padding to be aligned
>to 4 byte boundary in case of
>null encryption? can we bypass padding for null encryption?
>
>2] AH RFC says ICV can be of variable size, and is normally taken as
>12 bytes, in case if someone
>wants > 12 bytes of ICV how he/she can intimate other party of new
>size of the ICV?
>
>Thanks
>Lokesh
The ICV follows the end of the data that is nominally encrypted
(i.e., the NEXT field in ESP). We want the ICV aligned on a 4-byte
boundary for ease of access, hence the requirement for the padding to
be used even in the case of NULL encryption.
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 15 17:27:02 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 gAG1R1g03437;
Fri, 15 Nov 2002 17:27:01 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28156
Fri, 15 Nov 2002 19:57:39 -0500 (EST)
Date: Sat, 16 Nov 2002 02:59:31 +0200 (IST)
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
To: IPsec WG <ipsec@lists.tislabs.com>
Subject: SIGMA and the cryptographic rationale for IKE exchanges
Message-ID: <Pine.GSO.4.21.0211160200461.10055-100000@ee.technion.ac.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
A paper describing the rationale of the design of the SIGMA
key-exchange protocols that served as the cryptographic basis for the
signature modes of IKE and the current revised exchanges in ikev2 (and
jfk-r) is available from
http://www.ee.technion.ac.il/~hugo/sigma.ps
(you can also download sigma.pdf but I do not guarantee its font
quality...)
I will make a short announcement about this paper during the ipsec meeting
in Atlanta which may give an opprtunity for some off-line discussions.
I am posting the paper now.
Check in the next weeks for updates.
The abstract is attached.
Hugo
Title:
SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman
and its Use in the IKE Protocols
Abstract:
We present the SIGMA key-exchange protocols and the ``SIGn-and-MAc"
approach to authenticated Diffie-Hellman that stands at the core of the
cryptographic design of SIGMA. The SIGMA protocols provide perfect forward
secrecy via a Diffie-Hellman exchange authenticated with digital
signatures. They are specifically designed to provide a variety of
features and trade-offs required in practical scenarios (such as optional
identity protection and reduced number of protocol rounds) as well as to
enjoy sound cryptographic security. In particular, the SIGMA protocols
serve as the cryptographic basis for the signature-based modes of the
standarized Internet Key Exchange (IKE) protocol, and are also used in the
ongoing revision of this standard.
This paper describes the design rationale behind the SIGMA approach and
protocols, and points out to many subtleties surrounding the design
of secure key-exchange protocols in general, and identity-protecting
protocols in particular. We motivate the design of SIGMA by comparing
it to other protocols, most notable the STS protocol and its variants.
In particular, it is shown how SIGMA solves some of the security
shortcomings found in previous protocols.
From owner-ipsec@lists.tislabs.com Sat Nov 16 03:48: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 gAGBmbg22133;
Sat, 16 Nov 2002 03:48:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA29258
Sat, 16 Nov 2002 06:16:32 -0500 (EST)
Message-ID: <007301c28d61$97af08d0$baff2ed4@trustworks.com>
From: "Valery Smyslov" <svan@trustworks.com>
To: <Charlie_Kaufman@notesdev.ibm.com>
Cc: <ipsec@lists.tislabs.com>
References: <OFC021FFEC.BC4D49E7-ON85256C72.000FF9FD-85256C72.001325A1@iris.com>
Subject: Re: Authentication methods in IKEv2
Date: Sat, 16 Nov 2002 14:16:19 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
----- Original Message -----
From: <Charlie_Kaufman@notesdev.ibm.com>
To: "Valery Smyslov" <svan@trustworks.com>
Cc: <ipsec@lists.tislabs.com>; <owner-ipsec@lists.tislabs.com>
Sent: Friday, November 15, 2002 6:29 AM
Subject: Re: Authentication methods in IKEv2
> A problem only occurs when one or both sides have multiple different keys
> (or different ways of using the keys) with which they could authenticate.
I
> would expect this case to be unusual, but it certainly could happen. If it
> did, I think it would be more natural to encode "what kind of
> authentication information I will accept" not in the SA negotiation but
> rather in the CERTREQ payload (which would have to be extended) or another
> payload like it. I don't think it belongs in the SA negotiation because
the
> two sides don't have to agree on it. But as with telling you my list of
> trusted roots, I might want to tell you what mechanisms I can accept. Also
> a natural for this space would be information like the names of Kerberos
> realms from which I can accept tickets (for some hypothetical future
> extended version of the protocol).
I agree with you that SA payload is not a good place for such information
unless we want authentication method to become negotiable again.
Actually I was thinking about new dedicated payload or CERTREQ
payload. Putting this information into CERTREQ payload seem to be
a bit more convinient, it allows to bind authentication method to particular
issuer
(for example, it allows to say: I will accept RSA certificates issued by CA1
or
DSS certificates issued by CA2), but the overall semantics of CERTREQ
payload seem to become very complex (especially for CRLs and
different certificate formats).
> > Another thing that makes me feeling uncomfortable is that even
> > type of key an enpoint uses for her own signature is not always
> explicitely
> > indicated in the protocol. It can easily be learned if certificate
> > is present in exchange, but certificate payload is optional...
>
> This is an oversight dating back to when there was only certificate based
> authentication. Unless someone objects, I'll add a specifier of the
> authentication data type, of which we currently have 3: RSA signature, DSA
> signature, and shared key HMAC.
OK.
> Paul Hoffman writes:
> > The worst-case scenario is that the responder tells the initiator "I
> > don't trust you", and the initiator tries again with a different
> > authentication mechanism.
> >
> I don't buy this.
> This works if it's the initiator who has multiple mechanisms. It
> doesn't help the responder with multiple mechanisms.
Actually, responder may attempt to perform new SA establishment
in reverse direction (as initiator), but this behaviour has so many
drawbacks, that I even don't propose it...
> > For the rare case where the two endpoints don't really know each
> > other *and* are going to trust each other *and* have multiple
> > authentication mechanisms, we have eliminated a confusing option from
> > IKEv1. That's exactly what IKEv2 was designed to do.
> >
> I might buy this. It is an uncommon circumstance. It will add
> complexity to IKEv2 to handle it. If we decide to allow this, I
> believe we could best do it with an optional payload - perhaps
> CERTREQ, in which case we could add it later without backwards
> compatibility problems. I could go either way... what do others
> think?
I think it is worthwhile to have such an option. Currently the situation
with multiple authentication mechanisms is uncommon, but things
might change in the future. Imagine new auth mechanism appear and
become popular (or RSA is suddenly compromised) and IKE needs to migrate to
it.
During migration period this situation will be very common.
> --Charlie Kaufman
>
> Opinions expressed may not even be mine by the time you read them, and
> certainly don't reflect those of any other entity (legal or otherwise).
Regards,
Valery Smyslov.
From owner-ipsec@lists.tislabs.com Sat Nov 16 15:22: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 gAGNMSg04407;
Sat, 16 Nov 2002 15:22:29 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00066
Sat, 16 Nov 2002 17:44:47 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f42b9fc219d4a43@[165.227.249.18]>
In-Reply-To: <3DD5444F.D07FE7@briank.com>
References: <200211151445.gAFEjkaZ016986@ritz.appli.se>
<3DD5444F.D07FE7@briank.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Sat, 16 Nov 2002 11:25:17 -0500
To: Brian Korver <briank@xythos.com>, Niklas Hallqvist <niklas@appli.se>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: FQDN goes in commonName or domainComponent?
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 11:00 AM -0800 11/15/02, Brian Korver wrote:
>It's more-or-less standard in several protocols (SSL for instance),
>but I didn't mean standard in the sense of appearing in some
>document (although that might be true too).
>
>The issue isn't whether to use subjectAltName. That is the right thing
>to do. The issue is: if someone is going to place a domain name in
>SubjectName (perhaps because it's a v1 certificate? :), then what
>attribute should be used?
DC, period. If you think you can put it in CN, why not put it in O? Or OU?
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Sat Nov 16 18:58: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 gAH2w6g17186;
Sat, 16 Nov 2002 18:58:06 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA00465
Sat, 16 Nov 2002 21:31:13 -0500 (EST)
Date: Sat, 16 Nov 2002 21:31:35 -0500
From: "Theodore Ts'o" <tytso@mit.edu>
To: "David A. Mcgrew" <mcgrew@cisco.com>
Cc: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>, ipsec@lists.tislabs.com
Subject: Re: Counter Mode Security: Analysis and Recommendations
Message-ID: <20021117023134.GA753@think.thunk.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
n-Reply-To: <FPELKLHKCBJLMMMNOGDFIEKKEIAA.mcgrew@cisco.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi David,
Barbara and I held off issuing a last call on
draft-ietf-ipsec-ciph-aes-ctr-01 on Friday because Barbara indicated
to me that she had talked to you, and she had told you that you were
about to publish a five-page writeup documenting a security
shortcoming in the current I-D that was about to be published. I assume
that this writeup is the one that you were referring to:
> http://www.mindspring.com/~dmcgrew/ctr-security.pdf
Having read your writeup, I'm confused how this applies to
draft-ietf-ipsec-ciph-aes-ctr-01. The basic summary of your writeup
seems to be (1) the IV needs to be 64 bit, (2) it needs to be
unpredictable, and a good way to do this is to generate the IV using a
counter starting at an unpredictable random value.
The current ID specifies the use of a 64-bit explicit IV, which can be
set by the sender in any fashion which is convenient for the sender,
as long as the requirement that an IV is never reused for a particular
key. There is even text in the security requirements section which
covers the topic of precomputation attacks.
Perhaps it could be made more explicit in the light of your comments
by adding a recommendation that if the sender is using an incrementing
counter or an LFSR to generate the IV, an unpredictable starting value
for the counter or LFSR would be a good idea. Not starting the IV at
zero would seem to me to be self-evident, but sometimes stating such
things explicitly for the benefit of the college intern implementing
from the RFC is a good thing.
Did I miss anything from your counter-mode security writeup?
- Ted
From owner-ipsec@lists.tislabs.com Sun Nov 17 07:43: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 gAHFhUg14575;
Sun, 17 Nov 2002 07:43:30 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01563
Sun, 17 Nov 2002 10:03:47 -0500 (EST)
Subject: Situation in Phase 2 SA Payload
From: venkat <venkat@dexceldesigns.com>
To: IPSec Mail Group <ipsec@lists.tislabs.com>
Cc: manjunath <manjunathsp@dexceldesigns.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Date: 17 Nov 2002 20:38:14 +0530
Message-Id: <1037545696.7979.12.camel@venkat>
Mime-Version: 1.0
X-Mailserver: Sent using PostMaster (v4.1.13)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
RFC2407
I have a little problem with phase 2 SA Payload
SA Payload -> Situation Field
SIT_IDENTITY_ONLY a communication session must have a ID payload
SIT_SECRECY labeled secrecy environment
SIT_INTEGRITY labeled integrity environment
What do you mean by labeled secrecy, and labeled integrity ?
Labeled Domain Identifier has a value
RESERVED 0 (What about other instances?)
Do we have any labeled Security services ?
Have any IPSec vendors implemented SIT_SECRECY or SIT_INTEGRITY.
I'm not finding any proper documentation on labeled secrecy or labeled
integrity, does anyone have any dedicated links or references regarding
this.
Have a nice day
- Venkat
--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
From owner-ipsec@lists.tislabs.com Sun Nov 17 09:17: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 gAHHHEg24543;
Sun, 17 Nov 2002 09:17:14 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01703
Sun, 17 Nov 2002 11:50:34 -0500 (EST)
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD093DED@mailserver.sylantro.com>
From: "Eric Nielsen" <Eric.Nielsen@sylantro.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
cc: "'stu.jacobs@verizon.com'" <stu.jacobs@verizon.com>
Subject: draft of broad requirements for VoIP security
Date: Sun, 17 Nov 2002 08:49:26 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 11C9171059461-01-01
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The draft draft-jacobs-signaling-security-requirements-00.txt
http://www.ietf.org/internet-drafts/draft-jacobs-signaling-security-requirem
ents-00.txt
attempts to define the body of security requirements
that must be dealt with in order to carrier-scale VoIP
deployments. The requirements are generic, and are not
written relative to specific threats.
This draft was a direct result of our initial pursuit of a
light-weight key distribution design to be coupled with ESP.
Instead of moving straight to a solution Jeff Schiller
recommended that we publish a requirements draft to have the
IETF community help determine if a solution exists, to see
if these security needs of large carrier deployments of SIP,
MGCP and Megaco can already be met.
A significant issue for this draft is that the requirements
do not neatly fit into any one WG charter. I believe this
is more of a security issue than an application level
issue. To date the SIP WG has worked to fill in a variety
of gaps whereas MGCP and Megaco say not much more than
"just use IPsec". Security is an essential part of VoIP,
and many of the needed features exist. Still, the issue of
a cohesive, workable security solution for carrier-scale
deployment remains beyond the scope of any one workgroup.
Thus we are posting this note here.
The goal of this draft is to get agreement on the broader
requirements, followed by an determining what gaps there
are between what exists and what is needed. Obviously if
we could see a full solution, we would not be pursuing this.
For example, common usage of current technology leads to
poor practices in handling keying material. The technology
must be defined so that it is possible to define simple and
secure common practices.
We would like to work to get agreement on the requirements,
as well as how to best meet them.
Thank you,
Eric Nielsen
Sylantro Systems
Stuart Jacobs CISSP
Verizon Laboratories
From owner-ipsec@lists.tislabs.com Sun Nov 17 19:26: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 gAI3QJg27572;
Sun, 17 Nov 2002 19:26:20 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02406
Sun, 17 Nov 2002 21:52:02 -0500 (EST)
From: "David A. Mcgrew" <mcgrew@cisco.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>, <ipsec@lists.tislabs.com>
Subject: RE: Counter Mode Security: Analysis and Recommendations
Date: Sun, 17 Nov 2002 18:45:58 -0800
Message-ID: <FPELKLHKCBJLMMMNOGDFCEOEEIAA.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)
Importance: Normal
In-Reply-To: <20021117023134.GA753@think.thunk.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ted,
here is a long-winded reply and a suggested direction for the ipsec counter mode
draft. First, thanks for your feedback, I realize that I need to be more
clear on the point that you brought up.
Randomly setting the initial value of the 64-bit explicit IV of
draft-ietf-ipsec-ciph-aes-ctr-01 does *not* protect against the precomputation
attacks described in the writeup. This is because all values of that IV will be
used during the lifetime of a key. So an attacker can pick any value of the IV
during its precomputation stage, then wait for the corresponding packet to
appear in the data stream protected by a particular key before attacking that
key. If the attacker does not store the ciphertext contained by the packets
that were sent previous to the IV value used in the precomputation, she will not
be able to decipher those packets. However, this does not seriously impair the
effectiveness of the attack, since on average 1/2 of the plaintext will be
decipherable by the attacker.
What I'm suggesting is that there be a distinct field in in the counter which is
unpredictable. In principle, counter mode *can* have a 64-bit randomizer
because the limitation that no more than 2^64 blocks can be generated implies
that 64 bits suffice to index all of those blocks. So the block counter and IV
fields together need not occupy more than 64 bits.
Here's a concrete proposal: reduce the block counter to 16 bits and the IV to 48
bits, and replace the 'truncated spi' field with a 56-bit field that is set
randomly at key setup time. This field should be considered part of the key, so
that key setup is easy. This proposal has the following advantages: better
security than the current draft, and the independence of the cipher from the SPI
allocation. It has the following minor disadvantage: it cannot encrypt ipv6
jumbograms.
As an aside, the 8-bit 'flags' field prevents us from making the randomizer
field 64 bits long. I'd prefer 64 bits but would happy to get 56.
An important point about the current draft is that, while it aims to admit a
variety of implementation strategies, it excludes the cryptographically
conservative one. In my opinion, that would be a mistake.
In the interest of moving the WG forward on the issue, I suggest that we solicit
WG input on the following questions:
1) is a security level lower than that recommended for commercial encryption
(88 bits) considered acceptable?
2) is a limitation to encrypting packets less than 64kb in length considered
acceptable?
3) if you could answer "yes" to only one of the above questions, which would
it be?
4) is it acceptable to implement AES-192 or AES-256 and use those ciphers for
counter mode? Or is it desirable to use AES-128 for both CBC and counter mode?
Knowing the WG sentiment on these topics will enable us to make a dispassionate
evaluation. It is late and I'm tired, and I may have missed decision point, so
I invite others to propose questions as well.
For the record, I am still of the opinion that omitting the explicit IV in order
to cut down on the size of the packet is worthwhile. However, I'm neglecting
that issue in order to focus the discussion on the security issue, which is
certainly more important.
David
> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso@mit.edu]
> Sent: Saturday, November 16, 2002 6:32 PM
> To: David A. Mcgrew
> Cc: Paul Hoffman / VPNC; ipsec@lists.tislabs.com
> Subject: Re: Counter Mode Security: Analysis and Recommendations
>
>
> Hi David,
>
> Barbara and I held off issuing a last call on
> draft-ietf-ipsec-ciph-aes-ctr-01 on Friday because Barbara indicated
> to me that she had talked to you, and she had told you that you were
> about to publish a five-page writeup documenting a security
> shortcoming in the current I-D that was about to be published. I assume
> that this writeup is the one that you were referring to:
>
> > http://www.mindspring.com/~dmcgrew/ctr-security.pdf
>
> Having read your writeup, I'm confused how this applies to
> draft-ietf-ipsec-ciph-aes-ctr-01. The basic summary of your writeup
> seems to be (1) the IV needs to be 64 bit, (2) it needs to be
> unpredictable, and a good way to do this is to generate the IV using a
> counter starting at an unpredictable random value.
>
> The current ID specifies the use of a 64-bit explicit IV, which can be
> set by the sender in any fashion which is convenient for the sender,
> as long as the requirement that an IV is never reused for a particular
> key. There is even text in the security requirements section which
> covers the topic of precomputation attacks.
>
> Perhaps it could be made more explicit in the light of your comments
> by adding a recommendation that if the sender is using an incrementing
> counter or an LFSR to generate the IV, an unpredictable starting value
> for the counter or LFSR would be a good idea. Not starting the IV at
> zero would seem to me to be self-evident, but sometimes stating such
> things explicitly for the benefit of the college intern implementing
> from the RFC is a good thing.
>
> Did I miss anything from your counter-mode security writeup?
>
> - Ted
From owner-ipsec@lists.tislabs.com Mon Nov 18 06: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 gAIEgtg28502;
Mon, 18 Nov 2002 06:42:56 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03345
Mon, 18 Nov 2002 09:09:12 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: briank@xythos.com
Cc: ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021115154953.0556d310@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Nov 2002 15:51:41 -0500
Subject: Re: support for v1 certificates?
In-Reply-To: <3DD5433C.1FECA244@briank.com>
References: <5.1.0.14.2.20021115115605.02114618@exna07.securitydynamics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Brian:
> > >That said, if someone supports v3, v1 basically comes
> > >for free.
> >
> > Not really. With v1 certificates, you cannot have the basic constraints
> > extension. That was the point that started this thread.
>
>I meant "basically free" in the sense that very little additional
>implementation work necessary.
>
>
> > >Does anyone care whether support for v1 is optional
> > >vs. mandatory?
> >
> > I do not see a need for v1 certificates in general. That is why I
> > suggested breaking the discussion into two parts. One part should address
> > trust anchors. In this area, v1 should be permitted. The other part
> > should address the certification path, which terminates at the trust
> > anchor, but does not include the trust anchor itself. In this area, v3
> > should be mandated.
>
>I'm not sure how that differs from saying that possibly any
>CA certificate -- any that is a trust anchor by local policy --
>can be a v1 certificate.
>
>Let's say host A has chain CA1->CA2->EEA while host B
>has chain CA2->EEB (CA2 is the trust anchor for B).
>If CA2 is a trust anchor, then are you saying that CA2
>should be permitted to be a v1 cert?
NO!
I am suggesting that a discussion of trust anchors is needed. The use of
v1 certs to install a trust anchor is reasonable.
If the cert is transmitted in IKE, then it ought to be a v3 cert.
Russ
From owner-ipsec@lists.tislabs.com Mon Nov 18 06: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 gAIEgtg28501;
Mon, 18 Nov 2002 06:42:56 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03331
Mon, 18 Nov 2002 09:06:13 -0500 (EST)
Date: Mon, 18 Nov 2002 21:55:33 +0800
From: Jerry Yao <jerryyao@mail.jl.cn>
Subject: RE: UDP-encapsulated IPsec Transport mode
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Cc: "james.huang@watchguard.com" <james.huang@watchguard.com>
Message-id: <0H5R00I5EXUDAZ@mta2.mail.jl.cn>
MIME-version: 1.0
X-Mailer: Foxmail 4.2 [cn]
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello
I think the best method to solve NAT-T problem is to use technique like build-in NAT above IPSec. When Suzi received packet from Ari or Bob, firstly translates the source address of the packet to Ari's or Bob's private address, then applies the ipsec functions, then passes the packet up to TCP or UDP.When sending, after applies the ipsec functions, encapsulates the packet with UDP header whose target address and port are the same to the address and port of original packet that received from Ari or Bob.
But according to draft-ietf-ipsec-udp-encaps-04.txt, SSH may have intellectual property rights relating to this implementation technique. Is that mean that we can't solve the problem that way?
From owner-ipsec@lists.tislabs.com Mon Nov 18 06:45: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 gAIEjRg28880;
Mon, 18 Nov 2002 06:45:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03405
Mon, 18 Nov 2002 09:15:15 -0500 (EST)
Message-Id: <200211181415.gAIEFWte027276@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Michael Thomas <mat@cisco.com>
cc: Uri Blumenthal <uri@lucent.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Fri, 15 Nov 2002 10:35:50 PST.
<15829.16006.663304.736259@thomasm-u1.cisco.com>
Date: Mon, 18 Nov 2002 15:15:32 +0100
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:
If I'm understanding Francis correctly, I think I
agree. Identity should not be bound up with IP
addresses where the credential does not otherwise
require it, cf x.509, kerberos, etc. The general
flow on the incoming side should be:
=> my message was about IKE itself, not IPsec... But IPsec
is another example of ACL-like validation because only some
transforms/modes provide integrity check over addresses
(something stronger than the check against SA/SPD selectors).
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Mon Nov 18 06:45: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 gAIEjWg28901;
Mon, 18 Nov 2002 06:45:33 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03385
Mon, 18 Nov 2002 09:13:12 -0500 (EST)
Date: Fri, 15 Nov 2002 14:22:52 -0800
Subject: Re: support for v1 certificates?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ipsec@lists.tislabs.com
To: "Housley, Russ" <rhousley@rsasecurity.com>
From: Brian Korver <briank@xythos.com>
In-Reply-To: <5.1.0.14.2.20021115154953.0556d310@exna07.securitydynamics.com>
Message-Id: <C822A294-F8E8-11D6-A746-000393751598@xythos.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-Envelope-To: ipsec@lists.tislabs.com,
rhousley@rsasecurity.com
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Friday, November 15, 2002, at 12:51 PM, Housley, Russ wrote:
> NO!
>
> I am suggesting that a discussion of trust anchors is needed. The use
> of v1 certs to install a trust anchor is reasonable.
>
> If the cert is transmitted in IKE, then it ought to be a v3 cert.
Ah, then we're in 100% agreement.
On that note, I left out using "raw" keys to install
trust anchors because I thought the practice was too
antiquated. Does anyone know of any IPsec implementations
actually support importing public key blobs for this
purpose?
-brian
briank@xythos.com
From owner-ipsec@lists.tislabs.com Mon Nov 18 06:45: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 gAIEjfg28936;
Mon, 18 Nov 2002 06:45:41 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03330
Mon, 18 Nov 2002 09:06:11 -0500 (EST)
Message-ID: <001b01c28f0c$38ce0300$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>,
<ipsec@lists.tislabs.com>
Cc: <ckaufman@notesdev.ibm.com>
References: <200211152117.gAFLHTJ29190@sydney.East.Sun.COM>
Subject: Re: Traffic Selectors
Date: Mon, 18 Nov 2002 08:10:13 -0600
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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>
Cc: <ckaufman@notesdev.ibm.com>
Sent: Friday, November 15, 2002 3:17 PM
Subject: Re: Traffic Selectors
<snip>
| But the way it's specified, as long as the source on traffic
| from Alice to Bob is included in ANY of the traffic selectors in TSi,
| and the destination is included in ANY of the traffic selectors in TSr,
| then it's legal.
|
| Radia
|
The above paragraph clears up my confusion. I was making it
more complicted than it needed to be. For instance, initially
I was thinking of an example where a pair of gateways would
protect all traffic for a specific application (TCP port X)
AND traffic from subnets Y to Z, while everything else would
be in the clear. This type of configuration would require
negotiating 2 separate SAs.
David
From owner-ipsec@lists.tislabs.com Mon Nov 18 06:47: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 gAIElYg29206;
Mon, 18 Nov 2002 06:47:34 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03429
Mon, 18 Nov 2002 09:20:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100300b9fea5279e12@[128.89.88.34]>
In-Reply-To: <00b501c28b69$185c14f0$1e72788a@ca.alcatel.com>
References: <00b501c28b69$185c14f0$1e72788a@ca.alcatel.com>
Date: Mon, 18 Nov 2002 09:13:41 -0500
To: andrew.krywaniuk@alcatel.com
From: Stephen Kent <kent@bbn.com>
Subject: RE: Suites vs a-la-carte
Cc: <ipsec@lists.tislabs.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 6:05 PM -0500 11/13/02, Andrew Krywaniuk wrote:
> > Sure we can; we just can't agree to the limited number of numbers
>> that we would encode.
>
>I agree with this. One of the reasons I have endorsed GUI suites all along
>is that I felt we would be much more likely to get consensus on the base
>suites if it were easy to create your own private suites.
>
Andrew,
I have to come to think that this is also a critical feature going
forward, if we adopt suites i.e., we need to require implementations
to be "easily configurable" re private suites. I would go a step
further, however, and say that I don't just want the suites to be
vendor-specific, but also user community-specific. I've gotten some
feedback from the DoD community that they would like to be able to
use commercial IPsec products in appropriate contexts, but that they
need to be able to configure their own DH groups. If we mandate
user-configurable algorithms/suites in IKEv2, then these folks, and
maybe others, will be able to buy these products and use them in
environments where the mandatory-to-implement suites do not suffice.
Steve
From owner-ipsec@lists.tislabs.com Mon Nov 18 06:47: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 gAIElrg29262;
Mon, 18 Nov 2002 06:47:53 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03417
Mon, 18 Nov 2002 09:16:15 -0500 (EST)
Date: Sun, 17 Nov 2002 23:06:37 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: ipng@sunroof.eng.sun.com
cc: ipsec@lists.tislabs.com
Subject: Re: I-D ACTION:draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt
In-Reply-To: <200210311113.GAA12830@ietf.org>
Message-ID: <Pine.LNX.4.44.0211172254320.11018-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 31 Oct 2002 Internet-Drafts@ietf.org wrote:
> Title : Requirements for Plug and Play IPsec for IPv6
> applications
> Author(s) : T. Kobayakawa, S. Miyakawa
> Filename : draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt
> Pages : 5
> Date : 2002-10-30
>
> This document describes requirements about how IPsec is supplemented
> for IPv6 Plug and Play applications.
Comments.
Substantial:
There is another reason for Internet users to choose IPv6. IPv6 is
believed to be equipped with IPsec as default, and many users choose
IPv6 because of IPsec. However, IPsec is independent from version
numbers of IP, and IPv6 does not have special advantages for IPsec.
We have two options to cope with this myth:
==> "no special advantages" is not true. Well, directly, there seem to be
no special advantages. But increased address space and e2e addressing
make e2e IPSEC much easier -- NAT boxes severely hinder IPSEC usability.
However, we should
not mandate the existence of this outside server because there are
many situations in which such servers are not available, and IP layer
authentication and Man-in-the-Middle protection are not important.
==> I don't understand this at all. Please elaborate a bit. I fail
to see cases when MITM protection is irrelevant.
After the establishment of this security level of IPsec SAs,
authentication, authorization, accounting, and Man-in-the-Middle
prevention are added on to those SAs.
==> how are these added there? I fail to see how establishing possibly
MITM'ed "authenticated" IPSEC SA's helps _any_ with this.
==> You forgot Security Considerations section. I believe using IPSEC
when it's known to be possibly wrong is not good -- no security is better
than false sense of security.
Editorial:
==> many places s/configurations/configuration/
abundant (IPv4 global addresses are not, especially in Asia.) Such
peer-to-peer applications often require authentication and secrecy
mechanisms, which are provided by IPsec.
==> s/are provided/can be provided/
Many IPv6 applications assume embedded devices without keyboard and
display. For embedded devices, maintaining X.509 certificate, such
as Certificate Update and Certificate Revocation Handling, is too
heavy and often diminishes the usability.
==> reword this, the latter part isn't clearly related to _maintaining_
certificates.
but it's not practical to apply to IP communications.) Assuming no
==> s/.)/)./
Just "key-exchange-before-all-the-communication" does not work
because it forces delay on all the communications regardless of this
kind of IPsec supports.
==> reword the last part, e.g. "support for PnP IPSEC".
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
From owner-ipsec@lists.tislabs.com Mon Nov 18 06:49: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 gAIEneg29525;
Mon, 18 Nov 2002 06:49:41 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03491
Mon, 18 Nov 2002 09:27:34 -0500 (EST)
From: Ghislaine Labouret <gl+ietf-ipsec-0211@labouret.net>
To: ipsec@lists.tislabs.com
Cc: plugtests@etsi.fr, Philippe Cousin <Philippe.Cousin@etsi.fr>
Subject: Interop IPsec organised by ETSI: declaration of interest
Date: Mon, 18 Nov 2002 15:14:09 +0100
X-Mailer: Forte Agent 1.92/32.572
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20021118141423.DDC1323A5D@etheria.labouret.net>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello,
In answer to the various requests about the potential bakeoff in France
in 2003, ETSI has asked me to forward the following announcement to the
list:
-----
The ETSI Plugtests Service is a professional service that specializes in
the organization of interoperability events for any telecommunication /
Internet / Information Technology standard.
We are currently studying the possibility of organizing an IPsec
Interoperability event (also known as bake-off) in 2003 and tentatively
in July after the IETF meeting.
In order to assess such interest and start studying the organization of
such event, we have put in place a non-binding declaration of interest
at the following link:
http://www.etsi.org/plugtests/02UpcomingEvents/IPsec/Ipsec2_interest.htm
Should you be interest to attend such event please fill in the form.
Regards
Philippe COUSIN
Interoperability Service Manager
Tel: + 33 (0)4 92 94 4306
Fax: +33 (0)4 92 38 5248
http://www.etsi.org/plugtests/
-----
Sincerely,
--
Ghislaine Labouret, Network Security Expert
From owner-ipsec@lists.tislabs.com Mon Nov 18 06: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 gAIEqbg00509;
Mon, 18 Nov 2002 06:52:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03485
Mon, 18 Nov 2002 09:27:32 -0500 (EST)
Message-Id: <200211181427.gAIERete027311@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Uri Blumenthal <uri@lucent.com>
cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Fri, 15 Nov 2002 14:10:45 EST.
<5.2.0.9.0.20021115140010.00a97298@nwimap.wh.lucent.com>
Date: Mon, 18 Nov 2002 15:27:40 +0100
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:
And replying to Francis - I'm too lazy to check myself, but wasn't cookie
(which is
IP address-based) used then as a part of signed contents in IKEv1 exchange?
=> the cookie is built by the other peer so the only effect is the
addresses must remain the same between all packets of a phase,
a check which is currently done even between phases.
Can you explain how cookies can forbid an attacker to change en route
or as the peer to put a rogue address in all messages?
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Mon Nov 18 06:53: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 gAIEr1g00577;
Mon, 18 Nov 2002 06:53:02 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03539
Mon, 18 Nov 2002 09:30:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100301b9fea8c97865@[128.89.88.34]>
In-Reply-To: <200211151347.gAFDlQte016623@givry.rennes.enst-bretagne.fr>
References: <200211151347.gAFDlQte016623@givry.rennes.enst-bretagne.fr>
Date: Mon, 18 Nov 2002 09:29:27 -0500
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 2:47 PM +0100 11/15/02, Francis Dupont wrote:
> In your previous mail you wrote:
>
> ...
> - when names are used as identities, we need to be able to
> map the name to a current address (during SA establishment) so that
> we can make later decisions on a per-packet basis using the current
> address. in this case, we verify that the named entity is at whatever
> address is asserted by it in real time, and just use that address
> going forward.
>
>=> this mapping from names to addresses is in this statement done
>by looking the source address of received messages (i.e., address
>IKE runs over). This cannot provide in all cases the needed flexibility
>and safety. For instance the address can be changed "en route",
>the peer can put a rogue address (a real concern for 1+1 exchanges),
>etc. And if another mapping mechanism is used (IPaddress alternate
>Subject names in certificates, DNS/DNSsec, etc) the balance between
>flexibility and safety is not the same.
>But my main concern is that this balance is not controled: this is just
>the result of never documented implementation choices...
Francis,
An intermediate IPsec device has only per-packet header data
available as a basis for making access control decisions for traffic
on an extant SA. Thus we must bind the traffic for the SA to a set of
addresses that we know about when we establish the SA. For tunnel
mode, the outer addresses can change during the SA without breaking
the SA, but the inner addresses must remain constant (or at least be
part of the same set established during SA establishment). Those
addresses cannot be changed by black routers, NAT devices, etc.,
since they are inside the protection boundary.
I don't think this characterization of the use of symbolic names and
mapping to addresses is an implementation choice issue, as you
suggest above. It is an architectural issue.
Steve
From owner-ipsec@lists.tislabs.com Mon Nov 18 06:56: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 gAIEueg00700;
Mon, 18 Nov 2002 06:56:40 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03558
Mon, 18 Nov 2002 09:31:40 -0500 (EST)
Message-Id: <200211181432.gAIEWBte027340@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Michael Thomas <mat@cisco.com>
cc: Uri Blumenthal <uri@lucent.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Fri, 15 Nov 2002 11:32:59 PST.
<15829.19435.623711.682955@thomasm-u1.cisco.com>
Date: Mon, 18 Nov 2002 15:32:11 +0100
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:
> And replying to Francis - I'm too lazy to check myself, but wasn't cookie
> (which is
> IP address-based) used then as a part of signed contents in IKEv1 exchange?
Right... if it's true, we really need to fix this
in IKEv2 (if it's not already fixed). IKE qua
protocol should be completely independent of which
src address the message originated from. Anything
that breaks that requirement needs to be fixed.
=> I disagree: the function of the cookie is to verify
the peer really exists at this address. But I agree
with the requirement for anything but this exception.
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Mon Nov 18 07:05: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 gAIF5Pg00894;
Mon, 18 Nov 2002 07:05:25 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03617
Mon, 18 Nov 2002 09:40:53 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100302b9feaa1dc87a@[128.89.88.34]>
In-Reply-To: <15829.19435.623711.682955@thomasm-u1.cisco.com>
References: <200211151352.gAFDqite016645@givry.rennes.enst-bretagne.fr>
<3DD17A5E.E2C8B38A@lucent.com>
<5.2.0.9.0.20021115140010.00a97298@nwimap.wh.lucent.com>
<15829.19435.623711.682955@thomasm-u1.cisco.com>
Date: Mon, 18 Nov 2002 09:35:38 -0500
To: Michael Thomas <mat@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 11:32 AM -0800 11/15/02, Michael Thomas wrote:
>Uri Blumenthal writes:
> > At 10:35 11/15/2002 -0800, Michael Thomas wrote:
> > >1) Credentials are verified, 2) Authorization is applied given
>the policy in
> > >the SPD -- for IPsec, this means setting up ... parameters on the receiver
> > > side...*may* or *may* *not* have anything to do with the
>source IP address
> > >3) packets are ....checked, classified and run through ......#2........
> > >
> > >All of this should be *independent* of the IP address the key management
> > >protocol is being run on, and in fact should be completely separable.
> >
> > Ah, with this I agree. I think you mean: not IP address but SA itself is
> > validated
> > by crypto signatures. That's fine.
> >
> > Except that to the best of my knowledge, IP addresses are part of SA
> > information,
> > i.e. filtering is done NOT based solely on SPI...
>
>To be pedantic...
>
>There are two things going on: first is SADB
>lookup for the incoming packet. I believe that
>Steve a while back said that it is currently
>SPI+DSTaddr, but that in revisions it would only
>be SPI unless DSTaddr is a multicast address in
>which case it would be SPI+DSTaddr as now. There's
>never been a requirement for SRCaddr that I'm
>aware of if implementations (mistakenly, IMO)
>often do use it as part of the lookup operation.
right.
>
>The second is the classification/filtering
>operation after the packet is integrity checked.
>This is just the normal 5-tuple filtering which
>may or may not pay attention to the source address
>(ie, it could be wildcarded).
in principle the SPD entry for this SA might wild card the source
address, but in practice we create pairs of SAs and the IP address
for outbound traffic in the matching SA must be constrained in some
fashion, typically by specifying a single IP address or address range
(or mask), to ensure that all traffic destined to a host or set of
hosts is mapped to an SA that terminates at an IPsec implementation
serving that host or set of hosts.
Steve
From owner-ipsec@lists.tislabs.com Mon Nov 18 07:37: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 gAIFbOg01871;
Mon, 18 Nov 2002 07:37:24 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03989
Mon, 18 Nov 2002 10:10:18 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100306b9feb24fb545@[128.89.88.34]>
In-Reply-To: <53E04FFA-F845-11D6-A746-000393751598@xythos.com>
References: <53E04FFA-F845-11D6-A746-000393751598@xythos.com>
Date: Mon, 18 Nov 2002 10:09:35 -0500
To: Brian Korver <briank@xythos.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: FQDN goes in commonName or domainComponent?
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 6:52 PM -0800 11/14/02, Brian Korver wrote:
>Re: draft-ietf-ipsec-pki-profile-01.txt
>
>On Wednesday, November 13, 2002, at 08:41 AM, Housley, Russ wrote:
>>>>In section 4.1.2.2.2, describing conventions for FQDN Host Names,
>>>>I think that the SHOULD and MAY are backwards. When a DQDN is
>>>>carried in the subject field of a certificate, the
>>>>domainComponent attribute SHOULD be used. The commonName
>>>>attribute MAY be used instead. I prefer dNSName in the
>>>>SubjectAltName extension to both of these!
>
>Your final statement agrees with the draft's SHOULD NOT.
>
>On the other hand, domainComponent isn't nearly as standard
>as commonName for containing FQDNs. In fact, I'd be surprised
>if much software could even process that attribute type and
>display it to a user.
>
>Question to the list: How common is support domainComponent?
>Which should be preferred?
>
FYI: BBN has developed open source CA software under the DARPA CHATS
(Composable High Assurance Trusted Systems) program, which is being
made freely available. It supports the DC construct for domain names
in the Subject or Issuer fields.
PKIX is pretty clear about what is preferred re DNS names, and
putting them in the CN attribute is not the preferred answer.
Steve
From owner-ipsec@lists.tislabs.com Mon Nov 18 08:09: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 gAIG9qg04302;
Mon, 18 Nov 2002 08:09:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04363
Mon, 18 Nov 2002 10:40:49 -0500 (EST)
Message-Id: <200211181541.gAIFfEte027647@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Stephen Kent <kent@bbn.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Mon, 18 Nov 2002 09:29:27 EST.
<p05100301b9fea8c97865@[128.89.88.34]>
Date: Mon, 18 Nov 2002 16:41:14 +0100
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 mapping from names to addresses is in this statement done
>by looking the source address of received messages (i.e., address
>IKE runs over).
=> so the addresses I talk about are the outer addresses.
>This cannot provide in all cases the needed flexibility
>and safety. For instance the address can be changed "en route",
>the peer can put a rogue address (a real concern for 1+1 exchanges),
>etc. And if another mapping mechanism is used (IPaddress alternate
>Subject names in certificates, DNS/DNSsec, etc) the balance between
>flexibility and safety is not the same.
>But my main concern is that this balance is not controled: this is just
>the result of never documented implementation choices...
An intermediate IPsec device has only per-packet header data
available as a basis for making access control decisions for traffic
on an extant SA. Thus we must bind the traffic for the SA to a set of
addresses that we know about when we establish the SA. For tunnel
mode, the outer addresses can change during the SA without breaking
the SA, but the inner addresses must remain constant (or at least be
part of the same set established during SA establishment). Those
addresses cannot be changed by black routers, NAT devices, etc.,
since they are inside the protection boundary.
=> my concern is about outer addresses: we need flexibility in order
to change when needed these addresses (I believe we agree about this
point) and we need safety in order to avoid DoS attacks using SA
establishment with rogue outer addresses.
I don't think this characterization of the use of symbolic names and
mapping to addresses is an implementation choice issue, as you
suggest above. It is an architectural issue.
=> it should be an architectural issue but if the specifications
don't say anything clear about it, it becomes an implementation choice,
i.e., it follows the path we don't want.
As I have written, the revised identities proposal cuts the spurious
link between identities and addresses, so the issue can become back
an architectural one.
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Mon Nov 18 13:38:00 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id gAILbvg24651;
Mon, 18 Nov 2002 13:37:58 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04985
Mon, 18 Nov 2002 15:54:06 -0500 (EST)
Message-Id: <5.2.0.9.0.20021118154924.00b210e8@nwimap.wh.lucent.com>
X-Sender: uri@nwimap.wh.lucent.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 18 Nov 2002 15:54:06 -0500
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
From: Uri Blumenthal <uri@lucent.com>
Subject: Re: Adding revised identities to IKEv2
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
In-Reply-To: <200211181427.gAIERete027311@givry.rennes.enst-bretagne.fr>
References: <Your message of Fri, 15 Nov 2002 14:10:45 EST. <5.2.0.9.0.20021115140010.00a97298@nwimap.wh.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 15:27 11/18/2002 +0100, Francis Dupont wrote:
> In your previous mail you wrote:
>
> And replying to Francis - I'm too lazy to check myself, but wasn't cookie
> (which is
> IP address-based) used then as a part of signed contents in IKEv1
> exchange?
>
>=> the cookie is built by the other peer so the only effect is the
>addresses must remain the same between all packets of a phase,
>a check which is currently done even between phases.
>Can you explain how cookies can forbid an attacker to change en route
>or as the peer to put a rogue address in all messages?
If the cookie is a part of the signed contents, then changing IP address
of a packet during IKE exchange will invalidate the signature and will
be detected.
Of course "invisible" denial of service is always possible... I don't know
whether anything can be done to defend against it.
Later on, IP addresses used are those stored in SA, so if a cryptographically
"valid"packet comes from a "wrong" IP address, it's local policy matter what
to do with it...
A peer can put any IP address it wishes (of course), but why would it
do it - it's already free to advertise any address it chooses.
From owner-ipsec@lists.tislabs.com Mon Nov 18 13:55: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 gAILtBg25094;
Mon, 18 Nov 2002 13:55:12 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05055
Mon, 18 Nov 2002 16:26:22 -0500 (EST)
Cc: ipsec@lists.tislabs.com
Message-ID: <3DD95B2C.21D77B48@lucent.com>
Date: Mon, 18 Nov 2002 16:27:08 -0500
From: Uri Blumenthal <uri@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: David Faucher <dfaucher@lucent.com>
Original-CC: ipsec@lists.tislabs.com
Subject: Re: Generating Keying Material
References: <015301c28ce3$d8697550$23f22b42@mv.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
David Faucher wrote:
>
> Section 4.3 of draft-ietf-ipsec-ikev2-03.txt states
>
> "Keying material will always be derived as the output of the
> negotiated prf algorithm. If the amount of keying material is greater
> than the size of the output of the prf algorithm, we will use the prf
> iteratively..."
>
> Rather than having two methods for generating key material (based on the
> size of key material needed vs. the size of the prf output), wouldn't it
> easier to have prf+ generate a pseudo-random stream from which all key
> material is taken?
My understanding of PRF is that it produces a pseudo-random STREAM.
Otherwise it's not a PRF! (:-)
We can talk about it at the meeting, or at CFRG.
> Keeps it simple and straight forward.
Strongly agree.
From owner-ipsec@lists.tislabs.com Mon Nov 18 14: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 gAIMRQg26223;
Mon, 18 Nov 2002 14:27:27 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05145
Mon, 18 Nov 2002 16:53:44 -0500 (EST)
Message-Id: <200211182154.gAILsjte028719@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Uri Blumenthal <uri@lucent.com>
cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Mon, 18 Nov 2002 15:54:06 EST.
<5.2.0.9.0.20021118154924.00b210e8@nwimap.wh.lucent.com>
Date: Mon, 18 Nov 2002 22:54:45 +0100
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've just reread the pki draft so I propose to use the term
"peer source address" for the address you said it is validated
by the signature... a point I disagree about.
>=> the cookie is built by the other peer so the only effect is the
>addresses must remain the same between all packets of a phase,
>a check which is currently done even between phases.
>Can you explain how cookies can forbid an attacker to change en route
>or as the peer to put a rogue address in all messages?
If the cookie is a part of the signed contents, then changing IP address
of a packet during IKE exchange will invalidate the signature and will
be detected.
=> yes, this is the function of the cookie. But the cookie doesn't
provide any protection against a rogue address in all packets of
an IKE exchange.
Of course "invisible" denial of service is always possible... I don't know
whether anything can be done to defend against it.
=> if the address is changed en route, it is enough to include it
in something covered by the signature. If the peer itself cannot be
trusted another mechanism is needed.
Later on, IP addresses used are those stored in SA, so if a cryptographically
"valid"packet comes from a "wrong" IP address, it's local policy matter what
to do with it...
=> with a proper flexibility about addresses, this will make the "wrong" IP
address "right"... Note this only solves half of the problem of mobility
or multi-homing because SAs are negociated by pairs and the SA in the other
way will get the new address only with explicit signaling (I can develop
this point if someone is interested).
A peer can put any IP address it wishes (of course), but why would it
do it - it's already free to advertise any address it chooses.
=> I fully agree about outer addresses in IPsec SAs (even I know
a lot of implementations which drop packets with an unexpected
source address). But about the peer source address in IKE, things
are less obvious:
- end-to-end protection (safety against some DoS attacks using
IKE to redirect traffic) or not (NAT-traversal capability)
- same address during a whole exchange (with the consequence
that one-one exchange should be transformed in longer (i.e.,
using more messages) exchange to get a return routability
check... Not a new idea, remember the optional-cookie-when-
under-attack)
- capability according to a policy to change addresses between
two exchanges (IKE-SPI is here for that!)
- a new readdress exchange, etc.
Regards
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Mon Nov 18 19:48: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 gAJ3mHg11837;
Mon, 18 Nov 2002 19:48:17 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA05853
Mon, 18 Nov 2002 22:08:11 -0500 (EST)
Message-Id: <200211190308.gAJ38NII016101@sandelman.ottawa.on.ca>
To: IP Security List <ipsec@lists.tislabs.com>
Subject: IPsec archives on www.sandelman.ca
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 18 Nov 2002 22:08:22 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
Some of you have complained that my IPsec archives are not accessible.
www.sandelman.ca is aka www.tcpdump.org. It is under partial quarantine.
(It is accessible from the IETF network at this time)
The machine will get re-installed after IETF Atlanta. The intrusion
was caused in part by having too many eggs in one basket.
Likely, it will find itself duplicated into multiple machines, each
with fewer responsibilities. One effect is that the search capability
will return. There were too many contradictory dependancies for various
things, and the search was not important enough to force other things
to be broken.
] At IETF55 in Atlanta, GA | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPdmrI4qHRg3pndX9AQFXvQQA3UDJWSqJ+j6iinVckRhBSwip4uUlZe7S
uYtC4cDAFQ1qFBVnpJylA2kHoRkTSj+wOcsjqRit/fnnxL2e/SczCH9arZ+muD5/
z0iBsMm6D4uNTCabVP74+l8d7opjmFnNDqSZ+McnzHWFyZueiIEiyuR7LkiUXTlw
uAfGvCo63KA=
=BxJG
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Mon Nov 18 19:52: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 gAJ3qpg12008;
Mon, 18 Nov 2002 19:52:51 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA05861
Mon, 18 Nov 2002 22:13:14 -0500 (EST)
Message-Id: <200211190313.gAJ3DcTJ016446@sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: IPsec and DNSSEC
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 18 Nov 2002 22:13:38 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
I'm posting this since a couple of people were curious about the DNSSEC
packets that I mentioned at the WG meeting. Here is a trace from Saturday
at the DNSSEC workshop. It is not the best trace there is, but it is
pretty good example. Type43 is "DS", which tcpdump doesn't know about (yet).
Note that RSA keys stored in DNS are much smaller than CERTs.
11:23:12.728566 192.1.2.45.500 > 192.1.2.23.500: isakmp: phase 1 I ident:
(sa: doi=ipsec situation=identity
(p: #0 protoid=isakmp transform=4
(t: #0 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=3des)(type=hash value=md5)(type=auth value=rsa sig)(type=group desc value=0005))
(t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=3des)(type=hash value=sha1)(type=auth value=rsa sig)(type=group desc value=0005))
(t: #2 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=3des)(type=hash value=sha1)(type=auth value=rsa sig)(type=group desc value=modp1024))
(t: #3 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=3des)(type=hash value=md5)(type=auth value=rsa sig)(type=group desc value=modp1024)))) (DF)
11:23:12.760746 192.1.2.23.500 > 192.1.2.45.500: isakmp: phase 1 R ident:
(sa: doi=ipsec situation=identity
(p: #0 protoid=isakmp transform=1
(t: #0 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=3des)(type=hash value=md5)(type=auth value=rsa sig)(type=group desc value=0005)))) (DF)
11:23:13.111953 192.1.2.45.500 > 192.1.2.23.500: isakmp: phase 1 I ident:
(ke: key len=192)
(nonce: n len=16) (DF)
11:23:13.654194 192.1.2.23.500 > 192.1.2.45.500: isakmp: phase 1 R ident:
(ke: key len=192)
(nonce: n len=16) (DF)
11:23:14.787339 192.1.2.45.500 > 192.1.2.23.500: isakmp: phase 1 I ident[E]: [encrypted id] (DF)
At this point, we have transmitted the IDs and stuff, and here we go with
DNSSEC. Clearly we just gave the IDs away --- one of the reason we'd like to
do OE to the DNS servers as well. 192.1.2.129 is a local (fake) root name server.
11:23:14.971909 192.1.2.23.1029 > 192.1.2.129.53: 49634 [1au] KEY? 45.2.1.192.in-addr.arpa. (52) (DF)
11:23:14.996431 192.1.2.129.53 > 192.1.2.23.1029: 49634*- 2/3/7 KEY, SIG (1065) (DF)
11:23:15.024044 192.1.2.23.1029 > 192.1.2.129.53: 28790 [1au] KEY? 2.1.192.in-addr.arpa. (49) (DF)
11:23:15.071367 192.1.2.129.53 > 192.1.2.23.1029: 28790*- 2/3/5 KEY, SIG (672) (DF)
11:23:15.091019 192.1.2.23.1029 > 192.1.2.129.53: 7257 [1au] Type43? 2.1.192.in-addr.arpa. (49) (DF)
11:23:15.116719 192.1.2.129.53 > 192.1.2.23.1029: 7257- 0/4/5 (508) (DF)
11:23:15.138023 192.1.2.23.1029 > 192.1.2.129.53: 43181 [1au] Type43? 2.1.192.in-addr.arpa. (49) (DF)
11:23:15.178295 192.1.2.129.53 > 192.1.2.23.1029: 43181- 0/4/5 (508) (DF)
11:23:15.209710 192.1.2.23.1029 > 192.1.2.254.53: 23990 [1au] Type43? 2.1.192.in-addr.arpa. (49) (DF)
11:23:15.228795 192.1.2.254.53 > 192.1.2.23.1029: 23990*- 2/3/7 Type43, SIG (820) (DF)
11:23:15.254679 192.1.2.23.1029 > 192.1.2.130.53: 11995 [1au] KEY? 1.192.in-addr.arpa. (47) (DF)
11:23:15.271300 192.1.2.130.53 > 192.1.2.23.1029: 11995*- 2/3/5 KEY, SIG (668) (DF)
11:23:15.289401 192.1.2.23.1029 > 192.1.2.129.53: 30311 [1au] KEY? 192.in-addr.arpa. (45) (DF)
11:23:15.308475 192.1.2.129.53 > 192.1.2.23.1029: 30311*- 2/3/5 KEY, SIG (660) (DF)
11:23:15.325525 192.1.2.23.1029 > 192.1.2.129.53: 58800 [1au] Type43? 192.in-addr.arpa. (45) (DF)
11:23:15.344598 192.1.2.129.53 > 192.1.2.23.1029: 58800- 0/4/5 (492) (DF)
11:23:15.364417 192.1.2.23.1029 > 192.1.2.254.53: 62168 [1au] Type43? 192.in-addr.arpa. (45) (DF)
11:23:15.379614 192.1.2.254.53 > 192.1.2.23.1029: 62168*- 2/3/7 Type43, SIG (798) (DF)
11:23:15.390795 192.1.2.23.1029 > 192.1.2.130.53: 31891 [1au] A? beet.uml.freeswan.org. (50) (DF)
11:23:15.416174 192.1.2.130.53 > 192.1.2.23.1029: 31891*- 2/3/7 A 192.1.2.129, SIG (795) (DF)
11:23:15.448143 192.1.2.23.1029 > 192.1.2.130.53: 6395 [1au] KEY? in-addr.arpa. (41) (DF)
11:23:15.465954 192.1.2.130.53 > 192.1.2.23.1029: 6395*- 2/3/5 KEY, SIG (650) (DF)
11:23:15.481494 192.1.2.23.1029 > 192.1.2.129.53: 34237 [1au] KEY? arpa. (33) (DF)
11:23:15.500268 192.1.2.129.53 > 192.1.2.23.1029: 34237*- 2/3/5 KEY, SIG (624) (DF)
11:23:15.519473 192.1.2.23.1029 > 192.1.2.129.53: 17229 [1au] Type43? arpa. (33) (DF)
11:23:15.537361 192.1.2.129.53 > 192.1.2.23.1029: 17229*- 2/3/7 Type43, SIG (740) (DF)
11:23:16.700977 192.1.2.23.500 > 192.1.2.45.500: isakmp: phase 1 R ident[E]: [encrypted id] (DF)
11:23:17.053262 192.1.2.45.500 > 192.1.2.23.500: isakmp: phase 2/others I oakley-quick[E]: [encrypted hash] (DF)
...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPdmsX4qHRg3pndX9AQFzpwQAjis1BHzRVZfSnNDcf9kYYeLTf4GqfE/Z
a4RzlkmnCtBytFvQVkEIz81u5YoUY+/arisUVCZZw3xUUUl20vwJHcVZ1T3G+n/h
3/ra21WtLPgo7rNqHnNf6HCdIBRl7+Kdm5GPW+YQsyMW+i2BfOqTUmHAkZ7oJlyN
rKIHICTmmV8=
=g2NS
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Mon Nov 18 20:01: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 gAJ412g12132;
Mon, 18 Nov 2002 20:01:02 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA05899
Mon, 18 Nov 2002 22:25:17 -0500 (EST)
Message-ID: <541402FFDC56DA499E7E13329ABFEA872CE218@SARATOGA>
From: Gregory Lebovitz <Gregory@netscreen.com>
To: ipsec@lists.tislabs.com
Cc: dhartman@icsa.net
Subject: Inputs to PKI profile
Date: Mon, 18 Nov 2002 19:13:49 -0800
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
Check out the requirements draft at
http://www.projectdploy.com/draft-dploy-requirements-00.rtf
It says -00, but it is actually a 4th version of a team effort that lasted a
good 6 months. It contains a lot of details about what you are trying to
address, and should likely be heavily incorporated/merged.
Also, I would encourage you to talk with ICSA labs (Darren Hartman,
dhartman@icsa.net) who recently gained a lot of scar tissue wrt this very
topic and would likely have great perspective to share.
+*******************++********************+
Gregory M. Lebovitz
Staff Architect, CTO Office
NetScreen Technologies, Inc.
Ph: 408.730.6002
E: gregory@netscreen.com
Pg: page.gregory@netscreen.com
NASDAQ: NSCN
+*******************++********************+
From owner-ipsec@lists.tislabs.com Tue Nov 19 10:12: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 gAJIClg01726;
Tue, 19 Nov 2002 10:12:48 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07513
Tue, 19 Nov 2002 12:39:16 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: "David A. Mcgrew" <mcgrew@cisco.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
Paul Hoffman / VPNC
<paul.hoffman@vpnc.org>, ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021118200706.038df200@mail.binhost.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 18 Nov 2002 20:22:57 -0500
Subject: RE: Counter Mode Security: Analysis and Recommendations
In-Reply-To: <FPELKLHKCBJLMMMNOGDFCEOEEIAA.mcgrew@cisco.com>
References: <20021117023134.GA753@think.thunk.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
David:
Thanks for documenting this issue so clearly. The material presented here
might be new for many participants on this list, but it was discussed at
length by the design team.
During the design team, I posted the following reply when you raised this
issue. At that time, you were calling the additional random value a
salt. This paper does not seem to use the same name.
> > I have spoken to Ron Rivest about salt, and he is strongly opposed to
> > it. His reasons are pretty straightforward. First, if the salt is needed
> > to defeat a precomputation attack, then the key is too short. A better
> > countermeasure is a longer key. With AES, longer keys are readily
> > available.
While I have not spoken to Ron Rivest about this topic since the design
team, Ron was quite emphatic that the appropriate countermeasure to
precomputation attacks is longer keys. This is the reason that the counter
mode draft includes support for all three AES key sizes.
The use of the additional secret value that you propose leads to the
generation of additional keying material. If these attacks are an issue,
then I propose that it is better to use it to make a longer AES key.
There is already a discussion of precomputation attacks in the Security
Considerations section of the current draft. It says:
There are fairly generic precomputation attacks against all block
cipher modes that allow a meet-in-the-middle attack against the key.
These attacks require the creation and searching of huge tables of
ciphertext associated with known plaintext and known keys. Assuming
that the memory and processor resources are available for a
precomputation attack, then the theoretical strength of AES-CTR (and
any other block cipher mode) is limited to 2^(n/2) bits, where n is
the number of bits in the key. The use of long keys is the best
countermeasure to precomputation attacks. Therefore, implementations
that employ 128-bit AES keys should take precautions to make the
precomputation attacks more difficult. The concatenation of the
Flags, Truncated SPI, and IV fields within the counter block can be
thought of as a per-packet nonce. Repeated use of the same nonce
value (even with different keys) ought to be avoided. One approach
is to consecutively assign SPI values; however, since the only 24
bits of the SPI are included in the nonce, a SPI value provides
limited additional security.
In my view, this document is ready for working group last call.
Russ
From owner-ipsec@lists.tislabs.com Tue Nov 19 10: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 gAJICqg01748;
Tue, 19 Nov 2002 10:12:52 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07520
Tue, 19 Nov 2002 12:42:18 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15834.30716.519974.558790@thomasm-u1.cisco.com>
Date: Tue, 19 Nov 2002 09:42:20 -0800 (PST)
To: Uri Blumenthal <uri@lucent.com>
Cc: Francis Dupont <Francis.Dupont@enst-bretagne.fr>,
Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <5.2.0.9.0.20021118154924.00b210e8@nwimap.wh.lucent.com>
References: <Your message of Fri, 15 Nov 2002 14:10:45 EST. <5.2.0.9.0.20021115140010.00a97298@nwimap.wh.lucent.com>
<5.2.0.9.0.20021118154924.00b210e8@nwimap.wh.lucent.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
Uri Blumenthal writes:
> At 15:27 11/18/2002 +0100, Francis Dupont wrote:
> > In your previous mail you wrote:
> >
> > And replying to Francis - I'm too lazy to check myself, but wasn't cookie
> > (which is
> > IP address-based) used then as a part of signed contents in IKEv1
> > exchange?
> >
> >=> the cookie is built by the other peer so the only effect is the
> >addresses must remain the same between all packets of a phase,
> >a check which is currently done even between phases.
> >Can you explain how cookies can forbid an attacker to change en route
> >or as the peer to put a rogue address in all messages?
>
>
> If the cookie is a part of the signed contents, then changing IP address
> of a packet during IKE exchange will invalidate the signature and will
> be detected.
Right. Perhaps a distinction should be draw between
subsequent exchanges (eg, main/quick). It's probably
not a hardship to say the IP address must stay stable
during an exchange; what we don't want is to have to
renegotiate a new main mode SA if the IP address
changes.
Mike
From owner-ipsec@lists.tislabs.com Tue Nov 19 10: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 gAJICqg01747;
Tue, 19 Nov 2002 10:12:52 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07512
Tue, 19 Nov 2002 12:39:16 -0500 (EST)
X-Originating-IP: [64.230.108.47]
From: "Andrew Krywaniuk" <askrywan@hotmail.com>
To: kent@bbn.com
Cc: ipsec@lists.tislabs.com
Subject: RE: Suites vs a-la-carte
Date: Mon, 18 Nov 2002 19:36:49 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F88pWd7KKQpQq5pneeF000002c5@hotmail.com>
X-OriginalArrivalTime: 19 Nov 2002 00:36:49.0585 (UTC) FILETIME=[BF6BEA10:01C28F63]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>I've gotten some feedback from the DoD community that they would like to be
>able to use commercial IPsec products in appropriate contexts, but that
>they need to be able to configure their own DH groups. If we mandate
>user-configurable algorithms/suites in IKEv2, then these folks, and maybe
>others, will be able to buy these products and use them in
>environments where the mandatory-to-implement suites do not suffice.
Yes, that was also part of my rationale. I wrote about this back in the
"last ditch proposal for ciphersuites" thread, but I went into less detail
this time. The way our products worked is that you could select a
ciphersuite from a droplist, but the information in the droplist was taken
from a ciphersuite definition file. This meant that you could customize the
ciphersuites for a specific customer without adding lots of confusing
options to the GUI.
Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
From owner-ipsec@lists.tislabs.com Tue Nov 19 10:53: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 gAJIrbg02865;
Tue, 19 Nov 2002 10:53:38 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07729
Tue, 19 Nov 2002 13:28:06 -0500 (EST)
Message-Id: <200211191829.gAJIT6te031844@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Michael Thomas <mat@cisco.com>
cc: Uri Blumenthal <uri@lucent.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Tue, 19 Nov 2002 09:42:20 PST.
<15834.30716.519974.558790@thomasm-u1.cisco.com>
Date: Tue, 19 Nov 2002 19:29:06 +0100
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:
Right. Perhaps a distinction should be draw between
subsequent exchanges (eg, main/quick). It's probably
not a hardship to say the IP address must stay stable
during an exchange; what we don't want is to have to
renegotiate a new main mode SA if the IP address
changes.
=> I agree at 100%!
Thanks
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Tue Nov 19 14:36: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 gAJMaqg23292;
Tue, 19 Nov 2002 14:36:52 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08401
Tue, 19 Nov 2002 17:01:13 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15834.46260.21749.515468@pkoning.dev.equallogic.com>
Date: Tue, 19 Nov 2002 17:01:24 -0500
From: Paul Koning <pkoning@equallogic.com>
To: mcgrew@cisco.com
Cc: tytso@mit.edu, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com
Subject: RE: Counter Mode Security: Analysis and Recommendations
References: <20021117023134.GA753@think.thunk.org>
<FPELKLHKCBJLMMMNOGDFCEOEEIAA.mcgrew@cisco.com>
X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "David" == David A Mcgrew <mcgrew@cisco.com> writes:
David> Randomly setting the initial value of the 64-bit explicit IV
David> of draft-ietf-ipsec-ciph-aes-ctr-01 does *not* protect against
David> the precomputation attacks described in the writeup. This is
David> because all values of that IV will be used during the lifetime
David> of a key. So an attacker can pick any value of the IV during
David> its precomputation stage, then wait for the corresponding
David> packet to appear in the data stream protected by a particular
David> key before attacking that key. ...
Given that counter mode is limited to 2^64 blocks, all values of the
IV are used only if every packet contains at most 16 bytes. But
admittedly in many data streams the average packet size is not
dramatically bigger than the block size. (If the average packet size
is <= 128 bytes, then you get the same gain in the TMTO attack if you
increase the table size by a factor of 8.)
David> What I'm suggesting is that there be a distinct field in in
David> the counter which is unpredictable. In principle, counter
David> mode *can* have a 64-bit randomizer because the limitation
David> that no more than 2^64 blocks can be generated implies that 64
David> bits suffice to index all of those blocks. So the block
David> counter and IV fields together need not occupy more than 64
David> bits.
David> Here's a concrete proposal: reduce the block counter to 16
David> bits and the IV to 48 bits, and replace the 'truncated spi'
David> field with a 56-bit field that is set randomly at key setup
David> time. This field should be considered part of the key, so
David> that key setup is easy. This proposal has the following
David> advantages: better security than the current draft, and the
David> independence of the cipher from the SPI allocation. It has
David> the following minor disadvantage: it cannot encrypt ipv6
David> jumbograms.
David> As an aside, the 8-bit 'flags' field prevents us from making
David> the randomizer field 64 bits long. I'd prefer 64 bits but
David> would happy to get 56.
Could we drop the flags byte? I can't see much point in having a
field that provides compatibility with a different transform, because
by definition we're not using that transform when we're using the
AES-CTR transform...
David> An important point about the current draft is that, while it
David> aims to admit a variety of implementation strategies, it
David> excludes the cryptographically conservative one. In my
David> opinion, that would be a mistake.
David> In the interest of moving the WG forward on the issue, I
David> suggest that we solicit WG input on the following questions:
David> 1) is a security level lower than that recommended for
David> commercial encryption (88 bits) considered acceptable?
NO way.
David> 2) is a limitation to encrypting packets less than 64kb in
David> length considered acceptable?
You mean "is it acceptable to limit packets to be 64k or less?" If
you make the block counter 16 bits, then the actual packet size limit
is 1 megabyte because blocks are 16 bytes... That's fine.
David> 3) if you could answer "yes" to only one of the above
David> questions, which would it be?
David> 4) is it acceptable to implement AES-192 or AES-256 and use
David> those ciphers for counter mode? Or is it desirable to use
David> AES-128 for both CBC and counter mode?
I would hate to depend on AES-192 or above, since it's not clear to me
how widely those will initialy be implemented in high speed silicon.
paul
From owner-ipsec@lists.tislabs.com Tue Nov 19 14:56: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 gAJMu8g24821;
Tue, 19 Nov 2002 14:56:09 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08494
Tue, 19 Nov 2002 17:33:33 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f26ba006c7e2075@[204.42.71.167]>
In-Reply-To: <200211190308.gAJ38NII016101@sandelman.ottawa.on.ca>
References: <200211190308.gAJ38NII016101@sandelman.ottawa.on.ca>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 19 Nov 2002 17:33:15 -0500
To: IP Security List <ipsec@lists.tislabs.com>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: IPsec archives on www.sandelman.ca
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In the meantime, there is another archive at <http://www.vpnc.org/ietf-ipsec/>.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Tue Nov 19 15:37: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 gAJNbkg26158;
Tue, 19 Nov 2002 15:37:46 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08625
Tue, 19 Nov 2002 18:11:08 -0500 (EST)
Message-Id: <200211192311.gAJNBZfR004480@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@east.sun.com>
To: Paul Koning <pkoning@equallogic.com>
cc: mcgrew@cisco.com, tytso@mit.edu, paul.hoffman@vpnc.org,
ipsec@lists.tislabs.com
Subject: Re: Counter Mode Security: Analysis and Recommendations
In-Reply-To: Your message of "Tue, 19 Nov 2002 17:01:24 EST."
<15834.46260.21749.515468@pkoning.dev.equallogic.com>
Reply-to: sommerfeld@east.sun.com
Date: Tue, 19 Nov 2002 18:11:35 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> You mean "is it acceptable to limit packets to be 64k or less?" If
> you make the block counter 16 bits, then the actual packet size limit
> is 1 megabyte because blocks are 16 bytes... That's fine.
There's an effort underway to investigate much larger packet sizes as
link speed increases.
See http://www.psc.edu/~mathis/MTU/
- Bill
From owner-ipsec@lists.tislabs.com Tue Nov 19 17:49: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 gAK1nag02948;
Tue, 19 Nov 2002 17:49:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08887
Tue, 19 Nov 2002 20:25:07 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15834.58547.654111.747142@pkoning.akdesign.com>
Date: Tue, 19 Nov 2002 20:26:11 -0500
From: Paul Koning <pkoning@equallogic.com>
To: sommerfeld@east.sun.com
Cc: mcgrew@cisco.com, tytso@mit.edu, paul.hoffman@vpnc.org,
ipsec@lists.tislabs.com
Subject: Re: Counter Mode Security: Analysis and Recommendations
References: <15834.46260.21749.515468@pkoning.dev.equallogic.com>
<200211192311.gAJNBZfR004480@thunk.east.sun.com>
X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Bill" == Bill Sommerfeld <sommerfeld@east.sun.com> writes:
>> You mean "is it acceptable to limit packets to be 64k or less?"
>> If you make the block counter 16 bits, then the actual packet size
>> limit is 1 megabyte because blocks are 16 bytes... That's fine.
Bill> There's an effort underway to investigate much larger packet
Bill> sizes as link speed increases.
Bill> See http://www.psc.edu/~mathis/MTU/
That's fine, but if I have to choose between that, and a counter mode
that's 12 orders of magnitude less secure than it should be, I'll pick
the latter, always.
paul
From owner-ipsec@lists.tislabs.com Tue Nov 19 19:04: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 gAK34Kg05246;
Tue, 19 Nov 2002 19:04:21 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA09015
Tue, 19 Nov 2002 21:36:31 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15834.55168.933346.42408@thomasm-u1.cisco.com>
Date: Tue, 19 Nov 2002 16:29:52 -0800 (PST)
To: Stephen Kent <kent@bbn.com>
Cc: Michael Thomas <mat@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <p05100302b9feaa1dc87a@[128.89.88.34]>
References: <200211151352.gAFDqite016645@givry.rennes.enst-bretagne.fr>
<3DD17A5E.E2C8B38A@lucent.com>
<5.2.0.9.0.20021115140010.00a97298@nwimap.wh.lucent.com>
<15829.19435.623711.682955@thomasm-u1.cisco.com>
<p05100302b9feaa1dc87a@[128.89.88.34]>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent writes:
> At 11:32 AM -0800 11/15/02, Michael Thomas wrote:
> >The second is the classification/filtering
> >operation after the packet is integrity checked.
> >This is just the normal 5-tuple filtering which
> >may or may not pay attention to the source address
> >(ie, it could be wildcarded).
>
> in principle the SPD entry for this SA might wild card the source
> address, but in practice we create pairs of SAs and the IP address
> for outbound traffic in the matching SA must be constrained in some
> fashion, typically by specifying a single IP address or address range
> (or mask), to ensure that all traffic destined to a host or set of
> hosts is mapped to an SA that terminates at an IPsec implementation
> serving that host or set of hosts.
This is clearly a trade off. Your network security, is my
mobile hositility :)
Mike
From owner-ipsec@lists.tislabs.com Wed Nov 20 06:58: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 gAKEw6g14475;
Wed, 20 Nov 2002 06:58:06 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10385
Wed, 20 Nov 2002 09:15:58 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C28FFB.AED8F4F6"
Subject: What would be the main difference between the ...
Date: Tue, 19 Nov 2002 10:44:25 -0800
Message-ID: <C0D4C89202149845BB2F176451F9F87428D2B0@sdontfps01.iomegacorp.com>
Thread-Topic: What would be the main difference between the ...
Thread-Index: AcKP+65CWrxFaet4QfyMKH72Aw5IZA==
From: "Sukanta Ganguly" <ganguly@iomega.com>
To: <gsec@lists.tislabs.com>
X-OriginalArrivalTime: 19 Nov 2002 18:44:25.0942 (UTC) FILETIME=[AF3DC760:01C28FFB]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------_=_NextPart_001_01C28FFB.AED8F4F6
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
What would be the main difference between the Client-Server and the
Member-Controller models? I see the Member-Controller model being a
special case of the Client - Server model! I was wondering if I missed
something in the presentation.
=20
=20
SG
------_=_NextPart_001_01C28FFB.AED8F4F6
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2715.400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D076264218-19112002><FONT face=3DArial=20
size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D076264218-19112002><FONT face=3DArial size=3D2> =
What would be=20
the main difference between the Client-Server and the Member-Controller =
models?=20
I see the Member-Controller model being a special case of the Client - =
Server=20
model! I was wondering if I missed something in the=20
presentation.</FONT></SPAN></DIV>
<DIV><SPAN class=3D076264218-19112002><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D076264218-19112002><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D076264218-19112002><FONT face=3DArial=20
size=3D2>SG</FONT></SPAN></DIV></BODY></HTML>
=00
------_=_NextPart_001_01C28FFB.AED8F4F6--
From owner-ipsec@lists.tislabs.com Wed Nov 20 12:24: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 gAKKOag06729;
Wed, 20 Nov 2002 12:24:36 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11089
Wed, 20 Nov 2002 14:43:47 -0500 (EST)
Message-ID: <00b301c290cd$cd3b34a0$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Subject: Deleting SAs
Date: Wed, 20 Nov 2002 13:48:28 -0600
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Questions on draft-ietf-ipsec-ikev2-03.txt section 3.3
The 6th paragraph describes the process of deleting SAs
and has some confusing text. Is my understanding correct?
- A node that initiates a delete request places into
delete payloads the SPIs for its incoming SAs.
- A node that receives a delete request would close the
outgoing SAs that correspond to the SPIs received in
the delete payloads. Additionally, it would respond by
placing into delete payloads the SPIs for its paired
incoming SAs.
- If by chance the delete requests for two nodes pass
in transit then the responses do not contain any delete
payloads. In other words, an SPI for a given SA must not
appear in more than one delete payload.
The 7th paragraph describes half-open connections where
"A node MAY refuse to accept incoming data on half open
connections but MUST NOT...".
Since a node that initiates a delete request is deleting
its incoming SA, it is not possible to have a half open
connection where the outgoing SA is closed but the
incoming is still active.
David
From owner-ipsec@lists.tislabs.com Wed Nov 20 15:28: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 gAKNSfg18638;
Wed, 20 Nov 2002 15:28:41 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11536
Wed, 20 Nov 2002 17:53:13 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05111a06ba01bba02a64@[204.42.67.13]>
In-Reply-To: <15834.55168.933346.42408@thomasm-u1.cisco.com>
References: <200211151352.gAFDqite016645@givry.rennes.enst-bretagne.fr>
<3DD17A5E.E2C8B38A@lucent.com>
<5.2.0.9.0.20021115140010.00a97298@nwimap.wh.lucent.com>
<15829.19435.623711.682955@thomasm-u1.cisco.com>
<p05100302b9feaa1dc87a@[128.89.88.34]>
<15834.55168.933346.42408@thomasm-u1.cisco.com>
Date: Wed, 20 Nov 2002 17:32:35 -0500
To: Michael Thomas <mat@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Adding revised identities to 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:29 PM -0800 11/19/02, Michael Thomas wrote:
>Stephen Kent writes:
> > At 11:32 AM -0800 11/15/02, Michael Thomas wrote:
> > >The second is the classification/filtering
> > >operation after the packet is integrity checked.
> > >This is just the normal 5-tuple filtering which
> > >may or may not pay attention to the source address
> > >(ie, it could be wildcarded).
> >
> > in principle the SPD entry for this SA might wild card the source
> > address, but in practice we create pairs of SAs and the IP address
> > for outbound traffic in the matching SA must be constrained in some
> > fashion, typically by specifying a single IP address or address range
> > (or mask), to ensure that all traffic destined to a host or set of
> > hosts is mapped to an SA that terminates at an IPsec implementation
> > serving that host or set of hosts.
>
>This is clearly a trade off. Your network security, is my
>mobile hositility :)
>
> Mike
I would not want to be portrayed as hostile to mobile users :-), but
I do note that if one puts a wildcard source address for the source
IP address in an SPD entry, then one enables the peer IPsec to
masquerade as any possible source. This falls into the category that
yes, you could do this, but you may be sorry! This clearly requires
an asymmetric SPD entry, since you do need to know the source address
to select the right outbound SA.
Steve
From owner-ipsec@lists.tislabs.com Wed Nov 20 15:30: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 gAKNUrg18792;
Wed, 20 Nov 2002 15:30:53 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11561
Wed, 20 Nov 2002 18:01:18 -0500 (EST)
Date: Wed, 20 Nov 2002 15:58:44 -0700
Message-Id: <200211202258.gAKMwi519601@localhost.localdomain>
From: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
To: rhousley@rsasecurity.com
Cc: ipsec@lists.tislabs.com
In-reply-to: Yourmessage <5.1.0.14.2.20021118200706.038df200@mail.binhost.com>
Subject: RE: Counter Mode Security: Analysis and Recommendations
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The basic question is whether or not a cipher that is susceptible to
an attack requiring 2^88 bytes of storage is acceptable for an IPsec
standard. Were this a voting organization, I'd vote no.
The implication of this, should others agree, would be that something
would have to change in the proposed counter mode. All parties appear
to agree that a longer key for the cipher is a solution. Thus, I'd
expect everyone to agree that the draft should say that AES with
192-bit or 256-bit keys is a MUST for counter mode. If there's no
agreement on such an obvious point, then call the whole thing off.
Why, though, would one (even Rivest) be more willing to accept a
slower cipher than to generate more keying material at the start?
I've got a few nits about the draft. The phrase "As such," is always
useless and should be excised. There's a phrase "need not be full 128
bits" that needs fixing. It is redundant to specify the number of AES
rounds for use with each key size, because it leads to the thought
that the AES standard leaves the choice open to the user. The section
on the counter block is a little confusing because it looks like the
counter block is on the wire. Terminology that leads to a phrase "AES
counter block cipher block" is saddening.
Hilarie
From owner-ipsec@lists.tislabs.com Wed Nov 20 15:58: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 gAKNwJg19649;
Wed, 20 Nov 2002 15:58:20 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11620
Wed, 20 Nov 2002 18:28:29 -0500 (EST)
From: "David A. Mcgrew" <mcgrew@cisco.com>
To: "Housley, Russ" <rhousley@rsasecurity.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
"Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>, <ipsec@lists.tislabs.com>
Subject: RE: Counter Mode Security: Analysis and Recommendations
Date: Wed, 20 Nov 2002 12:01:25 -0800
Message-ID: <FPELKLHKCBJLMMMNOGDFAEEPEJAA.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)
Importance: Normal
In-Reply-To: <5.1.0.14.2.20021118200706.038df200@mail.binhost.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Russ,
yes, Rivest's recommendation provides equivalent protection, but at a higher
implementation cost. The larger AES key sizes require more computation, and are
not actually required of an AES implementation. Perhaps this increased
implementation cost is an acceptable tradeoff to the WG. I favor the lower
implementation cost solution since resources are a premium in embedded systems
and many network devices.
David
> -----Original Message-----
> From: Housley, Russ [mailto:rhousley@rsasecurity.com]
> Sent: Monday, November 18, 2002 5:23 PM
> To: David A. Mcgrew
> Cc: Theodore Ts'o; Paul Hoffman / VPNC; ipsec@lists.tislabs.com
> Subject: RE: Counter Mode Security: Analysis and Recommendations
>
>
> David:
>
> Thanks for documenting this issue so clearly. The material presented here
> might be new for many participants on this list, but it was discussed at
> length by the design team.
>
> During the design team, I posted the following reply when you raised this
> issue. At that time, you were calling the additional random value a
> salt. This paper does not seem to use the same name.
>
> > > I have spoken to Ron Rivest about salt, and he is strongly opposed to
> > > it. His reasons are pretty straightforward. First, if the salt is needed
> > > to defeat a precomputation attack, then the key is too short. A better
> > > countermeasure is a longer key. With AES, longer keys are readily
> > > available.
>
> While I have not spoken to Ron Rivest about this topic since the design
> team, Ron was quite emphatic that the appropriate countermeasure to
> precomputation attacks is longer keys. This is the reason that the counter
> mode draft includes support for all three AES key sizes.
>
> The use of the additional secret value that you propose leads to the
> generation of additional keying material. If these attacks are an issue,
> then I propose that it is better to use it to make a longer AES key.
>
> There is already a discussion of precomputation attacks in the Security
> Considerations section of the current draft. It says:
>
> There are fairly generic precomputation attacks against all block
> cipher modes that allow a meet-in-the-middle attack against the key.
> These attacks require the creation and searching of huge tables of
> ciphertext associated with known plaintext and known keys. Assuming
> that the memory and processor resources are available for a
> precomputation attack, then the theoretical strength of AES-CTR (and
> any other block cipher mode) is limited to 2^(n/2) bits, where n is
> the number of bits in the key. The use of long keys is the best
> countermeasure to precomputation attacks. Therefore, implementations
> that employ 128-bit AES keys should take precautions to make the
> precomputation attacks more difficult. The concatenation of the
> Flags, Truncated SPI, and IV fields within the counter block can be
> thought of as a per-packet nonce. Repeated use of the same nonce
> value (even with different keys) ought to be avoided. One approach
> is to consecutively assign SPI values; however, since the only 24
> bits of the SPI are included in the nonce, a SPI value provides
> limited additional security.
>
> In my view, this document is ready for working group last call.
>
> Russ
>
From owner-ipsec@lists.tislabs.com Wed Nov 20 17:06: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 gAL16og22613;
Wed, 20 Nov 2002 17:06:51 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11774
Wed, 20 Nov 2002 19:37:03 -0500 (EST)
Message-ID: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
From: Bob Doud <BDoud@hifn.com>
To: "'Paul Koning'" <pkoning@equallogic.com>, mcgrew@cisco.com
Cc: tytso@mit.edu, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com
Subject: RE: Counter Mode Security: Analysis and Recommendations
Date: Wed, 20 Nov 2002 16:37:57 -0800
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
> >>>>> "David" == David A Mcgrew <mcgrew@cisco.com> writes:
<snip>
>
> David> 4) is it acceptable to implement AES-192 or AES-256 and use
> David> those ciphers for counter mode? Or is it desirable to use
> David> AES-128 for both CBC and counter mode?
>
> I would hate to depend on AES-192 or above, since it's not clear to me
> how widely those will initialy be implemented in high speed silicon.
>
> paul
And let's keep in mind that a fundamental reason that we're pursuing
counter mode in the first place is for high-performance as systems
move into the multi-Gigabit range. (Parallelizing the crypto operations
across multiple engines with staggered counters.) It's safe to say that
all hardware and software implementations will be noticably slower with
AES-256 than with AES-128.
Bob
From owner-ipsec@lists.tislabs.com Wed Nov 20 19:21:02 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 gAL3L2g28556;
Wed, 20 Nov 2002 19:21:02 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12184
Wed, 20 Nov 2002 21:48:06 -0500 (EST)
Date: Wed, 20 Nov 2002 21:48:46 -0500
From: "Theodore Ts'o" <tytso@mit.edu>
To: Bob Doud <BDoud@hifn.com>
Cc: "'Paul Koning'" <pkoning@equallogic.com>, mcgrew@cisco.com,
paul.hoffman@vpnc.org, ipsec@lists.tislabs.com
Subject: Re: Counter Mode Security: Analysis and Recommendations
Message-ID: <20021121024845.GA792@think.thunk.org>
References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
User-Agent: Mutt/1.3.28i
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Wed, Nov 20, 2002 at 04:37:57PM -0800, Bob Doud wrote:
> > >>>>> "David" == David A Mcgrew <mcgrew@cisco.com> writes:
> <snip>
> >
> > David> 4) is it acceptable to implement AES-192 or AES-256 and use
> > David> those ciphers for counter mode? Or is it desirable to use
> > David> AES-128 for both CBC and counter mode?
> >
> > I would hate to depend on AES-192 or above, since it's not clear to me
> > how widely those will initialy be implemented in high speed silicon.
> >
> And let's keep in mind that a fundamental reason that we're pursuing
> counter mode in the first place is for high-performance as systems
> move into the multi-Gigabit range. (Parallelizing the crypto operations
> across multiple engines with staggered counters.) It's safe to say that
> all hardware and software implementations will be noticably slower with
> AES-256 than with AES-128.
The speed hit to go from AES-128 to AES-192 is about 20% (12 rounds
versus 10 rounds). But that's assuming that folks feel this is
actually necessary.
I want to make sure that everyone in the IPSEC working group
understands that the TMTO attack requires only O(2**85) in time, but
it also requires O(2**85) in space. That means that in order to carry
out this attack, the attacker needs to have access to order of
magnitude 512 yottabytes of storage. (For those who aren't familiar
with the SI prefixes, that's kilo-, mega-, giga-, tera-, peta-, exa-,
zetta-, yotta-).
It's hard to describe how much space this is. Currently, the biggest
single system commercially available from IBM and EMC (the Shark and
Symmetrix products, respectively) is 60-70 terabytes. The ASCI
Purple, which is an incredibly large system for simulating atomic bomb
explosions at close to the atomic level, and which will probably end
up costing at least tens of billions of dollars, calls for 1.2
petabytes. CERN estimates that by 2007, they will hopefully have 2.4
petabytes of disk storage. Now, 512 yottabytes is 400,000,000 times
bigger.
Now, I'm willing to believe that the NSA has a much bigger budget than
the Atomic Bomb folks --- but I'm not sure they have a budget which is
a factor of four hundred million times bigger.
Speaking of budgets, using an estimate of $2,500/terrabyte, the
storage required to carry out this attack would cost approximately
$1,000,000,000,000,000,000 US dollars. That's approximately 200
hundred thousand times the current US National Debt, and a million
times the current U.S. Federal budget. So when it was stated that
this would require a "well funded" attacker, this was rather somewhat
of an understatement. Even if the prices declined to a penny a
terrabyte (which might happen by 2023, according to some estimates, if
storage breakthroughs can continue to happen at current spaces), it
would still cost $5,000,000,000,000,000, which is still approximately
a thousand times the current U.S. National Debt. (Of course, by 2023,
the U.S. National Debt will no doubt be much larger!)
Of course, this estimate completely ignores the overhead in indexing
this much data for fast access, and the amount of time it would take
to *write* 512 yottabytes worth of data. (At today's rates of 100
megabytes/second, it would take quite a while.)
The bottom line is that it's not at all clear to me (with my working
group chair off) the TMTO attack against AES-128 counter mode is
really realistic. Furthermore, as I pointed out at the IPSEC working
group, the recommendation of 75 bits worth of keyspace in the ad-hoc
key-length paper assumed brute-force attacks using large numbers of
fast, specialized FPGA's with relatively insignificant amounts of
storage --- hundreds of bytes, not 512 yottabytes of storage. So the
claim that the strength of AES Counter mode with a 128-bit key has
fallen below the cipher strength of as recommended by the ad-hoc
keylength paper seems to involve an apples vs oranges comparison.
That being said, there has been a number of hallway discussions about
some other ways in which we could add some additional bits of
unpredictability with minimal disruptions to the drafts, regardless of
whether it is not necessary. It might not add as many bits as you had
suggested, but (again with my working group chair hat off), I'm still
not convinced that this attack, and thus the requirement to defend
against it, is really realistic. Personally speaking, requiring an
additional 20% overhead for those people who are worried about what
seems like a largely theoretical concern doesn't seem like a horrible
thing.
- Ted
From owner-ipsec@lists.tislabs.com Wed Nov 20 23:48: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 gAL7mHg18812;
Wed, 20 Nov 2002 23:48:18 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12755
Thu, 21 Nov 2002 02:14:10 -0500 (EST)
Message-Id: <3.0.3.32.20021120231356.01ab1b80@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Wed, 20 Nov 2002 23:13:56 -0800
To: Bob Doud <BDoud@hifn.com>, "'Paul Koning'" <pkoning@equallogic.com>,
mcgrew@cisco.com
From: Alex Alten <Alten@attbi.com>
Subject: RE: Counter Mode Security: Analysis and Recommendations
Cc: tytso@mit.edu, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com
In-Reply-To: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 04:37 PM 11/20/2002 -0800, Bob Doud wrote:
>> >>>>> "David" == David A Mcgrew <mcgrew@cisco.com> writes:
><snip>
>>
>> David> 4) is it acceptable to implement AES-192 or AES-256 and use
>> David> those ciphers for counter mode? Or is it desirable to use
>> David> AES-128 for both CBC and counter mode?
>>
>> I would hate to depend on AES-192 or above, since it's not clear to me
>> how widely those will initialy be implemented in high speed silicon.
>>
>> paul
>
>And let's keep in mind that a fundamental reason that we're pursuing
>counter mode in the first place is for high-performance as systems
>move into the multi-Gigabit range. (Parallelizing the crypto operations
>across multiple engines with staggered counters.) It's safe to say that
>all hardware and software implementations will be noticably slower with
>AES-256 than with AES-128.
>
>Bob
>
Really? And all these expensive parallel hardware engines will still be
effective on the receiving end when packets arrive out of order, are lost,
duplicated or fragmented? What about interleaved packet streams from
different hosts? What about hash computations?
And who will buy them? 1 Gigabit/sec cards go for $50 today. The cheapest
AES chips are $25 each, which is $125 retail. You will need about 4 of
them at least. So now that card becomes a $500 card. Ten times as expensive.
By the time they become cheap enough the world will be using 10 gigabit/sec
Ethernet.
I think counter mode is interesting for another reason, it is certainly
not speed.
- Alex
--
Alex Alten
Alten@ATTBI.com
"I said be there.
And you crushed the stones to be there."
- Genghis Khan, 13th century
From owner-ipsec@lists.tislabs.com Thu Nov 21 04:19: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 gALCJRg22961;
Thu, 21 Nov 2002 04:19:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13172
Thu, 21 Nov 2002 06:52:32 -0500 (EST)
Message-ID: <C1590740235CD211BA5600A0C9E1F6FF0507C242@hydmail>
From: Harshwardhan Mittal <mittal@mihy.mot.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Generating the DES key
Date: Thu, 21 Nov 2002 17:01:31 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
What is the standard way to generate DES keys?
Is there any standard for it?
Regards,
Harsh
----------------------------------------
Harsh Mittal
Software Engineer
Motorola India Electronics Ltd.
Hyderabad, India.
From owner-ipsec@lists.tislabs.com Thu Nov 21 06:07: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 gALE7fg02621;
Thu, 21 Nov 2002 06:07:41 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13395
Thu, 21 Nov 2002 08:38:04 -0500 (EST)
Message-Id: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10>
X-Sender: lokeshnb@172.16.1.10
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 21 Nov 2002 19:13:59 +0530
To: ipsec@lists.tislabs.com
From: Lokesh <lokeshnb@intotoinc.com>
Subject: SPD policy document/article
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
I'm looking for a document or article where a SPD policy's all complexities
and intricacies are
explained better in detail. If there is one please let me know the link.
Basically, I'm looking for configuration and behavior of SPD and
IPSec that generate
1] mutiple SA Bundles in a policy
2] configuration of SPD policy that generate SA Bundles containing SAs
terminating at different tunnel
end points etc ..
3] IPsec operation and policy configuration for Road worrier case.
Thanks in Advance
Lokesh
From owner-ipsec@lists.tislabs.com Thu Nov 21 08:14: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 gALGEeg14591;
Thu, 21 Nov 2002 08:14:40 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13829
Thu, 21 Nov 2002 10:42:36 -0500 (EST)
Subject: Need Guidelines for IKE key generation (SKEYID, KEYMAT and their variants)
From: venkat <venkat@dexceldesigns.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Date: 21 Nov 2002 21:22:15 +0530
Message-Id: <1037893941.2559.100.camel@venkat>
Mime-Version: 1.0
X-Mailserver: Sent using PostMaster (v4.1.13)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
My Machine
----------
Linux venkat 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386
GNU/Linux
This is i386 arch machine with a little-endian arch
I am using the GNU Mathematical Precision Library (gmp) for DH
exponentiation, but i seem to have to some problems
(1). To use the g^xy variable in the gmp lib I access the internals of
the gmp variable, the gmp stores the variable in little endian way.
Can I just memcpy the contents of the gmp variable into a buffer and run
my prf() on it?
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)
(2) Or should I convert the variable into Big endian and then memcpy it
into my buffer to run prf()
(3) What about the 64 bit Cookie field should I convert it to network
order before any mathematical(crypto) operations and I use the values
directly as it is stored in the memory. (Ignoring any arch features)
I think this is a critical features for interop. and doing anything
wrong can really put my ike to the trash.
Is there any standard test cases or any documents at all which verifies
the SKEYID, KEYMAT generation, some thing like take these inputs and
verify them with the standard set results
Anything of this sort a test document could be of great help
--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
From owner-ipsec@lists.tislabs.com Thu Nov 21 08:15: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 gALGFcg14736;
Thu, 21 Nov 2002 08:15:38 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13849
Thu, 21 Nov 2002 10:46:37 -0500 (EST)
Message-ID: <015d01c2916d$7d849960$0601a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <ipsec@lists.tislabs.com>
Subject: IPsec Global Summit & Deploying IPv6 Conference
Date: Thu, 21 Nov 2002 15:51:35 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_015A_01C29175.DEDB2460"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_015A_01C29175.DEDB2460
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
"Deploying IPv6 Networks" second edition and "IPsec Global Summit" =
fourth edition will be held at the same time in Paris La Defense from 3 =
to 6 December.=20
The concurrence of these two events will result in a panel of =
specialists from these two closely knit areas of interest without =
precedent.=20
Get all details at:
http://www.upperside.fr/ipsec02/ipv6etipsec.htm
------=_NextPart_000_015A_01C29175.DEDB2460
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><SPAN=20
class=3Dtitresession><SPAN class=3Dtexte>"<SPAN =
class=3Dtextebold>Deploying IPv6=20
Networks</SPAN>" second edition and "<SPAN class=3Dtextebold>IPsec =
Global=20
Summit</SPAN>" fourth edition will be held at the same time in Paris La =
Defense=20
from 3 to 6 December.</SPAN></SPAN>=20
<DIV><FONT size=3D2><SPAN class=3Dtitresession><SPAN class=3Dtexte><SPAN =
class=3Dtitreinterventions><SPAN class=3Dtexte>The concurrence of these =
two events=20
will result in a panel of specialists from these two closely knit areas =
of=20
interest without precedent. <BR><FONT size=3D2><SPAN =
class=3Dtitresession><SPAN=20
class=3Dtexte><SPAN class=3Dtitreinterventions>Get all details=20
at:</SPAN></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN></FONT></DIV>
<DIV><FONT size=3D2><SPAN class=3Dtitresession><FONT =
color=3D#996699><SPAN=20
class=3Dtexte><FONT color=3D#000000><SPAN =
class=3Dtitreinterventions><SPAN=20
class=3Dtexte><FONT size=3D2><SPAN class=3Dtitresession><FONT =
color=3D#996699><SPAN=20
class=3Dtexte><FONT color=3D#000000><SPAN class=3Dtitreinterventions><A=20
href=3D"http://www.upperside.fr/ipsec02/ipv6etipsec.htm">http://www.upper=
side.fr/ipsec02/ipv6etipsec.htm</A><BR></SPAN></FONT></SPAN></FONT></SPAN=
></FONT></SPAN></SPAN></FONT></SPAN></FONT></SPAN></FONT></FONT></FONT><F=
ONT=20
face=3DArial size=3D2></FONT></DIV></DIV></BODY></HTML>
------=_NextPart_000_015A_01C29175.DEDB2460--
From owner-ipsec@lists.tislabs.com Thu Nov 21 09: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 gALHOMg18479;
Thu, 21 Nov 2002 09:24:22 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14207
Thu, 21 Nov 2002 11:52:53 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15837.3954.124006.75966@pkoning.dev.equallogic.com>
Date: Thu, 21 Nov 2002 11:53:06 -0500
From: Paul Koning <pkoning@equallogic.com>
To: tytso@mit.edu
Cc: BDoud@hifn.com, mcgrew@cisco.com, paul.hoffman@vpnc.org,
ipsec@lists.tislabs.com
Subject: Re: Counter Mode Security: Analysis and Recommendations
References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
<20021121024845.GA792@think.thunk.org>
X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Theodore" == Theodore Ts'o <tytso@mit.edu> writes:
Theodore> On Wed, Nov 20, 2002 at 04:37:57PM -0800, Bob Doud wrote:
>> > >>>>> "David" == David A Mcgrew <mcgrew@cisco.com> writes:
>> <snip>
>> >
>> > David> 4) is it acceptable to implement AES-192 or AES-256 and
>> use > David> those ciphers for counter mode? Or is it desirable
>> to use > David> AES-128 for both CBC and counter mode?
>> >
>> > I would hate to depend on AES-192 or above, since it's not clear
>> to me > how widely those will initialy be implemented in high
>> speed silicon.
>> >
>> And let's keep in mind that a fundamental reason that we're
>> pursuing counter mode in the first place is for high-performance
>> as systems move into the multi-Gigabit range. (Parallelizing the
>> crypto operations across multiple engines with staggered
>> counters.) It's safe to say that all hardware and software
>> implementations will be noticably slower with AES-256 than with
>> AES-128.
Theodore> The speed hit to go from AES-128 to AES-192 is about 20%
Theodore> (12 rounds versus 10 rounds). But that's assuming that
Theodore> folks feel this is actually necessary.
Theodore> I want to make sure that everyone in the IPSEC working
Theodore> group understands that the TMTO attack requires only
Theodore> O(2**85) in time, but it also requires O(2**85) in space.
That's true. But the real question is: do we want to have transforms
that have a work factor way below that of the underlying cipher, and
way below that of other transforms that use that cipher? I believe
it's a basic rule of modern cryptography that you avoid ciphers, and
modes, which have a work factor less than 2^k for k bit keys.
As it stands, I see NO justification for the existence of AES-CTR
mode, in its current form, with 128 bit keys (the only sensible
transform with AES 128 bit keys is CBC). Adopting David's proposal
will fix that, and make 128 bit keyed AES acceptable for AES-CTR.
paul
From owner-ipsec@lists.tislabs.com Thu Nov 21 09: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 gALHOMg18480;
Thu, 21 Nov 2002 09:24:22 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14230
Thu, 21 Nov 2002 12:00:55 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15837.4447.607540.347108@pkoning.dev.equallogic.com>
Date: Thu, 21 Nov 2002 12:01:19 -0500
From: Paul Koning <pkoning@equallogic.com>
To: Alten@attbi.com
Cc: BDoud@hifn.com, mcgrew@cisco.com, tytso@mit.edu, paul.hoffman@vpnc.org,
ipsec@lists.tislabs.com
Subject: RE: Counter Mode Security: Analysis and Recommendations
References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
<3.0.3.32.20021120231356.01ab1b80@mail>
X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Alex" == Alex Alten <Alten@attbi.com> writes:
Alex> At 04:37 PM 11/20/2002 -0800, Bob Doud wrote:
>> <snip>
>> And let's keep in mind that a fundamental reason that we're
>> pursuing counter mode in the first place is for high-performance
>> as systems move into the multi-Gigabit range. (Parallelizing the
>> crypto operations across multiple engines with staggered
>> counters.) It's safe to say that all hardware and software
>> implementations will be noticably slower with AES-256 than with
>> AES-128.
>>
>> Bob
>>
Alex> Really? And all these expensive parallel hardware engines will
Alex> still be effective on the receiving end when packets arrive out
Alex> of order, are lost, duplicated or fragmented? What about
Alex> interleaved packet streams from different hosts? What about
Alex> hash computations?
IPsec acts on IP datagrams. So loss, duplication, or reordering of IP
packets clearly has no effect.
Fragments? In IPv6 there are no fragments, obviously. In IPv4, there
are no fragments either in settings where high performance is
expected.
Alex> And who will buy them? 1 Gigabit/sec cards go for $50 today.
Alex> The cheapest AES chips are $25 each, which is $125 retail. You
Alex> will need about 4 of them at least. So now that card becomes a
Alex> $500 card. Ten times as expensive. By the time they become
Alex> cheap enough the world will be using 10 gigabit/sec Ethernet.
You seem to be assuming that the only way to get multiple AES units is
to buy multiple chips, and collect them on a board. That's actually
the least likely approach.
All high speed crypto chips contain multiple cipher units inside the
chip. Right now, with CBC mode, it's difficult to keep them all
working effectively, because any given packet has to be handled by a
single cipher unit due to the chaining. With counter mode, such
multiple-unit chips can easily run at full speed even when acting on a
single packet stream, because each cipher block can be processed by a
separate unit. In other words, a packet as short as 64 bytes can get
the performance gain of four cipher units working in parallel.
In high speed crypto chips, and especially with efficient ciphers like
AES, the crypto cores are not all that large a part of the whole
chip. Control, embedded memory, bus interfaces, etc. all tie up large
parts. So the incremental cost of a whole bunch of cipher units is
very much lower than you claimed.
paul
From owner-ipsec@lists.tislabs.com Thu Nov 21 09:24: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 gALHOng18551;
Thu, 21 Nov 2002 09:24:49 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14236
Thu, 21 Nov 2002 12:01:55 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15837.4485.707574.793760@thomasm-u1.cisco.com>
Date: Thu, 21 Nov 2002 09:01:57 -0800 (PST)
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-Reply-To: <200211181541.gAIFfEte027647@givry.rennes.enst-bretagne.fr>
References: <p05100301b9fea8c97865@[128.89.88.34]>
<200211181541.gAIFfEte027647@givry.rennes.enst-bretagne.fr>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Francis Dupont writes:
> In your previous mail you wrote:
>
> >=> this mapping from names to addresses is in this statement done
> >by looking the source address of received messages (i.e., address
> >IKE runs over).
>
> => so the addresses I talk about are the outer addresses.
>
> >This cannot provide in all cases the needed flexibility
> >and safety. For instance the address can be changed "en route",
> >the peer can put a rogue address (a real concern for 1+1 exchanges),
> >etc. And if another mapping mechanism is used (IPaddress alternate
> >Subject names in certificates, DNS/DNSsec, etc) the balance between
> >flexibility and safety is not the same.
> >But my main concern is that this balance is not controled: this is just
> >the result of never documented implementation choices...
>
> An intermediate IPsec device has only per-packet header data
> available as a basis for making access control decisions for traffic
> on an extant SA. Thus we must bind the traffic for the SA to a set of
> addresses that we know about when we establish the SA. For tunnel
> mode, the outer addresses can change during the SA without breaking
> the SA, but the inner addresses must remain constant (or at least be
> part of the same set established during SA establishment). Those
> addresses cannot be changed by black routers, NAT devices, etc.,
> since they are inside the protection boundary.
>
> => my concern is about outer addresses: we need flexibility in order
> to change when needed these addresses (I believe we agree about this
> point) and we need safety in order to avoid DoS attacks using SA
> establishment with rogue outer addresses.
Francis,
If I'm understanding this thread correctly, I
agree with your concern that tunnel endpoints
ought to be moveable. However, my understanding is
that this is mainly a *signaling* issue: eg IKE
doesn't have a way to tell the other IKE to move
the tunnel endpoint.
Mike
From owner-ipsec@lists.tislabs.com Thu Nov 21 10:52: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 gALIqlg23265;
Thu, 21 Nov 2002 10:52:47 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14543
Thu, 21 Nov 2002 13:22:37 -0500 (EST)
Message-ID: <51C7002B020CD411824E009027C469F7DD3393@cldxch01.hifn.com>
From: Bob Doud <BDoud@hifn.com>
To: "'Paul Koning'" <pkoning@equallogic.com>, Alten@attbi.com
Cc: mcgrew@cisco.com, tytso@mit.edu, paul.hoffman@vpnc.org,
ipsec@lists.tislabs.com
Subject: RE: Counter Mode Security: Analysis and Recommendations
Date: Thu, 21 Nov 2002 10:23:07 -0800
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
> >>>>> "Alex" == Alex Alten <Alten@attbi.com> writes:
>
> At 04:37 PM 11/20/2002 -0800, Bob Doud wrote:
> >> <snip>
> >> And let's keep in mind that a fundamental reason that we're
> >> pursuing counter mode in the first place is for high-performance
> >> as systems move into the multi-Gigabit range. (Parallelizing the
> >> crypto operations across multiple engines with staggered
> >> counters.) It's safe to say that all hardware and software
> >> implementations will be noticably slower with AES-256 than with
> >> AES-128.
> >>
> >> Bob
> >>
>
> Alex> Really? And all these expensive parallel hardware engines will
> Alex> still be effective on the receiving end when packets arrive out
> Alex> of order, are lost, duplicated or fragmented? What about
> Alex> interleaved packet streams from different hosts? What about
> Alex> hash computations?
>
> IPsec acts on IP datagrams. So loss, duplication, or reordering of IP
> packets clearly has no effect.
>
> Fragments? In IPv6 there are no fragments, obviously. In IPv4, there
> are no fragments either in settings where high performance is
> expected.
>
> Alex> And who will buy them? 1 Gigabit/sec cards go for $50 today.
> Alex> The cheapest AES chips are $25 each, which is $125 retail. You
> Alex> will need about 4 of them at least. So now that card becomes a
> Alex> $500 card. Ten times as expensive. By the time they become
> Alex> cheap enough the world will be using 10 gigabit/sec Ethernet.
>
> You seem to be assuming that the only way to get multiple AES units is
> to buy multiple chips, and collect them on a board. That's actually
> the least likely approach.
>
> All high speed crypto chips contain multiple cipher units inside the
> chip. Right now, with CBC mode, it's difficult to keep them all
> working effectively, because any given packet has to be handled by a
> single cipher unit due to the chaining. With counter mode, such
> multiple-unit chips can easily run at full speed even when acting on a
> single packet stream, because each cipher block can be processed by a
> separate unit. In other words, a packet as short as 64 bytes can get
> the performance gain of four cipher units working in parallel.
>
> In high speed crypto chips, and especially with efficient ciphers like
> AES, the crypto cores are not all that large a part of the whole
> chip. Control, embedded memory, bus interfaces, etc. all tie up large
> parts. So the incremental cost of a whole bunch of cipher units is
> very much lower than you claimed.
>
> paul
>
Correct Paul. And stay tuned Alex... we'll be seeing VERY cost effective
Gigabit security chip coming along soon. It would just be nice to get
these CTR mode issues nailed down soon so us chip guys can provide
support for this mode!
Bob
From owner-ipsec@lists.tislabs.com Thu Nov 21 10:55: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 gALIt0g23529;
Thu, 21 Nov 2002 10:55:00 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14549
Thu, 21 Nov 2002 13:24:40 -0500 (EST)
Message-ID: <AD1F046251DCD311BA6F0020484037670446A4BA@aimexc02.corp.adaptec.com>
From: "Mukund, Shridhar" <Shridhar_Mukund@adaptec.com>
To: "'Bob Doud'" <BDoud@hifn.com>, "'Paul Koning'" <pkoning@equallogic.com>,
mcgrew@cisco.com
Cc: tytso@mit.edu, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com
Subject: RE: Counter Mode Security: Analysis and Recommendations
Date: Thu, 21 Nov 2002 10:25:19 -0800
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
Agree with Paul and Bob. Silicon implementation is challenging
but just about feasible with counter-mode AES-128 at multi-Gig.
-Shridhar Mukund
> > I would hate to depend on AES-192 or above, since it's not
> clear to me
> > how widely those will initialy be implemented in high speed silicon.
> >
> > paul
>
> And let's keep in mind that a fundamental reason that we're pursuing
> counter mode in the first place is for high-performance as systems
> move into the multi-Gigabit range. (Parallelizing the crypto
> operations
> across multiple engines with staggered counters.) It's safe
> to say that
> all hardware and software implementations will be noticably
> slower with
> AES-256 than with AES-128.
>
> Bob
>
From owner-ipsec@lists.tislabs.com Thu Nov 21 11:00: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 gALJ0Lg24214;
Thu, 21 Nov 2002 11:00:22 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14570
Thu, 21 Nov 2002 13:33:44 -0500 (EST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15837.10043.997127.533128@thomasm-u1.cisco.com>
Date: Thu, 21 Nov 2002 10:34:35 -0800 (PST)
To: Paul Koning <pkoning@equallogic.com>
Cc: Alten@attbi.com, BDoud@hifn.com, mcgrew@cisco.com, tytso@mit.edu,
paul.hoffman@vpnc.org, ipsec@lists.tislabs.com
Subject: RE: Counter Mode Security: Analysis and Recommendations
In-Reply-To: <15837.4447.607540.347108@pkoning.dev.equallogic.com>
References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
<3.0.3.32.20021120231356.01ab1b80@mail>
<15837.4447.607540.347108@pkoning.dev.equallogic.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
Paul Koning writes:
> Fragments? In IPv6 there are no fragments, obviously. In IPv4, there
> are no fragments either in settings where high performance is
> expected.
One small correction: IP6 does have fragmentation,
it's just that routers have nothing to do with it
(ie, it's the host's responsibility).
Mike
From owner-ipsec@lists.tislabs.com Thu Nov 21 12:15: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 gALKFrg27780;
Thu, 21 Nov 2002 12:15:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14933
Thu, 21 Nov 2002 14:45:35 -0500 (EST)
From: "David A. Mcgrew" <mcgrew@cisco.com>
To: "Paul Koning" <pkoning@equallogic.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Counter Mode Security: Analysis and Recommendations
Date: Thu, 21 Nov 2002 11:45:51 -0800
Message-ID: <FPELKLHKCBJLMMMNOGDFGEHPEJAA.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)
Importance: Normal
In-Reply-To: <15834.46260.21749.515468@pkoning.dev.equallogic.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul,
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning
> Sent: Tuesday, November 19, 2002 2:01 PM
> To: mcgrew@cisco.com
> Cc: tytso@mit.edu; paul.hoffman@vpnc.org; ipsec@lists.tislabs.com
> Subject: RE: Counter Mode Security: Analysis and Recommendations
>
>
> >>>>> "David" == David A Mcgrew <mcgrew@cisco.com> writes:
>
> David> Randomly setting the initial value of the 64-bit explicit IV
> David> of draft-ietf-ipsec-ciph-aes-ctr-01 does *not* protect against
> David> the precomputation attacks described in the writeup. This is
> David> because all values of that IV will be used during the lifetime
> David> of a key. So an attacker can pick any value of the IV during
> David> its precomputation stage, then wait for the corresponding
> David> packet to appear in the data stream protected by a particular
> David> key before attacking that key. ...
>
> Given that counter mode is limited to 2^64 blocks, all values of the
> IV are used only if every packet contains at most 16 bytes. But
> admittedly in many data streams the average packet size is not
> dramatically bigger than the block size. (If the average packet size
> is <= 128 bytes, then you get the same gain in the TMTO attack if you
> increase the table size by a factor of 8.)
that's right. If the whole keystream isn't used, then the strategy of
randomizing the explicit IV would provide additional security. In my analysis,
I made the (unstated) assumption that the key would be used up all the way.
>
> David> What I'm suggesting is that there be a distinct field in in
> David> the counter which is unpredictable. In principle, counter
> David> mode *can* have a 64-bit randomizer because the limitation
> David> that no more than 2^64 blocks can be generated implies that 64
> David> bits suffice to index all of those blocks. So the block
> David> counter and IV fields together need not occupy more than 64
> David> bits.
>
> David> Here's a concrete proposal: reduce the block counter to 16
> David> bits and the IV to 48 bits, and replace the 'truncated spi'
> David> field with a 56-bit field that is set randomly at key setup
> David> time. This field should be considered part of the key, so
> David> that key setup is easy. This proposal has the following
> David> advantages: better security than the current draft, and the
> David> independence of the cipher from the SPI allocation. It has
> David> the following minor disadvantage: it cannot encrypt ipv6
> David> jumbograms.
>
> David> As an aside, the 8-bit 'flags' field prevents us from making
> David> the randomizer field 64 bits long. I'd prefer 64 bits but
> David> would happy to get 56.
>
> Could we drop the flags byte? I can't see much point in having a
> field that provides compatibility with a different transform, because
> by definition we're not using that transform when we're using the
> AES-CTR transform...
This is a good question. I'm not sure to what extent the current draft lines up
with CCM.
David
>
> David> An important point about the current draft is that, while it
> David> aims to admit a variety of implementation strategies, it
> David> excludes the cryptographically conservative one. In my
> David> opinion, that would be a mistake.
>
> David> In the interest of moving the WG forward on the issue, I
> David> suggest that we solicit WG input on the following questions:
>
> David> 1) is a security level lower than that recommended for
> David> commercial encryption (88 bits) considered acceptable?
>
> NO way.
>
> David> 2) is a limitation to encrypting packets less than 64kb in
> David> length considered acceptable?
>
> You mean "is it acceptable to limit packets to be 64k or less?" If
> you make the block counter 16 bits, then the actual packet size limit
> is 1 megabyte because blocks are 16 bytes... That's fine.
>
> David> 3) if you could answer "yes" to only one of the above
> David> questions, which would it be?
>
> David> 4) is it acceptable to implement AES-192 or AES-256 and use
> David> those ciphers for counter mode? Or is it desirable to use
> David> AES-128 for both CBC and counter mode?
>
> I would hate to depend on AES-192 or above, since it's not clear to me
> how widely those will initialy be implemented in high speed silicon.
>
> paul
>
From owner-ipsec@lists.tislabs.com Thu Nov 21 14:06: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 gALM5xg08107;
Thu, 21 Nov 2002 14:05:59 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15130
Thu, 21 Nov 2002 16:34:15 -0500 (EST)
From: Black_David@emc.com
Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C57C@corpmx14.us.dg.com>
To: ipsec@lists.tislabs.com
Subject: Counter Mode Security: Attacks, Storage & a Proposal
Date: Thu, 21 Nov 2002 16:34:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ted observed that the O(2**85) attack requires O(2**85) storage for
the precomputation. Actually it requires more, since each of those
O(2**85) records is at least 256 bits (2**5 bytes) in size, so the
need is at least O(2**90) bytes of storage. Since I work for a storage
company that builds large storage infrastructures, I thought I'd offer
some observations on feasibility of that size of storage infrastructure
- the upshot is that I have no idea how to build anything within several
orders of magnitude of that scale in the near future ... but we'd love
to be paid to try :-). Here are the details:
Next year, the disk drive industry should be producing disk drives of
about 300GB capacity. The largest currently available disk array
holds 1024 drives, and that number's not likely to go up much. The
result is 300TB with 300GB drives. Three such arrays yield a petabyte
(2**50) and so 3000 arrays would yield about an exabyte (2**60) storage
infrastructure, and that's near the edge of what's feasible with current
storage networking technology. The cost to build that sort of system
will be $5-10 billion or more - between that cost and the fact that
this is close to current technology scaling limits, 2**60 is probably
a decent approximation of what a very-well-funded adversary could put
together next year.
Projecting into the future, areal bit density of disk media doubles
about annually, but drive capacities lag that because drive manufacturers
spend some of that density on reducing the number and size of platters.
In addition, about once every 5 years or so, a form factor reduction
occurs that results in no drive capacity increase for about a year. We're
nearing the end of one now - about a year ago the largest commercially
available drive was a 180GB 3.5" HH (1.5" high) drive - that drive and
the HH form factor are being phased out, and the largest alternative
3.5" LP (1" high) drive currently available is 160GB. Taking this into
consideration and allowing for some scaling improvements in storage
networking technology, another factor of 2**10 covers 8-10 years into
the future (i.e., 8-10 years from now, O(2**70) storage is what a
very-well-funded adversary could reasonably expect to put together).
Assuming that the attack scales uniformly in time vs. space (a serious
assumption that knowledgeable experts should check), O(2**70) storage is
O(2**20) short of the O(2**90) requirement for the O(2**85) attack - adding
that O(2**20) factor to the attack complexity yields a feasible attack of
O(2**105) rather than O(2**85). In hallway discussions with several
interested parties, it was proposed that 24 unpredictable bits be used
instead of the truncated SPI in the counter block, and IKE nonces were
suggested as a good source for these unpredictable bits. An additional
24 unpredictable bits increases the attack effort by O(2**16) [effort scales
as 2/3 of added unpredictable bits according to McGrew's paper] yielding
an O(2**121) attack in 8-10 years against 128-bit keys, and a current
situation in which the brute force attack is easier (2**128) than the
precomputation attack (2**131). I think that should suffice ... Further,
these attack effort estimates do not include the time necessary to search
the huge precomputed storage.
One caveat - this analysis is not as rigorous as David McGrew's -
I would apply a fudge factor of something like O(2**3) to the size
and scale estimates to be safe, but I believe the conclusion that
24 additional unpredictable bits in the counter block are sufficient
still holds.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786
black_david@emc.com Mobile: +1 (978) 394-7754
----------------------------------------------------
From owner-ipsec@lists.tislabs.com Thu Nov 21 14:39: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 gALMd4g09997;
Thu, 21 Nov 2002 14:39:04 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15200
Thu, 21 Nov 2002 17:10:31 -0500 (EST)
To: Lokesh <lokeshnb@intotoinc.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: SPD policy document/article
References: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10>
From: Wes Hardaker <hardaker@tislabs.com>
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Organization: Network Associates Laboratories
Date: Thu, 21 Nov 2002 14:10:21 -0800
In-Reply-To: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10> (Lokesh's
message of "Thu, 21 Nov 2002 19:13:59 +0530")
Message-ID: <sdvg2qk20i.fsf@wanderer.hardakers.net>
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts,
i686-pc-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> On Thu, 21 Nov 2002 19:13:59 +0530, Lokesh <lokeshnb@intotoinc.com> said:
lokeshnb> I'm looking for a document or article where a SPD policy's
lokeshnb> all complexities and intricacies are explained better in
lokeshnb> detail. If there is one please let me know the link.
lokeshnb> Basically, I'm looking for configuration and behavior of SPD
lokeshnb> and IPSec that generate
Lokesh,
The IPSP working group has done a lot of work in this area to define
what a security policy database should contain. Specifically, they've
produced a conceptual data model and a SNMP MIB and a COPS PIB for
actually manipulating that data model on the network. A publicly
available reference release of the MIB for linux (and a policy
management server which should work on any server) have been written
and is available from net-policy.sourceforge.net (though at this
moment, some of the sourceforge servers are apparently down).
I strongly recommend you look at the documents that the IPSP group
have written (and the DMTF's UML diagrams of the same model).
--
Wes Hardaker
Network Associates Laboratories
From owner-ipsec@lists.tislabs.com Thu Nov 21 15:23: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 gALNNbg13094;
Thu, 21 Nov 2002 15:23:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15277
Thu, 21 Nov 2002 17:50:36 -0500 (EST)
Message-Id: <200211212250.gALMoZte040573@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Michael Thomas <mat@cisco.com>
cc: Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com
Subject: Re: Adding revised identities to IKEv2
In-reply-to: Your message of Thu, 21 Nov 2002 09:01:57 PST.
<15837.4485.707574.793760@thomasm-u1.cisco.com>
Date: Thu, 21 Nov 2002 23:50:35 +0100
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:
If I'm understanding this thread correctly,
=> the main thread is about peer source addresses in IKE
but there is a sub-thread about the same thing than this message.
I agree with your concern that tunnel endpoints
ought to be moveable. However, my understanding is
that this is mainly a *signaling* issue: eg IKE
doesn't have a way to tell the other IKE to move
the tunnel endpoint.
=> there is today an indirect way through rekeying (new phase 2)
but:
- with PFS this is a bit expensive
- so a new readdressing exchange should be wellcome
(in IKEv2 which mandates "phase 2" PFS)
- of course, implementations which use addresses in place of
the SPI (aka cookies in IKEv1) to get the from phase 1 context
have to be fixed!
Another point: spurious checks on the outer source address should not
be performed.
(BTW I believe we agree about these points)
Thanks
Francis.Dupont@enst-bretagne.fr
From owner-ipsec@lists.tislabs.com Thu Nov 21 16:21: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 gAM0LXg14881;
Thu, 21 Nov 2002 16:21:34 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15403
Thu, 21 Nov 2002 18:55:47 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05111a00ba02a2eeeea0@[204.42.67.13]>
In-Reply-To: <20021121024845.GA792@think.thunk.org>
References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
<20021121024845.GA792@think.thunk.org>
Date: Thu, 21 Nov 2002 09:52:54 -0500
To: "Theodore Ts'o" <tytso@mit.edu>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Counter Mode Security: Analysis and Recommendations
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ted,
I concur with your analysis re the storage requirements for this
attack, and how daunting they seem. This strikes me as the sort of
attack that I would protect against if it cost almost nothing, but as
we see, it does have a cost, e.g., in terms of extra storage for
additional per-SA state for the added bits, or in terms of using
bigger AES keys, with attendant increases in the number of rounds and
the key state size. Also there are costs to vendors in supporting the
additional key sizes and numbers of rounds. At a time when we are
trying to simplify IPsec and IKE, this seem to be heading in the
wrong direction.
Steve
From owner-ipsec@lists.tislabs.com Thu Nov 21 16:52: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 gAM0qVg17999;
Thu, 21 Nov 2002 16:52:31 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15486
Thu, 21 Nov 2002 19:19:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05111a02ba032870e00d@[10.0.1.3]>
In-Reply-To: <sdvg2qk20i.fsf@wanderer.hardakers.net>
References: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10>
<sdvg2qk20i.fsf@wanderer.hardakers.net>
Date: Thu, 21 Nov 2002 19:21:05 -0500
To: Wes Hardaker <hardaker@tislabs.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: SPD policy document/article
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 2:10 PM -0800 11/21/02, Wes Hardaker wrote:
> >>>>> On Thu, 21 Nov 2002 19:13:59 +0530, Lokesh
><lokeshnb@intotoinc.com> said:
>
>lokeshnb> I'm looking for a document or article where a SPD policy's
>lokeshnb> all complexities and intricacies are explained better in
>lokeshnb> detail. If there is one please let me know the link.
>lokeshnb> Basically, I'm looking for configuration and behavior of SPD
>lokeshnb> and IPSec that generate
>
>Lokesh,
>
>The IPSP working group has done a lot of work in this area to define
>what a security policy database should contain. Specifically, they've
>produced a conceptual data model and a SNMP MIB and a COPS PIB for
>actually manipulating that data model on the network. A publicly
>available reference release of the MIB for linux (and a policy
>management server which should work on any server) have been written
>and is available from net-policy.sourceforge.net (though at this
>moment, some of the sourceforge servers are apparently down).
>I strongly recommend you look at the documents that the IPSP group
>have written (and the DMTF's UML diagrams of the same model).
>
>--
>Wes Hardaker
>Network Associates Laboratories
Wes,
RFC 2401 establishes the standard for the minimum required data
elements for the SPD used in IPsec, and then defines how a conformant
IPsec implementation uses this data. So, I assume your comments are
referring to other protocols, right?
Steve
From owner-ipsec@lists.tislabs.com Thu Nov 21 17:41: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 gAM1fcg18877;
Thu, 21 Nov 2002 17:41:38 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15746
Thu, 21 Nov 2002 20:18:10 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15837.34306.911000.501269@gargle.gargle.HOWL>
Date: Thu, 21 Nov 2002 20:18:58 -0500
From: Paul Koning <pkoning@equallogic.com>
To: Black_David@emc.com
Cc: ipsec@lists.tislabs.com
Subject: Re: Counter Mode Security: Attacks, Storage & a Proposal
References: <277DD60FB639D511AC0400B0D068B71E0564C57C@corpmx14.us.dg.com>
X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I continue to prefer a design where the transform strength is equal to
the cipher strength unconditionally, because that's (as far as I know)
the normal design rule.
I'm also somewhat hesitant to argue about your storage cost numbers,
but still, two observations...
1. As I recall, the historical rate of capacity growth has not been
all that constant (unlike, say, the Moore's Law analog in processing
power). Not all that many years ago the rate increased dramatically,
I believe.
2. The analysis assumes that hard drives are and continue to be the
most cost effective (YB/$) technology. I'm not sure that's true now
(consider tape libraries) and it may not be true later.
If the goal is to reuse as much as possible of the proposed header
format, I would suggest a 32-bit random number, replacing both the
24-bit truncated SPI as well as the unused flags byte.
But I still prefer the 64 bit random number, keeping the best known
attack at O(2^128).
On the subject of the gigantic MTU proposal vs. the 16 bit block
number field: consider that we're talking about encrypted packets
here, so the question isn't just what sort of link speeds are
available, but also what encryption speeds are available. 100 Gb/s
seems plausible not too long from now; at a 1 MB MTU limit that
translates to a packet time of 125 microseconds. That's quite a
civilized number. At 1 Tb/s it becomes 12.5 microseconds, STILL a
very civilized number. So a 1 MB MTU restriction for counter mode
isn't an issue.
(I would point out that the argument for larger MTU is partly valid,
in that packet times have dropped much too quickly. But since all the
switch guts are very definitely getting much faster, there is no
reason to crank up MTU so much that packet time remains constant. All
that's needed is that it drops no faster than the bottleneck rate of
the per-packet processing components of switches. That's probably the
address lookup. In 1992, on a 40 MHz processor, 10 microseconds
wasn't a big deal, so it's rather strange to argue that one should aim
for packet times substantially above one microsecond today.)
paul
From owner-ipsec@lists.tislabs.com Thu Nov 21 17:57: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 gAM1vLg19485;
Thu, 21 Nov 2002 17:57:21 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15781
Thu, 21 Nov 2002 20:33:23 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15837.35214.666000.792119@gargle.gargle.HOWL>
Date: Thu, 21 Nov 2002 20:34:06 -0500
From: Paul Koning <pkoning@equallogic.com>
To: kent@bbn.com
Cc: tytso@mit.edu, ipsec@lists.tislabs.com
Subject: Re: Counter Mode Security: Analysis and Recommendations
References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
<20021121024845.GA792@think.thunk.org>
<p05111a00ba02a2eeeea0@[204.42.67.13]>
X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:
Stephen> Ted, I concur with your analysis re the storage requirements
Stephen> for this attack, and how daunting they seem. This strikes me
Stephen> as the sort of attack that I would protect against if it
Stephen> cost almost nothing, but as we see, it does have a cost,
Stephen> e.g., in terms of extra storage for additional per-SA state
Stephen> for the added bits, or in terms of using bigger AES keys,
Stephen> with attendant increases in the number of rounds and the key
Stephen> state size. Also there are costs to vendors in supporting
Stephen> the additional key sizes and numbers of rounds.
Agreed on increasing key sizes. But I don't agree for the case where
128-bit keys and a 64-bit random number are used. Yes, that increases
the per-SA state by 8 bytes. And yes, that cost is "almost nothing".
paul
From owner-ipsec@lists.tislabs.com Thu Nov 21 23:06: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 gAM76Qg08515;
Thu, 21 Nov 2002 23:06:27 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA16392
Fri, 22 Nov 2002 01:39:34 -0500 (EST)
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: SPD policy document/article
References: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10>
<sdvg2qk20i.fsf@wanderer.hardakers.net>
<p05111a02ba032870e00d@[10.0.1.3]>
From: Wes Hardaker <hardaker@tislabs.com>
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Organization: Network Associates Laboratories
Date: Thu, 21 Nov 2002 22:39:11 -0800
In-Reply-To: <p05111a02ba032870e00d@[10.0.1.3]> (Stephen Kent's message of
"Thu, 21 Nov 2002 19:21:05 -0500")
Message-ID: <sdadk2jegg.fsf@wanderer.hardakers.net>
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts,
i686-pc-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> On Thu, 21 Nov 2002 19:21:05 -0500, Stephen Kent <kent@bbn.com> said:
Stephen> RFC 2401 establishes the standard for the minimum required
Stephen> data elements for the SPD used in IPsec, and then defines how
Stephen> a conformant IPsec implementation uses this data. So, I
Stephen> assume your comments are referring to other protocols, right?
RFC2401 does talk about the SPD but in a very minimal context. The
IPSP work is intended to define Ipsec Security Policy in greater detail.
--
Wes Hardaker
Network Associates Laboratories
From owner-ipsec@lists.tislabs.com Fri Nov 22 05:18: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 gAMDIwg17846;
Fri, 22 Nov 2002 05:18:58 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA17220
Fri, 22 Nov 2002 07:52:49 -0500 (EST)
Date: Thu, 21 Nov 2002 23:00:09 -0500
From: "Theodore Ts'o" <tytso@mit.edu>
To: Paul Koning <pkoning@equallogic.com>
Cc: Black_David@emc.com, ipsec@lists.tislabs.com
Subject: Re: Counter Mode Security: Attacks, Storage & a Proposal
Message-ID: <20021122040009.GA549@think.thunk.org>
References: <277DD60FB639D511AC0400B0D068B71E0564C57C@corpmx14.us.dg.com> <15837.34306.911000.501269@gargle.gargle.HOWL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15837.34306.911000.501269@gargle.gargle.HOWL>
User-Agent: Mutt/1.3.28i
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, Nov 21, 2002 at 08:18:58PM -0500, Paul Koning wrote:
> I continue to prefer a design where the transform strength is equal to
> the cipher strength unconditionally, because that's (as far as I know)
> the normal design rule.
The problem I have with this imputed design rule is that it appears to
completely ignore the storage requirements of attacks, and that
doesn't seem right. For example, if you create a lookup table that
enumerates the encryption of a known plaintext for every single
possible key, you can carry out the attack in O(1) time. This ignores
the cost of the storage, and the time it takes to create the table in
the first place, but if you posit the existence of this table, the
strength of any cipher (by what I believe is a very flawed definition)
is 0 bits.
This is why I don't believe that claim that the fact that there exists
an attack which takes O(2**85) time but requires O(2**85) storage
means that the cipher is only 85 bits strong. That just doesn't seem
to be an appropriate way of judging the strength of a cipher.
(As another example, triple DES is succeptible to attacks that require
O(2**56) in time and O(2**56) in space. Does this mean that if both
can be attacked in O(2**56) time, completely ignoring the storage
requirements, both ciphers are identically strong with 56 bits of
strength? I don't think so.)
> 1. As I recall, the historical rate of capacity growth has not been
> all that constant (unlike, say, the Moore's Law analog in processing
> power). Not all that many years ago the rate increased dramatically,
> I believe.
The risk actually is probably in the opposite direction; there are
strong indications that Moore's law will not be able to continue going
forward. This is also true for disk drives; the size of a magnetic
domain on a disk platter has been getting smaller and smaller, and
it's not clear this can continue.
> 2. The analysis assumes that hard drives are and continue to be the
> most cost effective (YB/$) technology. I'm not sure that's true now
> (consider tape libraries) and it may not be true later.
Tape libraries aren't particularly useful because you need to do
O(2**85) lookups. If you need to mount and unmount tapes between
lookups, this will rather slow down the time to perform the attack....
Finally, a further issue which will likely make the TMTO attack remain
completely intractable is the (lack of) rates of improvement in disk
read/write speeds. While it is true that disk capacities have been
growing very rapidly, the speed at which disk blocks can read or
written have not increased nearly as quickly.
- Ted
From owner-ipsec@lists.tislabs.com Fri Nov 22 07:24: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 gAMFO4g26650;
Fri, 22 Nov 2002 07:24:04 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17454
Fri, 22 Nov 2002 09:48:28 -0500 (EST)
Date: Fri, 22 Nov 2002 09:49:11 -0500 (EST)
From: Henry Spencer <henry@spsystems.net>
To: IP Security List <ipsec@lists.tislabs.com>
Subject: Re: Counter Mode Security: Attacks, Storage & a Proposal
In-Reply-To: <20021122040009.GA549@think.thunk.org>
Message-ID: <Pine.BSI.3.91.1021122093509.6341C-100000@spsystems.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Thu, 21 Nov 2002, Theodore Ts'o wrote:
> The risk actually is probably in the opposite direction; there are
> strong indications that Moore's law will not be able to continue going
> forward. This is also true for disk drives; the size of a magnetic
> domain on a disk platter has been getting smaller and smaller, and
> it's not clear this can continue.
However, a quick review of similar predictions dating back at least twenty
years ("it is impossible to build 64Kbit DRAMs with optical lithography"
was a particularly infamous one) suggests that you should bet on people
finding ways around those problems. Developers get really creative when
billions of dollars are at stake.
> Finally, a further issue which will likely make the TMTO attack remain
> completely intractable is the (lack of) rates of improvement in disk
> read/write speeds...
The same issue comes up for RAM, also. To some extent you can get around
both with clever algorithms (for example, linear hash-collision resolution
is making a partial comeback -- it is *much* quicker to do a linear search
of the rest of the cache line than to immediately go out to memory
again...), but applications with inherently (quasi)random accesses can't
do that very much.
Henry Spencer
henry@spsystems.net
From owner-ipsec@lists.tislabs.com Fri Nov 22 07:25: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 gAMFPPg26752;
Fri, 22 Nov 2002 07:25:26 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17476
Fri, 22 Nov 2002 10:03:39 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15838.18317.363863.128726@pkoning.dev.equallogic.com>
Date: Fri, 22 Nov 2002 10:04:45 -0500
From: Paul Koning <pkoning@equallogic.com>
To: tytso@mit.edu
Cc: ipsec@lists.tislabs.com
Subject: Re: Counter Mode Security: Attacks, Storage & a Proposal
References: <277DD60FB639D511AC0400B0D068B71E0564C57C@corpmx14.us.dg.com>
<15837.34306.911000.501269@gargle.gargle.HOWL>
<20021122040009.GA549@think.thunk.org>
X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Theodore" == Theodore Ts'o <tytso@mit.edu> writes:
Theodore> On Thu, Nov 21, 2002 at 08:18:58PM -0500, Paul Koning
Theodore> wrote:
>> I continue to prefer a design where the transform strength is
>> equal to the cipher strength unconditionally, because that's (as
>> far as I know) the normal design rule.
Theodore> The problem I have with this imputed design rule is that it
Theodore> appears to completely ignore the storage requirements of
Theodore> attacks, and that doesn't seem right. For example, if you
Theodore> create a lookup table that enumerates the encryption of a
Theodore> known plaintext for every single possible key, you can
Theodore> carry out the attack in O(1) time. This ignores the cost
Theodore> of the storage, and the time it takes to create the table
Theodore> in the first place, but if you posit the existence of this
Theodore> table, the strength of any cipher (by what I believe is a
Theodore> very flawed definition) is 0 bits.
But I never said to ignore the cost of storage. What I meant (perhaps
I didn't say this explicitly) is that, given an attack requiring O(x)
storage and O(y) time, I judge the cipher strength to be O(max(x,y)).
Theodore> This is why I don't believe that claim that the fact that
Theodore> there exists an attack which takes O(2**85) time but
Theodore> requires O(2**85) storage means that the cipher is only 85
Theodore> bits strong. That just doesn't seem to be an appropriate
Theodore> way of judging the strength of a cipher.
The alternative is to apply a scale factor to storage cost different
from computation cost. But the problem with doing this is that the
process for arriving at such a scale factor involves a lot of
guessword, especially when you're trying to secure data for 30 years.
(We are, right? Clearly we should be.)
Theodore> (As another example, triple DES is succeptible to attacks
Theodore> that require O(2**56) in time and O(2**56) in space. Does
Theodore> this mean that if both can be attacked in O(2**56) time,
Theodore> completely ignoring the storage requirements, both ciphers
Theodore> are identically strong with 56 bits of strength? I don't
Theodore> think so.)
No, it's double DES that is subject to that attack ("meet in the
middle") which is precisely why double DES is never used.
(Note that the incremental cost in SA state of 3DES -- in the form
used in IPsec -- compared to 2DES is essentially the same as the
incremental cost of the 64-bit random seed as proposed by David
McGrew.)
paul
From owner-ipsec@lists.tislabs.com Fri Nov 22 07:25: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 gAMFPRg26764;
Fri, 22 Nov 2002 07:25:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17475
Fri, 22 Nov 2002 10:03:33 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100301ba03f1dcfbc8@[128.89.88.34]>
In-Reply-To: <sdadk2jegg.fsf@wanderer.hardakers.net>
References: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10>
<sdvg2qk20i.fsf@wanderer.hardakers.net>
<p05111a02ba032870e00d@[10.0.1.3]> <sdadk2jegg.fsf@wanderer.hardakers.net>
Date: Fri, 22 Nov 2002 09:57:09 -0500
To: Wes Hardaker <hardaker@tislabs.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: SPD policy document/article
Cc: ipsec@lists.tislabs.com, smb@research.att.com, jis@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:39 PM -0800 11/21/02, Wes Hardaker wrote:
> >>>>> On Thu, 21 Nov 2002 19:21:05 -0500, Stephen Kent <kent@bbn.com> said:
>
>Stephen> RFC 2401 establishes the standard for the minimum required
>Stephen> data elements for the SPD used in IPsec, and then defines how
>Stephen> a conformant IPsec implementation uses this data. So, I
>Stephen> assume your comments are referring to other protocols, right?
>
>RFC2401 does talk about the SPD but in a very minimal context. The
>IPSP work is intended to define Ipsec Security Policy in greater detail.
>
>--
>Wes Hardaker
>Network Associates Laboratories
Wes,
2401 defines what a compliant IPsec implementation MUST do. the IPsec
WG is responsible for defining IPsec device compliance. IPSP cannot
define additional requirements for what it means to be IPsec
compliant without impinging on the IPsec WG charter. I thought IPSP
was responsible to protocols for policy negotiation, for higher level
policy definition, etc., but not for policy at the level of detail
that the SPD, since that would result in 2 WGs with responsibility
for the same data structure. Maybe we need AD clarification here.
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 22 07:32: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 gAMFWmg27255;
Fri, 22 Nov 2002 07:32:48 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17496
Fri, 22 Nov 2002 10:06:30 -0500 (EST)
Message-ID: <3DDDCAF1.E2585BF2@bell-labs.com>
Date: Fri, 22 Nov 2002 01:13:05 -0500
From: Uri Blumenthal <uri@bell-labs.com>
Organization: Lucent Technologies / Bell Labs
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Re: Counter Mode Security: Analysis and Recommendations
References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
<20021121024845.GA792@think.thunk.org> <p05111a00ba02a2eeeea0@[204.42.67.13]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Stephen Kent wrote:
> Ted,
> I concur with your analysis re the storage requirements for this
> attack, and how daunting they seem. This strikes me as the sort of
> attack that I would protect against if it cost almost nothing, but as
> we see, it does have a cost,
Stephen, I'd think that (a) it's worth to protect against this
kind of attack, and (b) the modification should be not in adding
key bits or extra rounds - but by adding *some* "salt" to the IV.
Exactly how many bits, where and why - To Be Defined. There's
work underway to provide a more quantative analysis (D.McGrew
can comment on this part better.)
> .............e.g., in terms of extra storage for
> additional per-SA state for the added bits, or in terms of using
> bigger AES keys, with attendant increases in the number of rounds and
> the key state size.
I can't perceive a few extra bits per SA as real cost. Not really.
> Also there are costs to vendors in supporting the
> additional key sizes and numbers of rounds. At a time when we are
> trying to simplify IPsec and IKE, this seem to be heading in the
> wrong direction.
Yes I agree - this would be heading in the wrong direction.
> Steve
From owner-ipsec@lists.tislabs.com Fri Nov 22 07:57: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 gAMFv9g00544;
Fri, 22 Nov 2002 07:57:09 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17614
Fri, 22 Nov 2002 10:33:49 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100303ba03fb914383@[128.89.88.34]>
In-Reply-To: <3DDDCAF1.E2585BF2@bell-labs.com>
References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
<20021121024845.GA792@think.thunk.org>
<p05111a00ba02a2eeeea0@[204.42.67.13]> <3DDDCAF1.E2585BF2@bell-labs.com>
Date: Fri, 22 Nov 2002 10:27:31 -0500
To: Uri Blumenthal <uri@bell-labs.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Counter Mode Security: Analysis and Recommendations
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 1:13 AM -0500 11/22/02, Uri Blumenthal wrote:
>Stephen Kent wrote:
>> Ted,
>> I concur with your analysis re the storage requirements for this
>> attack, and how daunting they seem. This strikes me as the sort of
>> attack that I would protect against if it cost almost nothing, but as
>> we see, it does have a cost,
>
>Stephen, I'd think that (a) it's worth to protect against this
>kind of attack, and (b) the modification should be not in adding
>key bits or extra rounds - but by adding *some* "salt" to the IV.
>
>Exactly how many bits, where and why - To Be Defined. There's
>work underway to provide a more quantative analysis (D.McGrew
>can comment on this part better.)
>
We agree that it would be preferable to not use a longer key and
incur the cost of extra rounds. I think Russ has pointed out that if
one uses a salt here, it need not be secret, just unpredictable to an
attacker. But, even this has a cost, since these bits are security
relevant and must be maintained inside the security boundary of the
implementation (e.g., relative to FIPS evaluation). So, the bottom
line question is whether an attack requiring this magnitude of
storage is sufficiently realistic that we wish to incur this sort of
cost to protect against it. It's a value judgement, and we are just
seeing differing perspectives expressed.
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 22 08:31: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 gAMGVSg03051;
Fri, 22 Nov 2002 08:31:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17746
Fri, 22 Nov 2002 11:03:15 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100304ba040237d36b@[128.89.88.34]>
In-Reply-To: <15837.35214.666000.792119@gargle.gargle.HOWL>
References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com>
<20021121024845.GA792@think.thunk.org>
<p05111a00ba02a2eeeea0@[204.42.67.13]>
<15837.35214.666000.792119@gargle.gargle.HOWL>
Date: Fri, 22 Nov 2002 10:58:07 -0500
To: Paul Koning <pkoning@equallogic.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Counter Mode Security: Analysis and Recommendations
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 8:34 PM -0500 11/21/02, Paul Koning wrote:
> >>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:
>
> Stephen> Ted, I concur with your analysis re the storage requirements
> Stephen> for this attack, and how daunting they seem. This strikes me
> Stephen> as the sort of attack that I would protect against if it
> Stephen> cost almost nothing, but as we see, it does have a cost,
> Stephen> e.g., in terms of extra storage for additional per-SA state
> Stephen> for the added bits, or in terms of using bigger AES keys,
> Stephen> with attendant increases in the number of rounds and the key
> Stephen> state size. Also there are costs to vendors in supporting
> Stephen> the additional key sizes and numbers of rounds.
>
>Agreed on increasing key sizes. But I don't agree for the case where
>128-bit keys and a 64-bit random number are used. Yes, that increases
>the per-SA state by 8 bytes. And yes, that cost is "almost nothing".
>
> paul
The persistent, per-SA data that is crypto security related for
AES-128-CTR is 16 bytes of key. Depending on the way that the sender
generates the per-packet IV, another 8 bytes might also be retained
per outbound SA. The packet sequence counters (transmit or receive)
and receive window bit map are outside the crypto boundary and thus
may have less stringent storage requirements, so I don't count them
here. Adding 8 bytes for a salt to the 24 byte total noted above is a
33% increase of this type of data.
This cost is almost nothing for software implementations, but in
hardware it might be significant.
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 22 10:31: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 gAMIVVg10333;
Fri, 22 Nov 2002 10:31:31 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17951
Fri, 22 Nov 2002 13:03:54 -0500 (EST)
From: rcharlet@SonicWALL.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: RE: SPD policy document/article
Date: Fri, 22 Nov 2002 10:03:29 -0800
Message-ID: <F4FC57B40BEE6E418CF222DCF8D5546508C271@USEXCH3.us.sonicwall.com>
Thread-Topic: SPD policy document/article
Thread-Index: AcKSRfrKbqilxHcmSP+GKwHLV1PDRQACM5fg
To: <kent@bbn.com>, <hardaker@tislabs.com>
Cc: <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 22 Nov 2002 18:03:31.0364 (UTC) FILETIME=[77702640:01C29251]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA17948
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Howdy,
Maybe more than AD clarification... Realize also that the IPSP work toward developing an IPsec configuration policy model (from which the configuration PIB and MIB flow) was a co-effort between IETF and DMTF.
For perspective sake, the task of configuring differing vendors conformant IPsec implementations was divergent enough to seem to require a unified configuration model before work towards multi-vendor confiugration management tools could be realistic.
The existing configuration model includes several configuration notions not required by 2401 but judged by the authors (IETF and DMTF folks) to merrit inclusion based on (I assume) their deployment expriences.
Personally, I am very curious if anyone has made use of the Policy Model, the PIB or the MIB. NAI's (Wes's group's) implemntation of the MIB to configure an IPsec implementation is the only example I know of.
--
Ricky Charlet rcharlet@alumni.calpoly.edu USA (408) 962-8711
-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Friday, November 22, 2002 6:57 AM
To: Wes Hardaker
Cc: ipsec@lists.tislabs.com; smb@research.att.com; jis@mit.edu
Subject: Re: SPD policy document/article
At 10:39 PM -0800 11/21/02, Wes Hardaker wrote:
> >>>>> On Thu, 21 Nov 2002 19:21:05 -0500, Stephen Kent <kent@bbn.com> said:
>
>Stephen> RFC 2401 establishes the standard for the minimum required
>Stephen> data elements for the SPD used in IPsec, and then defines how
>Stephen> a conformant IPsec implementation uses this data. So, I
>Stephen> assume your comments are referring to other protocols, right?
>
>RFC2401 does talk about the SPD but in a very minimal context. The
>IPSP work is intended to define Ipsec Security Policy in greater detail.
>
>--
>Wes Hardaker
>Network Associates Laboratories
Wes,
2401 defines what a compliant IPsec implementation MUST do. the IPsec
WG is responsible for defining IPsec device compliance. IPSP cannot
define additional requirements for what it means to be IPsec
compliant without impinging on the IPsec WG charter. I thought IPSP
was responsible to protocols for policy negotiation, for higher level
policy definition, etc., but not for policy at the level of detail
that the SPD, since that would result in 2 WGs with responsibility
for the same data structure. Maybe we need AD clarification here.
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 22 10:53: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 gAMIrpg10727;
Fri, 22 Nov 2002 10:53:51 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18058
Fri, 22 Nov 2002 13:30:06 -0500 (EST)
From: "David A. Mcgrew" <mcgrew@cisco.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Counter Mode Security: Analysis and Recommendations
Date: Fri, 22 Nov 2002 10:30:38 -0800
Message-ID: <FPELKLHKCBJLMMMNOGDFMEKGEJAA.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)
Importance: Normal
In-Reply-To: <20021121024845.GA792@think.thunk.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ted,
thanks for your comments and the good data about big-storage systems. Your
point that the attacks that I'm describing are not practical given current
technology (and reasonable bounds on budgets) is certainly correct. A couple of
comments inline:
> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso@mit.edu]
> Sent: Wednesday, November 20, 2002 6:49 PM
> To: Bob Doud
> Cc: 'Paul Koning'; mcgrew@cisco.com; paul.hoffman@vpnc.org;
> ipsec@lists.tislabs.com
> Subject: Re: Counter Mode Security: Analysis and Recommendations
>
>
> On Wed, Nov 20, 2002 at 04:37:57PM -0800, Bob Doud wrote:
> > > >>>>> "David" == David A Mcgrew <mcgrew@cisco.com> writes:
> > <snip>
> > >
> > > David> 4) is it acceptable to implement AES-192 or AES-256 and use
> > > David> those ciphers for counter mode? Or is it desirable to use
> > > David> AES-128 for both CBC and counter mode?
> > >
> > > I would hate to depend on AES-192 or above, since it's not clear to me
> > > how widely those will initialy be implemented in high speed silicon.
> > >
> > And let's keep in mind that a fundamental reason that we're pursuing
> > counter mode in the first place is for high-performance as systems
> > move into the multi-Gigabit range. (Parallelizing the crypto operations
> > across multiple engines with staggered counters.) It's safe to say that
> > all hardware and software implementations will be noticably slower with
> > AES-256 than with AES-128.
>
> The speed hit to go from AES-128 to AES-192 is about 20% (12 rounds
> versus 10 rounds). But that's assuming that folks feel this is
> actually necessary.
>
> I want to make sure that everyone in the IPSEC working group
> understands that the TMTO attack requires only O(2**85) in time, but
> it also requires O(2**85) in space. That means that in order to carry
> out this attack, the attacker needs to have access to order of
> magnitude 512 yottabytes of storage. (For those who aren't familiar
> with the SI prefixes, that's kilo-, mega-, giga-, tera-, peta-, exa-,
> zetta-, yotta-).
You're right that Hellman's TMTO requires 2^85 in order to ensure that it can
break a session with probability close to one. However, there is also the
key-collision attack which should be considered, and that attack does not
require as much memory as does the TMTO.
Also, the TMTO can be implemented so that it requires less memory but has a
lower probability of success. With (2^85 / A) storage, the probability of
success when attacking any particular key will be about (1 / A), so that one out
of every A keys can be broken. This trick is pretty much equivalent to
hybridizing the KC and TMTO attacks.
>
> It's hard to describe how much space this is. Currently, the biggest
> single system commercially available from IBM and EMC (the Shark and
> Symmetrix products, respectively) is 60-70 terabytes. The ASCI
> Purple, which is an incredibly large system for simulating atomic bomb
> explosions at close to the atomic level, and which will probably end
> up costing at least tens of billions of dollars, calls for 1.2
> petabytes. CERN estimates that by 2007, they will hopefully have 2.4
> petabytes of disk storage. Now, 512 yottabytes is 400,000,000 times
> bigger.
>
> Now, I'm willing to believe that the NSA has a much bigger budget than
> the Atomic Bomb folks --- but I'm not sure they have a budget which is
> a factor of four hundred million times bigger.
>
> Speaking of budgets, using an estimate of $2,500/terrabyte, the
> storage required to carry out this attack would cost approximately
> $1,000,000,000,000,000,000 US dollars. That's approximately 200
> hundred thousand times the current US National Debt, and a million
> times the current U.S. Federal budget. So when it was stated that
> this would require a "well funded" attacker, this was rather somewhat
> of an understatement. Even if the prices declined to a penny a
> terrabyte (which might happen by 2023, according to some estimates, if
> storage breakthroughs can continue to happen at current spaces), it
> would still cost $5,000,000,000,000,000, which is still approximately
> a thousand times the current U.S. National Debt. (Of course, by 2023,
> the U.S. National Debt will no doubt be much larger!)
>
> Of course, this estimate completely ignores the overhead in indexing
> this much data for fast access, and the amount of time it would take
> to *write* 512 yottabytes worth of data. (At today's rates of 100
> megabytes/second, it would take quite a while.)
>
> The bottom line is that it's not at all clear to me (with my working
> group chair off) the TMTO attack against AES-128 counter mode is
> really realistic.
Granted. We're discussing appropriate levels of paranoia to protect us into the
future.
> Furthermore, as I pointed out at the IPSEC working
> group, the recommendation of 75 bits worth of keyspace in the ad-hoc
> key-length paper assumed brute-force attacks using large numbers of
> fast, specialized FPGA's with relatively insignificant amounts of
> storage --- hundreds of bytes, not 512 yottabytes of storage. So the
> claim that the strength of AES Counter mode with a 128-bit key has
> fallen below the cipher strength of as recommended by the ad-hoc
> keylength paper seems to involve an apples vs oranges comparison.
I disagree here. From http://www.counterpane.com/keylength.pdf:
<quote>
A cryptographic algorithm is considered strong if:
1. There is no shortcut that allows the opponent to recover the plain text
without using brute force to test keys until the correct one is found; and
2. The number of possible keys is sufficiently large to make such an attack
infeasible.
</quote>
So while this analysis didn't explicitly consider the use precomputation, it
clearly states that there should be no shortcut whose cost would be cheaper than
an exhaustive search. Precomputation attacks can provide such a shortcut, so I
believe that my recommendations are consistent with those of the ad-hoc work
cited above.
>
> That being said, there has been a number of hallway discussions about
> some other ways in which we could add some additional bits of
> unpredictability with minimal disruptions to the drafts, regardless of
> whether it is not necessary. It might not add as many bits as you had
> suggested, but (again with my working group chair hat off), I'm still
> not convinced that this attack, and thus the requirement to defend
> against it, is really realistic. Personally speaking, requiring an
> additional 20% overhead for those people who are worried about what
> seems like a largely theoretical concern doesn't seem like a horrible
> thing.
>
> - Ted
Every bit counts :-)
thanks,
David
From owner-ipsec@lists.tislabs.com Fri Nov 22 11:15: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 gAMJFBg11382;
Fri, 22 Nov 2002 11:15:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18109
Fri, 22 Nov 2002 13:52:18 -0500 (EST)
To: <rcharlet@SonicWALL.com>
Cc: <kent@bbn.com>, <ipsec@lists.tislabs.com>
Subject: Re: SPD policy document/article
References: <F4FC57B40BEE6E418CF222DCF8D5546508C271@USEXCH3.us.sonicwall.com>
From: Wes Hardaker <hardaker@tislabs.com>
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Organization: Network Associates Laboratories
Date: Fri, 22 Nov 2002 10:52:31 -0800
In-Reply-To: <F4FC57B40BEE6E418CF222DCF8D5546508C271@USEXCH3.us.sonicwall.com> (<rcharlet@SonicWALL.com>'s
message of "Fri, 22 Nov 2002 10:03:29 -0800")
Message-ID: <sd65upxwr4.fsf@wanderer.hardakers.net>
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts,
i686-pc-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> On Fri, 22 Nov 2002 10:03:29 -0800, rcharlet@sonicwall.com (Ricky Charlet) said:
Ricky> Personally, I am very curious if anyone has made use of the
Ricky> Policy Model, the PIB or the MIB. NAI's (Wes's group's)
Ricky> implemntation of the MIB to configure an IPsec implementation
Ricky> is the only example I know of.
I've heard of at least 2 other vendors that were at least using the
MIB in some form. I don't know of their current status, and how far
they got, however.
--
Wes Hardaker
Network Associates Laboratories
From owner-ipsec@lists.tislabs.com Fri Nov 22 11:17: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 gAMJHfg11473;
Fri, 22 Nov 2002 11:17:42 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18124
Fri, 22 Nov 2002 13:55:20 -0500 (EST)
Message-Id: <4.3.2.7.2.20021122095901.02e97208@mira-sjc5-4.cisco.com>
X-Sender: byfraser@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 22 Nov 2002 10:20:40 -0800
To: ipsec@lists.tislabs.com
From: Barbara Fraser <byfraser@cisco.com>
Subject: NIST comments on counter mode
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_43355001==_.ALT"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--=====================_43355001==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Folks,
Last August when the issue of FIPS-140 evaluation was mentioned, Ted and I
dropped a quick note to NIST to get their input. Arguably, we should have
cc'd the wg but at the time we were also trying to cool some heated
communications. That being said, it does make sense to get this exchange
included in the working group archives, and this week I asked and received
permission from Bill Burr to forward his email to the list.
Barb
============
X-Sender: wburr@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 14 Aug 2002 13:56:04 -0400
From: Bill Burr <william.burr@nist.gov>
Subject: Re: AES Counter Mode and SHA-256
Ted,
It may well be that it would be cleaner from an implementation and
validation point of view to separate the encryption counter field from the
packet sequence.
I suspect that, if you were making a totally new IPSec implementation from
scratch, or designing the whole protocol from scratch, it wouldn't be any
big deal to use the packet sequence counter as the encryption counter. But
I would imagine that, when you are adding a new counter encryption mode to
an existing IPSec protocol or implementation, it might well simplify your
life to use a separate counter IV field, because otherwise you might well
need to expand the crypto module boundary significantly to encompass a
counter driven from the packet sequence number, and you may not have built
your existing code with that in mind at all. I can't believe that killing
the two birds with the one counter makes FIPS 140 validation impossible,
but I could easily believe that it might double your implementation and
validation costs for the counter mode, or worse.
My intuition tells me that the cleanest, easiest way to add a secure,
easily validated counter mode in IPSEC is to use a separate counter IV in
every packet. This comes, of course, at the expense of extra overhead in
every packet. But we at NIST are not the best people to estimate the cost
to actual implementations of validating either solution.
I'm just saying that NIST isn't a priori ruling out driving your counter
from your packet sequence number. In fact that is the sort of thing we had
thought a lot of folks would want to do.
Bill Burr
At 12:08 PM 8/14/02 -0400, Theodore Ts'o wrote:
>On Wed, Aug 14, 2002 at 11:00:42AM -0400, Bill Burr wrote:
> >
> > So the bottom line is that an implicit counter synchronization mechanism
> > should not itself any bar to FIPS 140-2 validation of IPSEC implantations
> > of a counter mode. But in cryptography, the details matter, and we don't
> > have a lot of counter mode FIPS 140 precedent yet to work from. Pioneers
> > in FIPS new kinds of 140 validations, like pioneers generally, tend to
> step
> > in unmarked holes. When we allow the kind of flexibility we have with
> > counter mode, that makes the validation lab's job harder, and we have to
> > come up with the precise test requirements that the labs must apply.
> >
>
>Bill,
>
>Thanks for your comments. The specific question which has come up is
>with AES counter mode, and whether or not the IV should be generated
>from the normal IPSEC packet sequence, or whether the IV should be
>divorced from the IPSEC packet sequence number.
>
>The argument in favor of divorcing the AES counter mode IV from the
>IPSEC sequence counter is that it means that the code which handles
>the IPSEC packet sequence number (which would drag in largish portions
>of the IKE implementation) into the parts of the code which would need
>to be validated for FIPS 140 purposes. If a separate field were used,
>which was included in the ESP headers, then (so the argument goes)
>only the ESP implementation would need FIPS 140 validation. (Steve,
>please correct me if I haven't stated your concerns cogently.)
>
>The argument on the other side of this issue is that the extra field
>adds bulk to the packet size, and this overhead might be an issue in
>certain applications.
>
>There are unsettled points on both sides of this issue. On the
>"overhead is bad" side, it is unclear whether or not the overhead is
>in fact really a major problem, since it depends very much on the
>application, and complete details of example applications where this
>would be a problem has yet to be forthcoming.
>
>On the "keep the code that needs to be evaluated small" argument, I
>don't yet understand what the impacts would be of (in the worst case)
>the entire IKE implementation in a FIPS 140 validation. Does it make
>the validation impossible? Does it raise the costs by a factor of 2?
>10? 100? 1000?
>
>Many thanks for taking the time to look at this issue.
>
> - Ted
William E. Burr
NIST
Manager, Security Technology Group
301-975-2914
william.burr@nist.gov
--=====================_43355001==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Folks,<br>
<br>
Last August when the issue of FIPS-140 evaluation was mentioned, Ted and
I dropped a quick note to NIST to get their input. Arguably, we should
have cc'd the wg but at the time we were also trying to cool some heated
communications. That being said, it does make sense to get this exchange
included in the working group archives, and this week I asked and
received permission from Bill Burr to forward his email to the
list.<br>
<br>
Barb<br>
<br>
============<br>
<br>
<font size=3>X-Sender: wburr@email.nist.gov<br>
X-Mailer: QUALCOMM Windows Eudora Version 5.1<br>
Date: Wed, 14 Aug 2002 13:56:04 -0400<br>
From: Bill Burr <william.burr@nist.gov><br>
Subject: Re: AES Counter Mode and SHA-256<br>
<br>
</font>Ted,<br>
<br>
It may well be that it would be cleaner from an implementation and
validation point of view to separate the encryption counter field from
the packet sequence. <br>
<br>
I suspect that, if you were making a totally new IPSec implementation
from scratch, or designing the whole protocol from scratch, it wouldn't
be any big deal to use the packet sequence counter as the encryption
counter. But I would imagine that, when you are adding a new
counter encryption mode to an existing IPSec protocol or implementation,
it might well simplify your life to use a separate counter IV field,
because otherwise you might well need to expand the crypto module
boundary significantly to encompass a counter driven from the packet
sequence number, and you may not have built your existing code with that
in mind at all. I can't believe that killing the two birds with the
one counter makes FIPS 140 validation impossible, but I could easily
believe that it might double your implementation and validation costs for
the counter mode, or worse.<br>
<br>
My intuition tells me that the cleanest, easiest way to add a secure,
easily validated counter mode in IPSEC is to use a separate counter IV in
every packet. This comes, of course, at the expense of extra
overhead in every packet. But we at NIST are not the best people to
estimate the cost to actual implementations of validating either
solution. <br>
<br>
I'm just saying that NIST isn't <i>a priori</i> ruling out driving your
counter from your packet sequence number. In fact that is the sort
of thing we had thought a lot of folks would want to do.<br>
<br>
Bill Burr<br>
<br>
At 12:08 PM 8/14/02 -0400, Theodore Ts'o wrote:<br>
<blockquote type=cite cite>On Wed, Aug 14, 2002 at 11:00:42AM -0400, Bill
Burr wrote:<br>
> <br>
> So the bottom line is that an implicit counter synchronization
mechanism <br>
> should not itself any bar to FIPS 140-2 validation of IPSEC
implantations <br>
> of a counter mode. But in cryptography, the details matter,
and we don't <br>
> have a lot of counter mode FIPS 140 precedent yet to work
from. Pioneers <br>
> in FIPS new kinds of 140 validations, like pioneers generally, tend
to step <br>
> in unmarked holes. When we allow the kind of flexibility we
have with <br>
> counter mode, that makes the validation lab's job harder, and we
have to <br>
> come up with the precise test requirements that the labs must
apply.<br>
> <br>
<br>
Bill,<br>
<br>
Thanks for your comments. The specific question which has come up
is<br>
with AES counter mode, and whether or not the IV should be
generated<br>
from the normal IPSEC packet sequence, or whether the IV should be<br>
divorced from the IPSEC packet sequence number.<br>
<br>
The argument in favor of divorcing the AES counter mode IV from the<br>
IPSEC sequence counter is that it means that the code which handles<br>
the IPSEC packet sequence number (which would drag in largish
portions<br>
of the IKE implementation) into the parts of the code which would
need<br>
to be validated for FIPS 140 purposes. If a separate field were
used,<br>
which was included in the ESP headers, then (so the argument goes)<br>
only the ESP implementation would need FIPS 140 validation.
(Steve,<br>
please correct me if I haven't stated your concerns cogently.)<br>
<br>
The argument on the other side of this issue is that the extra
field<br>
adds bulk to the packet size, and this overhead might be an issue
in<br>
certain applications.<br>
<br>
There are unsettled points on both sides of this issue. On
the<br>
"overhead is bad" side, it is unclear whether or not the
overhead is<br>
in fact really a major problem, since it depends very much on the<br>
application, and complete details of example applications where
this<br>
would be a problem has yet to be forthcoming.<br>
<br>
On the "keep the code that needs to be evaluated small"
argument, I<br>
don't yet understand what the impacts would be of (in the worst
case)<br>
the entire IKE implementation in a FIPS 140 validation. Does it
make<br>
the validation impossible? Does it raise the costs by a factor of
2?<br>
10? 100? 1000?<br>
<br>
Many thanks for taking the time to look at this issue.<br>
<br>
<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>-
Ted</blockquote><br>
William E. Burr<br>
NIST<br>
Manager, Security Technology Group<br>
301-975-2914<br>
william.burr@nist.gov </html>
--=====================_43355001==_.ALT--
From owner-ipsec@lists.tislabs.com Fri Nov 22 11:20: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 gAMJKfg11732;
Fri, 22 Nov 2002 11:20:41 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18142
Fri, 22 Nov 2002 13:58:29 -0500 (EST)
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@lists.tislabs.com, smb@research.att.com, jis@mit.edu
Subject: Re: SPD policy document/article
References: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10>
<sdvg2qk20i.fsf@wanderer.hardakers.net>
<p05111a02ba032870e00d@[10.0.1.3]>
<sdadk2jegg.fsf@wanderer.hardakers.net>
<p05100301ba03f1dcfbc8@[128.89.88.34]>
From: Wes Hardaker <hardaker@tislabs.com>
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Organization: Network Associates Laboratories
Date: Fri, 22 Nov 2002 10:58:46 -0800
In-Reply-To: <p05100301ba03f1dcfbc8@[128.89.88.34]> (Stephen Kent's message
of "Fri, 22 Nov 2002 09:57:09 -0500")
Message-ID: <sd3cptxwgp.fsf@wanderer.hardakers.net>
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts,
i686-pc-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> On Fri, 22 Nov 2002 09:57:09 -0500, Stephen Kent <kent@bbn.com> said:
Stephen> 2401 defines what a compliant IPsec implementation MUST
Stephen> do. the IPsec WG is responsible for defining IPsec device
Stephen> compliance. IPSP cannot define additional requirements for
Stephen> what it means to be IPsec compliant without impinging on the
Stephen> IPsec WG charter.
The IPSP group doesn't mandate that you implement a SPD their way.
You are right that to be compliant you only need to implement the
minimum requirements of 2401. The IPSP group has many things in their
charter (including policy discovery, etc). The model (and MIB/PIB
extrapolations of it) are merely "one way" to implement the SPD. It's
not required that you do so to be a IPsec compliant device. Now, if
you want to be an IPsec compliant box which is compatible with other
boxes for configuration of the SPD then you might have to conform to
one of those other specs. IE, IPsec WG = protocol; IPSP WG =
interoperability configuration of the protocol.
At least this is my take on it. Listen to the ADs instead of me, of
course. Or better yet, we have these things called charters that
should clear things up as well:
http://www.ietf.org/html.charters/ipsp-charter.html
http://www.ietf.org/html.charters/ipsec-charter.html
--
Wes Hardaker
Network Associates Laboratories
From owner-ipsec@lists.tislabs.com Fri Nov 22 11:22:02 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 gAMJM1g11880;
Fri, 22 Nov 2002 11:22:02 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18158
Fri, 22 Nov 2002 14:01:32 -0500 (EST)
Date: Fri, 22 Nov 2002 11:59:34 -0700
Message-Id: <200211221859.gAMIxYn13111@localhost.localdomain>
From: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
To: tytso@mit.edu
Cc: ipsec@lists.tislabs.com
In-reply-to: Yourmessage <20021122040009.GA549@think.thunk.org>
Subject: Re: Counter Mode Security: Attacks, Storage & a Proposal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Creating a lookup table for a cipher with a key of N bits is 2^N in
time and space, not O(1). The 2^85 figure for counter mode is the
right way to look at it.
We are talking about 2^85 in storage and 2^85 in time for counter mode,
as noted several times. The argument is over whether or not there is such a
large linear factor associated with storage that we should take it into
account in the measure of difficulty. There are some reasons to do so,
two being the cost of access and the fact that storage is committed for
the duration of the calculation, while CPU cycles just keep accumulating.
Based on today's storage technology, it would appear that, given Moore's
Law, there is a 50 year safety margin in the 2^85 storage difficulty.
I'd cut that down considerably, because storage is area with the most
room for improvement, based on physics. Nonetheless, I guess it is
unlikely to change dramatically in the next 20 years. That puts it at
the edge of acceptability. I'd still vote no, were anyone voting.
Hilarie
From owner-ipsec@lists.tislabs.com Fri Nov 22 11:32: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 gAMJWNg12998;
Fri, 22 Nov 2002 11:32:24 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18194
Fri, 22 Nov 2002 14:07:32 -0500 (EST)
Date: Fri, 22 Nov 2002 12:04:43 -0700
Message-Id: <200211221904.gAMJ4hT13437@localhost.localdomain>
From: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
To: kent@bbn.com
Cc: hardaker@tislabs.com, jis@mit.edu, smb@research.att.com,
ipsec@lists.tislabs.com, lsanchez@xapiens.com
In-reply-to: Yourmessage <p05100301ba03f1dcfbc8@[128.89.88.34]>
Subject: Re: SPD policy document/article
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The work on the data model for PIBs and MIBs has resulted in defining
a greater level of detail about what it means to configure an IPsec
device. It would be impossible to do the work without coming across
these issues. However, this remains entirely consistent with RFC2401.
Hilarie
From owner-ipsec@lists.tislabs.com Fri Nov 22 11:41: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 gAMJfXg14251;
Fri, 22 Nov 2002 11:41:33 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18232
Fri, 22 Nov 2002 14:13:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100317ba0430edccf9@[128.89.88.34]>
In-Reply-To: <sd3cptxwgp.fsf@wanderer.hardakers.net>
References: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10>
<sdvg2qk20i.fsf@wanderer.hardakers.net>
<p05111a02ba032870e00d@[10.0.1.3]>
<sdadk2jegg.fsf@wanderer.hardakers.net>
<p05100301ba03f1dcfbc8@[128.89.88.34]>
<sd3cptxwgp.fsf@wanderer.hardakers.net>
Date: Fri, 22 Nov 2002 14:11:04 -0500
To: Wes Hardaker <hardaker@tislabs.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: SPD policy document/article
Cc: ipsec@lists.tislabs.com, smb@research.att.com, jis@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:58 AM -0800 11/22/02, Wes Hardaker wrote:
> >>>>> On Fri, 22 Nov 2002 09:57:09 -0500, Stephen Kent <kent@bbn.com> said:
>
>Stephen> 2401 defines what a compliant IPsec implementation MUST
>Stephen> do. the IPsec WG is responsible for defining IPsec device
>Stephen> compliance. IPSP cannot define additional requirements for
>Stephen> what it means to be IPsec compliant without impinging on the
>Stephen> IPsec WG charter.
>
>The IPSP group doesn't mandate that you implement a SPD their way.
>You are right that to be compliant you only need to implement the
>minimum requirements of 2401. The IPSP group has many things in their
>charter (including policy discovery, etc). The model (and MIB/PIB
>extrapolations of it) are merely "one way" to implement the SPD. It's
>not required that you do so to be a IPsec compliant device. Now, if
>you want to be an IPsec compliant box which is compatible with other
>boxes for configuration of the SPD then you might have to conform to
>one of those other specs. IE, IPsec WG = protocol; IPSP WG =
>interoperability configuration of the protocol.
>
It's obvious that there needs to be close coordination between what
the SPD specifies and what IKE can negotiate, something that caused
several last minute changes to 2401 and even then we didn't get it
perfect. In developing 2401bis and IKE v2 we are working closely to
ensure better coordination. So, if IPSP goes off and creates
additions to the SPD separate from the work in the IPsec WG, where
2401bis and IKEv2 are developed, don't you anticipate disconnects
that will impair operation?
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 22 12:00: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 gAMK0tg14686;
Fri, 22 Nov 2002 12:00:56 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18352
Fri, 22 Nov 2002 14:33:59 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100319ba04366b1745@[128.89.88.34]>
In-Reply-To: <200211221904.gAMJ4hT13437@localhost.localdomain>
References: <200211221904.gAMJ4hT13437@localhost.localdomain>
Date: Fri, 22 Nov 2002 14:32:41 -0500
To: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
From: Stephen Kent <kent@bbn.com>
Subject: Re: SPD policy document/article
Cc: hardaker@tislabs.com, jis@mit.edu, smb@research.att.com,
ipsec@lists.tislabs.com, lsanchez@xapiens.com, kent@bbn.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 12:04 PM -0700 11/22/02, The Purple Streak, Hilarie Orman wrote:
>The work on the data model for PIBs and MIBs has resulted in defining
>a greater level of detail about what it means to configure an IPsec
>device. It would be impossible to do the work without coming across
>these issues. However, this remains entirely consistent with RFC2401.
>
>Hilarie
Thanks for the clarification.
In that case I see no conflict, although it was impossible for me to
tell that from Wes's original message, or his subsequent responses.
Wes, if you agree with Hilarie's characterization, why didn't you
make that comment and avoid our continued discussion on the list?
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 22 12:49: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 gAMKn9g17447;
Fri, 22 Nov 2002 12:49:09 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18611
Fri, 22 Nov 2002 15:22:48 -0500 (EST)
From: Black_David@emc.com
Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C57E@corpmx14.us.dg.com>
To: pkoning@equallogic.com
Cc: ipsec@lists.tislabs.com
Subject: RE: Counter Mode Security: Attacks, Storage & a Proposal
Date: Fri, 22 Nov 2002 15:23:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Responding to Paul's two observations on my post ...
> I'm also somewhat hesitant to argue about your storage cost numbers,
> but still, two observations...
>
> 1. As I recall, the historical rate of capacity growth has not been
> all that constant (unlike, say, the Moore's Law analog in processing
> power). Not all that many years ago the rate increased dramatically,
> I believe.
I believe that's correct, and "doubles about annually" is the new
"dramatically" increased rate. The better part of a decade ago,
progress on disk media density was sufficiently slow that it looked
like DRAM might start seriously encroaching on disk space. Some
physicists/materials scientists got seriously annoyed about this,
and the results are now obvious ...
> 2. The analysis assumes that hard drives are and continue to be the
> most cost effective (YB/$) technology. I'm not sure that's true now
> (consider tape libraries) and it may not be true later.
As Ted pointed out, tape libraries are an obvious non-starter for this
sort of attack, although a cut down version of the attack computation
might make a nice tape drive and robot abuse test ;-) .
One can indeed speculate about new storage technologies coming along -
one could also speculate about the quantum computer folks succeeding
and rendering entire classes of complexity analyses obsolete.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786
black_david@emc.com Mobile: +1 (978) 394-7754
----------------------------------------------------
From owner-ipsec@lists.tislabs.com Fri Nov 22 13: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 gAMLlWg23762;
Fri, 22 Nov 2002 13:47:32 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA18765
Fri, 22 Nov 2002 16:21:33 -0500 (EST)
From: "Casey Carr" <caseyc@cipheroptics.com>
To: <rcharlet@SonicWALL.com>, <kent@bbn.com>, <hardaker@tislabs.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: SPD policy document/article
Date: Fri, 22 Nov 2002 15:55:16 -0500
Message-ID: <001001c29269$7631c5f0$b101a8c0@cipheroptics.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <F4FC57B40BEE6E418CF222DCF8D5546508C271@USEXCH3.us.sonicwall.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Loop-Detect: 1
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
We have made use of the IPSP policy model but we have not maintained our
implementation in lock step with the draft revisions. Implementing the MIB
is a possibility for us but it would have to be a customer driven
requirement because we are using a proprietary Web interface to manage our
device. We are moving toward integration with third party network
management products using an XML implementation of the model.
We used the IPSP policy model in the following fashion:
1) We created a proprietary XML schema based on the model.
2) Implemented a set of runtime CPP classes that implement the model
3) These classes are instantiated at runtime via parsing of an XML file
using Xerces.
4) This instantiated policy model is then used for all modifications to
IPSec policy within our device.
5) Changes to the model are saved to XML files.
6) The runtime instantiated policy is used to populate runtime SPD and
initialize the IKE runtime library.
7) We also implemented serialization of the model instance for remote
procedure calls via TCP sockets.
BTW, I agree with Ricky. This model did give us a more concrete way of
dealing with IPSec policies. Mapping this model to our 2401 compliant SPD
implementation was straight forward (well more like painful but doable).
I'm guessing that the model was very useful for MIB/PIB writers.
Our goal in choosing this path was to try to at least give ourselves a
chance at being standards based if this group successfully produced RFC
documents. If there is market demand for implementing the IPSP MIB, it
should be doable for us because are management is based on the model. If
there is any interest in the working group for standardizing the XML schema
I would like to hear about it. I can here the groans now. "Why didn't you
just use the MIB?" We had are reasons, I'm still convinced we made the
right choice but time will tell. We do include an SNMP agent and trap
generation in our product, just not SNMP device configuration.
Can anyone name a single network management platform that uses a standard
SNMP MIB for configuration management that works across multiple vendors?
If so, what was the effort level required between the device and NM platform
vendor to actually get it to work. If you are going to write device
specific/vendor specific code for configuration management, my personal
opinion is that SNMP is a very ineffective protocol to accomplish the task.
-----Original Message-----
From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]
On Behalf Of rcharlet@SonicWALL.com
Sent: Friday, November 22, 2002 1:03 PM
To: kent@bbn.com; hardaker@tislabs.com
Cc: ipsec@lists.tislabs.com
Subject: RE: SPD policy document/article
Howdy,
Maybe more than AD clarification... Realize also that the IPSP work toward
developing an IPsec configuration policy model (from which the configuration
PIB and MIB flow) was a co-effort between IETF and DMTF.
For perspective sake, the task of configuring differing vendors conformant
IPsec implementations was divergent enough to seem to require a unified
configuration model before work towards multi-vendor confiugration
management tools could be realistic.
The existing configuration model includes several configuration notions not
required by 2401 but judged by the authors (IETF and DMTF folks) to merrit
inclusion based on (I assume) their deployment expriences.
Personally, I am very curious if anyone has made use of the Policy Model,
the PIB or the MIB. NAI's (Wes's group's) implemntation of the MIB to
configure an IPsec implementation is the only example I know of.
--
Ricky Charlet rcharlet@alumni.calpoly.edu USA (408) 962-8711
-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Friday, November 22, 2002 6:57 AM
To: Wes Hardaker
Cc: ipsec@lists.tislabs.com; smb@research.att.com; jis@mit.edu
Subject: Re: SPD policy document/article
At 10:39 PM -0800 11/21/02, Wes Hardaker wrote:
> >>>>> On Thu, 21 Nov 2002 19:21:05 -0500, Stephen Kent <kent@bbn.com>
said:
>
>Stephen> RFC 2401 establishes the standard for the minimum required
>Stephen> data elements for the SPD used in IPsec, and then defines how
>Stephen> a conformant IPsec implementation uses this data. So, I
>Stephen> assume your comments are referring to other protocols, right?
>
>RFC2401 does talk about the SPD but in a very minimal context. The
>IPSP work is intended to define Ipsec Security Policy in greater detail.
>
>--
>Wes Hardaker
>Network Associates Laboratories
Wes,
2401 defines what a compliant IPsec implementation MUST do. the IPsec
WG is responsible for defining IPsec device compliance. IPSP cannot
define additional requirements for what it means to be IPsec
compliant without impinging on the IPsec WG charter. I thought IPSP
was responsible to protocols for policy negotiation, for higher level
policy definition, etc., but not for policy at the level of detail
that the SPD, since that would result in 2 WGs with responsibility
for the same data structure. Maybe we need AD clarification here.
Steve
From owner-ipsec@lists.tislabs.com Fri Nov 22 15:50:54 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id gAMNorg02490;
Fri, 22 Nov 2002 15:50:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18969
Fri, 22 Nov 2002 18:22:09 -0500 (EST)
To: Stephen Kent <kent@bbn.com>
Cc: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>, jis@mit.edu,
smb@research.att.com, ipsec@lists.tislabs.com, lsanchez@xapiens.com
Subject: Re: SPD policy document/article
References: <200211221904.gAMJ4hT13437@localhost.localdomain>
<p05100319ba04366b1745@[128.89.88.34]>
From: Wes Hardaker <hardaker@tislabs.com>
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Organization: Network Associates Laboratories
Date: Fri, 22 Nov 2002 15:21:49 -0800
In-Reply-To: <p05100319ba04366b1745@[128.89.88.34]> (Stephen Kent's message
of "Fri, 22 Nov 2002 14:32:41 -0500")
Message-ID: <sdn0o1w5pu.fsf@wanderer.hardakers.net>
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts,
i686-pc-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> On Fri, 22 Nov 2002 14:32:41 -0500, Stephen Kent <kent@bbn.com> said:
Stephen> Wes, if you agree with Hilarie's characterization, why didn't
Stephen> you make that comment and avoid our continued discussion on
Stephen> the list?
I was functionally trying to say the same thing, but in greater
detail. You apparently understood her description better, probably
because she's better at getting her point across and probably because
she's gotten more sleep than I have this week ;-)
--
Wes Hardaker
Network Associates Laboratories
From owner-ipsec@lists.tislabs.com Fri Nov 22 15:52: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 gAMNqdg02532;
Fri, 22 Nov 2002 15:52:39 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18975
Fri, 22 Nov 2002 18:25:09 -0500 (EST)
To: "Casey Carr" <caseyc@cipheroptics.com>
Cc: <rcharlet@SonicWALL.com>, <kent@bbn.com>, <ipsec@lists.tislabs.com>
Subject: Re: SPD policy document/article
References: <001001c29269$7631c5f0$b101a8c0@cipheroptics.com>
From: Wes Hardaker <hardaker@tislabs.com>
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Organization: Network Associates Laboratories
Date: Fri, 22 Nov 2002 15:24:53 -0800
In-Reply-To: <001001c29269$7631c5f0$b101a8c0@cipheroptics.com> ("Casey
Carr"'s message of "Fri, 22 Nov 2002 15:55:16 -0500")
Message-ID: <sdk7j5w5kq.fsf@wanderer.hardakers.net>
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts,
i686-pc-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> On Fri, 22 Nov 2002 15:55:16 -0500, "Casey Carr" <caseyc@cipheroptics.com> said:
Casey> Can anyone name a single network management platform that uses
Casey> a standard SNMP MIB for configuration management that works
Casey> across multiple vendors?
Yes, though I won't start this discussion in this forum, as it's *way*
off topic.
Casey> If you are going to write device specific/vendor specific code
Casey> for configuration management, my personal opinion is that SNMP
Casey> is a very ineffective protocol to accomplish the task.
You might see if the extensions being developed in the EoS working
group fit your needs, btw.
--
Wes Hardaker
Network Associates Laboratories
From owner-ipsec@lists.tislabs.com Sat Nov 23 04:32: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 gANCWOg01869;
Sat, 23 Nov 2002 04:32:24 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA20220
Sat, 23 Nov 2002 07:04:23 -0500 (EST)
Message-Id: <3.0.3.32.20021123040402.017769c8@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Sat, 23 Nov 2002 04:04:02 -0800
To: Bob Doud <BDoud@hifn.com>, "'Paul Koning'" <pkoning@equallogic.com>
From: Alex Alten <Alten@attbi.com>
Subject: RE: Counter Mode Security: Analysis and Recommendations
Cc: mcgrew@cisco.com, tytso@mit.edu, paul.hoffman@vpnc.org,
ipsec@lists.tislabs.com
In-Reply-To: <51C7002B020CD411824E009027C469F7DD3393@cldxch01.hifn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:23 AM 11/21/2002 -0800, Bob Doud wrote:
>> >>>>> "Alex" == Alex Alten <Alten@attbi.com> writes:
>>
>> At 04:37 PM 11/20/2002 -0800, Bob Doud wrote:
>> >> <snip>
>> >> And let's keep in mind that a fundamental reason that we're
>> >> pursuing counter mode in the first place is for high-performance
>> >> as systems move into the multi-Gigabit range. (Parallelizing the
>> >> crypto operations across multiple engines with staggered
>> >> counters.) It's safe to say that all hardware and software
>> >> implementations will be noticably slower with AES-256 than with
>> >> AES-128.
>> >>
>> >> Bob
>> >>
>>
>> Alex> Really? And all these expensive parallel hardware engines will
>> Alex> still be effective on the receiving end when packets arrive out
>> Alex> of order, are lost, duplicated or fragmented? What about
>> Alex> interleaved packet streams from different hosts? What about
>> Alex> hash computations?
>>
>> IPsec acts on IP datagrams. So loss, duplication, or reordering of IP
>> packets clearly has no effect.
>>
>> Fragments? In IPv6 there are no fragments, obviously. In IPv4, there
>> are no fragments either in settings where high performance is
>> expected.
>>
>> Alex> And who will buy them? 1 Gigabit/sec cards go for $50 today.
>> Alex> The cheapest AES chips are $25 each, which is $125 retail. You
>> Alex> will need about 4 of them at least. So now that card becomes a
>> Alex> $500 card. Ten times as expensive. By the time they become
>> Alex> cheap enough the world will be using 10 gigabit/sec Ethernet.
>>
>> You seem to be assuming that the only way to get multiple AES units is
>> to buy multiple chips, and collect them on a board. That's actually
>> the least likely approach.
>>
>> All high speed crypto chips contain multiple cipher units inside the
>> chip. Right now, with CBC mode, it's difficult to keep them all
>> working effectively, because any given packet has to be handled by a
>> single cipher unit due to the chaining. With counter mode, such
>> multiple-unit chips can easily run at full speed even when acting on a
>> single packet stream, because each cipher block can be processed by a
>> separate unit. In other words, a packet as short as 64 bytes can get
>> the performance gain of four cipher units working in parallel.
>>
>> In high speed crypto chips, and especially with efficient ciphers like
>> AES, the crypto cores are not all that large a part of the whole
>> chip. Control, embedded memory, bus interfaces, etc. all tie up large
>> parts. So the incremental cost of a whole bunch of cipher units is
>> very much lower than you claimed.
>>
>> paul
>>
>
>Correct Paul. And stay tuned Alex... we'll be seeing VERY cost effective
>Gigabit security chip coming along soon. It would just be nice to get
>these CTR mode issues nailed down soon so us chip guys can provide
>support for this mode!
>
OK. So each packet has an independent IV. And frags are infrequent.
Although to be honest, how the datalink drivers deliver the packet bytes
can be all over the map, I suspect internal control block frags may be
all too common an issue to deal with.
Of course there's still the *minor* matter of the hash. Unless I'm
mistaken, this still requires linear sequential processing of the packet
bytes. Won't this disrupt the tidy flow of parallel blocks?
Cost is still a factor. Let's say you drive it in total to $25 per chip
today. This is $125 retail + $50 for 1 Gbps Ethernet hardware. That's
a tough sell.
The really big win I see for AES-CTR is the fact you no longer need to add
padding to the packet. That simplifies life considerably for writing a
software driver/filter.
- Alex
--
Alex Alten
Alten@ATTBI.com
"I said be there.
And you crushed the stones to be there."
- Genghis Khan, 13th century
From owner-ipsec@lists.tislabs.com Sat Nov 23 11:16: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 gANJGdg02593;
Sat, 23 Nov 2002 11:16:39 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20740
Sat, 23 Nov 2002 13:42:31 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15839.52287.504564.638954@pkoning.akdesign.com>
Date: Sat, 23 Nov 2002 13:43:11 -0500
From: Paul Koning <pkoning@equallogic.com>
To: Alten@attbi.com
Cc: ipsec@lists.tislabs.com
Subject: RE: Counter Mode Security: Analysis and Recommendations
References: <51C7002B020CD411824E009027C469F7DD3393@cldxch01.hifn.com>
<3.0.3.32.20021123040402.017769c8@mail>
X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Alex" == Alex Alten <Alten@attbi.com> writes:
Alex> OK. So each packet has an independent IV. And frags are
Alex> infrequent. Although to be honest, how the datalink drivers
Alex> deliver the packet bytes can be all over the map, I suspect
Alex> internal control block frags may be all too common an issue to
Alex> deal with.
I have no idea what you're talking about.
Obviously, it's possible to design an OS and its drivers so as to
achieve poor performance. It's also possible to design it for good
performance. Take your pick.
Alex> Of course there's still the *minor* matter of the hash. Unless
Alex> I'm mistaken, this still requires linear sequential processing
Alex> of the packet bytes. Won't this disrupt the tidy flow of
Alex> parallel blocks?
Yes, which is why people keep looking for faster hashes. Note also
that in the past, encryption has generally been substantially slower
than the authentication hash, so a speedup of the encryption transform
translated directly into a speedup of the overall processing.
Alex> Cost is still a factor. Let's say you drive it in total to $25
Alex> per chip today. This is $125 retail + $50 for 1 Gbps Ethernet
Alex> hardware. That's a tough sell.
Maybe, maybe not; depends on the system cost and the value of the
data. In any case, you're talking about the cost of crypto in general
here; counter mode is certainly no worse, and most likely better, than
the others.
Alex> The really big win I see for AES-CTR is the fact you no longer
Alex> need to add padding to the packet. That simplifies life
Alex> considerably for writing a software driver/filter.
Not a chance. For one thing, you still need padding (to a multiple of
4 bytes, standard ESP encapsulation rule that applies to all
transforms unless they have a higher requirement). For another, the
total effort to do padding amounts to perhaps 20-30 lines out of
several thousand.
paul
From owner-ipsec@lists.tislabs.com Sat Nov 23 13:42: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 gANLgbg22731;
Sat, 23 Nov 2002 13:42:38 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20925
Sat, 23 Nov 2002 16:12:21 -0500 (EST)
Message-ID: <AD1F046251DCD311BA6F0020484037670446A4C3@aimexc02.corp.adaptec.com>
From: "Mukund, Shridhar" <Shridhar_Mukund@adaptec.com>
To: "'Alex Alten'" <Alten@attbi.com>, Bob Doud <BDoud@hifn.com>,
"'Paul Koning'" <pkoning@equallogic.com>
Cc: mcgrew@cisco.com, tytso@mit.edu, paul.hoffman@vpnc.org,
ipsec@lists.tislabs.com
Subject: RE: Counter Mode Security: Analysis and Recommendations
Date: Sat, 23 Nov 2002 13:12:39 -0800
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
Alex(/David),
You have a good point there about the authentication complexity of
say AES-CBC. It does not nicely match with that of Counter-mode-AES.
contd ...
> -----Original Message-----
>...
> Of course there's still the *minor* matter of the hash. Unless I'm
> mistaken, this still requires linear sequential processing of
> the packet
> bytes. Won't this disrupt the tidy flow of parallel blocks?
>
> Cost is still a factor. Let's say you drive it in total to
> $25 per chip
> today. This is $125 retail + $50 for 1 Gbps Ethernet
> hardware. That's
> a tough sell.
> ...
> - Alex
Having said that, simplifying one of them does help silicon
implementations quite a bit. I hate to get into $ numbers, because
no matter what we end up integrating, folks like David do not like
to pay us more than 20-40% margin over the cost of "sand" :-)
Whatever happend to the thoughts around specifying an authentication
algorithm that used AES-CBC-I (Interleaved CBC)? David, maybe you
should take this up next. I can do some leg work for you. With a
reasonable degree, instead of just 3, one can do wonders in
providing head room for run-time vs. space complexity trade-off.
-Shridhar Mukund
From owner-ipsec@lists.tislabs.com Sun Nov 24 23:52: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 gAP7qNg03087;
Sun, 24 Nov 2002 23:52:23 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA22925
Mon, 25 Nov 2002 02:06:13 -0500 (EST)
From: juha.ollila@nokia.com
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Subject: RE: draft-ietf-ipsec-pki-profile-01.txt
Date: Mon, 25 Nov 2002 08:32:56 +0200
Message-ID: <B49318639A71D3418DC1005FD40B3610E02967@ouebe005.ntc.nokia.com>
Thread-Topic: draft-ietf-ipsec-pki-profile-01.txt
Thread-Index: AcKJrD5kIu7+QEeqTD+23As5TcUy1AKnKfBg
To: <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 25 Nov 2002 06:32:57.0265 (UTC) FILETIME=[7E07A210:01C2944C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id CAA22922
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello!
In section 3.2.1:
"Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR ID type."
I think that there can be IKE for the dual IP stack, thus it should be:
Implementations MUST support the ID_IPV4_ADDR and/or ID_IPV6_ADDR ID type.
Best Regards,
Juha Ollila
From owner-ipsec@lists.tislabs.com Mon Nov 25 07:53: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 gAPFrjg14043;
Mon, 25 Nov 2002 07:53:45 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23697
Mon, 25 Nov 2002 10:19:40 -0500 (EST)
From: "David A. Mcgrew" <mcgrew@cisco.com>
To: "Alex Alten" <Alten@attbi.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Counter Mode Security: Analysis and Recommendations
Date: Mon, 25 Nov 2002 06:13:21 -0800
Message-ID: <FPELKLHKCBJLMMMNOGDFEEOKEJAA.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)
Importance: Normal
In-Reply-To: <3.0.3.32.20021123040402.017769c8@mail>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Alex,
Alex Alten wrote:
>
> Of course there's still the *minor* matter of the hash. Unless I'm
> mistaken, this still requires linear sequential processing of the packet
> bytes. Won't this disrupt the tidy flow of parallel blocks?
that's right. In order to reap the implementation benefits of counter mode, you
need to have a MAC that can also be pipelined. Unfortunately, none of the
standardized MACs have that property. This is especially problematic because
counter mode should be run with a MAC (and in the current ESP draft, MUST be run
with a MAC).
David
From owner-ipsec@lists.tislabs.com Mon Nov 25 09:11: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 gAPHBSg19302;
Mon, 25 Nov 2002 09:11:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23763
Mon, 25 Nov 2002 11:36:47 -0500 (EST)
From: Charlie_Kaufman@notesdev.ibm.com
Subject: Changing the cookie order in IKEv2
To: ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002
Message-ID: <OF074CA472.D9E837BE-ON85256C7C.000D43DA-85256C7C.000EAF99@iris.com>
Date: Sun, 24 Nov 2002 21:40:24 -0500
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 11/25/2002
11:37:30 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At the IETF meeting, Tero Kivinen explained to me some of the unnatural
acts NATs perform on IKEv1 in order to "transparently" support IPsec SAs
through NATs. One of the things they sometimes do is look at the "cookies"
in the header of IKEv1 messages in order to figure out how to route
packets. One of the changes I made in specifying IKEv2 was to change the
order of the cookies in messages going from responder to initiator so that
an endpoint could always identify an SA based on the first cookie in the
packet alone. I made the change both because there were certain fringe
cases where it was needed (because otherwise two SAs might have the same
cookie pair) and because it seemed more elegant and consistent with IP.
But the fringe case can be disambiguated using the I(nitiator) bit in the
header, and changing the cookie order will break certain NATs which
apparently will work unmodified with IKEv2 if we don't change the cookie
order.
So I'd like to propose that the cookie order be changed back to what it was
in IKEv1, with the IKE SA initiator's cookie followed by the IKE SA
responder's cookie regardless of the direction of the packet.
Any objections?
--Charlie
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
From owner-ipsec@lists.tislabs.com Mon Nov 25 09:11: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 gAPHBSg19301;
Mon, 25 Nov 2002 09:11:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23762
Mon, 25 Nov 2002 11:36:47 -0500 (EST)
From: Charlie_Kaufman@notesdev.ibm.com
In-Reply-To: <015301c28ce3$d8697550$23f22b42@mv.lucent.com>
Subject: Re: Generating Keying Material
To: "David Faucher" <dfaucher@lucent.com>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002
Message-ID: <OF5F4ED73B.BB950E89-ON85256C7C.000CB149-85256C7C.000D34B3@iris.com>
Date: Sun, 24 Nov 2002 21:24:14 -0500
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 11/25/2002
11:37:28 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Section 4.3 of draft-ietf-ipsec-ikev2-03.txt states
>
> "Keying material will always be derived as the output of the
> negotiated prf algorithm. If the amount of keying material is greater
> than the size of the output of the prf algorithm, we will use the prf
> iteratively..."
>
> Rather than having two methods for generating key material (based on the
> size of key material needed vs. the size of the prf output), wouldn't it
> easier to have prf+ generate a pseudo-random stream from which all key
> material is taken?
>
> Keeps it simple and straight forward.
>
> David
Oops. When I changed the iterative use of prf to prf+, I forgot to update
this text. Switching between two methods was never intended, and there
is no specification as to how the prf would be used if its output were
large enough.
I'll fix it.
--Charlie
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
From owner-ipsec@lists.tislabs.com Mon Nov 25 09:20: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 gAPHKUg19587;
Mon, 25 Nov 2002 09:20:31 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23803
Mon, 25 Nov 2002 11:45:09 -0500 (EST)
Message-ID: <007601c2949d$60023950$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Subject: Protection against DoS attack
Date: Mon, 25 Nov 2002 10:11:52 -0600
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Section 4.4 of draft-ietf-ipsec-ikev2-03.txt states
that there is a denial of service attack on the initiator
that can be avoided if the initiator takes proper care.
Is it worth the added complexity of having the initiator
accept multiple responses to its first message and are we
just trading one DoS for another?
Since there is a significant amount of processing associated
with creating message 3, an implementation would presumably
limit the number of responses it is willing to accept. An attacker
could flood the initiator with enough bogus responses to still
poison the connection setup.
David
From owner-ipsec@lists.tislabs.com Mon Nov 25 09:20: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 gAPHKfg19610;
Mon, 25 Nov 2002 09:20:41 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23849
Mon, 25 Nov 2002 11:56:21 -0500 (EST)
Message-Id: <200211251319.IAA26628@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-dpd-01.txt
Date: Mon, 25 Nov 2002 08:19:37 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : A Traffic-Based Method of Detecting Dead IKE Peers
Author(s) : G. Huang, S. Beaulieu, D. Rochefort
Filename : draft-ietf-ipsec-dpd-01.txt
Pages : 10
Date : 2002-11-22
This draft describes a method of detecting a dead IKE peer. The
method, called Dead Peer Detection (DPD) uses IPSec traffic patterns
to limit the number of IKE messages sent. DPD, like other keepalive
mechanisms, is often necessary to perform IKE peer failover, or to
reclaim lost resources.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dpd-01.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-dpd-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-dpd-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2002-11-22112546.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-dpd-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-dpd-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2002-11-22112546.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Mon Nov 25 09:22: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 gAPHMLg19730;
Mon, 25 Nov 2002 09:22:22 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23837
Mon, 25 Nov 2002 11:55:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100300ba07ec8d3f84@[128.89.88.34]>
In-Reply-To: <3.0.3.32.20021123040402.017769c8@mail>
References: <3.0.3.32.20021123040402.017769c8@mail>
Date: Mon, 25 Nov 2002 11:47:14 -0500
To: Alex Alten <Alten@attbi.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Counter Mode Security: Analysis and Recommendations
Cc: Bob Doud <BDoud@hifn.com>, "'Paul Koning'" <pkoning@equallogic.com>,
mcgrew@cisco.com, tytso@mit.edu, paul.hoffman@vpnc.org,
ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Alex,
><SNIP>
>Of course there's still the *minor* matter of the hash. Unless I'm
>mistaken, this still requires linear sequential processing of the packet
>bytes. Won't this disrupt the tidy flow of parallel blocks?
>
>Cost is still a factor. Let's say you drive it in total to $25 per chip
>today. This is $125 retail + $50 for 1 Gbps Ethernet hardware. That's
>a tough sell.
>
>The really big win I see for AES-CTR is the fact you no longer need to add
>padding to the packet. That simplifies life considerably for writing a
>software driver/filter.
The avoidance of padding for block fill is useful, but the raw
performance of CTR mode is a very big attraction. The integrity
check is likely to be the limiting factor with CTR mode, but
integrity algorithms are separate from encryption algorithms in most
current uses. Some combined modes make use of integrity algorithms
are amenable to parallelism.
Steve
From owner-ipsec@lists.tislabs.com Mon Nov 25 09:23: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 gAPHNog19779;
Mon, 25 Nov 2002 09:23:50 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23846
Mon, 25 Nov 2002 11:56:19 -0500 (EST)
From: "Casey Carr" <caseyc@cipheroptics.com>
To: "'Wes Hardaker'" <hardaker@tislabs.com>
Cc: <rcharlet@SonicWALL.com>, <kent@bbn.com>, <ipsec@lists.tislabs.com>
Subject: RE: SPD policy document/article
Date: Mon, 25 Nov 2002 08:43:52 -0500
Message-ID: <001e01c29488$b1e47e00$b101a8c0@cipheroptics.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <sdk7j5w5kq.fsf@wanderer.hardakers.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Loop-Detect: 1
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Point taken.
-----Original Message-----
From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]
On Behalf Of Wes Hardaker
Sent: Friday, November 22, 2002 6:25 PM
To: Casey Carr
Cc: rcharlet@SonicWALL.com; kent@bbn.com; ipsec@lists.tislabs.com
Subject: Re: SPD policy document/article
>>>>> On Fri, 22 Nov 2002 15:55:16 -0500, "Casey Carr"
<caseyc@cipheroptics.com> said:
Casey> Can anyone name a single network management platform that uses
Casey> a standard SNMP MIB for configuration management that works
Casey> across multiple vendors?
Yes, though I won't start this discussion in this forum, as it's *way*
off topic.
Casey> If you are going to write device specific/vendor specific code
Casey> for configuration management, my personal opinion is that SNMP
Casey> is a very ineffective protocol to accomplish the task.
You might see if the extensions being developed in the EoS working
group fit your needs, btw.
--
Wes Hardaker
Network Associates Laboratories
From owner-ipsec@lists.tislabs.com Mon Nov 25 09:41: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 gAPHexg20860;
Mon, 25 Nov 2002 09:40:59 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24033
Mon, 25 Nov 2002 12:17:07 -0500 (EST)
Message-ID: <00b001c294a7$27705e00$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Subject: Rekey of IKE-SA
Date: Mon, 25 Nov 2002 11:21:50 -0600
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I believe IMHO, that there needs to be a mechanism for
avoiding a collision on an IKE-SA rekey. In its absence
nodes may end up assigning ownership of the child-SAs to
different IKE-SAs.
This subject has been brought up before (May 2002) but
without a firm resolution.
David
From owner-ipsec@lists.tislabs.com Mon Nov 25 12: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 gAPKbRg02868;
Mon, 25 Nov 2002 12:37:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24638
Mon, 25 Nov 2002 15:00:40 -0500 (EST)
From: "Stephane Beaulieu" <stephane@cisco.com>
To: "David Faucher" <dfaucher@lucent.com>, <ipsec@lists.tislabs.com>
Subject: RE: Rekey of IKE-SA
Date: Mon, 25 Nov 2002 15:01:10 -0500
Message-ID: <MDEJLHMEAJPNHKAIJCHKCELNDLAA.stephane@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <00b001c294a7$27705e00$23f22b42@mv.lucent.com>
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I would think that in the event of a rekey collision that both IKE SAs could
be used. It is a little bit wasteful of resources to have 2 where only 1 is
needed, but there should be no functional difference. After all, you still
need to be able to handle the time in which there is an overlap between the
old SA and the new one. So, if you have to handle that anyway, there is
probably no point in adding any functionality to the protocol. If that
should occur, you just have to make sure you only rekey (on the next rekey),
one of those 2 IKE SAs.
Adding a good jitter to your expiry should greatly reduce the number of
collisions (except maybe in the lab with very small lifetimes).
If you have a specific proposal that is VERY simple then I might change my
mind Otherwise I'm inclined to say that it's really not complicated to deal
with in the event it does happen, and should be rare enough to forget about
the resource impact.
Stephane.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of David Faucher
> Sent: Monday, November 25, 2002 12:22 PM
> To: ipsec@lists.tislabs.com
> Subject: Rekey of IKE-SA
>
>
>
> I believe IMHO, that there needs to be a mechanism for
> avoiding a collision on an IKE-SA rekey. In its absence
> nodes may end up assigning ownership of the child-SAs to
> different IKE-SAs.
>
> This subject has been brought up before (May 2002) but
> without a firm resolution.
>
> David
From owner-ipsec@lists.tislabs.com Mon Nov 25 13:13: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 gAPLDGg06631;
Mon, 25 Nov 2002 13:13:16 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24761
Mon, 25 Nov 2002 15:46:09 -0500 (EST)
Message-ID: <013e01c294c3$43da9fd0$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Subject: IKE header
Date: Mon, 25 Nov 2002 14:20:11 -0600
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Section 5.1 of draft-ietf-ipsec-ikev2-03.txt
describes the IKE header states
- Recipient SPI MUST be zero for the first packet
of IKE_SA_init and MUST NOT be zero for any other
packet
- Sender SPI MUST NOT be zero.
What about a node that is receiving packets
with unknown SPIs? If it has no IKE-SA then
what values would it place in the Recipient
and Sender SPI fields of an unprotected
informational containing a Notify payload?
- Flags (bit 3) MUST be set in messages sent by the
original initiator of the IKE-SA and MUST be cleared
in messages sent by the original responder.
Should "messages" be "requests" in the above
statement? And MUST a response contain the value
that was received in the request?
The term "original initiator" and "original responder"
are seen throughout the document without having been
defined. Is it safe to assume that they are referring
to the role that a node played during the establishment
of the original IKE-SA? Would these change if the original
responder initiated a rekey of the IKE-SA?
David
From owner-ipsec@lists.tislabs.com Mon Nov 25 13:13: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 gAPLDQg06661;
Mon, 25 Nov 2002 13:13:27 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24762
Mon, 25 Nov 2002 15:46:14 -0500 (EST)
Message-ID: <013f01c294c3$447e0bc0$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Subject: Child_SA key material
Date: Mon, 25 Nov 2002 14:26:08 -0600
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Section 4.16 of draft-ietf-ipsec-ikev2-03.txt
describes how key material is taken from KEYMAT
for CHILD-SAs.
If AH and ESP were negotiated would the key material
be taken as
1. AH_in, AH_out, ESP_in(encr, auth), ESP_out(encr, auth)
or
2. AH_in, ESP_in(encr, auth), AH_out, ESP_out(encr, auth)
David
From owner-ipsec@lists.tislabs.com Mon Nov 25 14:08: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 gAPM84g07901;
Mon, 25 Nov 2002 14:08:06 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24832
Mon, 25 Nov 2002 16:37:17 -0500 (EST)
Message-ID: <017001c294c9$63a46250$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Subject: Child_SA key material
Date: Mon, 25 Nov 2002 15:26:57 -0600
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Make that:
| 1. AH_ir, AH_ri, ESP_ir(encr, auth), ESP_ri(encr, auth)
|
| or
|
| 2. AH_ir, ESP_ir(encr, auth), AH_ri, ESP_ri(encr, auth)
where _ir = initiator to responder SA
_ri = responder to initiator SA
----- Original Message -----
From: "David Faucher" <dfaucher@lucent.com>
To: <ipsec@lists.tislabs.com>
Sent: Monday, November 25, 2002 2:26 PM
Subject: Child_SA key material
| Section 4.16 of draft-ietf-ipsec-ikev2-03.txt
| describes how key material is taken from KEYMAT
| for CHILD-SAs.
|
| If AH and ESP were negotiated would the key material
| be taken as
|
| 1. AH_in, AH_out, ESP_in(encr, auth), ESP_out(encr, auth)
|
| or
|
| 2. AH_in, ESP_in(encr, auth), AH_out, ESP_out(encr, auth)
|
| David
From owner-ipsec@lists.tislabs.com Mon Nov 25 14:09: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 gAPM9Fg07930;
Mon, 25 Nov 2002 14:09:16 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24847
Mon, 25 Nov 2002 16:42:24 -0500 (EST)
Message-ID: <014801c294c8$58c41250$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: "Stephane Beaulieu" <stephane@cisco.com>, <ipsec@lists.tislabs.com>
References: <MDEJLHMEAJPNHKAIJCHKCELNDLAA.stephane@cisco.com>
Subject: Re: Rekey of IKE-SA
Date: Mon, 25 Nov 2002 15:19:29 -0600
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.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I think adding a 3rd IKE-SA into the management
of CHILD-SAs does add some complexity.
- the deletion of CHILD-SAs must be coordinated between two IKE-SAs.
- simultaneous DELETEs of a CHILD-SA on the two rekeyed IKE-SAs.
- creation of new CHILD-SAs on both rekeyed IKE-SAs which prevents
rekeying only one of them (at the next rekey period).
As for a simple proposal, The "original initiator's" request
for a rekey always wins.
- if a collision is detected by the "original initiator", it MUST
respond to the rekey request with a NOTIFY payload containing a
error code of "REKEY-IN-PROGRESS".
- if a collision is detected by the "original repsonder", it MUST
respond to the rekey request as normal. (It's rekey request will
fail due to receipt of error "REKEY-IN-PROGRESS).
David
----- Original Message -----
From: "Stephane Beaulieu" <stephane@cisco.com>
To: "David Faucher" <dfaucher@lucent.com>; <ipsec@lists.tislabs.com>
Sent: Monday, November 25, 2002 2:01 PM
Subject: RE: Rekey of IKE-SA
| I would think that in the event of a rekey collision that both IKE SAs
could
| be used. It is a little bit wasteful of resources to have 2 where only 1
is
| needed, but there should be no functional difference. After all, you
still
| need to be able to handle the time in which there is an overlap between
the
| old SA and the new one. So, if you have to handle that anyway, there is
| probably no point in adding any functionality to the protocol. If that
| should occur, you just have to make sure you only rekey (on the next
rekey),
| one of those 2 IKE SAs.
|
| Adding a good jitter to your expiry should greatly reduce the number of
| collisions (except maybe in the lab with very small lifetimes).
|
| If you have a specific proposal that is VERY simple then I might change my
| mind Otherwise I'm inclined to say that it's really not complicated to
deal
| with in the event it does happen, and should be rare enough to forget
about
| the resource impact.
|
| Stephane.
|
| > -----Original Message-----
| > From: owner-ipsec@lists.tislabs.com
| > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of David Faucher
| > Sent: Monday, November 25, 2002 12:22 PM
| > To: ipsec@lists.tislabs.com
| > Subject: Rekey of IKE-SA
| >
| >
| >
| > I believe IMHO, that there needs to be a mechanism for
| > avoiding a collision on an IKE-SA rekey. In its absence
| > nodes may end up assigning ownership of the child-SAs to
| > different IKE-SAs.
| >
| > This subject has been brought up before (May 2002) but
| > without a firm resolution.
| >
| > David
|
From owner-ipsec@lists.tislabs.com Mon Nov 25 15: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 gAPNgLg12932;
Mon, 25 Nov 2002 15:42:21 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25120
Mon, 25 Nov 2002 18:09:11 -0500 (EST)
From: "Geoffrey Huang" <ghuang@cisco.com>
To: "'David Faucher'" <dfaucher@lucent.com>,
"'Stephane Beaulieu'" <stephane@cisco.com>, <ipsec@lists.tislabs.com>
Subject: RE: Rekey of IKE-SA
Date: Mon, 25 Nov 2002 15:10:26 -0800
Message-ID: <000101c294d7$d6d6dc40$3ba36b80@amer.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, Build 10.0.3416
In-Reply-To: <014801c294c8$58c41250$23f22b42@mv.lucent.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> I think adding a 3rd IKE-SA into the management
> of CHILD-SAs does add some complexity.
>
> - the deletion of CHILD-SAs must be coordinated between two IKE-SAs.
> - simultaneous DELETEs of a CHILD-SA on the two rekeyed IKE-SAs.
> - creation of new CHILD-SAs on both rekeyed IKE-SAs which prevents
> rekeying only one of them (at the next rekey period).
>
> As for a simple proposal, The "original initiator's" request
> for a rekey always wins.
>
> - if a collision is detected by the "original initiator", it MUST
> respond to the rekey request with a NOTIFY payload containing a
> error code of "REKEY-IN-PROGRESS".
>
> - if a collision is detected by the "original repsonder", it MUST
> respond to the rekey request as normal. (It's rekey request will
> fail due to receipt of error "REKEY-IN-PROGRESS).
If you want the NOTIFY message to be protected, then you'll have to wait
for the IKE SA to finish phase 1. I suppose in your proposal, then,
that the "original initiator" would determine which IKE SA gets the
REKEY-IN-PROGRESS error?
-g
> David
>
>
> ----- Original Message -----
> From: "Stephane Beaulieu" <stephane@cisco.com>
> To: "David Faucher" <dfaucher@lucent.com>; <ipsec@lists.tislabs.com>
> Sent: Monday, November 25, 2002 2:01 PM
> Subject: RE: Rekey of IKE-SA
>
>
> | I would think that in the event of a rekey collision that
> both IKE SAs
> could
> | be used. It is a little bit wasteful of resources to have
> 2 where only 1
> is
> | needed, but there should be no functional difference.
> After all, you
> still
> | need to be able to handle the time in which there is an
> overlap between
> the
> | old SA and the new one. So, if you have to handle that
> anyway, there is
> | probably no point in adding any functionality to the
> protocol. If that
> | should occur, you just have to make sure you only rekey (on the next
> rekey),
> | one of those 2 IKE SAs.
> |
> | Adding a good jitter to your expiry should greatly reduce
> the number of
> | collisions (except maybe in the lab with very small lifetimes).
> |
> | If you have a specific proposal that is VERY simple then I
> might change my
> | mind Otherwise I'm inclined to say that it's really not
> complicated to
> deal
> | with in the event it does happen, and should be rare enough
> to forget
> about
> | the resource impact.
> |
> | Stephane.
> |
> | > -----Original Message-----
> | > From: owner-ipsec@lists.tislabs.com
> | > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of David Faucher
> | > Sent: Monday, November 25, 2002 12:22 PM
> | > To: ipsec@lists.tislabs.com
> | > Subject: Rekey of IKE-SA
> | >
> | >
> | >
> | > I believe IMHO, that there needs to be a mechanism for
> | > avoiding a collision on an IKE-SA rekey. In its absence
> | > nodes may end up assigning ownership of the child-SAs to
> | > different IKE-SAs.
> | >
> | > This subject has been brought up before (May 2002) but
> | > without a firm resolution.
> | >
> | > David
> |
>
>
From owner-ipsec@lists.tislabs.com Mon Nov 25 16:21:58 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id gAQ0Lvg14961;
Mon, 25 Nov 2002 16:21:58 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25240
Mon, 25 Nov 2002 18:54:11 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f0eba08673cdaaf@[165.227.249.18]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Mon, 25 Nov 2002 15:53:19 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Draft minutes from the WG meeting
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Greetings. Below are the draft minutes of the IPsec WG meeting last
week in Atlanta. If you were at the meeting and spoke, please review
them and send any corrections to me. I will change these draft
minutes into a final version to be sent to the IETF Secretariat for
inclusion in the official minutes of the meeting.
If you read somthing here that you want to discuss on the mailing
list, please change the subject line to indicate the specific topic
you want to talk about. Thanks!
----------
Minutes for IPsec WG
November 18, 2002
Agenda was considered and accepted
ID Status
AES Related Drafts
draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt
in IESG wait (AD writeup)
draft-ietf-ike-modp-groups-04.txt
in IESG wait (AD writeup)
draft-ietf-ipsec-ciph-sha-256-01.txt
not going to be advanced
draft-ietf-ipsec-ciph-aes-cbc-04.txt
submitted for IETF last call
Extended sequence number docs
draft-ietf-ipsec-esp-v3-03.txt
ready for wg last call (one last round of
editing by authors)
draft-ietf-ipsec-rfc2402bis-01.txt
ready for wg last call (one last round of
editing by authors)
draft-ietf-ipsec-esn-addendum-00.tx
ready for wg last call
NAT Traversal docs
draft-ietf-ipsec-udp-encaps-04.txt
ready for IETF last call for proposed standard
draft-ietf-ipsec-nat-t-ike-04.txt
ready for IETF last call for proposed standard
draft-ietf-ipsec-udp-encaps-justification-01.txt
ready for IETF last call for informational RFC
MIB docs
Discussion has been non-existent since November.
Plan to forward all of them to WG last call
draft-ietf-ipsec-doi-tc-mib-06.txt
draft-ietf-ipsec-flow-monitoring-mib-02.txt
draft-ietf-ipsec-ike-monitor-mib-04.txt
draft-ietf-ipsec-isakmp-di-mon-mib-05.txt
draft-ietf-ipsec-monitor-mib-06.txt
Others
draft-ietf-ipsec-ike-ecc-groups-04.txt
Moribund; no WG interest
draft-ietf-ipsec-sctp-04.txt
Proposed standard
IESG wait (point raised by some AD; awaiting writeup)
DPD draft - to WG last call soon
IPsec properties - prepared to help with SOI
Needs more work to be publishable
Andrew wants to do work
Ted and Barb view as a distraction
VoIP Security Requirements - Eric Nielsen
draft-jacobs-signaling-security-requirements
VoIP is really across many protocols
How can they leverage IPsec as the underlying security mechanism?
Describes the view of a consumer of IPsec
Please review it
SIGMA paper announcement - Hugo Krawczyk
New paper was published
http://www.ee.technion.ac.il/~hugo/sigma.ps
Gives the crypto rationale for IKEv1 signature modes and IKEv2
cryptographic key exchange.
Covered ancient history (1995-1996) regarding the development of
SIGMA and its inclusion in IKE
Summary: don't just do a signature, also MAC the identity of the
signer (the MAC is essential for the key exchange security!).
This paper is informal and intended to a broad audience of
designers and practitioners. A formal mathematical analysis was
done in a paper with Ran Canetti presented at Crypto'2002.
PKI profile draft - Brian Korver
Profile PKIX for IKE
Compliments IKE
-00 and -01 were straw proposals
Types of issues
CRL processing
Empty CERTREQ
Using ID payload for policy
Which fields in the cert should be used as ID
Out of band exchange of keying material
Want comments for -02
Gregory Lebovitz - Project DPloy earlier this year did
much of the requirements
Paul Hoffman talked about previous document in this space. This
should not make IKEv1 implementations non-conformant.
Brian said
he wasn't sure how he wanted it to apply to v1 or v2
Michael Richardson - thinks it should apply to IKEv1 and IKEv2
Digital signatures for ESP and AH - Brian Weis
Main need for this is source origin authentication
This is needed for multicast or anycast
ESP and AH don't specify any particular authentication mechanism,
they just say where to do it.
Digital signatures are very well understood
RSA is widely implemented and is free
Also fast for verification, which is good in multicast because
the receivers do less work
Still some issues
Authentication data is larger
Performance is big issue, but not so much if you have hardware
acceleration
DoS vulnerability: RSA verification is much slower than HMAC
Bill Sommerfeld - Key size needs to be balanced against how long
you are going to use the key
Hilarie Orman - It's about time! The demultiplexing is done in a
different place. And why not use elliptic curves?
Andrea Colegrove - How do you tell IPsec who can send (and therefore
sign) the messages?
Is this of interest to the WG?
IPv6 and IPsec Deployment Issues - Tomoaki KOBAYAKAWA
Deployment scenario, not a proposal for a solution
Need a solution in order to help IPv6 get deployed
IPv6 deployment status
Definitely been deployed, especially in Japan
Lots of home appliances using it
But many IPv4 users think that IPv4 is enough
If IPv6 is cheaper than IPv4, it will cause greater IPv6
deployment
IPv6 plug-and-play can be help
Authentication can come from the ISP instead of from the
end user, making devices and games easier to start
from scratch
IPv6 autoconf can also help with sensors and devices that
need strong authentication
If we make IPv6 always use IPsec, it will appear to be
more secure
Security policy should be maintained by an external trusted third
party
PKI avoidance is good
Need plug-and-play IPsec for IPv6 for peer-to-peer, so please
think about proposals
Hugh Daniel - Won't buy a device that he cannot set the keys in
Scott Fanning - How do you get a credential for a device from the
factory?
Steve Bellovin - Doubts about plug-and-play because the lack of
authorization. How would an ISP know who is the end user for
connecting particular devices?
Charlie Kaufman - Protect against passive eavesdropping but others
in the crypto field don't want this
Gregory Lebovitz - Consumer devices already have less security and
people buy it all the time
Eric Nielsen - VoIP has similar problems of weighing the plug-and-play
vs. flexibility
Atsushi Inoue - What is the next step for this proposal? Will you
make a key management protocol that matches this? Kobayakawa
wants to do this.
Counter Mode Security Analysis and Recommendations - Dave McGrew
Wants to raise issues for discussion
CM can be implemented securely
Properties are different but not worse
CM is more vulnerable to some precomputation attacks
Lacks per-packet random input that CBC has
Attacker precomputes and stores a database
Amortizes the computation across many breaks lowering the
expected work per break
Protections against this attack
It has to be unpredictable to the adversary
To do this, use a larger key
Use AES-192 to get 128-bit strength
This requires more computation and mandates using
multiple key sizes
Instead, use a random or uniform field in the initial counter
Shrink the SPI field
Won't allow protection of jumbograms
Comparison
Table showed comparison of equivalent strengths
Asked for limits of memory, some disagreement was heard
Requires a very, very rich advisory
Questions
Is 85 or fewer bits of security acceptable?
Is inability to encrypt jumbograms OK?
Is it OK to require AES-192 acceptable?
Is an explicit IV needed?
For 10 Gbs message authentication, CM is the only non-encumbered
system known
Uri Blumenthal - Not related to the A5 attack. Wants more time to
review the numbers to see if this is really an 85-bit attack.
Russ Housley - Appreciates bringing the issue to the wider group.
Ron Rivest said just the longer key.
Ted Ts'o - Wants people who know crypto to help analyze whether it
is really a practical attack.
IKEv2 status discussion - Charlie Kaufman
New draft in October
Changed many things that became controversial:
Suites replaced ala carte
Went to always 4 messages
Simplified traffic selector (no one has complained)
Other controversies
NAT traversal
Tunnel vs. transport negotiation
Key sizes and algorithms
Legacy auth not covered
Revised identity proposal
NAT Traversal
Not in IKEv1, but now there is a draft
Should the new extensions be included in IKEv2?
Tunnel vs. transport
No negotiation in IKEv2
Charlie needs to understand why this is needed
If inner and outer IP addresses are the same,
MAY use transport
MUST key size and algorithms
1024 vs. 1023 bit keys
It's hard to have this debate until we know suites
vs. ala carte
Number of messages
4 messages except a few cases
Always-4 is more complicated to be stateless
Messages are larger, which causes UDP fragmentation issues
May impact legacy authentication
CRACK-style does better with 4/6 than with always-4
Legacy authentication
Road warrior configurations
Passwords, SecureID, challenge-response cards, etc.
All have subtle differences
History includes, XAUTH, CRACK, PIC
Use legacy auth to get a cert
Recursion problem
Need a PKI
What to do
Ignore it -- not
Don't hold up IKEv2: do it later
Use password as a shared key
Has dictionary attack
Design it in
Reference an existing multiplexer
like SASL/EAP or GSSAPI
Modify one of the IKEv1 solutions
Start over
Suites vs. ala carte
IKEv1: propose a subset and responder selects
Old IKEv2: same things but with a better encoding
JFK: responder decrees
Current IKEv2: defines suites, responder selects
Why people like suites
Easier to implement if the number is manageable
Why people like ala carte
Easier to implement if the number is large
Easier to add new parts
Options
Leave it as suites
Change it back to ala carte
Cleverly-chosen multi-byte suite IDs
Do both: MUST do suites but can do ala carte
Only good idea if believe many
implementations don't
do ala carte
Revised identity
Several proposals wrapped together
CERTREQ renamed TrustedRoot
Used to listing trust anchors
Instead of DN of trust anchor, use
SHA1 of public key
Charlie wants to copy TLS
Allow URLs to certificates instead of the
certs themselves
Some certs are very large
The other end might know it
But can't always use the URL
What are the MUST/MAY/SHOULDs to
guarantee interop
Negotiate authentication algorithms
New IDAccepted field
Needed if there are multiple ways
that you are capable
of authenticating and want to
autoselect
Merge ID and CERT into FullID
Today IDs is required but CERT is optional
Unstated what the relation between ID
and cert are
Whatever is in the cert is the ID:
need to translate
for your SADB
OK, how do we become an RFC?
Choose between multiple bales of hay (bad joke elided)
Integrate NAT traversal now or later?
Integrate legacy auth now or later?
Charlie's preference
Add some crypto tweaks from Hugo
Decide now on the choices
Work on other things in parallel that can be
folded into
this document if it doesn't hold up
the document
Ted Ts'o - If it is NAT-traversal friendly, we can do that
in another document that describes how. If
you leave holes
in the spec, it has to be filled fast,
otherwise a vendor
will do it for us and we won't be able to fix it.
Tero Kivinen - It isn't NAT-traversal friendly now but it can
be made so easily.
David Black - People designing suites have forgotten
some things,
so we need either ala carte or have a
well-defined extension
mechanism.
Phil Hallam-Baker- Must work with NATs or don't bother. We
should think about keys, not certs. Get rid
of policy from
key negotiation.
Hilarie Orman - AA Milne was quoted. Suggested negotiating key
policy in protocol from the IP Security Policy WG.
Eric Rescorla - TLS doesn't negotiate trust anchors
at all; this
is not a raging success. Maybe assume that
you only have one
certificate.
Cheryl Madsen - If we split off items from a single
document, we
lose momentum and it can take years.
William Dixon - Noticed that requirements draft died.
No one was
giving any feedback so there was no interest
in a requirements
document. The requirements are inherent in
the protocol design
and on the mailing list, but he wanted to be
sure that the
WG wanted this.
Jeff Schiller wearing his AD hat - Rest of the IETF wants to
consume this technology soon. It's time. If
this effort is
to succeed, it must terminate. If this
doesn't finish soon,
we will terminate the WG and everyone has to use IKEv1.
Wants a timeline that finishes by Feb. 15, 2003.
Ted Ts'o - We negotiated that date.
Cheryl Madsen - The scope of IKEv2 is VPNs and remote access.
William Dixon - What are doing that is different than IKEv1?
Paul Hoffman - We need remote access or else it looks
like IKEv1.
Jeff Schiller - Can the WG decided between always-4 or 4/6 in
the next 15 minutes?
Paul Hoffman - 4/6 is much better for CRACK-like.
Michael Richardson - Doesn't care about always-4 or 4/6.
We should embed remote access, just take it from IPSRA.
If we got good cert stuff, we don't need
legacy auth, but if
we are going to do it, do it now.
Bill Sommerfeld - Good if we can do always-4 if we don't do
legacy auth. This might push against legacy auth.
Tero Kivinen - NAT traversal is more complicated if we do
always-4, but simple to add in 4/6. We need to do port
floating.
Eric Rescorla - Because 4/6 takes less thinking, we should use
it.
Ted Ts'o took a straw poll. Humming happened. The
consensus was 4/6.
Barbara Fraser wanted to have a meeting about legacy
authentication
this week.
Gregory Lebovitz - Are we also including remote configuration?
Jeff Schiller - Can you decided suites vs. ala carte
in 4 minutes?
David Black and Cheryl Madsen - There is also a way to do a
hybrid mechanism.
William Dixon - Needs to be able to swap in a
different algorithm.
Magnus Nystrom - Prefers suites because of interaction between
algorithms.
Jeff Schiller - Just decide between suites or ala carte for
crypto only; other items will be decided later.
Ted Ts'o took a straw poll on crypto suite or suites.
Humming happened, but it sounded close. Hands
were raised.
The chairs saw three times as many for suites
than for ala carte.
Jeff Schiller asked who cared a great deal about the way that
they voted. Only a few hands went up.
Meeting was adjourned only a few minute over time. Many folks said they
would work on the remote access problem, the suites extension issue,
NAT traversal, and other problems.
Minutes taker: Paul Hoffman, VPN Consortium
Apologies in advance for spelling errors, particularly in
people's names.
From owner-ipsec@lists.tislabs.com Mon Nov 25 16:22: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 gAQ0M0g14975;
Mon, 25 Nov 2002 16:22:00 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25239
Mon, 25 Nov 2002 18:54:10 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f0fba0868732383@[165.227.249.18]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Mon, 25 Nov 2002 15:54:55 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Resource for the IKEv2 discussion
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Greetings again. VPNC has a web site to help focus the discussion
about IKEv2. See <http://www.vpnc.org/ikev2/> for an unofficial list
of proposed changes, copies of drafts, and so on. Please let me know
if you want things added to the site.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Mon Nov 25 21:44: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 gAQ5iWg01751;
Mon, 25 Nov 2002 21:44:32 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA25815
Tue, 26 Nov 2002 00:16:27 -0500 (EST)
Subject: ISAKMP SA message #1 (proposing attributes/transforms)
From: venkat <venkat@dexceldesigns.com>
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Date: 26 Nov 2002 10:52:10 +0530
Message-Id: <1038288132.797.24.camel@venkat>
Mime-Version: 1.0
X-Mailserver: Sent using PostMaster (v4.1.13)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi all,
Protocol ID: IPSEC_AH
Transform ID: AH_MD5
Attributes(Auth Algo): HMAC-MD5
Attributes(Auth Algo): HMAC-SHA
Attributes(Encap Mode): Tunnel
Attributes(Encap Mode): Transport
Can we propose all the attributes we support so that the responder has
an option to choose from our list and reply his conformation.
e.g. IPSEC_AH(AH_MD5 transform) Security Association supporting HMAC_SHA
Authentication Algorithm, IPSEC_AH(AH_SHA1 transform) SA supporting
HMAC_MD5
Thanks in advance
- Venkat
--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
From owner-ipsec@lists.tislabs.com Tue Nov 26 02:15: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 gAQAFCg08119;
Tue, 26 Nov 2002 02:15:13 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA26248
Tue, 26 Nov 2002 04:38:49 -0500 (EST)
Date: Tue, 26 Nov 2002 15:13:26 +0530 (India Standard Time)
From: Thota Kiran Kumar <Kiran_Thota@pmc-sierra.com>
To: venkat <venkat@dexceldesigns.com>
cc: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: ISAKMP SA message #1 (proposing attributes/transforms)
In-Reply-To: <1038288132.797.24.camel@venkat>
Message-ID: <Pine.WNT.4.30.0211261511200.1464-100000@pun1-thotakiran>
X-X-Sender: thota@[192.168.0.35]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Venkat,
Yes, You should propose all attributes you support. In case,
you have an order of preference, you should order them
in the decreasing order of preference.
The responder chooses the first transform attribute(s) that
it supports and confirms it.
Regards,
- Kiran Kumar
On 26 Nov 2002, venkat wrote:
> Hi all,
>
> Protocol ID: IPSEC_AH
> Transform ID: AH_MD5
> Attributes(Auth Algo): HMAC-MD5
> Attributes(Auth Algo): HMAC-SHA
> Attributes(Encap Mode): Tunnel
> Attributes(Encap Mode): Transport
>
> Can we propose all the attributes we support so that the responder has
> an option to choose from our list and reply his conformation.
>
> e.g. IPSEC_AH(AH_MD5 transform) Security Association supporting HMAC_SHA
> Authentication Algorithm, IPSEC_AH(AH_SHA1 transform) SA supporting
> HMAC_MD5
>
> Thanks in advance
> - Venkat
>
>
> --------------------------------------------------------------
> Dexcel Electronics Designs (P) Ltd., Bangalore, India
>
>
From owner-ipsec@lists.tislabs.com Tue Nov 26 03:11: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 gAQBBpg11104;
Tue, 26 Nov 2002 03:11:51 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26424
Tue, 26 Nov 2002 05:45:19 -0500 (EST)
Message-ID: <3DE3510B.7040600@F-Secure.com>
Date: Tue, 26 Nov 2002 12:46:35 +0200
From: Ari Huttunen <Ari.Huttunen@f-secure.com>
Organization: F-Secure Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
CC: ipsec@lists.tislabs.com
Subject: Re: Draft minutes from the WG meeting
References: <p05200f0eba08673cdaaf@[165.227.249.18]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Nov 2002 10:46:36.0420 (UTC) FILETIME=[17C42440:01C29539]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul Hoffman / VPNC wrote:
> IKEv2 status discussion - Charlie Kaufman
> New draft in October
> Changed many things that became controversial:
> Suites replaced ala carte
> Went to always 4 messages
> Simplified traffic selector (no one has complained)
> Other controversies
> NAT traversal
> Tunnel vs. transport negotiation
> Key sizes and algorithms
> Legacy auth not covered
> Revised identity proposal
> NAT Traversal
> Not in IKEv1, but now there is a draft
> Should the new extensions be included in IKEv2?
> Tunnel vs. transport
> No negotiation in IKEv2
> Charlie needs to understand why this is needed
> If inner and outer IP addresses are the same,
> MAY use transport
IMHO, NAT traversal is currently unnecessarily complicated.
If we can imagine tweaking some things that we could not tweak
when specifying it for IKEv1, we could make it simpler.
I would myself throw out transport mode, and specify only
tunnel mode for NAT traversal. I would also make IKEv2 always
floated, so we can get rid of the ugly part of changing
a protocol from one port to another.
Ari
--
I play it cool and dig all jive,
that's the reason I stay alive.
My motto as I live and learn,
is dig and be dug in return. <Langston Hughes>
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
From owner-ipsec@lists.tislabs.com Tue Nov 26 04:03: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 gAQC3sg17883;
Tue, 26 Nov 2002 04:03:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26507
Tue, 26 Nov 2002 06:35:34 -0500 (EST)
Message-ID: <20021126112957.16470.qmail@web15104.mail.bjs.yahoo.com>
Date: Tue, 26 Nov 2002 19:29:57 +0800 (CST)
From: =?gb2312?q?king=20wu?= <wmyking49@yahoo.com.cn>
Subject: How important is identity protecton?
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi,all
In IKE, how important is identity protecton?
In IKEv1, only the main mode with public key
encrytion can protect identity of both sides from a
active attacker.However, the modes are removed in
IKEv2 and JFK. IKEv2 or JFKr just can protect
responser's identity from a active attacker.
In my opinion, we should protect a initiator's
indentity rather than a responser, because a responser
is usually stationary and its identity information can
be found more easily.
However, the thing puzzles me is that for a active
attacker, will he acctack a link more easily if he
gets the identity information of one side or both. If
the answer is yes, then why not we try to protect the
identitis of both sides?
So, i have to ask,"how important is identity
protecton?"
please help,
think you
_________________________________________________________
Do You Yahoo!?
"ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡"
http://cn.promo.yahoo.com/cgi-bin/udb/u
From owner-ipsec@lists.tislabs.com Tue Nov 26 06:07: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 gAQE7pg25248;
Tue, 26 Nov 2002 06:07:52 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26732
Tue, 26 Nov 2002 08:38:17 -0500 (EST)
Message-ID: <000f01c29551$b5883f50$23f22b42@mv.lucent.com>
From: "David Faucher" <dfaucher@lucent.com>
To: "Geoffrey Huang" <ghuang@cisco.com>,
"'Stephane Beaulieu'" <stephane@cisco.com>, <ipsec@lists.tislabs.com>
References: <000101c294d7$d6d6dc40$3ba36b80@amer.cisco.com>
Subject: Re: Rekey of IKE-SA
Date: Tue, 26 Nov 2002 07:42:45 -0600
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
| > I think adding a 3rd IKE-SA into the management
| > of CHILD-SAs does add some complexity.
| >
| > - the deletion of CHILD-SAs must be coordinated between two IKE-SAs.
| > - simultaneous DELETEs of a CHILD-SA on the two rekeyed IKE-SAs.
| > - creation of new CHILD-SAs on both rekeyed IKE-SAs which prevents
| > rekeying only one of them (at the next rekey period).
| >
| > As for a simple proposal, The "original initiator's" request
| > for a rekey always wins.
| >
| > - if a collision is detected by the "original initiator", it MUST
| > respond to the rekey request with a NOTIFY payload containing a
| > error code of "REKEY-IN-PROGRESS".
| >
| > - if a collision is detected by the "original repsonder", it MUST
| > respond to the rekey request as normal. (It's rekey request will
| > fail due to receipt of error "REKEY-IN-PROGRESS).
|
| If you want the NOTIFY message to be protected, then you'll have to wait
| for the IKE SA to finish phase 1. I suppose in your proposal, then,
| that the "original initiator" would determine which IKE SA gets the
| REKEY-IN-PROGRESS error?
|
| -g
|
The proposal doesn't actually need the NOTIFY to work properly. It
was merely sent as a courtesy (MUST could be changed to SHOULD or MAY)
since the "original responder" would detect the collision as well
and thus could tear down its rekey request.
| > David
| >
| >
| > ----- Original Message -----
| > From: "Stephane Beaulieu" <stephane@cisco.com>
| > To: "David Faucher" <dfaucher@lucent.com>; <ipsec@lists.tislabs.com>
| > Sent: Monday, November 25, 2002 2:01 PM
| > Subject: RE: Rekey of IKE-SA
| >
| >
| > | I would think that in the event of a rekey collision that
| > both IKE SAs
| > could
| > | be used. It is a little bit wasteful of resources to have
| > 2 where only 1
| > is
| > | needed, but there should be no functional difference.
| > After all, you
| > still
| > | need to be able to handle the time in which there is an
| > overlap between
| > the
| > | old SA and the new one. So, if you have to handle that
| > anyway, there is
| > | probably no point in adding any functionality to the
| > protocol. If that
| > | should occur, you just have to make sure you only rekey (on the next
| > rekey),
| > | one of those 2 IKE SAs.
| > |
| > | Adding a good jitter to your expiry should greatly reduce
| > the number of
| > | collisions (except maybe in the lab with very small lifetimes).
| > |
| > | If you have a specific proposal that is VERY simple then I
| > might change my
| > | mind Otherwise I'm inclined to say that it's really not
| > complicated to
| > deal
| > | with in the event it does happen, and should be rare enough
| > to forget
| > about
| > | the resource impact.
| > |
| > | Stephane.
| > |
| > | > -----Original Message-----
| > | > From: owner-ipsec@lists.tislabs.com
| > | > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of David Faucher
| > | > Sent: Monday, November 25, 2002 12:22 PM
| > | > To: ipsec@lists.tislabs.com
| > | > Subject: Rekey of IKE-SA
| > | >
| > | >
| > | >
| > | > I believe IMHO, that there needs to be a mechanism for
| > | > avoiding a collision on an IKE-SA rekey. In its absence
| > | > nodes may end up assigning ownership of the child-SAs to
| > | > different IKE-SAs.
| > | >
| > | > This subject has been brought up before (May 2002) but
| > | > without a firm resolution.
| > | >
| > | > David
| > |
| >
| >
|
From owner-ipsec@lists.tislabs.com Tue Nov 26 07:24: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 gAQFO3g02010;
Tue, 26 Nov 2002 07:24:03 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26878
Tue, 26 Nov 2002 09:55:05 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f28ba093b8fc7fd@[165.227.249.18]>
In-Reply-To: <3DE3510B.7040600@F-Secure.com>
References: <p05200f0eba08673cdaaf@[165.227.249.18]>
<3DE3510B.7040600@F-Secure.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 26 Nov 2002 06:55:58 -0800
To: Ari Huttunen <Ari.Huttunen@f-secure.com>
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: NAT Traversal in IKEv2
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
[[ Please note that I changed the subject line. Everyone: if you want
to comment on what was said at the meeting, please make a better
subject line for your thread! ]]
At 12:46 PM +0200 11/26/02, Ari Huttunen wrote:
>Paul Hoffman / VPNC wrote:
>>IKEv2 status discussion - Charlie Kaufman
>> New draft in October
>> Changed many things that became controversial:
>> Suites replaced ala carte
>> Went to always 4 messages
>> Simplified traffic selector (no one has complained)
>> Other controversies
>> NAT traversal
>> Tunnel vs. transport negotiation
>> Key sizes and algorithms
>> Legacy auth not covered
>> Revised identity proposal
>> NAT Traversal
>> Not in IKEv1, but now there is a draft
>> Should the new extensions be included in IKEv2?
>> Tunnel vs. transport
>> No negotiation in IKEv2
>> Charlie needs to understand why this is needed
>> If inner and outer IP addresses are the same,
>> MAY use transport
>
>IMHO, NAT traversal is currently unnecessarily complicated.
>If we can imagine tweaking some things that we could not tweak
>when specifying it for IKEv1, we could make it simpler.
>I would myself throw out transport mode, and specify only
>tunnel mode for NAT traversal. I would also make IKEv2 always
>floated, so we can get rid of the ugly part of changing
>a protocol from one port to another.
Just to be clear, are you saying that the port for IKEv2 should
always be floated even if NAT-traversal is not negotiated?
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Tue Nov 26 07:48: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 gAQFm4g05326;
Tue, 26 Nov 2002 07:48:04 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26919
Tue, 26 Nov 2002 10:19:38 -0500 (EST)
Message-Id: <5.2.0.9.2.20021126092238.00b8fe58@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 26 Nov 2002 09:42:20 -0500
To: ipsec@lists.tislabs.com
From: Russ Housley <housley@vigilsec.com>
Subject: IKEv2 use of HMAC-SHA-1 for Key Derivation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On pages 23 and 33 of draft-ietf-ipsec-ikev2-03.txt, there is a discussion
of the use of HMAC-SHA1 for key derivation. I have no doubt that this
construction is secure, but I do wonder if it is overkill.
HMAC-SHA1 was designed as a packet integrity mechanism. The designers
needed to deal with many concerns that are not obviously (at least to me)
needed to generate a good key derivation function.
Can anyone tell me the properties HMAC-SHA1 that are needed here that are
not otherwise provided by a straightforward application of SHA1?
Putting it another way, the current document uses:
T1 = HMAC-SHA1(K, S | 0x01)
T2 = HMAC-SHA1(K, T1 | S | 0x02)
T3 = HMAC-SHA1(K, T2 | S | 0x03)
T4 = HMAC-SHA1(K, T3 | S | 0x04)
What needed property does this construction have that is not provided by
the following?
T1 = SHA1(K, S | 0x01)
T2 = SHA1(K, T1 | S | 0x02)
T3 = SHA1(K, T2 | S | 0x03)
T4 = SHA1(K, T3 | S | 0x04)
Thanks for any insights that can be provided.
Russ
From owner-ipsec@lists.tislabs.com Tue Nov 26 09: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 gAQHqAg12892;
Tue, 26 Nov 2002 09:52:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27213
Tue, 26 Nov 2002 12:21:46 -0500 (EST)
From: Charlie_Kaufman@notesdev.ibm.com
In-Reply-To: <00b001c294a7$27705e00$23f22b42@mv.lucent.com>
Subject: Re: Rekey of IKE-SA
To: "David Faucher" <dfaucher@lucent.com>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002
Message-ID: <OFE8A69AD2.305E1814-ON85256C7D.000B3440-85256C7D.000BD0FA@iris.com>
Date: Mon, 25 Nov 2002 21:09:04 -0500
X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 11/26/2002
12:22:18 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
David Faucher wrote:
> I believe IMHO, that there needs to be a mechanism for
> avoiding a collision on an IKE-SA rekey. In its absence
> nodes may end up assigning ownership of the child-SAs to
> different IKE-SAs.
>
> This subject has been brought up before (May 2002) but
> without a firm resolution.
What would you recommend. At the suggestion of someone I
talked with at IETF, I added language suggesting that if
you find yourself with redundant SAs that you should wait
a random amount of time (for jitter) and then close one.
I was about to claim that a probabilistic solution was the
best you could do when it occurred to me that we could do
better. We could say that if both ends try to rekey at once,
the SA with the smallest nonce (of the four nonces) should
be closed. Technically, it's still a probabilistic solution,
but the probability of a nonce collision should be
vanishingly small.
--Charlie
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
From owner-ipsec@lists.tislabs.com Tue Nov 26 11:35: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 gAQJZvg20182;
Tue, 26 Nov 2002 11:35:58 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27439
Tue, 26 Nov 2002 13:48:35 -0500 (EST)
Date: Tue, 26 Nov 2002 10:23:45 -0700
Message-Id: <200211261723.gAQHNjf29469@localhost.localdomain>
From: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
To: housley@vigilsec.com
Cc: ipsec@lists.tislabs.com
In-reply-to: Yourmessage <5.2.0.9.2.20021126092238.00b8fe58@mail.binhost.com>
Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The HMAC construction is not necessary for key derivation, but both
methods are wrong if K is large (in size and entropy) and security
requirements dictate that a derived key must have more entropy than
2^(blocksize). This is a persistently misunderstood issue.
Hilarie
From owner-ipsec@lists.tislabs.com Tue Nov 26 13:14: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 gAQLEIg25287;
Tue, 26 Nov 2002 13:14:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27660
Tue, 26 Nov 2002 15:40:33 -0500 (EST)
Message-Id: <200211262041.gAQKfVJ08833@sydney.East.Sun.COM>
Date: Tue, 26 Nov 2002 15:41:31 -0500 (EST)
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: How important is identity protecton?
To: ipsec@lists.tislabs.com, wmyking49@yahoo.com.cn
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=ISO-8859-1
Content-MD5: qJYZqE/ut+A7c4GMD7T1yQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lists.tislabs.com id PAA27657
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I have a lot of sympathy with your question, but the bottom
line is that is doesn't matter a lot, and it's more important
at this point to get the spec out quickly.
I was originally unconvinced that identity hiding mattered
at all, but it doesn't cost a lot to provide it.
And then I believed that hiding the initiator's identity
from an active attacker was more important than hiding the
responder's identity. As a matter of fact, we argued that point of view
in a paper a few years ago:
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf
And the original JFK and SIGMA protocols also did that (had
the responder reveal and prove its identity first). So your
point of view is certainly reasonable, and was shared by
many people.
However, when writing IKEv2, we decided that there was
more of a problem with a "polling attack", where someone
could find out who was listening at a particular IP address just
by initiating a connection to it. The WG, when faced with
the two styles, seemed to have consensus around avoiding the
polling attack. The reasoning was
that IKE is a peer-to-peer protocol where either
side can initiate, and the polling attack is way easier (just
initiate a connection to an IP address) than impersonating the
responder's IP address and seeing who connects.
Based on these arguments and the perceived consensus of the
WG, JFK and SIGMA added handshakes to avoid the polling attack.
So at any rate, this issue has been considered.
I think it's far-fetched to come up with a scenario where
it would be horrible if
you could be tricked into revealing that you are attempting to
connect to someone. In a case like two freedom-fighters trying to
talk across the Internet, it would seem prudent to use an anonymizer
and an identity other than your name and address. In the case of
trying to buy porn on the Internet (the canonical example of
the client wanting to hide its identity :-) ) one could easily
tell the police, once you realized Bob wasn't really Bob, that you'd merely
connected to the wrong IP address.
But as I said at the beginning, the alternatives just aren't important
enough or a clear-cut security advantage, to change now.
And by the way...I understand that with legacy authentication added,
there will be a possibility for Alice to demand that Bob say who
he is before she reveals who she is. This wouldn't lead to
a generalized polling attack, because this requires Bob to both
support legacy authentication and be willing to reveal his identity first.
Radia
From: king wu <wmyking49@yahoo.com.cn>
Subject: How important is identity protecton?
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
hi,all
In IKE, how important is identity protecton?
In IKEv1, only the main mode with public key
encrytion can protect identity of both sides from a
active attacker.However, the modes are removed in
IKEv2 and JFK. IKEv2 or JFKr just can protect
responser's identity from a active attacker.
In my opinion, we should protect a initiator's
indentity rather than a responser, because a responser
is usually stationary and its identity information can
be found more easily.
However, the thing puzzles me is that for a active
attacker, will he acctack a link more easily if he
gets the identity information of one side or both. If
the answer is yes, then why not we try to protect the
identitis of both sides?
So, i have to ask,"how important is identity
protecton?"
please help,
think you
_________________________________________________________
Do You Yahoo!?
"ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡"
http://cn.promo.yahoo.com/cgi-bin/udb/u
From owner-ipsec@lists.tislabs.com Tue Nov 26 22:22: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 gAR6MTg22461;
Tue, 26 Nov 2002 22:22:30 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA28354
Wed, 27 Nov 2002 00:40:26 -0500 (EST)
Date: Wed, 27 Nov 2002 07:43:05 +0200 (IST)
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
To: Russ Housley <housley@vigilsec.com>
cc: ipsec@lists.tislabs.com
Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation
In-Reply-To: <5.2.0.9.2.20021126092238.00b8fe58@mail.binhost.com>
Message-ID: <Pine.GSO.4.21.0211270739360.530-100000@ee.technion.ac.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Russ,
I guess that you are suggesting to use "prepended SHA1" (i.e. SHA1(K,...))
instead of HMAC as the the default instantiation of the prf in IKEv2. The
advantage of "prepended SHA1" is that it may require one less application
of the compression function of SHA1 (per 160 bits of key material). The
disadvantage is that, in general, "prepended SHA1" is broken as a prf
(extension attacks as those in the Preneel-van Oorschot paper break the
unpredictability of the function). While this later disadvantage may not
be crucial in the current application (since the known attacks against
prepended-key hash use variable length inputs), the computational
advantage in IKEv2 is not an issue either (what is the cost of the extra
application of the compression function compared to the DH exchange, the
signatures, the encryption, the MAC, and (if applicable) the DoS cookie
generation?) Therefore, it seems to me that using a prf that is more
secure in general and computationally equivalent in this context is the
right choice. Not to mention that IKEv2 requires the use of a MAC function
for which HMAC is definitely more secure than "prepended SHA1" and thus
using HMAC for both saves the implementation of yet another function.
Hugo
On Tue, 26 Nov 2002, Russ Housley wrote:
> On pages 23 and 33 of draft-ietf-ipsec-ikev2-03.txt, there is a discussion
> of the use of HMAC-SHA1 for key derivation. I have no doubt that this
> construction is secure, but I do wonder if it is overkill.
>
> HMAC-SHA1 was designed as a packet integrity mechanism. The designers
> needed to deal with many concerns that are not obviously (at least to me)
> needed to generate a good key derivation function.
> > Can anyone tell me the properties HMAC-SHA1 that are needed here that
are
> not otherwise provided by a straightforward application of SHA1?
>
> Putting it another way, the current document uses:
>
> T1 = HMAC-SHA1(K, S | 0x01)
> T2 = HMAC-SHA1(K, T1 | S | 0x02)
> T3 = HMAC-SHA1(K, T2 | S | 0x03)
> T4 = HMAC-SHA1(K, T3 | S | 0x04)
>
> What needed property does this construction have that is not provided by
> the following?
>
> T1 = SHA1(K, S | 0x01)
> T2 = SHA1(K, T1 | S | 0x02)
> T3 = SHA1(K, T2 | S | 0x03)
> T4 = SHA1(K, T3 | S | 0x04)
>
> Thanks for any insights that can be provided.
>
> Russ
>
>
From owner-ipsec@lists.tislabs.com Tue Nov 26 22:25: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 gAR6PJg22696;
Tue, 26 Nov 2002 22:25:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA28360
Wed, 27 Nov 2002 00:42:31 -0500 (EST)
Date: Wed, 27 Nov 2002 07:45:30 +0200 (IST)
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
To: "The Purple Streak, Hilarie Orman" <ho@alum.mit.edu>
cc: housley@vigilsec.com, IPsec WG <ipsec@lists.tislabs.com>
Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation
In-Reply-To: <200211261723.gAQHNjf29469@localhost.localdomain>
Message-ID: <Pine.GSO.4.21.0211270743310.530-100000@ee.technion.ac.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hilarie, can you clarify what you mean by your comment below?
In particular, what is wrong if K is large and what
do you mean by "blocksize" in this context?
Thanks,
Hugo
On Tue, 26 Nov 2002, The Purple Streak, Hilarie Orman wrote:
> The HMAC construction is not necessary for key derivation, but both
> methods are wrong if K is large (in size and entropy) and security
> requirements dictate that a derived key must have more entropy than
> 2^(blocksize). This is a persistently misunderstood issue.
>
> Hilarie
>
>
From owner-ipsec@lists.tislabs.com Tue Nov 26 22:42: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 gAR6gFg24294;
Tue, 26 Nov 2002 22:42:16 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA28421
Wed, 27 Nov 2002 01:08:04 -0500 (EST)
Message-Id: <4.3.2.7.1.20021126182302.00dd1520@golf.cpgdesign.analog.com>
X-Sender: ramana@golf.cpgdesign.analog.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 26 Nov 2002 18:27:35 -0800
To: venkat <venkat@dexceldesigns.com>,
"ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
From: Ramana Yarlagadda <ramana.yarlagadda@analog.com>
Subject: Re: ISAKMP SA message #1 (proposing attributes/transforms)
In-Reply-To: <1038288132.797.24.camel@venkat>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Venkat,
At 10:52 AM 11/26/02 +0530, venkat wrote:
>Hi all,
>
>Protocol ID: IPSEC_AH
>Transform ID: AH_MD5
>Attributes(Auth Algo): HMAC-MD5
>Attributes(Auth Algo): HMAC-SHA
>Attributes(Encap Mode): Tunnel
>Attributes(Encap Mode): Transport
>
>Can we propose all the attributes we support so that the responder has
>an option to choose from our list and reply his conformation.
>
>e.g. IPSEC_AH(AH_MD5 transform) Security Association supporting HMAC_SHA
>Authentication Algorithm, IPSEC_AH(AH_SHA1 transform) SA supporting
>HMAC_MD5
IKE/ISKAMP allows you to negotiate. Please refer to ISAKMP std to see how
you can send this.
-ramana
From owner-ipsec@lists.tislabs.com Wed Nov 27 01:25:56 2002
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id gAR9Ptg20018;
Wed, 27 Nov 2002 01:25:55 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA28802
Wed, 27 Nov 2002 03:52:52 -0500 (EST)
Message-ID: <421CB3B9B2D2F645B548D213C0A90E5583F9C2@TMM_EDGMSMSG01>
From: Van Aken Dirk <VanAkenD@thmulti.com>
To: "'Paul Hoffman / VPNC'" <paul.hoffman@vpnc.org>,
Ari Huttunen
<Ari.Huttunen@f-secure.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: NAT Traversal in IKEv2
Date: Wed, 27 Nov 2002 09:05:41 +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
-----Original Message-----
From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
Sent: dinsdag 26 november 2002 15:56
To: Ari Huttunen
Cc: ipsec@lists.tislabs.com
Subject: NAT Traversal in IKEv2
[[ Please note that I changed the subject line. Everyone: if you want
to comment on what was said at the meeting, please make a better
subject line for your thread! ]]
At 12:46 PM +0200 11/26/02, Ari Huttunen wrote:
>Paul Hoffman / VPNC wrote:
>>IKEv2 status discussion - Charlie Kaufman
>> New draft in October
>> Changed many things that became controversial:
>> Suites replaced ala carte
>> Went to always 4 messages
>> Simplified traffic selector (no one has complained)
>> Other controversies
>> NAT traversal
>> Tunnel vs. transport negotiation
>> Key sizes and algorithms
>> Legacy auth not covered
>> Revised identity proposal
>> NAT Traversal
>> Not in IKEv1, but now there is a draft
>> Should the new extensions be included in IKEv2?
>> Tunnel vs. transport
>> No negotiation in IKEv2
>> Charlie needs to understand why this is needed
>> If inner and outer IP addresses are the same,
>> MAY use transport
>
>IMHO, NAT traversal is currently unnecessarily complicated.
>If we can imagine tweaking some things that we could not tweak
>when specifying it for IKEv1, we could make it simpler.
>I would myself throw out transport mode, and specify only
>tunnel mode for NAT traversal. I would also make IKEv2 always
>floated, so we can get rid of the ugly part of changing
>a protocol from one port to another.
Just to be clear, are you saying that the port for IKEv2 should
always be floated even if NAT-traversal is not negotiated?
>>
Is there a reason for not allowing IKEv2 to not use floating ports ?
In this way IKEv2 would behave like any other UDP based protocol
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Wed Nov 27 02:55: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 gARAtvg03585;
Wed, 27 Nov 2002 02:55:58 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA29031
Wed, 27 Nov 2002 05:04:29 -0500 (EST)
Message-ID: <3DE498E4.30806@F-Secure.com>
Date: Wed, 27 Nov 2002 12:05:24 +0200
From: Ari Huttunen <Ari.Huttunen@f-secure.com>
Organization: F-Secure Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Van Aken Dirk <VanAkenD@thmulti.com>
CC: "'Paul Hoffman / VPNC'" <paul.hoffman@vpnc.org>, ipsec@lists.tislabs.com
Subject: Re: NAT Traversal in IKEv2
References: <421CB3B9B2D2F645B548D213C0A90E5583F9C2@TMM_EDGMSMSG01>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Nov 2002 10:05:26.0448 (UTC) FILETIME=[81F61300:01C295FC]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Van Aken Dirk wrote:
>
> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
>>IMHO, NAT traversal is currently unnecessarily complicated.
>>If we can imagine tweaking some things that we could not tweak
>>when specifying it for IKEv1, we could make it simpler.
>>I would myself throw out transport mode, and specify only
>>tunnel mode for NAT traversal. I would also make IKEv2 always
>>floated, so we can get rid of the ugly part of changing
>>a protocol from one port to another.
>
>
> Just to be clear, are you saying that the port for IKEv2 should
> always be floated even if NAT-traversal is not negotiated?
Yes. It would be much cleaner if IKE packet format was the same
before and after discovering the existance of a NAT, and on the
same ports. (Based on the experience of having gone through the
discussions for producing NAT traversal drafts once already, the
ESP-in-UDP and IKE should stay on the same port. I'm not wishing
to change that.)
Still, this is not a major issue. I don't see a lot of complaints
about the current scheme on this list.
(Van Aken Dirk...)
> Is there a reason for not allowing IKEv2 to not use floating ports ?
> In this way IKEv2 would behave like any other UDP based protocol
I parse this as 'always use'.. Yes, this makes every IKEv2 packet
larger by 4 bytes, according to the current floating scheme. It's also
bound to have, maybe, interoperability issues with earlier IKEs and
maybe firewalls/NATs. Still, I'd prefer the least complex protocol possible.
You can reduce the 4 bytes to even 1 bit if you can tweak both the
IKEv2 and an ESPv2 specification. (Steal one bit of the SPI field..)
I'm not saying you should do it, but it's a possibility.
Ari
--
I play it cool and dig all jive,
that's the reason I stay alive.
My motto as I live and learn,
is dig and be dug in return. <Langston Hughes>
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
From owner-ipsec@lists.tislabs.com Wed Nov 27 03:12: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 gARBCEg05290;
Wed, 27 Nov 2002 03:12:14 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA29121
Wed, 27 Nov 2002 05:34:45 -0500 (EST)
Message-ID: <20021127103536.77145.qmail@web15105.mail.bjs.yahoo.com>
Date: Wed, 27 Nov 2002 18:35:36 +0800 (CST)
From: =?gb2312?q?king=20wu?= <wmyking49@yahoo.com.cn>
Subject: Can the initiator send a type of ID randomly?
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi, all
In the scenario with public sigiture keys in IKE, how
does the initiator choose a type of ID? As we know,
the ID includes FQDN,RFC822_ADDR,DER_ASN1_DN,etc.
Then, can the initiator send a type of ID randomly?
Or, are there some rules for doing it? I can't find
the rules through the documents on IKE.
Please help.
thanks.
--King Wu
_________________________________________________________
Do You Yahoo!?
"ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡"
http://cn.promo.yahoo.com/cgi-bin/udb/u
From owner-ipsec@lists.tislabs.com Wed Nov 27 06:36: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 gAREa4g19614;
Wed, 27 Nov 2002 06:36:05 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29459
Wed, 27 Nov 2002 08:56:06 -0500 (EST)
Message-Id: <200211270303.WAA20534@sentry.gw.tislabs.com>
From: "=?GB2312?Q?=D9=BA=95F?=" <phoenixcry@sina.com>
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: a question to isakmp sa
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
charset="GB2312"
Content-Transfer-Encoding: 7bit
Date: Wed, 27 Nov 2002 10:56:18 +0800
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
isakmp sa indicates which encrypt method is used to encrypt the phase 2 sa.
In the isakmp sa negotiation procedure, how to realize it?
The proposal payload? how to list the encrypt method?
thanks for your answer!
From owner-ipsec@lists.tislabs.com Wed Nov 27 08:09: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 gARG9kg25188;
Wed, 27 Nov 2002 08:09:47 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29498
Wed, 27 Nov 2002 09:28:19 -0500 (EST)
Message-ID: <F504A8CEE925D411AF4A00508B8BE90A0162D056@exna07.securitydynamics.com>
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Counter Mode: Proposed Way Forward
Date: Wed, 27 Nov 2002 09:25:24 -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
I want to thank David McGrew for his detailed analysis. I wish that David
had been able to generate his document sooner, but now that we have the
information, we can plot a way forward.
David has proposed the use of additional secret random material to salt the
counter block. Further discussions have shown that this is not needed.
Rather, unpredictability is the only property that is needed. If the value
cannot be know in advance, then the attacker cannot start the computation of
the very huge table until the value is learned. If the value is
predictable, then the attacker can mount the attack using the likely value.
This is the situation in the current draft. Since many implementations use
the SPI as an index into a table of security associations, the truncated SPI
value is too predictable.
I propose the replacement of the truncated SPI with the 24 most significant
bits form the IKE nonces. I propose that the initiator use 24 bits from its
own nonce, and the responder use 24 bits from its own nonce. In this way,
we can accommodate any future key establishment techniques that might use
the same key in both directions, Even with the same key, the initiator and
responder will have different counter block values, and thus different key
streams.
Based on the analysis of storage system technology posted by David Black,
the additional 24 unpredictable bits in the counter block should thwart the
precomputation attack for several decades, even if the attacker were able to
discover the values that would be used a long time prior to their use, Use
of the IKE nonces makes this impossible (assuming reasonable random number
generation capabilities), thus completely thwarting the attack.
Unless I hear an uproar on the list, I will update the draft to reflect this
way forward.
Russ
From owner-ipsec@lists.tislabs.com Wed Nov 27 10:35: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 gARIZag07920;
Wed, 27 Nov 2002 10:35:36 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29866
Wed, 27 Nov 2002 12:51:26 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15845.1606.961113.340051@pkoning.dev.equallogic.com>
Date: Wed, 27 Nov 2002 12:52:06 -0500
From: Paul Koning <pkoning@equallogic.com>
To: rhousley@rsasecurity.com
Cc: ipsec@lists.tislabs.com
Subject: Re: Counter Mode: Proposed Way Forward
References: <F504A8CEE925D411AF4A00508B8BE90A0162D056@exna07.securitydynamics.com>
X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Russ" == Russ Housley <Housley> writes:
Russ> ...
Russ> I propose the replacement of the truncated SPI with the 24 most
Russ> significant bits form the IKE nonces. I propose that the
Russ> initiator use 24 bits from its own nonce, and the responder use
Russ> 24 bits from its own nonce. ...
Russ> Unless I hear an uproar on the list, I will update the draft to
Russ> reflect this way forward.
Sounds good.
How about losing the flags field, since it appears to serve no
purpose, and using 32 bits of nonce?
paul
From owner-ipsec@lists.tislabs.com Thu Nov 28 07:17: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 gASFHHg14510;
Thu, 28 Nov 2002 07:17:17 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01680
Thu, 28 Nov 2002 09:36:09 -0500 (EST)
Message-ID: <20021128143628.62088.qmail@web15104.mail.bjs.yahoo.com>
Date: Thu, 28 Nov 2002 22:36:28 +0800 (CST)
From: =?gb2312?q?king=20wu?= <wmyking49@yahoo.com.cn>
Subject: Why is IDAccepted added?
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi,all
In "Adding revised identities to IKEv2" by Paul
Hoffman, a new payload IDAccepted is added. Who can
tell me why and give a example?
Thanks very much.
_________________________________________________________
Do You Yahoo!?
"ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡"
http://cn.promo.yahoo.com/cgi-bin/udb/u
From owner-ipsec@lists.tislabs.com Thu Nov 28 09:51: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 gASHpDg22839;
Thu, 28 Nov 2002 09:51:13 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02001
Thu, 28 Nov 2002 12:17:46 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org (Unverified)
Message-Id: <p05200f05ba0bffe8ff38@[216.26.32.159]>
In-Reply-To: <20021128143628.62088.qmail@web15104.mail.bjs.yahoo.com>
References: <20021128143628.62088.qmail@web15104.mail.bjs.yahoo.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Thu, 28 Nov 2002 09:18:56 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Why is IDAccepted added?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 10:36 PM +0800 11/28/02, king wu wrote:
>In "Adding revised identities to IKEv2" by Paul
>Hoffman, a new payload IDAccepted is added. Who can
>tell me why and give a example?
Certainly. If a responding IPsec system only accepts certificates and
cannot resolve URLs, the initiating system should not send a
hash-plus-URL. The IDAccepted method is a way for each side to say
what kind of IDs are supported before the other side sends its ID.
This prevents failures that could have been avoided.
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Fri Nov 29 09:55: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 gATHtlg06732;
Fri, 29 Nov 2002 09:55:48 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03945
Fri, 29 Nov 2002 12:17:59 -0500 (EST)
Message-Id: <5.2.0.9.2.20021127191422.00b82a78@mail.binhost.com>
X-Sender: housley@mail.binhost.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 27 Nov 2002 19:16:20 -0500
To: Paul Koning <pkoning@equallogic.com>
From: Russ Housley <housley@vigilsec.com>
Subject: Re: Counter Mode: Proposed Way Forward
Cc: ipsec@lists.tislabs.com
In-Reply-To: <15845.1606.961113.340051@pkoning.dev.equallogic.com>
References: <F504A8CEE925D411AF4A00508B8BE90A0162D056@exna07.securitydynamics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul:
We could do that, but I am hoping that people will be interested in CCM
once the new ESP gets rolling. CCM uses the flags field, but it cannot be
zero. This would make it very easy for an implementation to support CCM
and this counter mode specification too.
Russ
At 12:52 PM 11/27/2002 -0500, Paul Koning wrote:
> >>>>> "Russ" == Russ Housley <Housley> writes:
>
> Russ> ...
> Russ> I propose the replacement of the truncated SPI with the 24 most
> Russ> significant bits form the IKE nonces. I propose that the
> Russ> initiator use 24 bits from its own nonce, and the responder use
> Russ> 24 bits from its own nonce. ...
>
> Russ> Unless I hear an uproar on the list, I will update the draft to
> Russ> reflect this way forward.
>
>Sounds good.
>
>How about losing the flags field, since it appears to serve no
>purpose, and using 32 bits of nonce?
>
> paul
From owner-ipsec@lists.tislabs.com Fri Nov 29 10: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 gATIwNg09919;
Fri, 29 Nov 2002 10:58:24 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03946
Fri, 29 Nov 2002 12:18:04 -0500 (EST)
Message-Id: <5.2.0.9.2.20021127084405.00b13098@mail.binhost.com>
X-Sender: housley@mail.binhost.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 27 Nov 2002 08:46:47 -0500
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
From: Russ Housley <housley@vigilsec.com>
Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation
Cc: ipsec@lists.tislabs.com
In-Reply-To: <Pine.GSO.4.21.0211270739360.530-100000@ee.technion.ac.il>
References: <5.2.0.9.2.20021126092238.00b8fe58@mail.binhost.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hugo:
Thanks for the reply.
I agree that the overhead of the additional SHA-1 application for each
output is insignificant when compared to the other operations being
performed. However, I am seeing other standards adopt the same
construction, so I wanted to make sure that I understand the properties
that are needed.
Russ
At 07:43 AM 11/27/2002 +0200, Hugo Krawczyk wrote:
>Russ,
>
>I guess that you are suggesting to use "prepended SHA1" (i.e. SHA1(K,...))
>instead of HMAC as the the default instantiation of the prf in IKEv2. The
>advantage of "prepended SHA1" is that it may require one less application
>of the compression function of SHA1 (per 160 bits of key material). The
>disadvantage is that, in general, "prepended SHA1" is broken as a prf
>(extension attacks as those in the Preneel-van Oorschot paper break the
>unpredictability of the function). While this later disadvantage may not
>be crucial in the current application (since the known attacks against
>prepended-key hash use variable length inputs), the computational
>advantage in IKEv2 is not an issue either (what is the cost of the extra
>application of the compression function compared to the DH exchange, the
>signatures, the encryption, the MAC, and (if applicable) the DoS cookie
>generation?) Therefore, it seems to me that using a prf that is more
>secure in general and computationally equivalent in this context is the
>right choice. Not to mention that IKEv2 requires the use of a MAC function
>for which HMAC is definitely more secure than "prepended SHA1" and thus
>using HMAC for both saves the implementation of yet another function.
>
>Hugo
>
>On Tue, 26 Nov 2002, Russ Housley wrote:
>
> > On pages 23 and 33 of draft-ietf-ipsec-ikev2-03.txt, there is a discussion
> > of the use of HMAC-SHA1 for key derivation. I have no doubt that this
> > construction is secure, but I do wonder if it is overkill.
> >
> > HMAC-SHA1 was designed as a packet integrity mechanism. The designers
> > needed to deal with many concerns that are not obviously (at least to me)
> > needed to generate a good key derivation function.
> > > Can anyone tell me the properties HMAC-SHA1 that are needed here that
>are
> > not otherwise provided by a straightforward application of SHA1?
> >
> > Putting it another way, the current document uses:
> >
> > T1 = HMAC-SHA1(K, S | 0x01)
> > T2 = HMAC-SHA1(K, T1 | S | 0x02)
> > T3 = HMAC-SHA1(K, T2 | S | 0x03)
> > T4 = HMAC-SHA1(K, T3 | S | 0x04)
> >
> > What needed property does this construction have that is not provided by
> > the following?
> >
> > T1 = SHA1(K, S | 0x01)
> > T2 = SHA1(K, T1 | S | 0x02)
> > T3 = SHA1(K, T2 | S | 0x03)
> > T4 = SHA1(K, T3 | S | 0x04)
> >
> > Thanks for any insights that can be provided.
> >
> > Russ
> >
> >
From owner-ipsec@lists.tislabs.com Fri Nov 29 12:07: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 gATK7og13514;
Fri, 29 Nov 2002 12:07:51 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04241
Fri, 29 Nov 2002 14:40:23 -0500 (EST)
Message-Id: <200211291558.gATFvd3v003143@sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: How important is identity protecton?
In-reply-to: Your message of "Tue, 26 Nov 2002 15:41:31 EST."
<200211262041.gAQKfVJ08833@sydney.East.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 29 Nov 2002 10:57:38 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Radia" == Radia Perlman <- Boston Center for Networking <Radia.Perlman@sun.com>> writes:
Radia> the two styles, seemed to have consensus around avoiding the
Radia> polling attack. The reasoning was
Radia> that IKE is a peer-to-peer protocol where either
Radia> side can initiate, and the polling attack is way easier (just
Radia> initiate a connection to an IP address) than impersonating the
Radia> responder's IP address and seeing who connects.
Radia> Based on these arguments and the perceived consensus of the
Radia> WG, JFK and SIGMA added handshakes to avoid the polling attack.
Radia> So at any rate, this issue has been considered.
Radia> I think it's far-fetched to come up with a scenario where
Radia> it would be horrible if
Radia> you could be tricked into revealing that you are attempting to
Radia> connect to someone. In a case like two freedom-fighters trying to
One of the things that I'd like to be able to do is either change
identities, or create sub-negotiations with an IKEv2 phase 1.
Either lets people conceal their real identities behing fake identities.
Specifically, IPv4 identities which don't really tell anyone anything.
Changing identities could just be a matter of doing a rekey of phase 1
within the old phase 1. This might be easy to do by literally just embedding
an IKE payload inside of IKE. We will be writing text on this.
A sub-negotiation would permit multi-user systems to negotiate with
specific user's identities for per-port connections.
] 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 Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPeeOcIqHRg3pndX9AQHPnwP6AqJzo2eOWLUAFgB5G9QbMnPjEBmQZdry
7QSAqlYcWDosRc5HaVOdMgvzW6v07vJXkNdA9HP7WeUnl+Ln5TFwMJV03hrIh5Eo
Q9kROOFhllo6dlkQ0kEqa0MnZwopKlzXXo8Vf4CfW15TQATNey3+989I17Go1qI7
ETA9OQ4sfww=
=VFPX
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Fri Nov 29 12:07: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 gATK7pg13517;
Fri, 29 Nov 2002 12:07:52 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04242
Fri, 29 Nov 2002 14:40:28 -0500 (EST)
Message-Id: <200211291615.gATGEadG003399@sandelman.ottawa.on.ca>
To: Ramana Yarlagadda <ramana.yarlagadda@analog.com>
CC: ipsec@lists.tislabs.com
Subject: Re: ISAKMP SA message #1 (proposing attributes/transforms)
In-reply-to: Your message of "Tue, 26 Nov 2002 18:27:35 PST."
<4.3.2.7.1.20021126182302.00dd1520@golf.cpgdesign.analog.com>
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 29 Nov 2002 11:14:36 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Ramana" == Ramana Yarlagadda <ramana.yarlagadda@analog.com> writes:
Ramana> IKE/ISKAMP allows you to negotiate. Please refer to ISAKMP std to see how
Ramana> you can send this.
It does not permit negotiation.
It permits agreement.
Negotiation requires a conversation that goes like:
A: I like A, B, C, D
B: I like D, B, Q, Z
A: okay, let's do B.
] 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 Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPeeSSoqHRg3pndX9AQGyOAQAzSGPxaXvdyZQg1TU+3ih4RAebCDjw0t2
8SZ85yvqX5GZ1JwQWsDewFMyOjeSdjLuN/Q8HqCK6hEPGNjtZewOiGuWGKDKr1+e
wxzcG9mVzJxMPhXJeR+rhbH4PEhCSwmLgA+pSVL68i9h7BiWg2qdynRAbBhgNMQJ
G17OsJ9G/io=
=xM83
-----END PGP SIGNATURE-----