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: 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 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 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: 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 . Date: Sat, 2 Nov 2002 15:46:57 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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 >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: >List-ID: >List-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 > > o IPSec Policy Information Base > > >The IESG will also consider publication of IP Security Policy Requirements > 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: 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 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: In-Reply-To: References: Date: Mon, 4 Nov 2002 12:27:20 -0500 To: Charlie_Kaufman@notesdev.ibm.com From: Stephen Kent 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 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" To: "Edward Wilkinson" , Subject: RE: Dead peer detection Date: Fri, 1 Nov 2002 13:36:20 -0800 Message-ID: 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," =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 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 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 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." 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: 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 From: Stephen Kent 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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld 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 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" From: "Ahmed Bin Abbas Ahmed Ali Adas" To: Cc: 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" To: Cc: "Peter Gutmann" ; ; 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 To: "Ahmed Bin Abbas Ahmed Ali Adas" 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 Date: Tue, 5 Nov 2002 11:01:34 -0500 (EST) CC: ipsec@lists.tislabs.com From: Dan McDonald 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" Reply-To: andrew.krywaniuk@alcatel.com To: "'ipsec'" 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" > To: > Cc: "Peter Gutmann" ; > ; > > 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 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'" 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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk 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: 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 . Date: Tue, 5 Nov 2002 14:20:53 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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" To: "'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 From: Cheryl Madson Subject: Re: request to review draft in mobile IP wg Cc: ipsec@lists.tislabs.com, Vijay Devarapalli , Francis Dupont , Michael Thomas , 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. 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" To: 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 To: Paul Hoffman / VPNC 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. 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 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 Cc: Teemu Alakoski , ipsec@lists.tislabs.com Subject: MTU considerations (was: Public key distribution methods?) In-Reply-To: References: <20021104100331.GA17307@alakoski.ton.tut.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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: In-Reply-To: <15817.23906.865682.76556@thomasm-u1.cisco.com> References: <20021104100331.GA17307@alakoski.ton.tut.fi> <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 . Date: Wed, 6 Nov 2002 11:58:20 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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 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 Cc: ipsec@lists.tislabs.com Subject: Re: MTU considerations (was: Public key distribution methods?) In-Reply-To: References: <20021104100331.GA17307@alakoski.ton.tut.fi> <15817.23906.865682.76556@thomasm-u1.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/AuzN4mu!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 To: ipsec@lists.tislabs.com, "'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 X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Cheryl Madson CC: Jari Arkko , 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: Thread-Topic: I-D ACTION:draft-ietf-ipsec-udp-encaps-04.txt Thread-Index: AcKFqvdbaaM9ItjaQCKtbRm7IbZfrAAwbw5g From: "HOULLIER Francis FTRD/DMI/CAE" To: 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 Cc: ipsec@lists.tislabs.com, "'l2tpext@ietf.org'" Subject: Re: UDP-encapsulated IPsec Transport mode References: <1b5e89839d24839d709e637969682af73dc9afc1@watchguard.com> From: Markus Stenberg 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 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: In-Reply-To: <15817.23906.865682.76556@thomasm-u1.cisco.com> References: <20021104100331.GA17307@alakoski.ton.tut.fi> <15817.23906.865682.76556@thomasm-u1.cisco.com> Date: Thu, 7 Nov 2002 12:58:59 -0500 To: Michael Thomas From: Stephen Kent 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: 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 . Date: Thu, 7 Nov 2002 11:01:20 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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: From: James Huang To: "'Markus Stenberg'" Cc: ipsec@lists.tislabs.com, "'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 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 Message-Id: <200211071959.gA7JxPq5008847@oe8.briank.com> Subject: Re: Adding revised identities to IKEv2 In-Reply-To: "from Paul Hoffman / VPNC at Nov 7, 2002 11:01:20 am" To: "Paul Hoffman / VPNC" 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: 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 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 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 Cc: ipsec@lists.tislabs.com Subject: Re: Adding revised identities to IKEv2 In-Reply-To: References: <200211061452.gA6EqIte071906@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/AuzN4mu!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: In-Reply-To: <15818.54256.902876.454996@thomasm-u1.cisco.com> References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr> <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 . Date: Thu, 7 Nov 2002 13:09:08 -0800 To: Michael Thomas From: Paul Hoffman / VPNC 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" To: Cc: 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" Reply-To: andrew.krywaniuk@alcatel.com To: "'ipsec'" 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" To: , "ipsec" 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" Reply-To: andrew.krywaniuk@alcatel.com To: "'Niklas Hallqvist'" Cc: "'ipsec'" 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 > > > > >>>>> "Andrew" == Andrew Krywaniuk > 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 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 Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Adding revised identities to IKEv2 In-Reply-To: References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr> <15818.54256.902876.454996@thomasm-u1.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/AuzN4mu!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 To: Michael Thomas cc: Paul Hoffman / VPNC , Subject: Re: Adding revised identities to IKEv2 In-Reply-To: <15819.5560.908560.107036@thomasm-u1.cisco.com> Message-ID: 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 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 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 Cc: Michael Thomas , Paul Hoffman / VPNC , Subject: Re: Adding revised identities to IKEv2 In-Reply-To: References: <15819.5560.908560.107036@thomasm-u1.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/AuzN4mu!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 To: Michael Thomas cc: Paul Hoffman / VPNC , Subject: Re: Adding revised identities to IKEv2 In-Reply-To: <15819.8613.154747.926275@thomasm-u1.cisco.com> Message-ID: 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" To: "Paul Hoffman / VPNC" , "Michael Thomas" Cc: Subject: RE: Adding revised identities to IKEv2 Date: Thu, 7 Nov 2002 18:45:55 -0800 Message-ID: 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: 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 To: James Huang cc: "'Markus Stenberg'" , , "'l2tpext@ietf.org'" Subject: RE: UDP-encapsulated IPsec Transport mode In-Reply-To: Message-ID: 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 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: In-Reply-To: References: 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 . Date: Thu, 7 Nov 2002 20:01:33 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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 To: Paul Hoffman / VPNC 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. 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: From: "Vohra, Meenakshi" To: "'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" looking for VPN Clients on Linux / Solaris with X Auth

Hello everyone
Can anyone suggest me the VPN Clients for Linux / Solaris with XAuth support.

Thanks
Meenakshi


------_=_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: In-Reply-To: References: Date: Fri, 8 Nov 2002 09:44:17 -0500 To: Jan Vilhuber From: Stephen Kent Subject: Re: Adding revised identities to IKEv2 Cc: 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 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: In-Reply-To: References: Date: Fri, 8 Nov 2002 09:48:27 -0500 To: Paul Hoffman / VPNC From: Stephen Kent 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 cc: andrew.krywaniuk@alcatel.com, "'ipsec'" 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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Tue, 05 Nov 2002 16:10:10 -0500 > From: Michael Richardson > > >>>>> "Andrew" == Andrew Krywaniuk 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: 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 . Date: Fri, 8 Nov 2002 08:42:32 -0800 To: Francis Dupont From: Paul Hoffman / VPNC 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: In-Reply-To: References: 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 . Date: Fri, 8 Nov 2002 08:36:30 -0800 To: Stephen Kent From: Paul Hoffman / VPNC 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: In-Reply-To: References: Date: Fri, 8 Nov 2002 11:56:44 -0500 To: Paul Hoffman / VPNC From: Stephen Kent 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 To: "'Skip Booth'" Cc: "'Markus Stenberg'" , ipsec@lists.tislabs.com, "'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 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 To: James Huang cc: "'Markus Stenberg'" , , "'l2tpext@ietf.org'" Subject: RE: UDP-encapsulated IPsec Transport mode In-Reply-To: <97de41e0baaeb8917f5832b2faee1e633dcc0244@watchguard.com> Message-ID: 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 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: In-Reply-To: References: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr> Date: Fri, 8 Nov 2002 15:27:44 -0500 To: Paul Hoffman / VPNC From: Stephen Kent 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 To: "'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" 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 IKE Leadership

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-- 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: In-Reply-To: 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 . Date: Fri, 8 Nov 2002 13:21:59 -0800 To: Stephen Kent From: Paul Hoffman / VPNC 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: In-Reply-To: References: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr> Date: Fri, 8 Nov 2002 16:38:51 -0500 To: Paul Hoffman / VPNC From: Stephen Kent 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: In-Reply-To: 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 . Date: Fri, 8 Nov 2002 13:50:33 -0800 To: Stephen Kent From: Paul Hoffman / VPNC 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 To: Paul Hoffman / VPNC cc: Subject: RE: Adding revised identities to IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 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 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" To: Stephen Kent 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: References: <200211080946.gA89klte080353@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 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: In-Reply-To: References: <200211080946.gA89klte080353@givry.rennes.enst-bretagne.fr> Date: Fri, 8 Nov 2002 17:37:27 -0500 To: Paul Hoffman / VPNC From: Stephen Kent 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 To: "'Skip Booth'" Cc: "'Markus Stenberg'" , ipsec@lists.tislabs.com, "'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 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" To: "'James Huang'" , , 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: From: James Huang To: "'Satyadeva Konduru'" , 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" To: "'James Huang'" , , 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: 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 To: "'Satyadeva Konduru'" , 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 To: James Huang cc: "'Markus Stenberg'" , , "'l2tpext@ietf.org'" Subject: RE: UDP-encapsulated IPsec Transport mode In-Reply-To: <71a0e3c9e7381b9113b0757bf8dcd93f3dcc3fe4@watchguard.com> Message-ID: 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 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" To: "'James Huang'" , , 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 To: "'Satyadeva Konduru'" , 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: From: James Huang To: "'Skip Booth'" Cc: "'Markus Stenberg'" , ipsec@lists.tislabs.com, "'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 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" To: "'James Huang'" , , 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: From: James Huang To: "'Satyadeva Konduru'" , 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 To: James Huang cc: "'Markus Stenberg'" , , "'l2tpext@ietf.org'" Subject: RE: UDP-encapsulated IPsec Transport mode In-Reply-To: Message-ID: 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 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" To: Paul Hoffman / VPNC 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: References: 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 To: Paul Hoffman / VPNC 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. 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: From: "Awan Kumar Sharma" To: "'Skip Booth'" , "'James Huang'" Cc: "'Markus Stenberg'" , , 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: 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 | 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 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" To: 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 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 CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-udp-encaps-04.txt References: 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. 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: 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 . Date: Mon, 11 Nov 2002 09:28:47 -0800 To: "Valery Smyslov" , From: Paul Hoffman / VPNC 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" 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 To: "'awank@future.futsoft.com'" , "'Skip Booth'" Cc: "'Markus Stenberg'" , 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 | 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 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" To: "Valery Smyslov" , , "Paul Hoffman / VPNC" References: <001901c2895e$a54c3000$640572d4@trustworks.com> 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" To: "Valery Smyslov" ; 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 To: "Housley, Russ" cc: Paul Hoffman / VPNC , Subject: RE: Adding revised identities to IKEv2 In-Reply-To: <5.1.0.14.2.20021109161112.02d5e5b0@exna07.securitydynamics.com> Message-ID: 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" Reply-To: andrew.krywaniuk@alcatel.com To: "'Ari Huttunen'" , " 'HOULLIER Francis FTRD/DMI/CAE'" Cc: "'ipsec'" 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. > > 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" To: Paul Hoffman / VPNC 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: 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: 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 . Date: Mon, 11 Nov 2002 13:52:02 -0800 To: "Housley, Russ" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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" To: Cc: 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" To: "David Faucher" , , "Paul Hoffman / VPNC" References: <001901c2895e$a54c3000$640572d4@trustworks.com> <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" To: "Valery Smyslov" ; ; "Paul Hoffman / VPNC" 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" > To: "Valery Smyslov" ; > 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" To: , "Paul Hoffman / VPNC" References: <001901c2895e$a54c3000$640572d4@trustworks.com> 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" To: "Valery Smyslov" ; 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: 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: In-Reply-To: <001201c28a1b$3870ecb0$640572d4@trustworks.com> References: <001901c2895e$a54c3000$640572d4@trustworks.com> <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 . Date: Tue, 12 Nov 2002 09:35:23 -0800 To: "Valery Smyslov" , From: Paul Hoffman / VPNC 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: In-Reply-To: <000801c28a15$701f9720$640572d4@trustworks.com> References: <001901c2895e$a54c3000$640572d4@trustworks.com> <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 . Date: Tue, 12 Nov 2002 09:31:28 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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" >To: "Valery Smyslov" ; ; "Paul >Hoffman / VPNC" >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" From: Barbara Fraser Subject: RE: Dead peer detection Cc: "Edward Wilkinson" , , tytso@mit.edu In-Reply-To: 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 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" >From: Barbara Fraser >Subject: Re: status of aes-cbc and sha-256 drafts? >Cc: tytso@mit.edu, Sheila Frankel > >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" >From: Barbara Fraser >Subject: Re: status of aes-cbc and sha-256 drafts? >Cc: tytso@mit.edu, Sheila Frankel > >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: 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 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 To: ipsec@lists.tislabs.com CC: paul.hoffman@vpnc.org (Paul Hoffman / VPNC) Subject: Re: Adding revised identities to IKEv2 References: 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 To: 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 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 To: Valery Smyslov cc: , Paul Hoffman / VPNC Subject: Re: Authentication methods in IKEv2 In-Reply-To: <001201c28a1b$3870ecb0$640572d4@trustworks.com> Message-ID: 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" > To: "Valery Smyslov" ; > 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" 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 , 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 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" Reply-To: andrew.krywaniuk@alcatel.com To: "'Tero Kivinen'" , " 'ipsec'" 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 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> 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: In-Reply-To: <3DD17A5E.E2C8B38A@lucent.com> References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr> <3DD17A5E.E2C8B38A@lucent.com> Date: Tue, 12 Nov 2002 17:27:47 -0500 To: Uri Blumenthal From: Stephen Kent 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. > > >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 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 Original-CC: ipsec@lists.tislabs.com Subject: Re: Adding revised identities to IKEv2 References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr> <3DD17A5E.E2C8B38A@lucent.com> 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: In-Reply-To: <3DD183E6.6B899050@lucent.com> References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr> <3DD17A5E.E2C8B38A@lucent.com> <3DD183E6.6B899050@lucent.com> Date: Tue, 12 Nov 2002 17:56:41 -0500 To: Uri Blumenthal From: Stephen Kent 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" 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 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 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 Original-CC: ipsec@lists.tislabs.com Subject: Re: Adding revised identities to IKEv2 References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr> <3DD17A5E.E2C8B38A@lucent.com> <3DD183E6.6B899050@lucent.com> 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: In-Reply-To: <3DD1963A.4D09021E@lucent.com> References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr> <3DD17A5E.E2C8B38A@lucent.com> <3DD183E6.6B899050@lucent.com> <3DD1963A.4D09021E@lucent.com> Date: Tue, 12 Nov 2002 19:11:58 -0500 To: Uri Blumenthal From: Stephen Kent 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 Date: Tue, 12 Nov 2002 20:26:38 -0500 (EST) CC: ipsec@lists.tislabs.com From: Dan McDonald 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 To: andrew.krywaniuk@alcatel.com Cc: " 'ipsec'" 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: Thread-Topic: I-D ACTION:draft-ietf-ipsec-sctp-04.txt Thread-Index: AcJ6neFf3yKtSPMXTReY+QYkDzAN0wQdj+VA To: 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" From: Brian Korver 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" From: Brian Korver 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" 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: 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 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: To: "Greg Carter" From: Brian Korver 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 Subject: Re: Adding revised identities to IKEv2 In-Reply-To: References: <3DD1963A.4D09021E@lucent.com> <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr> <3DD17A5E.E2C8B38A@lucent.com> <3DD183E6.6B899050@lucent.com> <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 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 >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 >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: In-Reply-To: References: Date: Wed, 13 Nov 2002 11:37:04 -0500 To: "Padmapriya Parthasarathy" From: Stephen Kent 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" To: Brian Korver 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" To: Brian Korver 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: 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> <3DD17A5E.E2C8B38A@lucent.com> <3DD183E6.6B899050@lucent.com> <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 From: Stephen Kent 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, > >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 Subject: Re: Adding revised identities to IKEv2 In-Reply-To: References: 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: In-Reply-To: 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 . Date: Wed, 13 Nov 2002 09:13:01 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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 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 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> <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/AuzN4mu!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: In-Reply-To: <15825.25361.887103.61323@ryijy.hel.fi.ssh.com> References: <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 . Date: Wed, 13 Nov 2002 09:29:09 -0800 To: Tero Kivinen , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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: 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 . Date: Wed, 13 Nov 2002 08:51:42 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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: 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 . Date: Wed, 13 Nov 2002 08:43:53 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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: In-Reply-To: References: <200211061452.gA6EqIte071906@givry.rennes.enst-bretagne.fr> Date: Wed, 13 Nov 2002 16:25:46 -0500 To: Paul Hoffman / VPNC From: Stephen Kent 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 To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Adding revised identities to IKEv2 In-Reply-To: References: <15825.25361.887103.61323@ryijy.hel.fi.ssh.com> 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" Reply-To: andrew.krywaniuk@alcatel.com To: "'Paul Hoffman / VPNC'" , " 'ipsec'" 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: 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" 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> 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 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 Cc: ipsec@lists.tislabs.com Subject: Re: Adding revised identities to IKEv2 In-Reply-To: References: <200211061452.gA6EqIte071906@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/AuzN4mu!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: 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 . Date: Wed, 13 Nov 2002 17:30:55 -0500 To: "Housley, Russ" , Brian Korver From: Paul Hoffman / VPNC 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 To: IPSec Mail Group 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: 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 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" To: "Tero Kivinen" , "Paul Hoffman / VPNC" Cc: Subject: RE: Adding revised identities to IKEv2 Date: Thu, 14 Nov 2002 11:52:58 -0800 Message-ID: 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: From: "Awan Kumar Sharma" To: "'venkat'" , "'IPSec Mail Group'" 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 To: IPSec Mail Group 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 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 To: "Max Pritikin" Cc: "Paul Hoffman / VPNC" , Subject: RE: Adding revised identities to IKEv2 In-Reply-To: References: <15826.51228.546106.342625@ryijy.hel.fi.ssh.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" From: Brian Korver 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" From: Brian Korver 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" From: Brian Korver 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 To: Stephen Kent 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. 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 To: Uri Blumenthal 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 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 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 cc: "Housley, Russ" , 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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Thu, 14 Nov 2002 18:52:49 -0800 > From: Brian Korver > > 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 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 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 To: Uri Blumenthal 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 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 To: Uri Blumenthal 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 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 Cc: "Housley, Russ" , 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" To: Brian Korver 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" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: 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" To: Brian Korver 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 From: Russ Housley 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: <15826.51228.546106.342625@ryijy.hel.fi.ssh.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 , Francis Dupont 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 , Francis Dupont From: Uri Blumenthal 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 Reply-To: Brian Korver X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Niklas Hallqvist 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 Reply-To: briank@xythos.com X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Housley, Russ" 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" From: Brian Korver In-Reply-To: <5.1.0.14.2.20021115115152.03435ac8@exna07.securitydynamics.com> Message-Id: 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 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 Cc: Uri Blumenthal , 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/AuzN4mu!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" To: 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 In-Reply-To: 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 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 Cc: Michael Thomas , Francis Dupont , 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/AuzN4mu!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" To: 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" To: Brian Korver 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: 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 Reply-To: Radia Perlman - Boston Center for Networking 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" 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" To: "Paul Hoffman / VPNC" , Subject: Counter Mode Security: Analysis and Recommendations Date: Fri, 15 Nov 2002 14:10:12 -0800 Message-ID: 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: 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: 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 From: Stephen Kent 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 To: IPsec WG Subject: SIGMA and the cryptographic rationale for IKE exchanges Message-ID: 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" To: Cc: References: 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: To: "Valery Smyslov" Cc: ; 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: 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 . Date: Sat, 16 Nov 2002 11:25:17 -0500 To: Brian Korver , Niklas Hallqvist From: Paul Hoffman / VPNC 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" To: "David A. Mcgrew" Cc: Paul Hoffman / VPNC , 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: 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 To: IPSec Mail Group Cc: manjunath 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" To: "'ipsec@lists.tislabs.com'" cc: "'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" To: "Theodore Ts'o" Cc: "Paul Hoffman / VPNC" , Subject: RE: Counter Mode Security: Analysis and Recommendations Date: Sun, 17 Nov 2002 18:45:58 -0800 Message-ID: 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" 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 Subject: RE: UDP-encapsulated IPsec Transport mode To: "ipsec@lists.tislabs.com" Cc: "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 To: Michael Thomas cc: Uri Blumenthal , 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" From: Brian Korver In-Reply-To: <5.1.0.14.2.20021115154953.0556d310@exna07.securitydynamics.com> Message-Id: 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" To: "Radia Perlman - Boston Center for Networking" , Cc: 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" To: Cc: Sent: Friday, November 15, 2002 3:17 PM Subject: Re: Traffic Selectors | 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: 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 Subject: RE: Suites vs a-la-carte Cc: 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 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: 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 To: ipsec@lists.tislabs.com Cc: plugtests@etsi.fr, Philippe Cousin 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 To: Uri Blumenthal cc: Michael Thomas , 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: 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 From: Stephen Kent 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 To: Michael Thomas cc: Uri Blumenthal , 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: 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 From: Stephen Kent 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: 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 From: Stephen Kent 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 To: Stephen Kent 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. 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 From: Uri Blumenthal Subject: Re: Adding revised identities to IKEv2 Cc: Michael Thomas , ipsec@lists.tislabs.com In-Reply-To: <200211181427.gAIERete027311@givry.rennes.enst-bretagne.fr> References: 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 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 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 To: Uri Blumenthal cc: Michael Thomas , 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 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 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 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 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" To: "David A. Mcgrew" Cc: "Theodore Ts'o" , Paul Hoffman / VPNC , 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: 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 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 Cc: Francis Dupont , Michael Thomas , 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: <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/AuzN4mu!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" 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: 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 To: Michael Thomas cc: Uri Blumenthal , 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 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> 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 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: 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 . Date: Tue, 19 Nov 2002 17:33:15 -0500 To: IP Security List From: Paul Hoffman / VPNC 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 . --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 To: Paul Koning 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 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 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 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 Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Adding revised identities to IKEv2 In-Reply-To: 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> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!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: Thread-Topic: What would be the main difference between the ... Thread-Index: AcKP+65CWrxFaet4QfyMKH72Aw5IZA== From: "Sukanta Ganguly" To: 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 Message
Hi,
  = 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.
 
 
SG
=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" To: 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: 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> <15834.55168.933346.42408@thomasm-u1.cisco.com> Date: Wed, 20 Nov 2002 17:32:35 -0500 To: Michael Thomas From: Stephen Kent 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" 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" To: "Housley, Russ" Cc: "Theodore Ts'o" , "Paul Hoffman / VPNC" , Subject: RE: Counter Mode Security: Analysis and Recommendations Date: Wed, 20 Nov 2002 12:01:25 -0800 Message-ID: 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 To: "'Paul Koning'" , 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 writes: > > 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" 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 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 writes: > > > > > 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 , "'Paul Koning'" , mcgrew@cisco.com From: Alex Alten 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 writes: > >> >> 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: From: Harshwardhan Mittal To: "'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 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 To: "'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" To: 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
"Deploying IPv6=20 Networks" second edition and "IPsec = Global=20 Summit" fourth edition will be held at the same time in Paris La = Defense=20 from 3 to 6 December.=20
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.
Get all details=20 at:
http://www.upper= side.fr/ipsec02/ipv6etipsec.htm
------=_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 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 writes: Theodore> On Wed, Nov 20, 2002 at 04:37:57PM -0800, Bob Doud wrote: >> > >>>>> "David" == David A Mcgrew writes: >> >> > >> > 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 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 writes: Alex> At 04:37 PM 11/20/2002 -0800, Bob Doud wrote: >> >> 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 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 Cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Adding revised identities to IKEv2 In-Reply-To: <200211181541.gAIFfEte027647@givry.rennes.enst-bretagne.fr> References: <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/AuzN4mu!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 To: "'Paul Koning'" , 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 writes: > > At 04:37 PM 11/20/2002 -0800, Bob Doud wrote: > >> > >> 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: From: "Mukund, Shridhar" To: "'Bob Doud'" , "'Paul Koning'" , 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 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 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/AuzN4mu!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" To: "Paul Koning" Cc: Subject: RE: Counter Mode Security: Analysis and Recommendations Date: Thu, 21 Nov 2002 11:45:51 -0800 Message-ID: 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 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 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 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: 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 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 To: Michael Thomas cc: Stephen Kent , 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: 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" From: Stephen Kent 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: In-Reply-To: References: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10> Date: Thu, 21 Nov 2002 19:21:05 -0500 To: Wes Hardaker From: Stephen Kent 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 > 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 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 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> 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 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 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 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: (Stephen Kent's message of "Thu, 21 Nov 2002 19:21:05 -0500") Message-ID: 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 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" To: Paul Koning 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 To: IP Security List Subject: Re: Counter Mode Security: Attacks, Storage & a Proposal In-Reply-To: <20021122040009.GA549@think.thunk.org> Message-ID: 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 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 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: In-Reply-To: References: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10> Date: Fri, 22 Nov 2002 09:57:09 -0500 To: Wes Hardaker From: Stephen Kent 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 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 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> 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: In-Reply-To: <3DDDCAF1.E2585BF2@bell-labs.com> References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com> <20021121024845.GA792@think.thunk.org> <3DDDCAF1.E2585BF2@bell-labs.com> Date: Fri, 22 Nov 2002 10:27:31 -0500 To: Uri Blumenthal From: Stephen Kent 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: In-Reply-To: <15837.35214.666000.792119@gargle.gargle.HOWL> References: <51C7002B020CD411824E009027C469F7DD337C@cldxch01.hifn.com> <20021121024845.GA792@think.thunk.org> <15837.35214.666000.792119@gargle.gargle.HOWL> Date: Fri, 22 Nov 2002 10:58:07 -0500 To: Paul Koning From: Stephen Kent 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 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: Thread-Topic: SPD policy document/article Thread-Index: AcKSRfrKbqilxHcmSP+GKwHLV1PDRQACM5fg To: , Cc: 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 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" To: "Theodore Ts'o" Cc: Subject: RE: Counter Mode Security: Analysis and Recommendations Date: Fri, 22 Nov 2002 10:30:38 -0800 Message-ID: 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 writes: > > > > > > > > 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: 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. 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: Cc: , Subject: Re: SPD policy document/article References: From: Wes Hardaker 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: ('s message of "Fri, 22 Nov 2002 10:03:29 -0800") Message-ID: 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 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 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" 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-- 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 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> From: Wes Hardaker 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: (Stephen Kent's message of "Fri, 22 Nov 2002 09:57:09 -0500") Message-ID: 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 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" 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" 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 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: In-Reply-To: References: <5.1.0.14.0.20021121190320.023dd090@172.16.1.10> Date: Fri, 22 Nov 2002 14:11:04 -0500 To: Wes Hardaker From: Stephen Kent 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 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: 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" From: Stephen Kent 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" To: , , Cc: 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: 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 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 Cc: "The Purple Streak, Hilarie Orman" , 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> From: Wes Hardaker 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: (Stephen Kent's message of "Fri, 22 Nov 2002 14:32:41 -0500") Message-ID: 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 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" Cc: , , Subject: Re: SPD policy document/article References: <001001c29269$7631c5f0$b101a8c0@cipheroptics.com> From: Wes Hardaker 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: 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" 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 , "'Paul Koning'" From: Alex Alten 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 writes: >> >> At 04:37 PM 11/20/2002 -0800, Bob Doud wrote: >> >> >> >> 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 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 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: From: "Mukund, Shridhar" To: "'Alex Alten'" , Bob Doud , "'Paul Koning'" 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: Thread-Topic: draft-ietf-ipsec-pki-profile-01.txt Thread-Index: AcKJrD5kIu7+QEeqTD+23As5TcUy1AKnKfBg To: 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" To: "Alex Alten" Cc: Subject: RE: Counter Mode Security: Analysis and Recommendations Date: Mon, 25 Nov 2002 06:13:21 -0800 Message-ID: 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: 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" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: 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" To: 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: 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 From: Stephen Kent Subject: RE: Counter Mode Security: Analysis and Recommendations Cc: Bob Doud , "'Paul Koning'" , 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, > >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" To: "'Wes Hardaker'" Cc: , , 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: 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" 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" To: 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" To: "David Faucher" , Subject: RE: Rekey of IKE-SA Date: Mon, 25 Nov 2002 15:01:10 -0500 Message-ID: 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" To: 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" To: 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" To: 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" To: 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" To: "Stephane Beaulieu" , References: 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" To: "David Faucher" ; 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" To: "'David Faucher'" , "'Stephane Beaulieu'" , 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" > To: "David Faucher" ; > 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: 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 . Date: Mon, 25 Nov 2002 15:53:19 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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: 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 . Date: Mon, 25 Nov 2002 15:54:55 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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 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 To: "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 To: venkat cc: "ipsec@lists.tislabs.com" Subject: Re: ISAKMP SA message #1 (proposing attributes/transforms) In-Reply-To: <1038288132.797.24.camel@venkat> Message-ID: 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 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 CC: ipsec@lists.tislabs.com Subject: Re: Draft minutes from the WG meeting References: 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. 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?= 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" To: "Geoffrey Huang" , "'Stephane Beaulieu'" , 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" | > To: "David Faucher" ; | > 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: In-Reply-To: <3DE3510B.7040600@F-Secure.com> References: <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 . Date: Tue, 26 Nov 2002 06:55:58 -0800 To: Ari Huttunen From: Paul Hoffman / VPNC 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 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" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: 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" 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 Reply-To: Radia Perlman - Boston Center for Networking 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 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 To: Russ Housley 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: 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 To: "The Purple Streak, Hilarie Orman" cc: housley@vigilsec.com, IPsec WG Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation In-Reply-To: <200211261723.gAQHNjf29469@localhost.localdomain> Message-ID: 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 , "ipsec@lists.tislabs.com" From: Ramana Yarlagadda 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 To: "'Paul Hoffman / VPNC'" , Ari Huttunen 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 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 CC: "'Paul Hoffman / VPNC'" , 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. 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?= 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?=" To: "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: From: "Housley, Russ" To: "'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 To: rhousley@rsasecurity.com Cc: ipsec@lists.tislabs.com Subject: Re: Counter Mode: Proposed Way Forward References: 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 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?= 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: 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 . Date: Thu, 28 Nov 2002 09:18:56 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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 From: Russ Housley Subject: Re: Counter Mode: Proposed Way Forward Cc: ipsec@lists.tislabs.com In-Reply-To: <15845.1606.961113.340051@pkoning.dev.equallogic.com> References: 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 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 From: Russ Housley Subject: Re: IKEv2 use of HMAC-SHA-1 for Key Derivation Cc: ipsec@lists.tislabs.com In-Reply-To: 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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Radia" == Radia Perlman <- Boston Center for Networking > 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 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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ramana" == Ramana Yarlagadda 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-----