From owner-ipsec Thu Oct 1 01:42:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id BAA29539 for ipsec-outgoing; Thu, 1 Oct 1998 01:40:39 -0400 (EDT) Date: Wed, 30 Sep 1998 22:57:48 -0400 From: Paul Krumviede Subject: Re: Was Re: multiple payloads via "ID_LIST" To: yanfali@corp.hp.com Cc: ipsec@tis.com Reply-to: paul@mci.net Message-id: <3612EFAC.4AB870D2@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.06 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <9809302314.AA25137@hpcc103.corp.hp.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Yan-Fa LI wrote: [some text cut] > For example, wouldn't it be nice if we could make use of External BGP > for Encryption Gateways on the "RED"/Local/Trusted Side of a security > gateway to list all the networks on one side of a VPN and securely share > that information with the other side of the VPN link and vice versa. So > now both gateways have a list of the networks on either side of the VPN, > which BTW they are also propagating with their respective local network > clouds. For the paranoid, this begs the question of authenticating the data carried within BGP. This has been discussed in some of the routing areas (e.g. RPS), although in a different context. There is also the fun question of how much of this type of information one would want to redistribute. > And if the encryptor goes down the traffic can take a different path > rather than black hole the traffic due to the router interaction. > > Branch Site --- Encrypter --- Internet --- Encrypter --- Corporate > Router > > EBGP SOME KIND OF EBGP > ROUTER PROTOCOL > > Now I have a lot less configuration to do. And I've established > security for a group of networks on either side of the link. This configuration imples that the "encrypter" can handle the link layer of the internet connection. For some boxes, and some class of links, that may not be commonly available (particularly high speed links). > Ah you say, well how do we get a link into a useable SPI then since > we're not using destination/source addressing ? Well, it turns out > there's this little used but interesting field called "community" in > EBGP which could be used as a new selector. Then perhaps we could > configure on the encryptor: > > Peer Gateway IP Address > Authentication Required (PreShared/PK) > Community > > The Community would then be an index into what Encryption algorithm for > IPSec and even some basic Source/Dest Address filters and/or TCP/UDP > ports for the collective range of networks. BTW, business partners > could be in this mix, but they could get their own set of SPIs based on > community string and route propagation and so wouldn't necessarily be > using the same tunnels. > > So the idea a Meta-ID would be a way of exchanging this information > between IPSec devices, now we need a standard way of getting this > information in and out of the IPSec device in the first place and back > to a router at either end. Of course if the IPSec device were > a router, this might already be done ;P > > This idea isn't new, I think someone at cisco first proposed it. > > ___________________________________________________________________ > | Bio-Routing: | Electronic Connectivity: | > | | | > | Yan-Fa LI | Phone: ( +1 ) - 650 236 3680 | > | Hewlett-Packard Company | Fax: ( +1 ) - 650 236 3632 | > | Mail Stop: 20CX | | > | 3000 Hanover Street, | Telnet: 236 - 3680 | > | Palo Alto, CA 94304 | Email: yanfali@corp.hp.com | > | USA | | > |____________________________|______________________________________| -paul From owner-ipsec Thu Oct 1 11:08:22 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA01328 for ipsec-outgoing; Thu, 1 Oct 1998 10:59:34 -0400 (EDT) From: Richard Guy Briggs Message-Id: <199810011515.LAA16231@grendel.conscoop.ottawa.on.ca> Subject: Re: VPN Inteoperability Workshop To: fratezi@us.ibm.com (Armando Fratezi) Date: Thu, 1 Oct 1998 11:15:51 -0400 (EDT) Cc: ipsec@tis.com, bob@larribeau.com, rgm@icsa.net In-Reply-To: <5010400027398466000002L062*@MHS> from "Armando Fratezi" at Sep 30, 98 06:54:15 pm X-Mailer: ELM [version 2.4 PL25 PGP8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > The VPN Interoperability Workshop is filling up rapidly. A list of the > attendees is in the attached PDF file. Could this be posted in a non-proprietary format such as html, jpg or txt? > If you have already sent us your applications, check the PDF file to be > sure your application is included. In the aftermath of a crashed hard disk > I think I lost about one dozen email on the afternoon of Friday, September > 19. Send your application to me again if it does not appear on this list. > > If you have not sent your application in yet, do so right away. I expect we > will fill up by the end of the week. You can find an application and more > information about the workshop at http://www.ciug.org. > > Contact me if you have any questions. > > Bob Larribeau > -------------------------------------------------------------------------------- > > > ----------------------------------------------------------- > Bob Larribeau bob@larribeau.com > ISDN Consultant San Francisco > -------------------------------------------------------------------------------- slainte mhath, RGB - -- Just married! see: Richard Guy Briggs -- PGP key available Auto-Free Ottawa! rgb at conscoop dot ottawa dot on dot ca http://www.flora.org/afo/ http://www.conscoop.ottawa.on.ca/rgb/ Ottawa-Rideau Bioregion, Canada Please send all spam to root@127.0.0.1 "We left our footprints in the Earth And punched a hole right through the sky" -- S.Hogarth/J.Helmer(Marillion) -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNhOcpd+sBuIhFagtAQFdigP/aus0p6veRnXLThsp9Y8m2zdRV2m/D60Z q5oqcG0YQUibvQVHzzb0caE+MIyE4ZpHetmrIm7QPHNIMgsEPmse8eWYRJ5SKLjv qlD5Vm/qgLQEhSOPOMNtUdc6UyO2Jrwdq1/PRguM3snq2whlsDQ1RIRPDBzMeHNw hmEPCFKqoEs= =EVCQ -----END PGP SIGNATURE----- From owner-ipsec Thu Oct 1 11:32:02 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA01461 for ipsec-outgoing; Thu, 1 Oct 1998 11:31:36 -0400 (EDT) Message-Id: <199810011446.KAA28961@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 01 Oct 1998 11:48:10 -0400 To: ipsec@tis.com, ca-talk@icsa.net From: Rodney Thayer Subject: ASN-1 DUMPER Program Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Various people have asked me recently for the ASN-1 Dumper program I use at bake-offs. I just ran across an update to it, so here's the story, as I know it. I first ran across this program on an SSL-related mailing list more than two years ago. Then, at the IPSec bake-off in Detroit last year some kind person gave me a copy. This program is at: Read the comments, Peter Gutmann has listed credits for it's geneology and such. I run this on a Win32 box but it seems to be portable code so it should run elsewhere. I encourage those folks out there with hand-tweaked variants of this thing to work with Peter to update this. FYI it still doesn't decode the guts of a subjectAltName field. From owner-ipsec Thu Oct 1 13:20:30 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA01754 for ipsec-outgoing; Thu, 1 Oct 1998 13:15:02 -0400 (EDT) Message-ID: <3613BCD3.D57E3869@redcreek.com> Date: Thu, 01 Oct 1998 10:33:07 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: Daniel Harkins CC: Roy Pereira , Shawn_Mamros@BayNetworks.COM, "Michael C. Richardson" , ipsec@tis.com Subject: Re: multiple payloads via "ID_LIST" References: <199809301552.IAA21393@chip.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins wrote: > > Roy, > > I'm not talking about what policy is, I'm saying why would one want to > do IPSec at such a network aggregation point? One reason is to aggregate the traffic so as to thwart traffic analysis attempts. The packets going into the tunnel might already be encrypted in an end-to-end SA, yet this mechanism still has value. From owner-ipsec Thu Oct 1 15:46:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA02577 for ipsec-outgoing; Thu, 1 Oct 1998 15:43:30 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Location: ATT-0-10130A306F58D211932B00104B6AA8D8-D RAFT-%7E1.TXT In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF42DF12@exchange.timestep.com> Date: Thu, 01 Oct 1998 13:53:33 -0400 (EDT) From: "Dr. M. C. Nelson" To: Tim Jenkins Subject: RE: Re-keying Issues Document Cc: "ipsec@tis.com" , ipsec@icsa.net Sender: owner-ipsec@ex.tis.com Precedence: bulk Since rekeying is current in the discussion, I'd like to take this as an opportunity offer another thought related to rekeying. It is suggested by some that frequent rekeying is a way to provide perfect forward secrecy. I would like to question that hypothesis as it applies to IPSEC, per the assumption that few platforms will have a source of true random numbers. For any software key generator, any new key will be predictable given a knowledge of the algorithm and its inputs. An example would be, K-new = func( seed, T ), where T is any information that varies from one invocation to the next. T could be the previous result or a clock, or what-have-you. In any case T is also predictable (else we're talking about random number hardware). This will be the situation for any rekeying system that needs to run without a source of true random numbers. Despite any amount of rekeying, there is still really only one secret, the seed. In other words, in the absence of a true random number source, the cryptographic problem has only been transformed by "func( seed, T)", such that the secret is now the "seed" rather than the "key". For a brute force attack, the attacker simply chooses a seed and then generates the corresponding key(s). (Parenthetical note: The additional cost in computation to explore a field of seeds, can probably be made trivial, using a suitably designed machine.) >From the above, we see that there is no such thing as software generated perfect forward secrecy. But, the situation might be actually worse than that. Consider the possibility that all of the values "K-new" consitute a group related to "seed". In that case, as we repeatedly generate "K-new" we are sampling that group. Therefore, when we use the numbers to encrypt messages, it might be that we are giving away information about the cryptographic secret. That the messages are IP datagrams (which tend to include some portion of predictable content), would make this even-more-so. (Another parenthetic note: Perhaps ways can be found to attack some specific combinations of rekeying function and cipher.) If this is true, then in the absence of hardware random number generators on both ends, it would seem better to simply start off with a larger key and only rekey when motivated by some security signal and only using reliable sources of random numbers. The need for hardware random number generators at both ends (in this argument) can be seen on considering the D-H algorithm. The common secret is available to either party based on that party's secret and the other party's public key. Regards to all, Mitch Nelson From owner-ipsec Thu Oct 1 20:11:46 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA03265 for ipsec-outgoing; Thu, 1 Oct 1998 20:09:38 -0400 (EDT) From: Dan McDonald Message-Id: <199810012347.QAA17546@kebe.eng.sun.com> Subject: Re: Re-keying Issues Document To: mcnelson@mindspring.com (Dr. M. C. Nelson) Date: Thu, 1 Oct 1998 16:47:18 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: from "Dr. M. C. Nelson" at Oct 1, 98 01:53:33 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Mitch, These are good points, and provide strong arguments for real HW random number generators. One small nit, though... > For any software key generator, any new key will be predictable > given a knowledge of the algorithm and its inputs. An example > would be, > > K-new = func( seed, T ), > > where T is any information that varies from one invocation to the > next. T could be the previous result or a clock, or what-have-you. > In any case T is also predictable (else we're talking about random > number hardware). Is T really predictable? I ask this because if I frequently rekey based on the number of bytes I transmit, T will vary based on a human's input. Human input is not very predictable. If T is something along the lines of a nanosecond timer, the human input differences amplify. I'm not saying we don't need better randomness. Maybe I'm arguing that byte-based lifetimes provide better security, because of the unpredictability of humans using those bytes. Dan From owner-ipsec Thu Oct 1 22:29:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id WAA03517 for ipsec-outgoing; Thu, 1 Oct 1998 22:27:37 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199810012347.QAA17546@kebe.eng.sun.com> Date: Thu, 01 Oct 1998 22:42:53 -0400 (EDT) From: "Dr. M. C. Nelson" To: Dan McDonald Subject: Re: Re-keying Issues Document Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Thank you, I very much appreciate your mention of keying on the number of bytes transmitted. The important point of course is that you found a human input to provide some true randomness. But, of course this won't hold as a generic case. A transaction system for example might always transmit at a constant or quasiconstant rate. The other question that comes to mind, is that it seems that the number of bytes transmitted could often be quite small compared to what we usually demand of our random numbers. In any case, I think the point is that bigger keys are better than re-keying, in the absence of HW RNGs. On 01-Oct-98 Dan McDonald wrote: >Mitch, > >These are good points, and provide strong arguments for real HW random number >generators. One small nit, though... > >> For any software key generator, any new key will be predictable >> given a knowledge of the algorithm and its inputs. An example >> would be, >> >> K-new = func( seed, T ), >> >> where T is any information that varies from one invocation to the >> next. T could be the previous result or a clock, or what-have-you. >> In any case T is also predictable (else we're talking about random >> number hardware). > >Is T really predictable? I ask this because if I frequently rekey based on >the number of bytes I transmit, T will vary based on a human's input. Human >input is not very predictable. If T is something along the lines of a >nanosecond timer, the human input differences amplify. > >I'm not saying we don't need better randomness. Maybe I'm arguing that >byte-based lifetimes provide better security, because of the unpredictability >of humans using those bytes. > >Dan From owner-ipsec Fri Oct 2 03:23:19 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id DAA04159 for ipsec-outgoing; Fri, 2 Oct 1998 03:20:39 -0400 (EDT) From: Kai Martius Organization: Uniklinik TUD To: Rodney Thayer Date: Fri, 2 Oct 1998 09:14:43 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ASN-1 DUMPER Program Reply-to: kai@imib.med.tu-dresden.de CC: ipsec@tis.com In-reply-to: <199810011446.KAA28961@2gn.com> X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, > Various people have asked me recently for the ASN-1 Dumper program I > use at bake-offs. I just ran across an update to it, so here's the > story, as I know it. I first ran across this program on an > SSL-related mailing list more than two years ago. Then, at the > IPSec bake-off in Detroit last year some kind person gave me a copy. > This program is at: > > > > Read the comments, Peter Gutmann has listed credits for it's > geneology and such. I run this on a Win32 box but it seems to be > portable code so it should run elsewhere. Another program containing ASN.1 dump possiblities is Eric Young's SSL implementation, SSLeay (Overkill for just ASN.1-dumping ;-)) at http://www.cryptsoft.com/ . I can't compare it to the above, either. Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # Key and more info (especially IP-security related) see my Homepage # # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Fri Oct 2 08:27:20 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA05350 for ipsec-outgoing; Fri, 2 Oct 1998 08:24:41 -0400 (EDT) Message-ID: <19981002120725.9505.qmail@hotmail.com> X-Originating-IP: [195.89.23.171] From: "Markus Lagler" To: ipsec@tis.com Content-Type: text/plain Date: Fri, 02 Oct 1998 05:07:25 PDT Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi May be this is a silly question but I would like to know if anybody has a real life (Bob, Alies) explanation of ISAKMP. I studied some drafts around ISAKMP and I think I still didn't really get it. Markus ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec Fri Oct 2 09:51:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA05795 for ipsec-outgoing; Fri, 2 Oct 1998 09:49:52 -0400 (EDT) Message-Id: <199810021407.KAA19267@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: ipsec@tis.com Subject: Re: Re-keying Issues Document In-reply-to: Your message of "Thu, 01 Oct 1998 16:47:18 PDT." <199810012347.QAA17546@kebe.eng.sun.com> Date: Fri, 02 Oct 1998 10:07:25 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-ipsec@ex.tis.com Precedence: bulk See RFC 1750. If there is traffic you are trying to secure then it is presumably not known to bad guys and including anything about this taffic in the random number generation should help. And, if you use good techniques, even if the gad guys know that input to your randomness generator, it should be no worse than not inputting it at all. All that is required is that out of all the inputs there be enough entropy. On the other hand, if you have a strong initial seed, you can use the Blum-Blum-Shub or other methods to generate a cryptographcially strong sequence of keys where learning a value in the sequence is of no help in finding earlier or later values (see section 6.3.2 of RFC 1750). This eliminates the need for additional input. Donald From: Dan McDonald Message-Id: <199810012347.QAA17546@kebe.eng.sun.com> To: mcnelson@mindspring.com (Dr. M. C. Nelson) Date: Thu, 1 Oct 1998 16:47:18 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: from "Dr. M. C. Nelson" a t Oct 1, 98 01:53:33 pm >Mitch, > >These are good points, and provide strong arguments for real HW random number >generators. One small nit, though... > >> For any software key generator, any new key will be predictable >> given a knowledge of the algorithm and its inputs. An example >> would be, >> >> K-new = func( seed, T ), >> >> where T is any information that varies from one invocation to the >> next. T could be the previous result or a clock, or what-have-you. >> In any case T is also predictable (else we're talking about random >> number hardware). > >Is T really predictable? I ask this because if I frequently rekey based on >the number of bytes I transmit, T will vary based on a human's input. Human >input is not very predictable. If T is something along the lines of a >nanosecond timer, the human input differences amplify. > >I'm not saying we don't need better randomness. Maybe I'm arguing that >byte-based lifetimes provide better security, because of the unpredictability >of humans using those bytes. > >Dan From owner-ipsec Fri Oct 2 10:28:36 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA05928 for ipsec-outgoing; Fri, 2 Oct 1998 10:27:49 -0400 (EDT) Date: Fri, 2 Oct 1998 10:45:54 -0400 Message-Id: <199810021445.KAA04492@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mcnelson@mindspring.com Cc: ipsec@tis.com Subject: RE: Re-keying Issues Document References: <319A1C5F94C8D11192DE00805FBBADDF42DF12@exchange.timestep.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "M" == M C Nelson writes: M> Since rekeying is current in the discussion, I'd like to take this M> as an opportunity offer another thought related to rekeying. M> It is suggested by some that frequent rekeying is a way to provide M> perfect forward secrecy. I would like to question that hypothesis M> as it applies to IPSEC, per the assumption that few platforms will M> have a source of true random numbers. M> For any software key generator, any new key will be predictable M> given a knowledge of the algorithm and its inputs. An example M> would be, M> K-new = func( seed, T ), M> where T is any information that varies from one invocation to the M> next. T could be the previous result or a clock, or M> what-have-you. In any case T is also predictable (else we're M> talking about random number hardware). This will be the situation M> for any rekeying system that needs to run without a source of true M> random numbers. M> Despite any amount of rekeying, there is still really only one M> secret, the seed.... If your key generator is that poorly done, I would agree. And a hardware generator is clearly a Good Thing -- IF it is done well, which is not at all easy to verify. But in fact you can do a great deal better with software only. There's a good discussion in RFC 1750, as I recall. For example, rather than just "stir in" the current time, or the previous result, you can "gather entropy" on an ongoing basis. There are lots of source of entropy in any computer system, especially in things that have user interfaces, but even in those that do not. While any one piece you stir in may have very little entropy, perhaps even a fraction of a bit, still if you keep at it you will get more. Interestingly enough, this suggests that a system may want to impose or at least recommend an upper bound on the rate of key generation: it does no good to generate N bits of new key if you don't have somewhere near N bits of new entropy by then. In other words, the rekeying volume parameter should have a lower bound, which is implementation dependent. paul From owner-ipsec Fri Oct 2 10:42:49 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA05989 for ipsec-outgoing; Fri, 2 Oct 1998 10:42:19 -0400 (EDT) To: ipsec@ex.tis.com Path: not-for-mail From: daw@cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Re-keying Issues Document Date: 2 Oct 1998 08:04:23 -0700 Organization: ISAAC Group, UC Berkeley Lines: 85 Message-ID: <6v2q1n$9bj$1@joseph.cs.berkeley.edu> References: <319A1C5F94C8D11192DE00805FBBADDF42DF12@exchange.timestep.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk It's true that our key-generation algorithm must be computationally secure, or else the forward secrecy will be compromised. But that's already a requirement -- if the key-generation algorithm is poor (or poorly seeded), the entire system is at risk. See e.g. http://www.ddj.com/ddj/1996/1996_01/wagner.htm for an example of this failure mode. And it's true that finding enough good entropy to really seed these algorithms properly is a little tricky in kernel-mode. But I think it's not infeasible. See http://www.cs.berkeley.edu/~daw/netscape-randomness.html for a collection of links to help with this task. And yes, it's also true that the use of a computationally-secure key-generation algorithm means that we can't achieve information theoretically secure perfect forward secrecy. But that's ok; as long as the key-generator is good, we should be able to achieve computationally- secure forward secrecy; and we're not demanding information-theoretic security in other aspects of the system -- we're not using a one-time pad for encryption, for instance -- so computational security ought to be good enough for key generation too. I think a proper analysis of computationally-secure forward secrecy has to take into account the threat model and the reason why you're seeking forward secrecy. As I see it, there are two goals: one, if a session key is compromised by cryptanalysis, we want to recover; and two, if an intruder manages to break into our IPSEC machine and steal machine state, we want to limit the damage. The former is pretty easy to ensure. Just take a key-generation algorithm which is computationally secure (they're not too hard to build), and seed it well. The latter is somewhat trickier to achieve when you're using a key-generator to ``stretch'' limited amounts of true randomness, so let me concentrate on that for the remainder of the note. The issue is that if the intruder breaks into your machine, he can steal the internal state of the key-generator; you don't want him to be able to deduce the value of all your old keys from that. So the key-generator should periodically hash its internal state with a one-way function (technically, with a function whose output doesn't leak any information on the input). That's not so hard. Second, once the intruder loses access (for whatever reason), you don't want him to be able to ``follow along'' and predict the value of new keys -- that would also be catastrophic. This issue is quite a bit subtler. The obvious fix is to periodically update the state of your key-generator by hashing in some new entropy samples from whatever source you think appropriate. The idea is that eventually you'll accumulate enough new entropy so that the attacker won't be able to follow along any more. But there's a subtle problem with this fix. The same PRNG used to generate keys will probably also be used to generate other quantities -- such as IVs, nonces, and so on -- which are publicly disclosed. Now imagine that you grab an entropy sample, generate an IV, generate a session key, and repeat. If each entropy sample has only 20 bits of unpredictable entropy, which is not unlikely, then an attacker can follow along forever: he tries all 2^{20} possible values for the first sample, checks his guess against the first IV, recovers the first session key, and then repeats. The cost of recovering N session keys is then 2^{20} * N work. (In some cases, this can be reduced to just 2^{10} * N work, by playing some games.) Thus, the system never recovers, even after sampling thousands of bits of good entropy, despite the fact that you'd think it ought to eventually recover somehow. This attack is from some joint work on analysis of key-generators I've done with John Kelsey, Bruce Schneier, and Chris Hall. We called it a ``state compromise extension'' attack in our paper; I think it's pretty general. (See http://www.cs.berkeley.edu/~daw/prngs-fse98.ps for the paper.) Fortunately, the fix is pretty simple. Instead of immediately mixing every entropy sample into the internal state of the key-generator, use some buffering. Buffer the entropy samples until you're pretty sure you've got at least 128 bits of good unpredictable entropy -- or wait for a few hundred bits, just to be on the safe side, since estimating entropy is hard -- and then stir the buffered entropy into the internal state all at once. I do highly recommend using this technique, or some variant of it, in IPSEC key-generators to help reduce the risk of state compromise and to help improve the security of IPSEC's forward secrecy guarantees. From owner-ipsec Fri Oct 2 11:01:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA06116 for ipsec-outgoing; Fri, 2 Oct 1998 11:00:12 -0400 (EDT) Message-Id: <199810021518.LAA27325@postal.research.att.com> To: daw@cs.berkeley.edu (David Wagner) cc: ipsec@ex.tis.com Subject: Re: Re-keying Issues Document Date: Fri, 02 Oct 1998 11:18:06 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Let me add one more point here -- one should be extra-careful if using algorithms that are more sensitive to bad randomness. For example, DSS is a bad choice when you don't have a good random number source -- if an enemy can guess the random value k used in creating a signature, he or she can recover your secret key. From owner-ipsec Fri Oct 2 14:19:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA07335 for ipsec-outgoing; Fri, 2 Oct 1998 14:12:00 -0400 (EDT) Message-Id: From: "Rizwan Mallal" To: "Markus Lagler" , Subject: Re: Date: Fri, 2 Oct 1998 14:29:02 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk O'reilly Associates has new book out on VPN. I just looked at the cover. You might want to give that book a shot. It might contain real life examples of ISAKMP. --Rizwan --------- From: Markus Lagler To: ipsec@tis.com Subject: Date: Friday, October 02, 1998 8:07 AM Hi May be this is a silly question but I would like to know if anybody has a real life (Bob, Alies) explanation of ISAKMP. I studied some drafts around ISAKMP and I think I still didn't really get it. Markus ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec Fri Oct 2 17:16:04 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA07970 for ipsec-outgoing; Fri, 2 Oct 1998 17:14:18 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <6v2q1n$9bj$1@joseph.cs.berkeley.edu> Date: Fri, 02 Oct 1998 17:28:21 -0400 (EDT) From: "Dr. M. C. Nelson" To: (David Wagner) Subject: Re: Re-keying Issues Document Cc: ipsec@ex.tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk David, Perhaps I was overly succinct in my previous note. I am sorry that I can not think of a nice way to say that I think you missed the point. Regards, Mitch Nelson On 02-Oct-98 David Wagner wrote: >It's true that our key-generation algorithm must be computationally >secure, or else the forward secrecy will be compromised. But that's >already a requirement -- if the key-generation algorithm is poor (or >poorly seeded), the entire system is at risk. See e.g. > http://www.ddj.com/ddj/1996/1996_01/wagner.htm >for an example of this failure mode. > >And it's true that finding enough good entropy to really seed these >algorithms properly is a little tricky in kernel-mode. But I think it's >not infeasible. See > http://www.cs.berkeley.edu/~daw/netscape-randomness.html >for a collection of links to help with this task. > >And yes, it's also true that the use of a computationally-secure >key-generation algorithm means that we can't achieve information >theoretically secure perfect forward secrecy. But that's ok; as long as >the key-generator is good, we should be able to achieve computationally- >secure forward secrecy; and we're not demanding information-theoretic >security in other aspects of the system -- we're not using a one-time >pad for encryption, for instance -- so computational security ought to >be good enough for key generation too. > >I think a proper analysis of computationally-secure forward secrecy has >to take into account the threat model and the reason why you're seeking >forward secrecy. As I see it, there are two goals: one, if a session >key is compromised by cryptanalysis, we want to recover; and two, if an >intruder manages to break into our IPSEC machine and steal machine >state, we want to limit the damage. > >The former is pretty easy to ensure. Just take a key-generation >algorithm which is computationally secure (they're not too hard to >build), and seed it well. > >The latter is somewhat trickier to achieve when you're using a >key-generator to ``stretch'' limited amounts of true randomness, so let >me concentrate on that for the remainder of the note. > >The issue is that if the intruder breaks into your machine, he can steal >the internal state of the key-generator; you don't want him to be able >to deduce the value of all your old keys from that. So the >key-generator should periodically hash its internal state with a one-way >function (technically, with a function whose output doesn't leak any >information on the input). That's not so hard. > >Second, once the intruder loses access (for whatever reason), you don't >want him to be able to ``follow along'' and predict the value of new >keys -- that would also be catastrophic. This issue is quite a bit >subtler. The obvious fix is to periodically update the state of your >key-generator by hashing in some new entropy samples from whatever >source you think appropriate. The idea is that eventually you'll >accumulate enough new entropy so that the attacker won't be able to >follow along any more. > >But there's a subtle problem with this fix. The same PRNG used to >generate keys will probably also be used to generate other quantities -- >such as IVs, nonces, and so on -- which are publicly disclosed. Now >imagine that you grab an entropy sample, generate an IV, generate a >session key, and repeat. If each entropy sample has only 20 bits of >unpredictable entropy, which is not unlikely, then an attacker can >follow along forever: he tries all 2^{20} possible values for the first >sample, checks his guess against the first IV, recovers the first >session key, and then repeats. The cost of recovering N session keys is >then 2^{20} * N work. (In some cases, this can be reduced to just >2^{10} * N work, by playing some games.) Thus, the system never >recovers, even after sampling thousands of bits of good entropy, despite >the fact that you'd think it ought to eventually recover somehow. > >This attack is from some joint work on analysis of key-generators I've >done with John Kelsey, Bruce Schneier, and Chris Hall. We called it a >``state compromise extension'' attack in our paper; I think it's pretty >general. (See > http://www.cs.berkeley.edu/~daw/prngs-fse98.ps >for the paper.) > >Fortunately, the fix is pretty simple. Instead of immediately mixing >every entropy sample into the internal state of the key-generator, use >some buffering. Buffer the entropy samples until you're pretty sure >you've got at least 128 bits of good unpredictable entropy -- or wait >for a few hundred bits, just to be on the safe side, since estimating >entropy is hard -- and then stir the buffered entropy into the internal >state all at once. > >I do highly recommend using this technique, or some variant of it, in >IPSEC key-generators to help reduce the risk of state compromise and to >help improve the security of IPSEC's forward secrecy guarantees. From owner-ipsec Fri Oct 2 17:19:12 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA07984 for ipsec-outgoing; Fri, 2 Oct 1998 17:19:01 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199810021445.KAA04492@tonga.xedia.com> Date: Fri, 02 Oct 1998 17:42:07 -0400 (EDT) From: "Dr. M. C. Nelson" To: Paul Koning Subject: RE: Re-keying Issues Document Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Can you suggest where there can be 128 bits of entropy available at the desired intervals, from an arbitrary computing system in the *general case*? On 02-Oct-98 Paul Koning wrote: >>>>>> "M" == M C Nelson writes: > > M> Since rekeying is current in the discussion, I'd like to take this > M> as an opportunity offer another thought related to rekeying. > > M> It is suggested by some that frequent rekeying is a way to provide > M> perfect forward secrecy. I would like to question that hypothesis > M> as it applies to IPSEC, per the assumption that few platforms will > M> have a source of true random numbers. > > M> For any software key generator, any new key will be predictable > M> given a knowledge of the algorithm and its inputs. An example > M> would be, > > M> K-new = func( seed, T ), > > M> where T is any information that varies from one invocation to the > M> next. T could be the previous result or a clock, or > M> what-have-you. In any case T is also predictable (else we're > M> talking about random number hardware). This will be the situation > M> for any rekeying system that needs to run without a source of true > M> random numbers. > > M> Despite any amount of rekeying, there is still really only one > M> secret, the seed.... > >If your key generator is that poorly done, I would agree. And a >hardware generator is clearly a Good Thing -- IF it is done well, >which is not at all easy to verify. > >But in fact you can do a great deal better with software only. >There's a good discussion in RFC 1750, as I recall. > >For example, rather than just "stir in" the current time, or the >previous result, you can "gather entropy" on an ongoing basis. There >are lots of source of entropy in any computer system, especially in >things that have user interfaces, but even in those that do not. >While any one piece you stir in may have very little entropy, perhaps >even a fraction of a bit, still if you keep at it you will get more. > >Interestingly enough, this suggests that a system may want to impose >or at least recommend an upper bound on the rate of key generation: it >does no good to generate N bits of new key if you don't have somewhere >near N bits of new entropy by then. In other words, the rekeying >volume parameter should have a lower bound, which is implementation >dependent. > > paul From owner-ipsec Fri Oct 2 17:25:11 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA08025 for ipsec-outgoing; Fri, 2 Oct 1998 17:25:00 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199810021407.KAA19267@torque.pothole.com> Date: Fri, 02 Oct 1998 17:44:31 -0400 (EDT) From: "Dr. M. C. Nelson" To: "Donald E. Eastlake 3rd" Subject: Re: Re-keying Issues Document Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk On 02-Oct-98 Donald E. Eastlake 3rd wrote: >See RFC 1750. > >If there is traffic you are trying to secure then it is presumably not >known to bad guys and including anything about this taffic in the >random number generation should help. And, if you use good >techniques, even if the gad guys know that input to your randomness >generator, it should be no worse than not inputting it at all. All >that is required is that out of all the inputs there be enough >entropy. 1. Bear in mind that you need to build up something like 128 bits of randomness at the desired intervals. 2. The contents of traffic are not necessarily random. 3. Using the contents for key generation adds another possibility for cryptoanalysis, which will need to be studied on a case by case basis. > >On the other hand, if you have a strong initial seed, you can use the >Blum-Blum-Shub or other methods to generate a cryptographcially strong >sequence of keys where learning a value in the sequence is of no help >in finding earlier or later values (see section 6.3.2 of RFC 1750). >This eliminates the need for additional input. Here, you missed the point. The attacker attacks the seed. In the absence of an additional random input, this is the only secret in the system. Everything else is derived from it. > >Donald > >From: Dan McDonald >Message-Id: <199810012347.QAA17546@kebe.eng.sun.com> >To: mcnelson@mindspring.com (Dr. M. C. Nelson) >Date: Thu, 1 Oct 1998 16:47:18 -0700 (PDT) >Cc: ipsec@tis.com >In-Reply-To: from "Dr. M. C. Nel son" a >t Oct 1, 98 01:53:33 pm > >>Mitch, >> >>These are good points, and provide strong arguments for real HW random number >>generators. One small nit, though... >> >>> For any software key generator, any new key will be predictable >>> given a knowledge of the algorithm and its inputs. An example >>> would be, >>> >>> K-new = func( seed, T ), >>> >>> where T is any information that varies from one invocation to the >>> next. T could be the previous result or a clock, or what-have-you. >>> In any case T is also predictable (else we're talking about random >>> number hardware). >> >>Is T really predictable? I ask this because if I frequently rekey based on >>the number of bytes I transmit, T will vary based on a human's input. Human >>input is not very predictable. If T is something along the lines of a >>nanosecond timer, the human input differences amplify. >> >>I'm not saying we don't need better randomness. Maybe I'm arguing that >>byte-based lifetimes provide better security, because of the unpredictability >>of humans using those bytes. >> >>Dan From owner-ipsec Fri Oct 2 17:28:11 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA08053 for ipsec-outgoing; Fri, 2 Oct 1998 17:28:00 -0400 (EDT) Date: Fri, 2 Oct 1998 17:45:58 -0400 Message-Id: <199810022145.RAA05482@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mcnelson@mindspring.com Cc: ipsec@tis.com Subject: RE: Re-keying Issues Document References: <199810021445.KAA04492@tonga.xedia.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "M" == M C Nelson writes: M> Can you suggest where there can be 128 bits of entropy available M> at the desired intervals, from an arbitrary computing system in M> the *general case*? No, and I don't think anyone can. However, for a given system with properties I can observe, I can make an estimate about the rate at which I can accumulate entropy, and from that I can determine what rate I can support. paul From owner-ipsec Fri Oct 2 18:06:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA08223 for ipsec-outgoing; Fri, 2 Oct 1998 18:06:09 -0400 (EDT) Message-Id: <199810022223.SAA07010@postal.research.att.com> To: "Dr. M. C. Nelson" cc: daw@cs.berkeley.edu (David Wagner), ipsec@ex.tis.com Subject: Re: Re-keying Issues Document Date: Fri, 02 Oct 1998 18:23:41 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , "Dr. M. C. Nelson" wr ites: > David, > > Perhaps I was overly succinct in my previous note. I am sorry that > I can not think of a nice way to say that I think you missed the point. In that case, perhaps you could expand on your previous note? I personally thought that Wagner's reply was quite to the point. Your message (I assume that you're talking about your message of 13:53:33, 1 Oct 1998, , in the archives on ftp.tis.com -- the headers show that that's the note Wagner responded to) complained that (a) the attacker "only" has to guess the original seed, and (b) anything else T that you stir in isn't really random. Wagner responded to point (b), showing (via a Web page with a collection of excellent links) that it is feasible to get a *random enough* T to add to the PRNG. He further observed that one must be careful in how one does this -- an implementation note, if you will. Your central claim is that we all need hardware random number generators. I don't think anyone here would dispute that; certainly I won't. I will note, though, that bad use of hardware RNGs is very dangerous, and may fall victim to some of the same attacks that Wagner and others discuss. The bad thing about a RNG is that you never really know if it's working right. Furthermore, many designs are sensitive to temperature, electrical noise, etc. I assert that a good PRNG seeded by a true RNG is -- in practice -- far more secure than an RNG used directly. (Some may recall the design described by Denning (but later disclaimed) for generating Clipper unit keys. It was based on triple-Skipjack in EDE mode, with (apparently) true-random keys. Some people criticized it for not being based solely on true-random generators. I think that the designers were rather more cautious. I would also note that most true RNGs are rather slow. If you go to that well too often, you'll end up without enough random bits -- see Wagner's point, op cit. The bottom line, though, is this: we have three possible tools to use here: true randomness, a secret seed, and a combining function. We have limited amounts of true randomness available; attached RNGs, though certainly very helpful, are not a substitute for the other two. We can skip the secret seed, if we have enough true randomness; however, the cost of using it is low, and (if it is long enough and secret enough) it may compensate to some extent for the lack of true randomness. Finally, we have the combining function. Wagner's point is that you have to be very careful in how you use such functions, or you won't get the output strength desired. From owner-ipsec Fri Oct 2 18:14:32 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA08238 for ipsec-outgoing; Fri, 2 Oct 1998 18:14:03 -0400 (EDT) Message-ID: <6297CD447F92D11199F5006097BA9D1E2002CE@tbu1.hifn.com> From: Raouf Eldeeb To: ipsec@tis.com Subject: RE: VPN books Date: Fri, 2 Oct 1998 15:36:34 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk The O'Reilly book on VPN is really not very good. The book by Ford and Baum: Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption is much better For a simplified and accurate expose, you're better off with the following: http://www.redbooks.ibm.com/SG245201/sg240018.html together with http://www.redbooks.ibm.com/SG245201/sg240007.html Raouf Eldeeb E-mail: rledeeb@hifn.com Hi/fn Tel: (408) 399-3578 -----Original Message----- From: Rizwan Mallal [SMTP:rmallal@raptor.com] Sent: Friday, October 02, 1998 11:29 AM To: Markus Lagler; ipsec@tis.com Subject: Re: O'reilly Associates has new book out on VPN. I just looked at the cover. You might want to give that book a shot. It might contain real life examples of ISAKMP. --Rizwan From owner-ipsec Sat Oct 3 11:44:19 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA10085 for ipsec-outgoing; Sat, 3 Oct 1998 11:39:05 -0400 (EDT) Message-ID: <01BDEE18.5D5A32A0.mark_jones3@hp.com> From: Mark Jones To: "'richdr@microsoft.com'" Cc: "'ipsec@tis.com'" Subject: Query Results Date: Fri, 2 Oct 1998 15:21:43 -0700 Organization: VSET X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't see this as an inconsistency. You should not copy the options from the inner header to the outer header. But the outer header may contain options, depending on the local node's configuration. Rich > -----Original Message----- > From Msg 170, Level 15, State 1 Line 1: Incorrect syntax near 't see this as an inconsistency. You should not copy the options from the inner header to the outer header. But the outer header may contain options, depending on the local node'. (Rows Affected: 0) From owner-ipsec Sat Oct 3 11:44:22 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA10083 for ipsec-outgoing; Sat, 3 Oct 1998 11:39:04 -0400 (EDT) From: Charles Kunzinger To: Subject: IKE: minor clarification suggestions Message-ID: <5040100023235200000002L002*@MHS> Date: Fri, 2 Oct 1998 17:15:29 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk When I recently looked at the latest IKE draft (-08), I noticed two minor areas that might be made a little bit clearer in furture updates: 1. There are four methods described for authentication within Phase 1, and the content of Main Mode "second exchange"( messages 3 and 4) differs from case to case. The example formats given in Section 7.1, however, illustrate only the format for "pre-shared key" or "digital signature", showing only the KE and nonce fields. It might be worthwhile to expand the examples in this section to cover the other two cases, where "IDs" , for example, are also mandatory in these messages. Or maybe just a few words to say that the illustrated formats only cover some of the allowable methods? 2. In Sections 5.5 where we describe Phase 2 Quick Mode, we use the same notation for nonces (Ni, Nr)as in used in sections 5.1-5.4 for Phase 1 negotiations. Since, for example, the Ni in Phase 2 is chosen separately for each execution of Quick Mode and is not the same as the Ni used in the Phase 1 negotiations, would it be worthwile to have a different notation that distinguishes between them? ___________________________ Charles A Kunzinger (kunzinge@us.ibm.com) TCP/IP Technology Management, JDGA/501, RTP Phone: Tie 8-444-4142 , External 1-919-254-4142 Fax: Tie 8-444-6243, External 1-919-254-6243 VM: IBMUSM27(KUNZINGE) From owner-ipsec Sat Oct 3 11:44:24 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA10084 for ipsec-outgoing; Sat, 3 Oct 1998 11:39:05 -0400 (EDT) Date: Fri, 2 Oct 1998 14:08:42 -0700 (PDT) From: Dennis Glatting Message-Id: <199810022108.OAA06555@btw.plaintalk.bellevue.wa.us> To: ipsec@tis.com, mlagler@hotmail.com, rmallal@raptor.com Subject: Re: In-Reply-To: Sender: owner-ipsec@ex.tis.com Precedence: bulk I read that book. It's crap. Their idea of VPN is PPTP and AltaVista. IPsec is mentioned, but the book's focus is the authors' experience with the previously mentioned technologies. The authors, if I remember correctly, are an ISP. It's one of the few books I threw away. -dpg From owner-ipsec Sat Oct 3 15:19:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA10887 for ipsec-outgoing; Sat, 3 Oct 1998 15:12:03 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81369@RED-MSG-50> Date: Fri, 2 Oct 1998 15:30:19 -0400 To: IPsec WG List From: Stephen Kent Subject: RE: inbound policy verification Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, I'm sorry for any confusion resulting from the note in section 5.2. The inbound SPD is ordered, just like the outbound SPD. The destination address, SPI, and security protocol type are used to select the proper SAD (not SPD) entry to process the packet, e.g., decryption and authentication. Then the selectors are checked based on the SAD (not SPD) entry. At this point we know the packet is from an authorized origin (of auth has been selected) and that the selectors in the appropriate header match those specified for this SA. Only after this processing is there an SPD check. That check ensures that, if multiple IPsec protocols have been applied, that they have all been applied in the right order, and if only one was applied, then only one was intended. That way one can detect stripping off a tunnel mode AH, for example. Note that almost all of the processing we see now is for single layers of IPsec, in which this should not be an issue. Only two cases of required configurations yields multiple IPsec headers that are parsed at the same point: AH then ESP in transport mode or AH or ESP in tunnel, followed by AH or ESP transport. These are sufficiently simple that one could express the required conbinations in the SAD, without referebce to the SPD. The searching or linking to the SPD supports more elaborate protocol combinations, for which support is not required. The text suggests back pointers to the SPD as a way to make the mapping work quickly (in these later cases), and allows an ordered search as a simplier but less efficient alternative. Perhaps we need to revisit the viability of this alternative. In any case, the concerns cited in recent messages don't seem to match the required processing, as described in 5.2. Steve From owner-ipsec Sat Oct 3 17:19:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA11122 for ipsec-outgoing; Sat, 3 Oct 1998 17:16:05 -0400 (EDT) Message-ID: <36169816.9C068F0D@cs.umass.edu> Date: Sat, 03 Oct 1998 17:33:10 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, University of Massachusetts at Amherst X-Mailer: Mozilla 4.03 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: IPsec WG List CC: Richard Draves Subject: Re: inbound policy verification References: <4D0A23B3F74DD111ACCD00805F31D8100AF81369@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Richard Draves writes: > Lewis, I don't understand one aspect of your proposed work-around for my > example. If the administrator creates separate policies in the inbound SPD > for each of the hosts X2, Y2, Z2, etc in network N2, then won't this mean > that each of the hosts will need a different SA to send packets to H1? > Whereas in my example, all the hosts in N2 (except H2) could share an SA. > (Using "take-from-policy" for the source address selector with value N2 in > the second policy in the inbound SPD.) Right. This can be mitigated to some extent by specifying multiple hosts in a single selector using a _SUBNET or _RANGE ID Type (c.f. the IPsec DOI). But I agree it would be convenient to be able to specify a more or less arbitrary set of "atomic" IDs as the selector for a single SA. See the recent/current thread with Subject: Re: multiple payloads via "ID_LIST" for discussion of work on this issue. > Thanks, > Rich -Lewis From owner-ipsec Sat Oct 3 20:05:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA11449 for ipsec-outgoing; Sat, 3 Oct 1998 20:03:04 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81395@RED-MSG-50> From: Richard Draves To: "'Stephen Kent'" Cc: IPsec WG List Subject: RE: inbound policy verification Date: Sat, 3 Oct 1998 17:21:08 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk [Hmm, I received your message more than 24 hours after it was sent. I observed similar delay with Lewis's recent message - the copy sent directly to me arrived much sooner than the copy via the list.] > I'm sorry for any confusion resulting from the note in > section 5.2. The inbound SPD is ordered, just like the outbound SPD. Steve, I apologize for being slow. In what sense is the inbound SPD ordered? The note in section 5.2.1 says quite explicitly that my implementation should not stop if the first policy in the inbound SPD with selectors that match the incoming packet would result in rejection, but should keep searching. So any ordering of the inbound SPD will result in the same packets being accepted and rejected. So it is effectively not ordered. I've read and reread this subsection and I keep coming back to this conclusion. Thanks, Rich From owner-ipsec Sun Oct 4 00:16:51 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id AAA12841 for ipsec-outgoing; Sun, 4 Oct 1998 00:14:54 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199810022223.SAA07010@postal.research.att.com> Date: Sun, 04 Oct 1998 00:28:33 -0400 (EDT) From: "Dr. M. C. Nelson" To: Steve Bellovin Subject: Re: Re-keying Issues Document Cc: ipsec@ex.tis.com, (David Wagner) Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, The points in my letter (concerning rekeying) were (1) for a software key generator there is really only one secret. (2) repeated generation of keys from that single secret, can give away information about the secret. (3) therefore, it is perhap better to simply use a very good secret to begin with and only change it with proper true random input or when warranted, or perhaps otherwise, infrequently. A discussion of how one finds some source of randomness is not to the point. Thats not the case being discussed. Also, the claim that one can rely on adequate randomness being available in the general case without hardware specific to that purpose, is hard to believe. There are lots of systems that deal with lots of nearly repetitive or predictable stuff. The banking and financial industries are full of them. Mitch Nelson On 02-Oct-98 Steve Bellovin wrote: >In message , "Dr. M. C. Nelson" wr >ites: >> David, >> >> Perhaps I was overly succinct in my previous note. I am sorry that >> I can not think of a nice way to say that I think you missed the point. > >In that case, perhaps you could expand on your previous note? I >personally thought that Wagner's reply was quite to the point. > >Your message (I assume that you're talking about your message of >13:53:33, 1 Oct 1998, , in >the archives on ftp.tis.com -- the headers show that that's the note >Wagner responded to) complained that (a) the attacker "only" has to >guess the original seed, and (b) anything else T that you stir in isn't >really random. Wagner responded to point (b), showing (via a Web page >with a collection of excellent links) that it is feasible to get a >*random enough* T to add to the PRNG. He further observed that one >must be careful in how one does this -- an implementation note, if you >will. > >Your central claim is that we all need hardware random number >generators. I don't think anyone here would dispute that; certainly I >won't. I will note, though, that bad use of hardware RNGs is very >dangerous, and may fall victim to some of the same attacks that Wagner >and others discuss. > >The bad thing about a RNG is that you never really know if it's working >right. Furthermore, many designs are sensitive to temperature, >electrical noise, etc. I assert that a good PRNG seeded by a true RNG >is -- in practice -- far more secure than an RNG used directly. (Some >may recall the design described by Denning (but later disclaimed) for >generating Clipper unit keys. It was based on triple-Skipjack in EDE >mode, with (apparently) true-random keys. Some people criticized it >for not being based solely on true-random generators. I think that the >designers were rather more cautious. > >I would also note that most true RNGs are rather slow. If you go to >that well too often, you'll end up without enough random bits -- see >Wagner's point, op cit. > >The bottom line, though, is this: we have three possible tools >to use here: true randomness, a secret seed, and a combining function. >We have limited amounts of true randomness available; attached RNGs, >though certainly very helpful, are not a substitute for the other >two. We can skip the secret seed, if we have enough true randomness; >however, the cost of using it is low, and (if it is long enough and >secret enough) it may compensate to some extent for the lack of >true randomness. Finally, we have the combining function. Wagner's >point is that you have to be very careful in how you use such functions, >or you won't get the output strength desired. From owner-ipsec Sun Oct 4 00:16:53 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id AAA12833 for ipsec-outgoing; Sun, 4 Oct 1998 00:14:08 -0400 (EDT) Message-ID: From: Bryan Gleeson To: ipsec@tis.com, vpn@BayNetworks.COM Subject: FW: I-D ACTION:draft-gleeson-vpn-framework-00.txt Date: Fri, 2 Oct 1998 14:48:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDEE4E.56E1F2B0" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BDEE4E.56E1F2B0 Content-Type: text/plain See below for details on the VPN Framework Draft that was mentioned a little while back on these mailing lists. The primary purpose of the Draft is to provide a framework and context for protocol extensions needed to better support VPNs, and also to encourage the development of common mechanisms that can be used as building blocks to provide a variety of different types of VPNs. All comments are welcome. Bryan Gleeson Shasta Networks > -----Original Message----- > From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] > Sent: Friday, October 02, 1998 7:31 AM > Subject: I-D ACTION:draft-gleeson-vpn-framework-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A Framework for IP Based Virtual Private > Networks > Author(s) : B. Gleeson, J. Heinanen, G. Armitage > Filename : draft-gleeson-vpn-framework-00.txt > Pages : 47 > Date : 01-Oct-98 > > This document describes a framework for virtual private networks > (VPN) running across IP backbones. It discusses the various > different types of VPNs, their respective requirements, and > proposes > specific mechanisms that could be used to implement each type of > VPN > using existing or proposed specifications. The objective of this > Draft is to serve as a framework for related protocol development > in > order to develop the full set of specifications required for > widespread deployment of interoperable VPN solutions. > > Internet-Drafts are 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-gleeson-vpn-framework-00.txt". > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-drafts/draft-gleeson-vpn-framework-00.txt > > Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > > Internet-Drafts are also available by mail. > > Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-gleeson-vpn-framework-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. <> ------ =_NextPart_000_01BDEE4E.56E1F2B0 Content-Type: message/rfc822 Content-Description: Untitled Attachment To: Subject: Date: Fri, 2 Oct 1998 10:46:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BDEE4E.56E1F2B0" ------ =_NextPart_002_01BDEE4E.56E1F2B0 Content-Type: text/plain ------ =_NextPart_002_01BDEE4E.56E1F2B0 Content-Type: application/octet-stream; name="ATT01819.txt" Content-Disposition: attachment; filename="ATT01819.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981001105242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gleeson-vpn-framework-00.txt ------ =_NextPart_002_01BDEE4E.56E1F2B0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-gleeson-vpn-framework-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------ =_NextPart_002_01BDEE4E.56E1F2B0-- ------ =_NextPart_000_01BDEE4E.56E1F2B0-- From owner-ipsec Sun Oct 4 09:29:53 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA13672 for ipsec-outgoing; Sun, 4 Oct 1998 09:26:02 -0400 (EDT) Message-Id: <199810041343.JAA23494@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: ipsec@tis.com Subject: Re: Re-keying Issues Document In-reply-to: Your message of "Fri, 02 Oct 1998 17:44:31 EDT." Date: Sun, 04 Oct 1998 09:43:34 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "Dr. M. C. Nelson" Message-ID: In-Reply-To: <199810021407.KAA19267@torque.pothole.com> Date: Fri, 02 Oct 1998 17:44:31 -0400 (EDT) To: "Donald E. Eastlake 3rd" Cc: ipsec@tis.com >On 02-Oct-98 Donald E. Eastlake 3rd wrote: >>See RFC 1750. >> >>If there is traffic you are trying to secure then it is presumably not >>known to bad guys and including anything about this taffic in the >>random number generation should help. And, if you use good >>techniques, even if the gad guys know that input to your randomness >>generator, it should be no worse than not inputting it at all. All >>that is required is that out of all the inputs there be enough >>entropy. > >1. Bear in mind that you need to build up something like 128 bits >of randomness at the desired intervals. Only if you need all new randomness. Every single bit of entroy you add helps. >2. The contents of traffic are not necessarily random. If the message conveys no information, why are you sending it? Even if some messages are like that, those which are not still add entropy making prediction by the bad guys harder. >3. Using the contents for key generation adds another possibility >for cryptoanalysis, which will need to be studied on a case by >case basis. It's not "using the contents for key generation". I'm not talking about some autokey system. It's using the contents to add entropy to your pool from which the key is generated. Assuming you hash it in using a modern strong one-way function like SHA1 as the basic building block, I don't see the problem. If you have a method of deriving a key from your entropy pool that includes a functions which inverts SHA1, I'd like to know about it. >>On the other hand, if you have a strong initial seed, you can use the >>Blum-Blum-Shub or other methods to generate a cryptographcially strong >>sequence of keys where learning a value in the sequence is of no help >>in finding earlier or later values (see section 6.3.2 of RFC 1750). >>This eliminates the need for additional input. > >Here, you missed the point. The attacker attacks the seed. In the >absence of an additional random input, this is the only secret in >the system. Everything else is derived from it. Well, I was reading my mail in inverse chronological order so I hadn't seen your original message and was just responding to the message below. Donald >>From: Dan McDonald >>Message-Id: <199810012347.QAA17546@kebe.eng.sun.com> >>To: mcnelson@mindspring.com (Dr. M. C. Nelson) >>Date: Thu, 1 Oct 1998 16:47:18 -0700 (PDT) >>Cc: ipsec@tis.com >>In-Reply-To: from "Dr. M. C. Nel >son" a >>t Oct 1, 98 01:53:33 pm >> >>>Mitch, >>> >>>These are good points, and provide strong arguments for real HW random number >>>generators. One small nit, though... >>> >>>> For any software key generator, any new key will be predictable >>>> given a knowledge of the algorithm and its inputs. An example >>>> would be, >>>> >>>> K-new = func( seed, T ), >>>> >>>> where T is any information that varies from one invocation to the >>>> next. T could be the previous result or a clock, or what-have-you. >>>> In any case T is also predictable (else we're talking about random >>>> number hardware). >>> >>>Is T really predictable? I ask this because if I frequently rekey based on >>>the number of bytes I transmit, T will vary based on a human's input. Human >>>input is not very predictable. If T is something along the lines of a >>>nanosecond timer, the human input differences amplify. >>> >>>I'm not saying we don't need better randomness. Maybe I'm arguing that >>>byte-based lifetimes provide better security, because of the unpredictability >>>of humans using those bytes. >>> >>>Dan From owner-ipsec Sun Oct 4 13:37:37 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA14150 for ipsec-outgoing; Sun, 4 Oct 1998 13:32:01 -0400 (EDT) Date: Sun, 4 Oct 1998 13:50:22 -0400 (EDT) From: Henry Spencer To: "Dr. M. C. Nelson" cc: ipsec@ex.tis.com Subject: Re: Re-keying Issues Document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Also, the claim that one can rely on adequate randomness > being available in the general case without hardware > specific to that purpose, is hard to believe. There are > lots of systems that deal with lots of nearly repetitive or > predictable stuff... Even so, they do have their own hardware, and the details of its behavior are often not entirely predictable -- there is some useful randomness lurking in the low-order bits. The key word here is "adequate"; some randomness is definitely available, given cleverness, but whether it's enough depends on your needs. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Sun Oct 4 14:30:57 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA14256 for ipsec-outgoing; Sun, 4 Oct 1998 14:29:15 -0400 (EDT) Message-Id: <199810041848.OAA23578@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: ipsec@ex.tis.com Subject: Re: Re-keying Issues Document In-reply-to: Your message of "Sun, 04 Oct 1998 00:28:33 EDT." Date: Sun, 04 Oct 1998 14:48:32 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "Dr. M. C. Nelson" Message-ID: In-Reply-To: <199810022223.SAA07010@postal.research.att.com> Date: Sun, 04 Oct 1998 00:28:33 -0400 (EDT) >Steve, > >The points in my letter (concerning rekeying) were > > (1) for a software key generator there is really > only one secret. There is no reason why you can't continually be adding entropy to your secret pool so I don't see that this need be true in a practical sense. > (2) repeated generation of keys from that single > secret, can give away information about the secret. They "can". But cryptographically strong techniques, such as the Blum Blum Shub method, provably do not, although they are computationally intensive. > (3) therefore, it is perhap better to simply use > a very good secret to begin with and only change > it with proper true random input or when warranted, > or perhaps otherwise, infrequently. > >A discussion of how one finds some source of randomness >is not to the point. Thats not the case being discussed. > >Also, the claim that one can rely on adequate randomness >being available in the general case without hardware >specific to that purpose, is hard to believe. There are >lots of systems that deal with lots of nearly repetitive or >predictable stuff. The banking and financial industries >are full of them. I don't know what you mean by "the general case" but if your machine has a disk drive, for example, you can generate true randomness, although not very quickly. >Mitch Nelson Donald >On 02-Oct-98 Steve Bellovin wrote: >>In message , "Dr. M. C. Nelson" wr >>ites: >>> David, >>> >>> Perhaps I was overly succinct in my previous note. I am sorry that >>> I can not think of a nice way to say that I think you missed the point. >> >>In that case, perhaps you could expand on your previous note? I >>personally thought that Wagner's reply was quite to the point. >> >>Your message (I assume that you're talking about your message of >>13:53:33, 1 Oct 1998, , in >>the archives on ftp.tis.com -- the headers show that that's the note >>Wagner responded to) complained that (a) the attacker "only" has to >>guess the original seed, and (b) anything else T that you stir in isn't >>really random. Wagner responded to point (b), showing (via a Web page >>with a collection of excellent links) that it is feasible to get a >>*random enough* T to add to the PRNG. He further observed that one >>must be careful in how one does this -- an implementation note, if you >>will. >> >>Your central claim is that we all need hardware random number >>generators. I don't think anyone here would dispute that; certainly I >>won't. I will note, though, that bad use of hardware RNGs is very >>dangerous, and may fall victim to some of the same attacks that Wagner >>and others discuss. >> >>The bad thing about a RNG is that you never really know if it's working >>right. Furthermore, many designs are sensitive to temperature, >>electrical noise, etc. I assert that a good PRNG seeded by a true RNG >>is -- in practice -- far more secure than an RNG used directly. (Some >>may recall the design described by Denning (but later disclaimed) for >>generating Clipper unit keys. It was based on triple-Skipjack in EDE >>mode, with (apparently) true-random keys. Some people criticized it >>for not being based solely on true-random generators. I think that the >>designers were rather more cautious. >> >>I would also note that most true RNGs are rather slow. If you go to >>that well too often, you'll end up without enough random bits -- see >>Wagner's point, op cit. >> >>The bottom line, though, is this: we have three possible tools >>to use here: true randomness, a secret seed, and a combining function. >>We have limited amounts of true randomness available; attached RNGs, >>though certainly very helpful, are not a substitute for the other >>two. We can skip the secret seed, if we have enough true randomness; >>however, the cost of using it is low, and (if it is long enough and >>secret enough) it may compensate to some extent for the lack of >>true randomness. Finally, we have the combining function. Wagner's >>point is that you have to be very careful in how you use such functions, >>or you won't get the output strength desired. From owner-ipsec Mon Oct 5 09:26:01 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA17160 for ipsec-outgoing; Mon, 5 Oct 1998 09:21:05 -0400 (EDT) Date: Mon, 5 Oct 1998 10:39:21 -0300 (ADT) From: James Dean Moore X-Sender: moore@borg To: Dennis Glatting cc: ipsec@tis.com, mlagler@hotmail.com, rmallal@raptor.com Subject: Re: ISAKMP In-Reply-To: <199810022108.OAA06555@btw.plaintalk.bellevue.wa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk The book mentioned below is weak, but I don't think is the new one mentioned in the previous 'mails. "Virtual Private Networks" Scott,c et al. (O'Reiley,98) is not a good primer to VPNs in general, and expecially not IPSec implementations. -James- On Fri, 2 Oct 1998, Dennis Glatting wrote: > I read that book. It's crap. Their idea of VPN is PPTP and AltaVista. > IPsec is mentioned, but the book's focus is the authors' experience > with the previously mentioned technologies. The authors, if I > remember correctly, are an ISP. > > It's one of the few books I threw away. > > > -dpg > > From owner-ipsec Mon Oct 5 09:29:46 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA17223 for ipsec-outgoing; Mon, 5 Oct 1998 09:29:33 -0400 (EDT) Date: Mon, 5 Oct 1998 09:48:42 -0400 Message-Id: <199810051348.JAA11859@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mcnelson@mindspring.com Cc: ipsec@ex.tis.com Subject: Re: Re-keying Issues Document References: <199810022223.SAA07010@postal.research.att.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "M" == M C Nelson writes: > Steve, The points in my letter (concerning rekeying) were > (1) for a software key generator there is really only one secret. That's true. If ALL you use is a key stream extender without ever stirring in any entropy. Of course, if someone builds a key generator without ever reading RFC 1750, there's not much we can do to help him. > (2) repeated generation of keys from that single secret, can give > away information about the secret. > (3) therefore, it is perhap better to simply use a very good > secret to begin with and only change it with proper true random > input or when warranted, or perhaps otherwise, infrequently. > A discussion of how one finds some source of randomness is not to > the point. Thats not the case being discussed. So what is the case being discussed? The one where someone doesn't do what RFC 1750 recommends, but instead simply extends a bitstream without ever stirring in randomness? I suppose it might be useful to say "don't do that". I don't see much sense in spending any more words than that explaining how to "improve" on such a fundamentally broken approach. > Also, the claim that one can rely on adequate randomness being > available in the general case without hardware specific to that > purpose, is hard to believe. There are lots of systems that deal > with lots of nearly repetitive or predictable stuff. The banking > and financial industries are full of them. I don't remember such a claim being made. If you're referring to my comments, I was referring to specific analysis of specific systems. As Don pointed out, if it has a disk it has a random number generator. And my observation is that even systems with no disk may have low rate sources of entropy. At least, the one analyzed does. If your point is that it is possible to build systems where no adequate source of entropy is available, I agree that this might be so. If you have such a system, you can't build an adequate implementation of IKE on it until you change the hardware to supply a source of entropy. But if your claim is that the only useable source of entropy is devices purpose-built for the specific job of generating "true random numbers" I believe you will find ample data contradicting that, in places such as RFC 1750 and elsewhere. paul From owner-ipsec Mon Oct 5 12:16:38 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA18032 for ipsec-outgoing; Mon, 5 Oct 1998 12:14:27 -0400 (EDT) From: Kai Martius Organization: Uniklinik TUD To: ipsec@tis.com, linux-ipsec@clinet.fi Date: Mon, 5 Oct 1998 18:07:45 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: IKE Analysis / New E-IKE draft Reply-to: kai@imib.med.tu-dresden.de X-mailer: Pegasus Mail for Windows (v2.54) Message-ID: Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, there are some news on my website: - A little paper dealing with IKE analysis Abstract: This paper takes a closer look on the authentication and key generation mechanisms of IKE and gives some ideas on how it is designed from the cryptographic point of view. The first part shows basic de-sign principles of cryptographic protocols and their use in IKE. It is intended to provide interested people with the ideas and rationals behind this sort of protocol. Especially implementors, who "want to know what they do" could find some interesting information. The second part is more "scientific" providing a logic analysis by a derivation of the famous BAN logic. This kind of logic is a way to really prove the fulfillment of requirements under certain conditions (whereas it has some gaps the way it is shown here, I suppose). However, neither this paper is intended to be published at any confe-rence or so, nor it claims to be complete or even provide a strong prove in a scientific sense. It is open to improvements, comments and suggestions. ********* A new version of my E-IKE draft and an implementation of it. Table of Contents 1. Abstract ................................................... 2 2. Terms and Definitions ...................................... 3 3. Discussion ................................................. 3 3.1 The Problem ............................................. 3 3.2 Two Appoaches ........................................... 5 3.2.1 Separated Policy Management ........................ 5 3.2.2 Extending IKE ...................................... 5 4. Pre-Requisites ............................................. 6 4.1 Design Objectives ....................................... 6 4.2 Gateway Discovery ....................................... 7 4.3 Initial Message Routing ................................. 7 4.4 IKE+ - A Protocol using complete IKE Exchanges .......... 8 5. E-IKE: A Protocol using an IKE-secured Channel ............. 9 5.1 Message format ......................................... 10 5.1.1 Structure ......................................... 10 5.1.2 Proxy Authentication .............................. 11 5.1.3 Authentication fields / Authentication Methods .... 12 5.1.4 Using ISAKMP Payloads to build the Msg. Structure . 13 5.2 Message flow ........................................... 15 5.2.1 First Message Upflow (I->R) ....................... 16 5.2.2 First Message Downflow (R->I) ..................... 17 5.2.3 Next Message Upflow (I->R) ........................ 19 5.2.4 Next Message Downflow (R->I) ...................... 21 5.3 Message Matrix ......................................... 23 5.4 Key Derivation ......................................... 24 5.5 Restrictions ........................................... 25 5.5.1 Overlapping Tunnels ............................... 25 5.5.2 Rekeying / Fault Management ....................... 26 5.6 Comparison ............................................. 26 6. Local Security Management ................................. 28 6.1 SA bundling ............................................ 29 6.2 Asymmetric SAs ......................................... 29 6.3 Security policy management on gateways and end nodes ... 29 7. Security Considerations ................................... 31 Appendix A Pseudo Code Notation .............................. 32 A.1 - Symbolic functions, Variables and Identifiers ........ 32 A.2 - Pseudo Code of IKE+ .................................. 35 A.3 - Pseudo Code of E-IKE ................................. 35 Appendix B - Payload Explosion Example ....................... 42 Appendix C - Examples ........................................ 44 C.1 Remote Access .......................................... 45 C.2 VPN .................................................... 46 1. Abstract [MSST98] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independent; that is, it is designed to support many different key exchanges. [HC98] (IKE) describes a protocol using part of Oakley [Orm96] and part of SKEME [Kra96] in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. IKE is designed to authenticate endpoints and negotiate security associations (and necessary key material) between *two* parties. This document describes an extended protocol (E-IKE) based on IKE which allows involving more than two parties in the authentication process and key exchange. It supports extended SA management / ~ establishment by applying security policies of the involved parties during the protocol. Therefore it is a kind of a combined policy and key management protocol. ************ The URL is: http://www.imib.med.tu-dresden.de/imib/Internet/ike/index.html Feel free to download the stuff and send me comments. I've setup a mailinglist to discuss things on E-IKE for interested people. Subscription information on the Webpage, too. Kai # Kai Martius # # Dpt. of Medical CS and Biometrics / Dresden University of Technology # # PGP Fingerprint: to be compared after download of my key # # Key and more info (especially IP-security related) see my Homepage # # http://www.imib.med.tu-dresden.de/imib/personal/kai.html # From owner-ipsec Mon Oct 5 17:44:04 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA19477 for ipsec-outgoing; Mon, 5 Oct 1998 17:40:55 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF813A1@RED-MSG-50> From: Richard Draves To: "'IPsec'" Subject: autoconfiguration Date: Mon, 5 Oct 1998 14:59:01 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk [I suspect that the list has already discussed this issue, and I haven't read far enough back in the archives to find the discussion. I hope I'm raising a new perspective on the issue wrt IPv6.] I'm concerned about the provision in the security architecture spec (eg see section 5 first paragraph) that "If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded." I understand this to mean that a compliant implementation must be manually configured when it first boots. Automatic configuration is not possible because that would require network communication, which is not allowed. In particular, this would seem to conflict with IPv6's stateless address autoconfiguration. Would it be permissible for a compliant IPv6 implementation to have a default SPD that allows communication via link-local addresses to bypass IPsec, to support auto-configuration? Once the implementation has automatically configured addresses, I imagine that the implementation might proceed to configure the SPD from a network service. Note that I'm thinking about the default case of an implementation booting for the first time without any prior configuration. In some cases (like a mobile node visiting an untrusted link) an implementation will want to be more careful. Thanks, Rich From owner-ipsec Mon Oct 5 20:02:58 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA19927 for ipsec-outgoing; Mon, 5 Oct 1998 20:01:55 -0400 (EDT) From: Dan McDonald Message-Id: <199810052356.QAA04137@kebe.eng.sun.com> Subject: Re: autoconfiguration To: richdr@microsoft.com (Richard Draves) Date: Mon, 5 Oct 1998 16:56:30 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF813A1@RED-MSG-50> from "Richard Draves" at Oct 5, 98 02:59:01 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I'm concerned about the provision in the security architecture spec (eg see > section 5 first paragraph) that "If no policy is found in the SPD that > matches the packet (for either inbound or outbound traffic), the packet MUST > be discarded." I never took that literally. (And do you know how that affects performance? Per-node policy checking is slow, even with a spiffy lookup.) But that doesn't answer your question... > I understand this to mean that a compliant implementation must be manually > configured when it first boots. Automatic configuration is not possible > because that would require network communication, which is not allowed. > > In particular, this would seem to conflict with IPv6's stateless address > autoconfiguration. Yes. > Would it be permissible for a compliant IPv6 implementation to have a > default SPD that allows communication via link-local addresses to bypass > IPsec, to support auto-configuration? On the IPng list, Matt Crawford has brought up the question of "ICMPv6 codes as selectors". I suspect you could establish a narrow "BYPASS" entry for Neighbor Discovery packets. > Note that I'm thinking about the default case of an implementation booting > for the first time without any prior configuration. In some cases (like a > mobile node visiting an untrusted link) an implementation will want to be > more careful. A really neat IPv6/IPsec problem to solve is the "securing neighbor discovery" problem. We have the basic protocol mechanisms in place. IPsec allows multicast SAs, and IPv6 ND uses ICMPv6. The question becomes one of key mgmt. How do you solve the single-LAN key distribution problem? Dan From owner-ipsec Tue Oct 6 01:14:42 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id BAA20832 for ipsec-outgoing; Tue, 6 Oct 1998 01:12:59 -0400 (EDT) To: Richard Draves cc: "'IPsec'" In-reply-to: richdr's message of Mon, 05 Oct 1998 14:59:01 MST. <4D0A23B3F74DD111ACCD00805F31D8100AF813A1@RED-MSG-50> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: autoconfiguration Date: Tue, 06 Oct 1998 14:27:35 +0900 Message-ID: <6207.907651655@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipsec@ex.tis.com Precedence: bulk >I understand this to mean that a compliant implementation must be manually >configured when it first boots. Automatic configuration is not possible >because that would require network communication, which is not allowed. >In particular, this would seem to conflict with IPv6's stateless address >autoconfiguration. >Would it be permissible for a compliant IPv6 implementation to have a >default SPD that allows communication via link-local addresses to bypass >IPsec, to support auto-configuration? Once the implementation has >automatically configured addresses, I imagine that the implementation might >proceed to configure the SPD from a network service. Could you please let me know what kind of scenario is in your mind? - What is the initial configuration (default settings) of endhost, regarding to IPv6 and IPsec? - What kind of RA packet will be announced? (with/without AH?) itojun@kame.net itojun@itojun.org jun-ichiro itojun itoh From owner-ipsec Tue Oct 6 02:04:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id CAA20990 for ipsec-outgoing; Tue, 6 Oct 1998 02:03:57 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF813AE@RED-MSG-50> From: Richard Draves To: "'Jun-ichiro itojun Itoh'" Cc: "'IPsec'" Subject: RE: autoconfiguration Date: Mon, 5 Oct 1998 23:21:25 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk > Could you please let me know what kind of scenario is > in your mind? > - What is the initial configuration (default settings) > of endhost, > regarding to IPv6 and IPsec? > - What kind of RA packet will be announced? (with/without AH?) The scenario I'm thinking of is a completely compliant IPv6 host implementation (so it includes a compliant IPsec) straight out of the box, unmodified default installation/configuration, and booting for the first time. My understanding of this requirement in IPsec is that this compliant IPv6 host will not be able to send Router Solicitations, receive Router Advertisements, or do anything else with the network, until some knowledgeable person sitting at the keyboard configures the host's inbound and outbound SPDs. My concern is that I believe IPv6's auto-configuration capabilities are important and as I understand it this IPsec requirement is in conflict. Thanks, Rich From owner-ipsec Tue Oct 6 09:40:15 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA22709 for ipsec-outgoing; Tue, 6 Oct 1998 09:34:08 -0400 (EDT) From: Armando Fratezi To: Cc: Subject: VPN Interoperability Workshop Closed Message-ID: <5010400027558998000002L082*@MHS> Date: Tue, 6 Oct 1998 09:57:47 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk The VPN Interoperability Workshop to be held in Binghamton, NY the week of October 26 is now full and registration is closed. If you have not registered and would like to attend, we will add your application to the waiting list. There is a good likelihood that we will receive cancellations and be able to bring in additional participants. If you have registered and have found that you will not be able to come, please let us know right away so we can accommodate those on the waiting list. Also, if you have already submitted an application and not received a confirmation, let us know as well. Bob Larribeau Please respond to bob@larribeau.com From owner-ipsec Tue Oct 6 22:00:16 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA26691 for ipsec-outgoing; Tue, 6 Oct 1998 21:56:39 -0400 (EDT) Message-Id: <199810070038.UAA22238@istari.sandelman.ottawa.on.ca> To: "'IPsec'" Subject: Re: autoconfiguration In-reply-to: Your message of "Mon, 05 Oct 1998 23:21:25 PDT." <4D0A23B3F74DD111ACCD00805F31D8100AF813AE@RED-MSG-50> Date: Tue, 06 Oct 1998 20:38:40 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Richard" == Richard Draves writes: Richard> My understanding of this requirement in IPsec is that this Richard> compliant IPv6 host will not be able to send Router Richard> Solicitations, receive Router Advertisements, or do anything Richard> else with the network, until some knowledgeable person sitting Richard> at the keyboard configures the host's inbound and outbound SPDs. This sounds like the SNMPv2 security vs initial config problem all over again. Richard> My concern is that I believe IPv6's auto-configuration Richard> capabilities are important and as I understand it this IPsec Richard> requirement is in conflict. We have need to define a digital signature based AH. This is *not* going to be useful for bulk data transfers, but it does present a way to do things like initial config. The problem is then reduced to the problem of doing initial certificate enrollment and acquisition of appropriate certificate chains. While this isn't an easy problem, it is a problem that lots of people are already working on. You can't solve the initial boot on the network problem in a secure fashion unless you simultaneously answer questions like: - should you be allowed to connect here? - should you get an address? (or did you turn some other guys' machine off, yanked the network card and/or copied the MAC and now are impersonating him?) - if your PC gets fixed/upgraded/etc. do you risk loosing your network identity? :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Wed Oct 7 12:23:53 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA00090 for ipsec-outgoing; Wed, 7 Oct 1998 12:17:10 -0400 (EDT) Message-ID: <361B987A.F0A4B326@redcreek.com> Date: Wed, 07 Oct 1998 09:36:10 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: "Michael C. Richardson" CC: "'IPsec'" Subject: Re: autoconfiguration References: <199810070038.UAA22238@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael C. Richardson wrote: > We have need to define a digital signature based AH. This is *not* going to > be useful for bulk data transfers, but it does present a way to do things > like initial config. The problem is then reduced to the problem of > doing initial certificate enrollment and acquisition of appropriate > certificate chains. While this isn't an easy problem, it is a problem > that lots of people are already working on. > You can't solve the initial boot on the network problem in a secure > fashion unless you simultaneously answer questions like: > - should you be allowed to connect here? > - should you get an address? (or did you turn some other guys' > machine off, yanked the network card and/or copied the MAC > and now are impersonating him?) > - if your PC gets fixed/upgraded/etc. do you risk loosing your > network identity? > Mike St. Johns and I are working on a draft which discusses this problem and proposes solutions. The working title is 'Secure Configuration of IPsec-Enabled Network Devices'. I have another round of edits which I hope to get to later this week, and then we will probably post the draft for comment. From owner-ipsec Wed Oct 7 14:05:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA00683 for ipsec-outgoing; Wed, 7 Oct 1998 14:04:24 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199810051348.JAA11859@tonga.xedia.com> Date: Wed, 07 Oct 1998 14:15:33 -0400 (EDT) From: "Dr. M. C. Nelson" To: Paul Koning Subject: Re: Re-keying Issues Document Cc: ipsec@ex.tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk On 05-Oct-98 Paul Koning wrote: >>>>>> "M" == M C Nelson writes: > > > Steve, The points in my letter (concerning rekeying) were > > > (1) for a software key generator there is really only one secret. > >That's true. If ALL you use is a key stream extender without ever >stirring in any entropy. > >Of course, if someone builds a key generator without ever reading RFC >1750, there's not much we can do to help him. > > > (2) repeated generation of keys from that single secret, can give > > away information about the secret. > > > (3) therefore, it is perhap better to simply use a very good > > secret to begin with and only change it with proper true random > > input or when warranted, or perhaps otherwise, infrequently. > > > A discussion of how one finds some source of randomness is not to > > the point. Thats not the case being discussed. > >So what is the case being discussed? The one where someone doesn't do >what RFC 1750 recommends, but instead simply extends a bitstream >without ever stirring in randomness? I suppose it might be useful to >say "don't do that". I don't see much sense in spending any more >words than that explaining how to "improve" on such a fundamentally >broken approach. > > > Also, the claim that one can rely on adequate randomness being > > available in the general case without hardware specific to that > > purpose, is hard to believe. There are lots of systems that deal > > with lots of nearly repetitive or predictable stuff. The banking > > and financial industries are full of them. > >I don't remember such a claim being made. If you're referring to my >comments, I was referring to specific analysis of specific systems. >As Don pointed out, if it has a disk it has a random number >generator. And my observation is that even systems with no disk may >have low rate sources of entropy. At least, the one analyzed does. > Simply not true in the general case. And, the observation referred to can only be an anecdote, not a proof. >If your point is that it is possible to build systems where no >adequate source of entropy is available, I agree that this might be >so. If you have such a system, you can't build an adequate >implementation of IKE on it until you change the hardware to supply a >source of entropy. > >But if your claim is that the only useable source of entropy is >devices purpose-built for the specific job of generating "true random >numbers" I believe you will find ample data contradicting that, in >places such as RFC 1750 and elsewhere. > I admire you vehement enthusiasm to defend your work. Nonetheless there are plenty of machines in the world that have predictable inputs, states, and outputs. That in general terms is what a computer is. No amount of anecdotal sampling of a limited range of cases will change that fact. Moreover, with network appliances on the way, there will no doubt be many more machines that flagrantly violate your thesis. In any case, the point is that you can be much better off by simply using a very good key (with lost of bits) and changing it less frequently. It is simply impossible to say that the general case machine for which a network layer standard must apply, will always have the necessary randomness available to safely generate good keys at a substantial frequency. And it is simply impossible to say that any pure-software-key-generator acting in combination with encryption of datagrams is not going to open some cryptoanalytic door except on a case by case basis. > paul From owner-ipsec Wed Oct 7 14:22:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA00749 for ipsec-outgoing; Wed, 7 Oct 1998 14:22:06 -0400 (EDT) Message-Id: <199810071839.OAA12569@postal.research.att.com> To: "Dr. M. C. Nelson" cc: Paul Koning , ipsec@ex.tis.com Subject: Re: Re-keying Issues Document Date: Wed, 07 Oct 1998 14:39:40 -0400 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , "Dr. M. C. Nelson" wr ites: > Simply not true in the general case. And, the observation > referred to can only be an anecdote, not a proof. > > >If your point is that it is possible to build systems where no > >adequate source of entropy is available, I agree that this might be > >so. If you have such a system, you can't build an adequate > >implementation of IKE on it until you change the hardware to supply a > >source of entropy. > > > >But if your claim is that the only useable source of entropy is > >devices purpose-built for the specific job of generating "true random > >numbers" I believe you will find ample data contradicting that, in > >places such as RFC 1750 and elsewhere. > > > > I admire you vehement enthusiasm to defend your work. Nonetheless > there are plenty of machines in the world that have predictable inputs, > states, and outputs. That in general terms is what a computer is. > No amount of anecdotal sampling of a limited range of cases will > change that fact. Moreover, with network appliances on the way, > there will no doubt be many more machines that flagrantly violate > your thesis. Have you read any of the papers cited? For example, try Davis et al., http://world.std.com/~dtd/, on using disk drive air turbulence for randomness. Cryptolib, by Lacy et al., uses timing jitter between different clocks, a technique used by some "real" hardware RNGs. Sure, it's hard to do right. But blatant assertions that it can't be done simply don't hold. > > In any case, the point is that you can be much better off by simply > using a very good key (with lost of bits) and changing it less > frequently. It is simply impossible to say that the general case > machine for which a network layer standard must apply, will always > have the necessary randomness available to safely generate good > keys at a substantial frequency. And it is simply impossible to > say that any pure-software-key-generator acting in combination with > encryption of datagrams is not going to open some cryptoanalytic door > except on a case by case basis. Have you read the Blum, Blum, and Shub paper cited here? Have you looked at Wagner's set of pointers (http://www.cs.berkeley.edu/~daw/netscape-randomness.html)? From owner-ipsec Wed Oct 7 14:30:55 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA00804 for ipsec-outgoing; Wed, 7 Oct 1998 14:30:39 -0400 (EDT) Date: Wed, 7 Oct 1998 14:49:57 -0400 Message-Id: <199810071849.OAA13555@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mcnelson@mindspring.com Cc: ipsec@ex.tis.com Subject: Re: Re-keying Issues Document References: <199810051348.JAA11859@tonga.xedia.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "M" == M C Nelson writes: > On 05-Oct-98 Paul Koning wrote: >> ... >> If your point is that it is possible to build systems where no >> adequate source of entropy is available, I agree that this might >> be so. If you have such a system, you can't build an adequate >> implementation of IKE on it until you change the hardware to >> supply a source of entropy. >> >> But if your claim is that the only useable source of entropy is >> devices purpose-built for the specific job of generating "true >> random numbers" I believe you will find ample data contradicting >> that, in places such as RFC 1750 and elsewhere. > >... > In any case, the point is that you can be much better off by > simply using a very good key (with lost of bits) and changing it > less frequently. It is simply impossible to say that the general > case machine for which a network layer standard must apply, will > always have the necessary randomness available to safely generate > good keys at a substantial frequency. And it is simply impossible > to say that any pure-software-key-generator acting in combination > with encryption of datagrams is not going to open some > cryptoanalytic door except on a case by case basis. I keep wondering what exactly the point is you're trying to get across. It seems to me we have agreement that a software key generator that does not have any external source of entropy is vulnerable. And also that sources of entropy are slippery things that have to be analyzed on a case by case basis; there is no "general" source of entropy. On the other hand, it sounds at times like you're saying that the only sources of entropy are purpose-built chunks of hardware like noise diodes or radioactive sources. If that's the point, I disagree, and I would object to documents that claim this is so. In fact, any source of entropy is hard to build. They all require careful analysis as to bit rate and fault properties. That's no less true for purpose-built "true random number generators" as it is for processes that as a side effect can act as an entropy source (like disk drives). As I mentioned, I've done that analysis for the entropy sources in my system. You dismiss that work by the term "anecdote" without knowing anything about it. If you want "proof" of randomness, I suggest you may be asking for a proof of a negative. For any entropy source, all you can expect is a careful analysis and an engineering judgement that it has the right properties. To judge the merits of such an analysis you have to look at the particular system and the work that was done with it; you can't just sit and write adjectives like "anecdotal". The tradeoff on how key generation should work has to be an implementation decision. Some systems have relatively high rate entropy sources, and these can therefore support high rate key generation easily. Others do not, and have to be more careful in how they do key stream extension. I agree that "it is simply impossible to say that the general case machine..." so I would not want to prescribe a solution, but rather point designers at good principles such as those in RFC 1750. paul From owner-ipsec Wed Oct 7 14:39:30 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA00879 for ipsec-outgoing; Wed, 7 Oct 1998 14:39:11 -0400 (EDT) Message-ID: <19981007135652.A24312@austin.ibm.com> Date: Wed, 7 Oct 1998 13:56:52 -0500 From: Will Fiveash To: IETF IPSEC Cc: ddp@network-alchemy.com Subject: Issue concerning P1 ID port/protocol and Interop Testing Mail-Followup-To: IETF IPSEC , ddp@network-alchemy.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i Sender: owner-ipsec@ex.tis.com Precedence: bulk I've been running IKE interop tests against both the SSH (http://isakmp-test.ssh.fi/) and NIST (http://ipsec-wit.antd.nist.gov/) test sites. One thing that I've discovered that appears to be a problem common to both sites is they send a Phase 1 ID with the protocol field set to UDP but the port field is 0. Am I correct in thinking this is in violation of draft-ietf-ipsec-ipsec-doi-10.txt which states in section 4.6.2: During Phase I negotiations, the ID port and protocol fields MUST be set to zero or to UDP port 500. If an implementation receives any other values, this MUST be treated as an error and the security association setup MUST be aborted. This event SHOULD be auditable. ? This leads me to a more fundamental question: Is this restriction on the protocol/port fields really necessary in Phase 1? These fields don't appear to be useful in Phase 1 and if we test for 0/0 or UDP/500 we won't inter-operate with SSH or NIST (and I suspect other folks will have similar problems). -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com@internet Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec Wed Oct 7 15:32:37 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA01091 for ipsec-outgoing; Wed, 7 Oct 1998 15:31:21 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199810071849.OAA13555@tonga.xedia.com> Date: Wed, 07 Oct 1998 15:48:45 -0400 (EDT) From: "Dr. M. C. Nelson" To: Paul Koning Subject: Re: Re-keying Issues Document Cc: ipsec@ex.tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk On 07-Oct-98 Paul Koning wrote: >>>>>> "M" == M C Nelson writes: > > > On 05-Oct-98 Paul Koning wrote: > >> ... > >> If your point is that it is possible to build systems where no > >> adequate source of entropy is available, I agree that this might > >> be so. If you have such a system, you can't build an adequate > >> implementation of IKE on it until you change the hardware to > >> supply a source of entropy. > >> > >> But if your claim is that the only useable source of entropy is > >> devices purpose-built for the specific job of generating "true > >> random numbers" I believe you will find ample data contradicting > >> that, in places such as RFC 1750 and elsewhere. > > > >... > > In any case, the point is that you can be much better off by > > simply using a very good key (with lost of bits) and changing it > > less frequently. It is simply impossible to say that the general > > case machine for which a network layer standard must apply, will > > always have the necessary randomness available to safely generate > > good keys at a substantial frequency. And it is simply impossible > > to say that any pure-software-key-generator acting in combination > > with encryption of datagrams is not going to open some > > cryptoanalytic door except on a case by case basis. > >I keep wondering what exactly the point is you're trying to get >across. > >It seems to me we have agreement that a software key generator that >does not have any external source of entropy is vulnerable. And also >that sources of entropy are slippery things that have to be analyzed >on a case by case basis; there is no "general" source of entropy. > >On the other hand, it sounds at times like you're saying that the only >sources of entropy are purpose-built chunks of hardware like noise >diodes or radioactive sources. If that's the point, I disagree, and I >would object to documents that claim this is so. > >In fact, any source of entropy is hard to build. They all require >careful analysis as to bit rate and fault properties. That's no less >true for purpose-built "true random number generators" as it is for >processes that as a side effect can act as an entropy source (like >disk drives). > >As I mentioned, I've done that analysis for the entropy sources in my >system. You dismiss that work by the term "anecdote" without knowing >anything about it. If you want "proof" of randomness, I suggest you >may be asking for a proof of a negative. For any entropy source, all >you can expect is a careful analysis and an engineering judgement that >it has the right properties. To judge the merits of such an analysis >you have to look at the particular system and the work that was done >with it; you can't just sit and write adjectives like "anecdotal". > By your own comment, this is an analysis on your machine, hence anecdotal. (Quod Erat Demonstratum). >The tradeoff on how key generation should work has to be an >implementation decision. Some systems have relatively high rate >entropy sources, and these can therefore support high rate key >generation easily. Others do not, and have to be more careful in how >they do key stream extension. I agree that "it is simply impossible >to say that the general case machine..." so I would not want to >prescribe a solution, but rather point designers at good principles >such as those in RFC 1750. `I agree that "it is simply impossible >to say that the general case machine..."' Wonderful. Thank you. > > paul From owner-ipsec Wed Oct 7 15:40:02 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA01163 for ipsec-outgoing; Wed, 7 Oct 1998 15:39:41 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199810071839.OAA12569@postal.research.att.com> Date: Wed, 07 Oct 1998 15:59:04 -0400 (EDT) From: "Dr. M. C. Nelson" To: Steve Bellovin Subject: Re: Re-keying Issues Document Cc: ipsec@ex.tis.com, Paul Koning Sender: owner-ipsec@ex.tis.com Precedence: bulk On 07-Oct-98 Steve Bellovin wrote: >In message , "Dr. M. C. Nelson" wr >ites: >> Simply not true in the general case. And, the observation >> referred to can only be an anecdote, not a proof. >> >> >If your point is that it is possible to build systems where no >> >adequate source of entropy is available, I agree that this might be >> >so. If you have such a system, you can't build an adequate >> >implementation of IKE on it until you change the hardware to supply a >> >source of entropy. >> > >> >But if your claim is that the only useable source of entropy is >> >devices purpose-built for the specific job of generating "true random >> >numbers" I believe you will find ample data contradicting that, in >> >places such as RFC 1750 and elsewhere. >> > >> >> I admire you vehement enthusiasm to defend your work. Nonetheless >> there are plenty of machines in the world that have predictable inputs, >> states, and outputs. That in general terms is what a computer is. >> No amount of anecdotal sampling of a limited range of cases will >> change that fact. Moreover, with network appliances on the way, >> there will no doubt be many more machines that flagrantly violate >> your thesis. > >Have you read any of the papers cited? For example, try Davis et al., >http://world.std.com/~dtd/, on using disk drive air turbulence for >randomness. Cryptolib, by Lacy et al., uses timing jitter between >different clocks, a technique used by some "real" hardware RNGs. > >Sure, it's hard to do right. But blatant assertions that it can't >be done simply don't hold. >> The blatant assertion in this discussion is that adequate randomness is always available. >> In any case, the point is that you can be much better off by simply >> using a very good key (with lost of bits) and changing it less >> frequently. It is simply impossible to say that the general case >> machine for which a network layer standard must apply, will always >> have the necessary randomness available to safely generate good >> keys at a substantial frequency. And it is simply impossible to >> say that any pure-software-key-generator acting in combination with >> encryption of datagrams is not going to open some cryptoanalytic door >> except on a case by case basis. > >Have you read the Blum, Blum, and Shub paper cited here? Have you >looked at Wagner's set of pointers (http://www.cs.berkeley.edu/~daw/netscape-ra ndomness.html)? From owner-ipsec Wed Oct 7 16:40:53 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA01365 for ipsec-outgoing; Wed, 7 Oct 1998 16:39:01 -0400 (EDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199810071839.OAA12569@postal.research.att.com> Date: Wed, 07 Oct 1998 16:21:59 -0400 (EDT) From: "Dr. M. C. Nelson" To: Steve Bellovin Subject: Re: Re-keying Issues Document Cc: ipsec@ex.tis.com, Paul Koning Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, So far, I haven't seen anything in the references that alters any element of my thesis. First of all, my central point is that software-only key generation combined with frequent re-keying doesn't bode well for security. From the discussions so far, it seems that this point is not contested. (It seems that the arguments apply to the BBS algorithm also). Many of the papers that you and others have cited, try to find some hardware source of randomness to mix in to the software key generation method. This takes us into the tangential question, is there as a general case, a source of randomness available to software? I have maintained that one cannot say that in the general case there is a source of randomness available, short of saying that the general case always includes certain hardware or a human. If you can point me to a cite which otherwise constitutes a general case, I would be thankful. The clock drift method (which I have in my own notebooks from a long long time ago) by the author's own admission, is not a general case solution, nor are the solutions based on disk drives, or sound boards. Moreover, we can expect that there will soon be a large number of small networked devices that have single clocks, no disk drives, and otherwise lots of variability in configuration. Regards, Mitch Nelson On 07-Oct-98 Steve Bellovin wrote: >In message , "Dr. M. C. Nelson" wr >ites: >> Simply not true in the general case. And, the observation >> referred to can only be an anecdote, not a proof. >> >> >If your point is that it is possible to build systems where no >> >adequate source of entropy is available, I agree that this might be >> >so. If you have such a system, you can't build an adequate >> >implementation of IKE on it until you change the hardware to supply a >> >source of entropy. >> > >> >But if your claim is that the only useable source of entropy is >> >devices purpose-built for the specific job of generating "true random >> >numbers" I believe you will find ample data contradicting that, in >> >places such as RFC 1750 and elsewhere. >> > >> >> I admire you vehement enthusiasm to defend your work. Nonetheless >> there are plenty of machines in the world that have predictable inputs, >> states, and outputs. That in general terms is what a computer is. >> No amount of anecdotal sampling of a limited range of cases will >> change that fact. Moreover, with network appliances on the way, >> there will no doubt be many more machines that flagrantly violate >> your thesis. > >Have you read any of the papers cited? For example, try Davis et al., >http://world.std.com/~dtd/, on using disk drive air turbulence for >randomness. Cryptolib, by Lacy et al., uses timing jitter between >different clocks, a technique used by some "real" hardware RNGs. > >Sure, it's hard to do right. But blatant assertions that it can't >be done simply don't hold. >> >> In any case, the point is that you can be much better off by simply >> using a very good key (with lost of bits) and changing it less >> frequently. It is simply impossible to say that the general case >> machine for which a network layer standard must apply, will always >> have the necessary randomness available to safely generate good >> keys at a substantial frequency. And it is simply impossible to >> say that any pure-software-key-generator acting in combination with >> encryption of datagrams is not going to open some cryptoanalytic door >> except on a case by case basis. > >Have you read the Blum, Blum, and Shub paper cited here? Have you >looked at Wagner's set of pointers (http://www.cs.berkeley.edu/~daw/netscape-ra ndomness.html)? From owner-ipsec Wed Oct 7 19:02:47 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA01858 for ipsec-outgoing; Wed, 7 Oct 1998 19:01:50 -0400 (EDT) Date: Wed, 7 Oct 1998 19:18:18 -0400 (EDT) From: Henry Spencer To: "Dr. M. C. Nelson" cc: ipsec@ex.tis.com Subject: Re: Re-keying Issues Document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Many of the papers that you and others have cited, try to find some hardware > source of randomness to mix in to the software key generation method. This > takes us into the tangential question, is there as a general case, a source > of randomness available to software? It is undoubtedly possible to contrive a case where there is no source of randomness available. But that is not a very interesting fact. If an overwhelming majority of the *interesting* cases have modest amounts of randomness on hand, that is sufficient for many purposes. > I have maintained that one cannot say that in the general case there is a > source of randomness available... I don't think anybody is disputing this, but you don't seem to grasp that this is not an interesting result. The question is whether there are a significant number of systems which will want to communicate via IPSEC which have no randomness available. Asserting *that* requires you to supply examples -- which you have failed to do -- and also requires that you understand the wide variety of randomness sources available. > ...Moreover, we can expect that there > will soon be a large number of small networked devices that have single > clocks, no disk drives, and otherwise lots of variability in configuration. And they won't be listening to clocked bits from a network? Or accepting human keypresses? Also, not all of us expect this. Some of us think it's just the latest snake-oil marketing fad, and are gleefully looking forward to seeing this particular bubble punctured by the actual sales results. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Wed Oct 7 21:35:29 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA02250 for ipsec-outgoing; Wed, 7 Oct 1998 21:34:27 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81395@RED-MSG-50> Date: Wed, 7 Oct 1998 18:05:34 -0400 To: Richard Draves From: Stephen Kent Subject: RE: inbound policy verification Cc: IPsec WG List Sender: owner-ipsec@ex.tis.com Precedence: bulk Rich, I have to rethink this. It may be that we went overboard in our zeal to not mandate thge backpointer approach to handling complex SA constructs. Steve From owner-ipsec Wed Oct 7 21:35:29 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA02246 for ipsec-outgoing; Wed, 7 Oct 1998 21:34:24 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF813A1@RED-MSG-50> Date: Wed, 7 Oct 1998 18:13:30 -0400 To: Richard Draves From: Stephen Kent Subject: Re: autoconfiguration Cc: "'IPsec'" Sender: owner-ipsec@ex.tis.com Precedence: bulk Richard, >I'm concerned about the provision in the security architecture spec (eg see >section 5 first paragraph) that "If no policy is found in the SPD that >matches the packet (for either inbound or outbound traffic), the packet MUST >be discarded." > >I understand this to mean that a compliant implementation must be manually >configured when it first boots. Automatic configuration is not possible >because that would require network communication, which is not allowed. Right. >In particular, this would seem to conflict with IPv6's stateless address >autoconfiguration. > >Would it be permissible for a compliant IPv6 implementation to have a >default SPD that allows communication via link-local addresses to bypass >IPsec, to support auto-configuration? Once the implementation has >automatically configured addresses, I imagine that the implementation might >proceed to configure the SPD from a network service. One can have such a default SPD configuration and it would be IPSec compliant. Whether it's a good idea from a security perspective is another matter ... >Note that I'm thinking about the default case of an implementation booting >for the first time without any prior configuration. In some cases (like a >mobile node visiting an untrusted link) an implementation will want to be >more careful. Vendors have a history of supplying products that are insecure out of the box. This is especially problematic for a device that purports to implement security, e.g., an IPsec implementation. I think we need solutions to this problem that don't compromise one aspect of the system in order to comply with another. Steve From owner-ipsec Thu Oct 8 12:26:00 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA04702 for ipsec-outgoing; Thu, 8 Oct 1998 12:16:42 -0400 (EDT) Date: Thu, 8 Oct 1998 19:34:31 +0300 (EET DST) Message-Id: <199810081634.TAA11197@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Will Fiveash Cc: IETF IPSEC , ddp@network-alchemy.com Subject: Issue concerning P1 ID port/protocol and Interop Testing In-Reply-To: <19981007135652.A24312@austin.ibm.com> References: <19981007135652.A24312@austin.ibm.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Will Fiveash writes: > I've been running IKE interop tests against both the SSH > (http://isakmp-test.ssh.fi/) and NIST (http://ipsec-wit.antd.nist.gov/) > test sites. One thing that I've discovered that appears to be a problem > common to both sites is they send a Phase 1 ID with the protocol field > set to UDP but the port field is 0. Am I correct in thinking this is in > violation of draft-ietf-ipsec-ipsec-doi-10.txt which states in section > 4.6.2: > > During Phase I negotiations, the ID port and protocol fields MUST be > set to zero or to UDP port 500. If an implementation receives any > other values, this MUST be treated as an error and the security > association setup MUST be aborted. This event SHOULD be auditable. > > ? > > This leads me to a more fundamental question: Is this restriction on the > protocol/port fields really necessary in Phase 1? These fields don't > appear to be useful in Phase 1 and if we test for 0/0 or UDP/500 we won't > inter-operate with SSH or NIST (and I suspect other folks will have > similar problems). I don't think the value of port and protocol has any meaning in the phase 1 exchange. The reason why SSH's test site had UDP/0, was that it used to be UDP/xxxx, where xxxx was the real port number (quite often 1500 ), but someone complained about that and I changed it to UDP/0... I have already changed the test program to send 0/0, but I haven't updated the web-server yet. I will propably do it quite soon, and there will be some new features also (EC2N and ECP groups for Diffie-Hellman, Initial-contact notifications, etc). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Thu Oct 8 14:06:01 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA05108 for ipsec-outgoing; Thu, 8 Oct 1998 14:04:54 -0400 (EDT) Message-ID: <19981008132306.A38184@austin.ibm.com> Date: Thu, 8 Oct 1998 13:23:06 -0500 From: Will Fiveash To: IETF IPSEC Subject: Re: Issue concerning P1 ID port/protocol and Interop Testing Mail-Followup-To: IETF IPSEC References: <19981007135652.A24312@austin.ibm.com> <199810072127.XAA17909@waldorf.appli.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: <199810072127.XAA17909@waldorf.appli.se>; from Niklas Hallqvist on Wed, Oct 07, 1998 at 11:27:26PM +0200 Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, Oct 07, 1998 at 11:27:26PM +0200, Niklas Hallqvist wrote: > > Just to fill in: I had exactly the same problem. I mentioned it to > Tero and he said that he interpreted the draft like that (although I > don't see how to do that) which leads to the conclusion, that the > drafts does not seem to be very well phrased. I did not report it > here as I have seen messages saying it's too late this time 'round. After reading the responses so far to my previous mail note, I get the impression that there is some confusion regarding P1 ID protocol/port values. My feeling is that I should implement IKE on AIX such that it sends 0/0 when initiating but ignores these fields when responding (conservative in sending, liberal in receiving). This would make it easier on customers trying to inter-operate with the various flavors of IKE. The thing that concerns me about this is whether this behavior would count against us when organizations like ISCA test IKE for certification purposes. Anyone have an opinion on this? -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com@internet Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec Thu Oct 8 18:45:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA06060 for ipsec-outgoing; Thu, 8 Oct 1998 18:44:03 -0400 (EDT) Date: Thu, 8 Oct 1998 19:02:11 -0400 Message-Id: <199810082302.TAA05486@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: rpereira@TimeStep.com, adams@cisco.com Cc: ipsec@tis.com Subject: ipsec-ciph-cbc document (conditionally) approved by the IESG Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I have some good news and some bad news..... The good news was that the ipsec-ciph-cbc was approved by the IETF. The bad news was that it was conditional on our making one change to the document. This particular nit consists of adding the following text (from RFC 2026): "The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat." to the document. Probably the place to add it is as section 1.2, "Intellectual Property Rights Statement", after the other boilerplate text describing "MUST", "SHOULD", etc. So if the document editors could make this change and then resubmit the document as an I-D, it will automatically get sent to the IANA, at which point we should be able to finally get the IPSEC RFC's published. - Ted From owner-ipsec Fri Oct 9 08:18:15 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA07708 for ipsec-outgoing; Fri, 9 Oct 1998 08:13:24 -0400 (EDT) Date: Fri, 9 Oct 1998 15:30:56 +0300 (EET DST) From: Markku Savela Message-Id: <199810091230.PAA10642@anise.tte.vtt.fi> To: ipsec@tis.com Subject: arch-07 and protocol mode stored in SAD? Why? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk In draft-ietf-ipsec-arch-sec-07, "4.4.3 Security Association Database (SAD)" (page 24), in the list of required SAD fields, there is this "IPsec protocol mode", and I am wondering why? 1) There is no way to set this field from PFKEY, as far as I can see (unless one takes a hint from presence of a PROXY_ADDRESS extension, but even then it would leave open how to choose between "wildcard" and "transport") 2) in my "legacy implementation", the tunneling controlled by the policy definion, and this seems to be quite working solution. Again, one of the issues where Policy and SAD are getting mixed/confused? But anyway, it would seem that the description of the tunnel/wildcard/transport mode would not belong to SAD, but into SPD and bundles. On conformance, I doubt there is any way to detect from outside, whether I implement this on SAD, or in SPD. Now, looking at all the description about how to do tunneling, I am starting to wonder whether I do it right, when I do it simple and totally independent of the ESP or AH, eg... for each bundle Step. 1. Apply general tunnel (IPIP) to packet (if the bundle specifies a tunnel, e.g. my policy tells when to tunnel or not, SA knows nothing about it) Step. 2. Apply ESP or AH to packet (these don't care what the next protocol is, work equally well with IPIP and any other protocols) -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Fri Oct 9 09:15:12 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA08038 for ipsec-outgoing; Fri, 9 Oct 1998 09:14:21 -0400 (EDT) Message-ID: From: Greg Carter To: "'ca-talk@icsa.net'" , "'ipsec@tis.com'" Subject: IKE autoresponder update to freecerts.entrust.com Date: Fri, 9 Oct 1998 09:25:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Yet another IKE autoresponder is up and running at vpncerts.entrust.com or for the dns challenged 204.101.128.44 port 500. It has a cert issued by the same CA as freecerts.entrust.com will give you. Here is what you can do: Do IKE negotiations will all kinds of cert options such as: certificate request payload with types of: X.509 Signature, X.509 PKCS#7 wrapped, and CRL. certificate payload types of X.509, X.509 PKCS#7, and CRL. the entities cert contains a subjectAltName with ip=204.101.128.44, dns=vpncerts.entrust.com, email=greg.carter@entrust.com The ID used in the ID payload is X.509 DN. If people would prefer IP Address let me know. It has an RSA key so the only auth type that will work is RSA Signature. DES, 3DES, and CAST-128 are supported for IKE encryption, MD5 or SHA1 for IKE hashes, and either group one or group two for DH. There is NO ESP or AH capability at this address, however you can negotiate an IPSEC SA. For now it will only negotiate ESP, DES-CBC, MD5, TUNNEL MODE, with PFS with group 2. Any other proposal will probably fail. There is no web page to configure it and no way to observer the results other than what your own end tells you. As well LDAP should be available at 204.101.128.41 port 389 for those looking for CRLs etc. If there are any problems email me. Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com From owner-ipsec Fri Oct 9 11:43:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA08625 for ipsec-outgoing; Fri, 9 Oct 1998 11:42:31 -0400 (EDT) From: Dan McDonald Message-Id: <199810091600.JAA01463@kebe.eng.sun.com> Subject: Re: arch-07 and protocol mode stored in SAD? Why? To: msa@hemuli.tte.vtt.fi Date: Fri, 9 Oct 1998 09:00:41 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199810091230.PAA10642@anise.tte.vtt.fi> from "Markku Savela" at Oct 9, 98 03:30:56 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > "IPsec protocol mode", and I am wondering why? > > 1) There is no way to set this field from PFKEY, as far as I can see > (unless one takes a hint from presence of a PROXY_ADDRESS > extension, but even then it would leave open how to choose between > "wildcard" and "transport") Another way to see is on the SADB_ACQUIRE message, what the sadb_address_proto field is set to. If it's set to IPPROTO_IP or IPPROTO_IPV6, then you can safely assume it's tunnel. I have NEVER understood why people are so anal about tunnel vs. transport. One is a case of the other, IMHO. > But anyway, it would seem that the description of the > tunnel/wildcard/transport mode would not belong to SAD, but into SPD and > bundles. I agree! > eg... for each bundle > > Step. 1. Apply general tunnel (IPIP) to packet (if the bundle > specifies a tunnel, e.g. my policy tells when to tunnel or > not, SA knows nothing about it) > > Step. 2. Apply ESP or AH to packet (these don't care what the > next protocol is, work equally well with IPIP and any other > protocols) I believe you'll find more than a few implementations that do things this way. Dan From owner-ipsec Fri Oct 9 12:09:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA08708 for ipsec-outgoing; Fri, 9 Oct 1998 12:09:31 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB5978@wade.reo.dec.com> From: Stephen Waters To: bgleeson@shastanets.com Cc: ipsec@tis.com, l2tp@zendo.com Subject: comments on VPN framework document Date: Fri, 9 Oct 1998 17:26:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk (comments on ftp://ftp.ietf.org/internet-drafts/draft-gleeson-vpn-framework-00.txt ) Hi Bryan, just read-through your draft on VPN frameworks and I have a few comments: 1) L2TP seemed to get the thumbs-up on all count except security. If IPSEC is applied to the resulting L2TP UDP/IP packet in TRANSPORT mode, that does seem to solve the problems. I have never seen IPSEC-tunnel as being useful for LAN to LAN. It is fine for host-to-host, and for host to security gateway, but not LAN-LAN. Maybe it can be fixed, but in the meantime: L2TP tunnel packets protected with ESP encryption would add as little as 9 bytes of ESP overhead. The encryption algorithm used may add another 8 to 14bytes and the authentication option another 12 bytes. However, these encryption/authentication overheads would be incurred whatever route you take, so it comes back to 9 bytes per packet additional for ESP overhead. Four bytes of this overhead is used to prevent replay attacks, and four bytes are used to multiplex. The four bytes of replay protection are a general requirement, so they remain 5 bytes (multiplexing and next-hdr bytes) are the only true over head of applying ESP transport mode. 2) VPRNs look very complicated. The document is VERY VPRN-heavy, I feel. I am concerned that the VPRN model is both restrictive, inflexible and relies on security being managed for you by the VPRN provider. I much prefer the VLL approach described - just so you know :) 3) I am not convinced the 'Compulsory' tunneling for remote access will be attractive (I'll get some heat for that one no doubt). Again, it is inflexible, insecure on the outer PPP links, and relies on the ISP providing authentication services. To protect the LAC-LNS flow would mean sharing ipsec security information with the ISP. Besides, 'Voluntary' sounds more friendly :). I think a vanila IPSEC tunnel in valuntary mode would do most folk - no L2TP. Steve. From owner-ipsec Fri Oct 9 15:48:14 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA09532 for ipsec-outgoing; Fri, 9 Oct 1998 15:43:40 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Stephen Waters , Bryan Gleeson Cc: ipsec@tis.com, l2tp@zendo.com Subject: RE: comments on VPN framework document Date: Fri, 9 Oct 1998 13:00:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, > 1) L2TP seemed to get the thumbs-up on all count except > security. If IPSEC > is applied to the resulting > L2TP UDP/IP packet in TRANSPORT mode, that does seem to solve > the problems. > > I have never seen IPSEC-tunnel as being useful for LAN to > LAN. It is fine > for host-to-host, and for host to security gateway, but not > LAN-LAN. Maybe > it can be fixed, but in the meantime: Restricting the applicability of IPSEC to scenarios where one party is a host seems very limiting, and not necessary. Making small modifications to IPSEC to allow wider applicability of its use in non-host contexts definitely seems something that should be pursued. > > L2TP tunnel packets protected with ESP encryption would add > as little as 9 > bytes of ESP overhead. > The encryption algorithm used may add another 8 to 14bytes and the > authentication option another > 12 bytes. However, these encryption/authentication overheads would be > incurred whatever route you take, so it comes back to 9 bytes > per packet > additional for ESP overhead. Four bytes of this overhead is used to > prevent replay attacks, and four bytes are used to multiplex. > The four > bytes of replay protection are a general requirement, so they > remain 5 bytes > (multiplexing and next-hdr bytes) are the only true over head > of applying > ESP transport mode. While the extra bytes needed on the data plane may or may not be viewed as significant (and there's the PPP and UDP overhead also), there is the additional requirement of the L2TP signalling component, and its associated configuration. To me it just seems hard to justify why you need two of something, if one will do. I see the same motivation driving the idea of allowing a remote host's IP address and DNS server to be configured via ISAKMP, rather than requiring PPP-IPCP or DHCP as well. It also seems more pragmatic that requiring stacks that look like APP/TCP/IP/PPP/L2TP/UDP/IPSEC/IP/L2/L1 (I'm sure ISO-OSI would have been proud of that one :-) > 2) VPRNs look very complicated. The document is VERY > VPRN-heavy, I feel. I > am concerned that the VPRN model is both restrictive, > inflexible and relies > on security being managed for you by the VPRN provider. I > much prefer the > VLL approach described - just so you know :) The main benefit of a VPRN is that it allows for very simple CPE devices, in simple connectivity scenarios. If the CPE device just has a single link to the ISP you can configure it with a default route and you are done. The VPRN section describes a number of different problems that need to be solved for any VPN (e.g. membership and reachability determination and dissemination). There are a number of ways to solve each one, but I would not say that VPRNs are inherently complicated. It is more a matter of where you place the functionality - CPE router or ISP router. Also for network based VPNs many of the same mechanisms are needed whether the connectivity service provided is at layer 3 or layer 2 (VPLS). There will never be a 'one size fits all' answer to the level of trust a customer gives to a service provider. The level of trust given to a provider in the case of a VPRN is similar to that given to a provider that provides an ATM PVC today. Packets are switched inside the network, and sent to other sites in the corporate network, and you assume that they don't go to your competitor sites. A customer can always choose to do more security, transparently to the service provider. > 3) I am not convinced the 'Compulsory' tunneling for remote > access will be > attractive (I'll get some heat for that one no doubt). Again, it is > inflexible, insecure on the outer PPP links, and relies on > the ISP providing > authentication services. To protect the LAC-LNS flow would > mean sharing > ipsec security information with the ISP. Besides, > 'Voluntary' sounds more > friendly :). I think a vanila IPSEC tunnel in valuntary mode > would do most > folk - no L2TP. This seems an argument for using IPSEC by itself as a tunneling protocol, and not requiring L2TP. I agree! Bryan From owner-ipsec Fri Oct 9 17:41:00 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA09795 for ipsec-outgoing; Fri, 9 Oct 1998 17:39:59 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB5985@wade.reo.dec.com> From: Stephen Waters To: Bryan Gleeson Cc: ipsec@tis.com, l2tp@zendo.com Subject: RE: comments on VPN framework document Date: Fri, 9 Oct 1998 22:57:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk > -----Original Message----- > From: Bryan Gleeson [mailto:BGleeson@shastanets.com] > Sent: Friday, October 09, 1998 9:00 PM > To: Stephen Waters; Bryan Gleeson > Cc: ipsec@tis.com; l2tp@zendo.com > Subject: RE: comments on VPN framework document > > > Stephen, > > > 1) L2TP seemed to get the thumbs-up on all count except > > security. If IPSEC > > is applied to the resulting > > L2TP UDP/IP packet in TRANSPORT mode, that does seem to solve > > the problems. > > > > I have never seen IPSEC-tunnel as being useful for LAN to > > LAN. It is fine > > for host-to-host, and for host to security gateway, but not > > LAN-LAN. Maybe > > it can be fixed, but in the meantime: > > Restricting the applicability of IPSEC to scenarios where one > party is a host seems very limiting, and not necessary. Making > small modifications to IPSEC to allow wider applicability of > its use in non-host contexts definitely seems something that > should be pursued. Agreed, it needs fixing. > > > > > L2TP tunnel packets protected with ESP encryption would add > > as little as 9 > > bytes of ESP overhead. > > The encryption algorithm used may add another 8 to 14bytes and the > > authentication option another > > 12 bytes. However, these encryption/authentication > overheads would be > > incurred whatever route you take, so it comes back to 9 bytes > > per packet > > additional for ESP overhead. Four bytes of this overhead > is used to > > prevent replay attacks, and four bytes are used to multiplex. > > The four > > bytes of replay protection are a general requirement, so they > > remain 5 bytes > > (multiplexing and next-hdr bytes) are the only true over head > > of applying > > ESP transport mode. > > While the extra bytes needed on the data plane may or may not > be viewed as significant (and there's the PPP and UDP overhead > also), there is the additional requirement of the L2TP signalling > component, and its associated configuration. To me it just seems > hard to justify why you need two of something, if one will do. > I see the same motivation driving the idea of allowing a remote > host's IP address and DNS server to be configured via ISAKMP, > rather than requiring PPP-IPCP or DHCP as well. It also seems > more pragmatic that requiring stacks that look like > > APP/TCP/IP/PPP/L2TP/UDP/IPSEC/IP/L2/L1 > > (I'm sure ISO-OSI would have been proud of that one :-) So the difference would be: [IP2][IPSEC][UDP][L2TP][PPP][IP1][TCP][APP] now [IP2][IPSEC][ New Headers ][IP1][TCP][APP] later. The 'Newheader' would need to cover PPP-like and L2TP-like features. > > > 2) VPRNs look very complicated. The document is VERY > > VPRN-heavy, I feel. I > > am concerned that the VPRN model is both restrictive, > > inflexible and relies > > on security being managed for you by the VPRN provider. I > > much prefer the > > VLL approach described - just so you know :) > > The main benefit of a VPRN is that it allows for very > simple CPE devices, in simple connectivity scenarios. > If the CPE device just has a single link to the ISP > you can configure it with a default route and you are > done. The VPRN section describes a number of different > problems that need to be solved for any VPN (e.g. > membership and reachability determination and > dissemination). There are a number of ways to solve > each one, but I would not say that VPRNs are inherently > complicated. It is more a matter of where you place > the functionality - CPE router or ISP router. Also for > network based VPNs many of the same mechanisms are needed > whether the connectivity service provided is at layer 3 > or layer 2 (VPLS). > > There will never be a 'one size fits all' answer to > the level of trust a customer gives to a service > provider. The level of trust given to a provider > in the case of a VPRN is similar to that given to > a provider that provides an ATM PVC today. Packets > are switched inside the network, and sent to other > sites in the corporate network, and you assume that > they don't go to your competitor sites. A customer > can always choose to do more security, transparently > to the service provider. > Yes, just like Frame Relay and ATM - but aren't folk nervous of those links now? I thought the FR forum were doing some security work... > > > 3) I am not convinced the 'Compulsory' tunneling for remote > > access will be > > attractive (I'll get some heat for that one no doubt). Again, it is > > inflexible, insecure on the outer PPP links, and relies on > > the ISP providing > > authentication services. To protect the LAC-LNS flow would > > mean sharing > > ipsec security information with the ISP. Besides, > > 'Voluntary' sounds more > > friendly :). I think a vanila IPSEC tunnel in valuntary mode > > would do most > > folk - no L2TP. > > This seems an argument for using IPSEC by itself as a tunneling > protocol, and not requiring L2TP. I agree! > For IP-only networks, yes. Others would still need L2TP or one day the 'New Headers' and IPSEC. Thanks for the response Bryan. One aspect I wanted to see some focus on (and didn't spot) was end-to-end QOS monitoring - measuring dynamically how much of the 'guaranteed bandwidth' I'm actually getting through a VPN. Cheers, Steve. > Bryan > > > From owner-ipsec Fri Oct 9 18:28:35 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA09888 for ipsec-outgoing; Fri, 9 Oct 1998 18:27:59 -0400 (EDT) Message-Id: <199810092250.SAA10221@relay.hq.tis.com> Date: Fri, 9 Oct 98 18:35:50 EDT From: Charles Lynn To: Richard Draves cc: "'IPsec'" Subject: Re: inbound policy verification Sender: owner-ipsec@ex.tis.com Precedence: bulk Rich, et.al., Your question about why one should continue to search beyond the first matching SPD entry for an incoming packet, and other's comments, indicates that more explanation is needed. My understanding of the requirement is given below (maybe in too much detail :-). Maybe we can find a better solution to the problems, or legislate them away. First, in the common cases, I do not think one should get into the state described in the example you presented. What has never been mentioned in any of the discussion on this topic that I've seen, was how the lower precedence "net" policy SA for the host specified in the higher precedence "host" policy was created. It seems to me that the policy module should have told ISAKMP, or whatever KMP was used, to reject the net policy setup, since the ordered search of the inbound SPD (at SA setup time) would have first found the matching host entry and never proceeded to find the net one. Do you agree that it net SA should never have been created? If not, what scenario occurred to create it? On the other hand, if the policy module did (correctly) permit the net SA for the host to be created (for whatever reason), then looking beyond the host entry in the SPD during input packet processing would be necessary to allow that SA to be used. Do you agree? The architecture document described inbound and outbound SPDs (although some may implement a single one with a "direction" selector, or boxes with more than two interfaces might need a pair of SPDs per interface). However, there are no required ordering requirements between the policies expressed in the two (or more) SPDs. (Since it is "policy configuration", I doubt that we can legislate it. Doing so would require some module to compare the SPD entries for consistency. I suspect that would be A Good Thing, and some vendors may provide it, but I do not think that it should be a MUST. What do others think?) The next piece of the problem involves KMPs, such as ISAKMP, that negotiate a pair of SAs. If the order of the two policies at the initiator is different, then the KMP would setup both the outbound and inbound SAs based on the order in the outbound SPD. Does the KMP even check the inbound SPD to verify that the first matching selectors gave the same result? (What have implementors implemented?) We are now in the problem situation. When a reply packet arrives through the return SA the inbound SPD is searched during input processing, the different policy order might result in finding some other inbound SPD entry before the one that corresponds to the one used to setup the (outgoing) SA. In order for the packet to be accepted, one would have to continue searching the inbound SPD for the "proper" entry. The basic problem, in my opinion, is that the architecture describes a unidirectional model, but the KMP uses a bidirectional one. Where are the mechanisms needed to reconcile these perspectives defined? A third piece of the problem is the desire for "protocol, not implementation" that we all desire. At one point, there was a SAM and backpointers to the SPD entries. I think that was removed as being "implementation", not "protocol". Given that an SA may be shared between bundles, and a bundle may be used by multiple policies (or SPD entries), there may well be lists of lists that would need to be searched (at least if we want to allow sharing either now or in the future). I guess there is an engineering tradeoff between searching the SPD until one finds something acceptable and maintaining the backpointer lists and searching them. Maybe the architecture document made the wrong choice. Assuming that the security implications are the same, what do you think we should do? The architecture document could specify the backpointers (whether or not that is how an vendor chose to implement the functionality they describe). However, are the security implications the same? Your point is that it might be possible to exploit the "keep searching" rule. Would that, or related, vulnerabilities be reduced by using backpointers? We'll have to think a bit about that, I suspect. The answer may depend, in your example, on whether the KMP could have correctly setup that net SA. Note that if the order of the two SPDs is consistent, the situation you describe should not occur. If the communication used, e.g., well known ports, the situation would be less likely to occur. I do not think that we should rule out (not be able to protect) protocols that do not use well known (direction indicating) ports, or no ports at all. An additional point that we must not forget is that manually configured SAs must be supported. How they interact with the SPD(s), in particular with respect to ordering, needs to be considered. Charlie From owner-ipsec Fri Oct 9 19:18:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA09957 for ipsec-outgoing; Fri, 9 Oct 1998 19:17:08 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Stephen Waters , Bryan Gleeson Cc: ipsec@tis.com, l2tp@zendo.com Subject: RE: comments on VPN framework document Date: Fri, 9 Oct 1998 16:33:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, > So the difference would be: > > [IP2][IPSEC][UDP][L2TP][PPP][IP1][TCP][APP] now > > [IP2][IPSEC][ New Headers ][IP1][TCP][APP] later. > > The 'Newheader' would need to cover PPP-like and L2TP-like features. I think it depends on what the 'new headers' are and what procedures are needed to support them. At one extreme is a brand new tunneling protocol with its own set of signalling procedures, divorced from ISAKMP. In the middle would be a new protocol which did its signalling in an ISAKMP context, and which negotiated an extra layered 'SA' on top of an ESP/AH SA. The simplest approach is just to add some extra attributes to an ESP/AH SA. While there may be some scenarios which demanded the first or second cases, e.g. some new flow or congestion control scheme, I think that the third case can handle most common needs (e.g. multiprotocol / opaque transport for VPNs), and that for the common case the simplest solution possible should be pursued. > Thanks for the response Bryan. One aspect I wanted to see > some focus on (and didn't spot) was end-to-end QOS monitoring - > measuring dynamically how much of the 'guaranteed bandwidth' > I'm actually getting through a VPN. This is certainly an area that needs more analysis. I think one approach is to use a combination of RSVP, to reserve bandwidth between tunnel endpoints, and to treat a VLL just like any other (logical) interface on which traffic shaping, scheduling and policing can be carried out. Bryan From owner-ipsec Fri Oct 9 21:44:08 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA10417 for ipsec-outgoing; Fri, 9 Oct 1998 21:43:06 -0400 (EDT) Message-ID: <361EBFD4.F8D62375@brd.ie> Date: Sat, 10 Oct 1998 03:00:52 +0100 From: "Frank O'Dwyer" Organization: Rainbow Diamond Limited X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Waters CC: bgleeson@shastanets.com, ipsec@tis.com, l2tp@zendo.com Subject: Re: comments on VPN framework document References: <250F9C8DEB9ED011A14D08002BE4F64C01EB5978@wade.reo.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Waters wrote: > I have never seen IPSEC-tunnel as being useful for LAN to LAN. It is fine > for host-to-host, and for host to security gateway, but not LAN-LAN. Could you summarise the problem with IPSEC-tunnel for LAN-LAN use? Cheers, Frank O'Dwyer. From owner-ipsec Mon Oct 12 04:57:16 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id EAA15494 for ipsec-outgoing; Mon, 12 Oct 1998 04:48:13 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB598A@wade.reo.dec.com> From: Stephen Waters To: "Frank O'Dwyer" Cc: ipsec@tis.com, l2tp@zendo.com Subject: RE: comments on VPN framework document Date: Mon, 12 Oct 1998 10:02:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Frank, The VPN framework lists some of the problems, but my main problem with a plain 'IPSEC-tunnel' is that it is not a tunnel at all, really - just a security encapsulation scheme. If you encrypt the original IP header, what alternative have you got but to add another one. For LAN-to-LAN, I want to have a virtual IP interface to play with. An IP interface I can run routing over. For example: Virtual IP interface (16.36.16.200, RIP enabled) IP Tunnel (peer tunnel address 192.23.45.67) - a 'data-link' to the Virtual IP interface. IPSEC-transport-mode With IPSEC, there is no mechanism to define an 'Virtual IP interface' that can be managed as any other IP interface - routing/cost/filtering/.... Perhaps this is just the way that I (and others) have implemented it - following the basic model in the IPSEC architecture, i.e. the SPD model. Maybe the solution for LAN-to_LAN is to model IPSEC as a tunnel 'datalink' and have no SPD at all (or a single policy one): Virtual IP Interface (16.36.16.200, RIP enabled) IPSEC Tunnel 'data-link' (peer tunnel address 192.23.45.67, ESP/3DES tunnel) Now, if the IPSEC tunnel device could gain some of the features used in L2TP, we would have something for LAN-to-LAN. In the meantime, I'm thinking that L2TP+Transport-mode-IPSEC is as close as we can get today. Cheers, Steve. > -----Original Message----- > From: Frank O'Dwyer [mailto:fod@brd.ie] > Sent: Saturday, October 10, 1998 3:01 AM > To: Stephen Waters > Cc: bgleeson@shastanets.com; ipsec@tis.com; l2tp@zendo.com > Subject: Re: comments on VPN framework document > > > Stephen Waters wrote: > > I have never seen IPSEC-tunnel as being useful for LAN to > LAN. It is fine > > for host-to-host, and for host to security gateway, but > not LAN-LAN. > > Could you summarise the problem with IPSEC-tunnel for LAN-LAN use? > > Cheers, > Frank O'Dwyer. > From owner-ipsec Mon Oct 12 08:03:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA16287 for ipsec-outgoing; Mon, 12 Oct 1998 08:02:10 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199810091600.JAA01463@kebe.eng.sun.com> References: <199810091230.PAA10642@anise.tte.vtt.fi> from "Markku Savela" at Oct 9, 98 03:30:56 pm Date: Mon, 12 Oct 1998 08:16:44 -0400 To: Dan McDonald From: Stephen Kent Subject: Re: arch-07 and protocol mode stored in SAD? Why? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, >I have NEVER understood why people are so anal about tunnel vs. transport. >One is a case of the other, IMHO. Transport and tunnel mode require different processing for the external (outer) headers and differenbt processing upon receipt, e.g., which header is checked agaianst the selectors. Steve From owner-ipsec Mon Oct 12 08:14:19 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA16424 for ipsec-outgoing; Mon, 12 Oct 1998 08:14:11 -0400 (EDT) From: "Bernard Aboba" To: "Bryan Gleeson" , "Stephen Waters" Cc: , Subject: Re: comments on VPN framework document Date: Fri, 9 Oct 1998 19:19:38 -0700 Message-Id: <01bdf3f4$6e595540$0f8939cc@e1kj2.internaut.com> 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 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk >I see the same motivation driving the idea of allowing a remote >host's IP address and DNS server to be configured via ISAKMP, >rather than requiring PPP-IPCP or DHCP as well. Foisting lots of unrelated functionality onto a key management protocol is a supremely bad idea. Initial configuration is a specialized task that DHCP was designed to solve. Given that it has taken quite a while to converge dialup and LAN configuration (via DHCP-Inform), the last thing we need is to create yet another configuration mechanism. From owner-ipsec Mon Oct 12 10:23:30 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA16761 for ipsec-outgoing; Mon, 12 Oct 1998 10:22:11 -0400 (EDT) Message-Id: <199810121440.KAA20624@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-vpn-policy-schema-00.txt,.ps Date: Mon, 12 Oct 1998 10:40:24 -0400 Sender: owner-ipsec@ex.tis.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 : An LDAP Schema for Configuration and Administration of IPSec based Virtual Private Networks (VPNs) Author(s) : P. Bhattacharya, R. Adams, W. Dixon, R. Pereira, R. Rajan Filename : draft-ietf-ipsec-vpn-policy-schema-00.txt,.ps Pages : 40 Date : 09-Oct-98 This document describes the structure of an LDAP directory schema that enables policy based configuration and administration of IPSec based Virtual private networks within and among Internet domains, intranets, and extranets. The schema extends the base IPSec Policy data model in [9] to include end hosts and security gateways. The schema closely follows and expands on the DEN specification [7]. Internet-Drafts are 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-vpn-policy-schema-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-vpn-policy-schema-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-vpn-policy-schema-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981009155545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-vpn-policy-schema-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-vpn-policy-schema-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981009155545.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Oct 12 11:12:45 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA16980 for ipsec-outgoing; Mon, 12 Oct 1998 11:12:08 -0400 (EDT) Message-Id: <199810121530.LAA04179@clipper.hq.tis.com> X-Sender: balenson@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 12 Oct 1998 11:31:19 -0400 To: ipsec@tis.com From: "David M. Balenson" Subject: NDSS '99 Registration Now Taking Place!! Cc: balenson@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 3-5, 1999 Catamaran Resort Hotel San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Steve Kent, BBN Technologies Gene Tsudik, USC/Information Sciences Institute ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss99 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 1999 The 6th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Whitfield Diffie, Sun Microsystems. Co-author of "Privacy on the Line: The Politics of Wiretapping and Encryption." THIS YEAR'S TOPICS INCLUDE: - Secure Password-Based Protocol for Downloading a Private Key - A Real-World Analysis of Kerberos Password Security - Secure Remote Access to an Internal Web Server - Security and the User - Experimenting with Shared Generation of RSA Keys - Addressing the Problem of Undetected Signature Key Compromise - Practical Approach to Anonymity in Large Scale Electronic Voting Schemes - New Approaches to BGP Security - Distributed Policy Management for Java 1.2 - Distributed Execution with Remote Audit - Trust-Based Authentication in Open Networks - A Network Security Research Agenda - PGRIP: PNNI Global Routing Infrastructure Protection - A Cryptographic Countermeasure Against Connection Depletion Attacks - IPSec: Friend or Foe? EXPANDED PRE-CONFERENCE TECHNICAL TUTORIALS: - Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies) - Optical Network Security (Jeff Ingle and Dr. Eric Harder, NSA) - Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI) - Windows NT Security - Cryptography - Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI) - JAVA Security FOR MORE INFORMATION contact the Internet Society: Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA Phone: +1-703-648-9888 Fax: +1-703-648-9887 E-mail: ndss99reg@isoc.org URL: http://www.isoc.org/ndss99/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-648-9888 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. ---------------------------------------------------------------------------- David M. Balenson, Publicity Chair, NDSS '99 TIS Labs at Network Associates, Inc. 3060 Washington Road, Glenwood, MD 21738 USA balenson@tis.com; 301-854-5358; fax 301-854-5363 From owner-ipsec Mon Oct 12 11:43:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA17058 for ipsec-outgoing; Mon, 12 Oct 1998 11:42:08 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01C452D2@wade.reo.dec.com> From: John Bassett To: "'ipsec@tis.com'" Subject: Lifetime mismatch during phase1 Date: Mon, 12 Oct 1998 16:59:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, If, as a responder in a phase 1 exchange, I receive an SA proposal with a lifetime exceeding the value allowed by local policy, what action should I be taking ?. Should I be sending back a RESPONDER-LIFETIME notify along with the SA response (as described in the IPSEC DOI) or is the NOTIFY-SA-LIFETIME the correct code to use during phase 1? If it's the later is there a description of the parameters to the NOTIFY-SA-LIFETIME anywhere ? Thanks, John B. From owner-ipsec Mon Oct 12 13:00:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA17306 for ipsec-outgoing; Mon, 12 Oct 1998 12:59:16 -0400 (EDT) From: Dan McDonald Message-Id: <199810121717.KAA07557@kebe.eng.sun.com> Subject: LDAP draft problem... To: ipsec@tis.com Date: Mon, 12 Oct 1998 10:17:16 -0700 (PDT) X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk You've missed something important... > NAME SourceIPAddressRange > DESC Source IP addresses to which the policy applies > EQUALITY caseExactIA5Match > SYNTAX IA5String > SINGLE-VALUED > FORMAT SourceIPAddressRange is of the following form: three colon (':') > separated strings denoting a range of IP addresses. The > following formats are currently defined > > > 1:: > The IP v4 address is in dotted decimal format. The > CIDRPrefixLength is the number of unmasked leading bits. > A packet matches the condition if the unmasked > bits on the packet are identical to the unmasked bits on the > condition. > > > 2:: What about IPv6 addresses? Using a colon as a separator will break in the presence of IPv6 addresses. I don't even see IPv6 addressed in this document at all. Dan From owner-ipsec Mon Oct 12 13:59:35 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA17460 for ipsec-outgoing; Mon, 12 Oct 1998 13:59:18 -0400 (EDT) From: "Bernard Aboba" To: "Stephen Waters" , "Frank O'Dwyer" Cc: , Subject: Re: comments on VPN framework document Date: Mon, 12 Oct 1998 08:08:29 -0700 Message-Id: <01bdf5f2$2b45fe20$0f8939cc@e1kj2.internaut.com> 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 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk >'IPSEC-tunnel' is that it is not a >tunnel at all, really - just a >security encapsulation scheme. By my definition, a tunnel exists whenever you encapsulate one packet within another packet. By that scheme an IPSEC/IP tunnel is as much a tunnel as an IPSEC/L2TP tunnel. >If you encrypt the original IP header, >what alternative have you got but to >add another one. The same comment could be made about an L2TP packet, which is encrypted when contained in IPSEC/L2TP. >With IPSEC, there is no mechanism to define >an 'Virtual IP interface' that can be managed >as any other IP interface - routing/cost/filtering/.... > This is indeed a feature of your implementation. There is no intrinic reason why an IPSEC/IP tunnel cannot be treated as a virtual interface. IP-IP tunnels (for DVMRP, for example) have commonly been treated as virtual interfaces. >In the meantime, I'm thinking that >L2TP+Transport-mode-IPSEC is as close as >we can get today. > It is true that implementations of IPSEC/L2TP are often more advanced than IPSEC/IP implementations. However, let's not confuse details of implementations with discussions of the protocol differences. If we are attempting to discuss differences, we should focus on the ways in which IPSEC/IP and IPSEC/L2TP are different, namely the differences between IP and L2TP. There are no substantative security differences between IPSEC/IP and IPSEC/L2TP since both use IPSEC for security. From owner-ipsec Mon Oct 12 14:06:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA17594 for ipsec-outgoing; Mon, 12 Oct 1998 14:05:21 -0400 (EDT) Message-Id: <3.0.32.19981012114343.00ef4fd0@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 12 Oct 1998 11:43:44 -0400 To: Stephen Waters , bgleeson@shastanets.com From: Naganand Doraswamy Subject: Re: comments on VPN framework document Cc: ipsec@tis.com, l2tp@zendo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Can you copy these messages onto vpn@baynetworks.com mailing list as well. Thanks, --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Bay Architecture Lab (978)916-0620 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 From owner-ipsec Mon Oct 12 14:07:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA17623 for ipsec-outgoing; Mon, 12 Oct 1998 14:07:20 -0400 (EDT) Message-ID: <3622495F.8E4C0B49@brd.ie> Date: Mon, 12 Oct 1998 19:24:31 +0100 From: "Frank O'Dwyer" Organization: Rainbow Diamond Limited X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Waters CC: ipsec@tis.com, l2tp@zendo.com Subject: Re: comments on VPN framework document References: <250F9C8DEB9ED011A14D08002BE4F64C01EB598A@wade.reo.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Waters wrote: > The VPN framework lists some of the problems, but my main problem with a > plain 'IPSEC-tunnel' is that it is not a tunnel at all, really - just a > security encapsulation scheme. If you encrypt the original IP header, what > alternative have you got but to add another one. > > For LAN-to-LAN, I want to have a virtual IP interface to play with. An IP > interface I can run routing over. For example: > > Virtual IP interface (16.36.16.200, RIP enabled) > IP Tunnel (peer tunnel address 192.23.45.67) - a 'data-link' to the > Virtual IP interface. > IPSEC-transport-mode > > With IPSEC, there is no mechanism to define an 'Virtual IP interface' that > can be managed as any other IP interface - routing/cost/filtering/.... > > Perhaps this is just the way that I (and others) have implemented it - > following the basic model in the IPSEC architecture, i.e. the SPD model. Stephen, thanks for clarifying this - use of a virtual interface does sound more like a stack implementation issue than a protocol issue though (i.e. not a limitation of IPSEC-tunnel mode itself?). Or would something have to change on the wire protocol before you could implement that? It seemed to me from reading the I-Ds that the wire protocol was designed for host-host, host-gateway, gateway-gateway, and gateway-host modes--assuming the implementation is configurable enough. Have I missed something? Are any of these modes deprecated on security grounds (other than the obvious limitations of using a security gateway instead of an end-to-end protected connection)? Cheers, Frank O'Dwyer. [...] From owner-ipsec Mon Oct 12 14:25:56 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA17718 for ipsec-outgoing; Mon, 12 Oct 1998 14:25:20 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01EB598A@wade.reo.dec.com> Date: Mon, 12 Oct 1998 14:38:35 -0400 To: Stephen Waters From: Stephen Kent Subject: RE: comments on VPN framework document Cc: "Frank O'Dwyer" , ipsec@tis.com, l2tp@zendo.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, >The VPN framework lists some of the problems, but my main problem with a >plain 'IPSEC-tunnel' is that it is not a tunnel at all, really - just a >security encapsulation scheme. If you encrypt the original IP header, what >alternative have you got but to add another one. A tunnel, in th IP context, entails point-to-point encapsulation of traffic with an external IP header, designed to carry the traffic to a decapsulation point to which the traffic would not otherwise be routed. IPsec tunneling fits this definition, as does IP-in-IP and IPX-over-IP, etc. IPsec, because it has been designed for use with IP imposes certain processing on the content of tunnel mode traffic, specifically because IPsec is not just an encryption facility. It (usually) provides authentication and optional anti-replay, and embodies a simple form of access control. In tunnel mode, the headers use for access control are those encapsulated by IPsec, vs. use of the outer headers in transport mode. Steve From owner-ipsec Mon Oct 12 14:45:36 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA17841 for ipsec-outgoing; Mon, 12 Oct 1998 14:45:21 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB598E@wade.reo.dec.com> From: Stephen Waters To: Bernard Aboba Cc: ipsec@tis.com, l2tp@zendo.com Subject: RE: comments on VPN framework document Date: Mon, 12 Oct 1998 20:01:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk > >'IPSEC-tunnel' is that it is not a > >tunnel at all, really - just a > >security encapsulation scheme. > > By my definition, a tunnel exists whenever you > encapsulate one packet within another packet. > By that scheme an IPSEC/IP tunnel is as much a > tunnel as an IPSEC/L2TP tunnel. > I was comparing the IPSEC-tunnel (as defined in the IPSEC architecture) with other IP tunneling recommendations - all of which have much more too them than just encapsulating the original packet with an IP header. > >If you encrypt the original IP header, > >what alternative have you got but to > >add another one. > > The same comment could be made about an > L2TP packet, which is encrypted when contained > in IPSEC/L2TP. Again - I was making the point the adding an IP header is ALL the IPSEC tunnel is, nothing more. > > >With IPSEC, there is no mechanism to define > >an 'Virtual IP interface' that can be managed > >as any other IP interface - routing/cost/filtering/.... > > > This is indeed a feature of your implementation. > There is no intrinic reason why an IPSEC/IP > tunnel cannot be treated as a virtual interface. > IP-IP tunnels (for DVMRP, for example) have > commonly been treated as virtual interfaces. > There may be no reason why IPSEC/IP can't be treated as a virtual interface, but that is not the model defined in the IPSEC architecture where everything is driven from a security policy databases that are applied to data ON an interface, and a policy within a given SPD calling for tunnel-mode protection does not constitute an interface or anything that is managable as such. > > >In the meantime, I'm thinking that > >L2TP+Transport-mode-IPSEC is as close as > >we can get today. > > > > It is true that implementations of > IPSEC/L2TP are often more > advanced than IPSEC/IP > implementations. > > However, let's not confuse details > of implementations with discussions > of the protocol differences. > If we are attempting to discuss > differences, we should focus > on the ways in which IPSEC/IP and > IPSEC/L2TP are different, namely > the differences between IP and > L2TP. There are no substantative > security differences between > IPSEC/IP and IPSEC/L2TP since > both use IPSEC for security. > Let's hope so. Steve. > > > From owner-ipsec Mon Oct 12 15:07:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA17902 for ipsec-outgoing; Mon, 12 Oct 1998 15:06:20 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01EB598E@wade.reo.dec.com> Date: Mon, 12 Oct 1998 15:18:51 -0400 To: Stephen Waters From: Stephen Kent Subject: RE: comments on VPN framework document Cc: Bernard Aboba , ipsec@tis.com, l2tp@zendo.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, >I was comparing the IPSEC-tunnel (as defined in the IPSEC architecture) with >other IP tunneling recommendations - all of which have much more too them >than >just encapsulating the original packet with an IP header. > > >> >If you encrypt the original IP header, >> >what alternative have you got but to >> >add another one. >> >> The same comment could be made about an >> L2TP packet, which is encrypted when contained >> in IPSEC/L2TP. > >Again - I was making the point the adding an IP header is ALL the >IPSEC tunnel is, nothing more. Not quite true. There are processing rules for both sender and receiver that make IPsec tunnels more than you say here, e.g., how to construct the outbound header and what to check in the inner header upon receipt. Steve From owner-ipsec Mon Oct 12 15:27:42 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA17992 for ipsec-outgoing; Mon, 12 Oct 1998 15:27:20 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8142D@RED-MSG-50> From: Richard Draves To: "'Frank O'Dwyer'" , Stephen Waters , Bernard Aboba Cc: ipsec@tis.com, l2tp@zendo.com Subject: RE: comments on VPN framework document Date: Mon, 12 Oct 1998 12:44:17 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk > > With IPSEC, there is no mechanism to define an 'Virtual IP > interface' that > > can be managed as any other IP interface - > routing/cost/filtering/.... > > > > Perhaps this is just the way that I (and others) have > implemented it - > > following the basic model in the IPSEC architecture, i.e. > the SPD model. > > Stephen, thanks for clarifying this - use of a virtual interface does > sound more like a stack implementation issue than a protocol issue > though (i.e. not a limitation of IPSEC-tunnel mode itself?). Or would > something have to change on the wire protocol before you > could implement > that? I agree with Stephen on this - I think the security architecture document discourages the implementation of tunnel-mode SAs as virtual interfaces. At least for IPv6, there are real wire protocol implications to making something a virtual interface. IPv6 defines Neighbor Discovery, and if the tunnel is a virtual interface then I would expect ND to run over the tunnel. I would expect the virtual interface to have address(es) assigned to it (different from the IPv6 addresses assigned to the real interfaces). So at least with IPv6, there are real interoperability issues wrt implementing a tunnel-mode SA as a virtual interface. I believe that in practice, it is not possible to implement tunnel-mode SAs as virtual interfaces. Rich From owner-ipsec Mon Oct 12 16:17:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA18323 for ipsec-outgoing; Mon, 12 Oct 1998 16:16:23 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Bernard Aboba , Stephen Waters , "Frank O'Dwyer" Cc: ipsec@tis.com, l2tp@zendo.com, vpn@BayNetworks.COM Subject: RE: comments on VPN framework document Date: Mon, 12 Oct 1998 13:33:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Bernard, Stephen, > >'IPSEC-tunnel' is that it is not a > >tunnel at all, really - just a > >security encapsulation scheme. > > By my definition, a tunnel exists whenever you > encapsulate one packet within another packet. > By that scheme an IPSEC/IP tunnel is as much a > tunnel as an IPSEC/L2TP tunnel. I agree. Whether you choose in an implementation to model an IPSEC tunnel as a virtual interface or as an encapsulation method on an existing interface is an implementation issue, not a standards issue. I think there are a lot of benefits to modelling it as a virtual interface, as then you can treat all forms of tunneling in a similar manner. Also as 'policy' is something that you probably want to apply on all interfaces, physical or logical, you may also want, in an implementation, to have a common method of applying policy across all interfaces. The IPSEC documents kind of enmesh policy and protocol issues, for the purpose of describing the external functionality of a compliant implementation, but that's just a descriptive device. There is, however, one protocol issue which I believe unnecessarily complicates using an IPSEC tunnel as a virtual interface, and which should be addressed: Take a basic networking task (nothing to do with IPSEC) of configuring a point to point link (e.g. an ATM PVC) between two routers. When I configure the link I don't need to know the set of layer 3 packets that will at a later point travel over the link. Instead a set of packets, determined by a dynamic routing protocol, will be sent over the link, and this may change over time. So the steps are - configure the layer 2 link - turn on routing over this link - packets get sent on the link Now the problem with using an IPSEC tunnel in this way is that it is currently a requirement that when an SA is established between two routers (security gateways), it is necessary to specify the set of IP packets that will be sent over the SA - the proxy IDs (IDci and IDcr) in a Quick Mode message must be non zero. If you haven't, at this point, even turned on routing to run over this IP tunnel link, then you don't know what the set of packets will be. A mode of operation that allowed these fields to be unspecified would solve the problem. The security policy to be applied on the SA (by the receiver of the SA) could be determined by the identify of the Phase 1 negotiator, possibly in conjunction with extra information (such as a VPN-ID) conveyed before the Phase 2 exchange. Essentially this is a policy issue. The policy to be applied on a Phase 2 SA, should not have to be signalled in the establishment of the SA. We should allow the identification of the policy to be applied to be based on information other than the source and destination IP addresses of the packets that will be sent over the SA. This becomes particularly important if you are running a network where there are multiple domains (e.g VPNs) all using the same address space (e.g. 10.0.0.0/8). Bryan From owner-ipsec Mon Oct 12 16:22:37 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA18362 for ipsec-outgoing; Mon, 12 Oct 1998 16:22:21 -0400 (EDT) Date: Mon, 12 Oct 1998 16:40:01 -0400 (EDT) From: Henry Spencer To: Stephen Waters cc: ipsec@tis.com, l2tp@zendo.com Subject: RE: comments on VPN framework document In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01EB598A@wade.reo.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 12 Oct 1998, Stephen Waters wrote: > With IPSEC, there is no mechanism to define an 'Virtual IP interface' that > can be managed as any other IP interface - routing/cost/filtering/.... > Perhaps this is just the way that I (and others) have implemented it... Indeed so. In fact, the Linux FreeS/WAN implementation of IPSEC currently *does* use a virtual IP interface... and it causes enough headaches that we're going to do something different as soon as the evolution of the Linux kernel permits... Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Mon Oct 12 16:41:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA18433 for ipsec-outgoing; Mon, 12 Oct 1998 16:41:22 -0400 (EDT) Message-Id: <199810122056.NAA21894@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins owned process doing -bs X-Authentication-Warning: dharkins-ss20.cisco.com: dharkins@localhost didn't use HELO protocol To: Bryan Gleeson cc: Bernard Aboba , Stephen Waters , "Frank O'Dwyer" , ipsec@tis.com, l2tp@zendo.com, vpn@BayNetworks.COM Subject: Re: comments on VPN framework document In-reply-to: Your message of "Mon, 12 Oct 1998 13:33:09 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21892.908225769.1@cisco.com> Date: Mon, 12 Oct 1998 13:56:09 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan, Attempting to use a layer 3 security protocol to provide what is, in effect, layer 2 security is going to be problematic. No doubt about it. If you're deadset on doing this why not use a proxy identity type of subnet whose value is 0.0.0.0/0.0.0.0? Or why not just use the right tool for the right job: a link encryptor. Dan. On Mon, 12 Oct 1998 13:33:09 PDT you wrote > > Take a basic networking task (nothing to do > with IPSEC) of configuring a point to point > link (e.g. an ATM PVC) between two routers. > When I configure the link I don't need to > know the set of layer 3 packets that will at a > later point travel over the link. Instead a > set of packets, determined by a dynamic routing > protocol, will be sent over the link, and this > may change over time. So the steps are > > - configure the layer 2 link > - turn on routing over this link > - packets get sent on the link > > Now the problem with using an IPSEC tunnel in > this way is that it is currently a requirement > that when an SA is established between two > routers (security gateways), it is necessary > to specify the set of IP packets that will > be sent over the SA - the proxy IDs (IDci and > IDcr) in a Quick Mode message must be non zero. > If you haven't, at this point, even turned on > routing to run over this IP tunnel link, then > you don't know what the set of packets will be. > > A mode of operation that allowed these fields > to be unspecified would solve the problem. The > security policy to be applied on the SA (by > the receiver of the SA) could be determined > by the identify of the Phase 1 negotiator, > possibly in conjunction with extra information > (such as a VPN-ID) conveyed before the Phase > 2 exchange. Essentially this is a policy issue. > The policy to be applied on a Phase 2 SA, should > not have to be signalled in the establishment of > the SA. We should allow the identification of > the policy to be applied to be based on information > other than the source and destination IP addresses > of the packets that will be sent over the SA. This > becomes particularly important if you are running a > network where there are multiple domains (e.g VPNs) > all using the same address space (e.g. 10.0.0.0/8). > > Bryan > From owner-ipsec Mon Oct 12 16:41:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA18432 for ipsec-outgoing; Mon, 12 Oct 1998 16:41:21 -0400 (EDT) Message-ID: <003601bdf622$38775eb0$2b29e526@restart.osgroup.com> From: "Jeffrey Goodwin" To: "Bryan Gleeson" Cc: , , Subject: Re: comments on VPN framework document Date: Mon, 12 Oct 1998 15:52:26 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01BDF5F8.4F5F92C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0033_01BDF5F8.4F5F92C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >A mode of operation that allowed these fields >to be unspecified would solve the problem. The >security policy to be applied on the SA (by >the receiver of the SA) could be determined >by the identify of the Phase 1 negotiator, >possibly in conjunction with extra information >(such as a VPN-ID) conveyed before the Phase >2 exchange. Essentially this is a policy issue. >The policy to be applied on a Phase 2 SA, should >not have to be signalled in the establishment of >the SA. We should allow the identification of >the policy to be applied to be based on information >other than the source and destination IP addresses >of the packets that will be sent over the SA. This >becomes particularly important if you are running a >network where there are multiple domains (e.g VPNs) >all using the same address space (e.g. 10.0.0.0/8). Ashley Laurent, Inc. has developed extensions to IPSEC which solve this problem. We call it INS (Intranet Name Space). INS solves other problems as well, but this is one important one. We will be distributing an IETF draft which will be backed by several vendors in the next week or so (prior to the IPSEC bakeoff). The current version of our VPCom software implements the draft. ( www.VPCom.com ) Jeffrey Goodwin, Ashley Laurent, Inc. 707 West Avenue, Suite 201 Austin, TX 78701 512-322-0676; FAX: 512-322-0680 www.osgroup.com > >Bryan > ------=_NextPart_000_0033_01BDF5F8.4F5F92C0 Content-Type: text/x-vcard; name="Jeffrey M. Goodwin.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Jeffrey M. Goodwin.vcf" BEGIN:VCARD VERSION:2.1 N:Goodwin;Jeffrey;M. FN:Jeffrey M. Goodwin ORG:Ashley Laurent, Inc. TITLE:CEO TEL;WORK;VOICE:512 322 0676 TEL;WORK;FAX:512 322 0680 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;707 West Avenue=3D0D=3D0ASuite = 201;Austin;TX;78701;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:707 West Avenue=3D0D=3D0ASuite = 201=3D0D=3D0AAustin, TX 78701=3D0D=3D0AUSA URL: URL:http://www.osgroup.com EMAIL;PREF;INTERNET:jeffg@osgroup.com REV:19981012T205226Z END:VCARD ------=_NextPart_000_0033_01BDF5F8.4F5F92C0-- From owner-ipsec Mon Oct 12 17:52:42 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA18721 for ipsec-outgoing; Mon, 12 Oct 1998 17:51:23 -0400 (EDT) Date: Mon, 12 Oct 1998 15:09:16 -0400 From: Paul Krumviede Subject: Re: comments on VPN framework document To: Daniel Harkins Cc: Bryan Gleeson , Bernard Aboba , Stephen Waters , "Frank O'Dwyer" , ipsec@tis.com, l2tp@zendo.com, vpn@BayNetworks.COM Reply-to: paul@mci.net Message-id: <362253DC.8223B38B@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.06 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <199810122056.NAA21894@dharkins-ss20.cisco.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins wrote: > Or why not just use the right tool for the right job: a link encryptor. Because a tunnel can span more than one link? I think some of the ATM/FR link encryptors may work for this, but that doesn't help those who don't run that on our access links. -paul From owner-ipsec Mon Oct 12 17:52:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA18732 for ipsec-outgoing; Mon, 12 Oct 1998 17:52:23 -0400 (EDT) Message-ID: <6297CD447F92D11199F5006097BA9D1E216D30@tbu1.hifn.com> From: Raouf Eldeeb To: Bernard Aboba , Bryan Gleeson , Stephen Waters Cc: ipsec@tis.com, l2tp@zendo.com Subject: RE: comments on VPN framework document Date: Mon, 12 Oct 1998 15:14:44 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk >I see the same motivation driving the idea of allowing a remote >host's IP address and DNS server to be configured via ISAKMP, >rather than requiring PPP-IPCP or DHCP as well. Foisting lots of unrelated functionality onto a key management protocol is a supremely bad idea. Initial configuration is a specialized task that DHCP was designed to solve. Given that it has taken quite a while to converge dialup and LAN configuration (via DHCP-Inform), the last thing we need is to create yet another configuration mechanism. Routers are explicitly prohibited from being DHCP clients The same logic should apply to security gateways. There is no current configuration mechanism that works without some tweaking Raouf Eldeeb E-mail: rledeeb@hifn.com Hi/fn Tel: (408) 399-3578 From owner-ipsec Mon Oct 12 17:58:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA18756 for ipsec-outgoing; Mon, 12 Oct 1998 17:58:21 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Daniel Harkins , Bryan Gleeson Cc: Bernard Aboba , Stephen Waters , "Frank O'Dwyer" , ipsec@tis.com, l2tp@zendo.com, vpn@BayNetworks.COM Subject: RE: comments on VPN framework document Date: Mon, 12 Oct 1998 15:15:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > Attempting to use a layer 3 security protocol to provide what is, > in effect, layer 2 security is going to be problematic. No > doubt about it. > If you're deadset on doing this why not use a proxy identity > type of subnet > whose value is 0.0.0.0/0.0.0.0? If there was universal agreement on what this meant when you received it, there would not be a problem. However in previous email on this topic it was asserted that this would imply that I had a default route pointing out the SA. This is not true if there are separate inbound and outbound policies, i.e. just because I can receive from 'any' then it does not mean that I have to use that SA to send everything. Allowing the proxy ids to be omitted (or at a pinch included with the value 0.0.0.0) would certainly solve the problem, along with some explanatory text which indicated how this was to be interpreted. > Or why not just use the right tool for the right job: a > link encryptor. Not sure what you mean by 'link encryptor'. The endpoints of the IP tunnel could be separated by many intermediate routers. If IP is being used as a link layer (as it is when IP tunneling is being used, as seen, for example, by any routing instance that may be running over it) then using IPSEC just means you've got a secure link layer. Bryan From owner-ipsec Mon Oct 12 19:48:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA19026 for ipsec-outgoing; Mon, 12 Oct 1998 19:47:25 -0400 (EDT) Message-Id: <199810122354.QAA05351@chip.cisco.com> To: Bryan Gleeson cc: Bernard Aboba , Stephen Waters , "Frank O'Dwyer" , ipsec@tis.com, l2tp@zendo.com, vpn@BayNetworks.COM Subject: Re: comments on VPN framework document In-reply-to: Your message of "Mon, 12 Oct 1998 15:15:44 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5348.908236491.1@cisco.com> Date: Mon, 12 Oct 1998 16:54:52 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan, On Mon, 12 Oct 1998 15:15:44 PDT you wrote > > > Attempting to use a layer 3 security protocol to provide what is, > > in effect, layer 2 security is going to be problematic. No > > doubt about it. > > If you're deadset on doing this why not use a proxy identity > > type of subnet > > whose value is 0.0.0.0/0.0.0.0? > > If there was universal agreement on what this meant when you > received it, there would not be a problem. However in previous > email on this topic it was asserted that this would imply that > I had a default route pointing out the SA. What it's saying is that "I'm gonna stick anything I want into this tunnel and, likewise, I'll accept anything you choose to stick into it". In your example you wanted to configure a point-to-point link without knowing anything about the packets that would traverse the link; you wanted to do IPSec on IP packets without having to know the addressing of those packets. Having proxy IDs of "any to any" is a way to do this. If you have a routing table then you obviously care about the addressing of those packets and "any any" is not what you want. But that's a different scenario then what you described. And I don't know if there's universal agreement on this. I'm not sure whether those proxy IDs would be accepted by various implementations. "Encrypt anything and everything and send it to this single peer" may not be something every implementation can express. You can do it on my implementation but 99% of the time someone does it's not what they really intended and they're surprised by the result. > This is not true > if there are separate inbound and outbound policies, i.e. > just because I can receive from 'any' then it does not mean > that I have to use that SA to send everything. But in your example you didn't know that at SA establishment time. How is this policy established if you didn't know what you could route to in the first place? Are you dynamically modifying your IPSec policy based on routing updates? ("danger, danger, Will Robinson!") Dan. From owner-ipsec Mon Oct 12 23:28:12 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA19519 for ipsec-outgoing; Mon, 12 Oct 1998 23:26:28 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Daniel Harkins , Bryan Gleeson Cc: Bernard Aboba , Stephen Waters , "Frank O'Dwyer" , ipsec@tis.com, l2tp@zendo.com, vpn@BayNetworks.COM Subject: RE: comments on VPN framework document Date: Mon, 12 Oct 1998 20:43:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > > If there was universal agreement on what this meant when you > > received it, there would not be a problem. However in previous > > email on this topic it was asserted that this would imply that > > I had a default route pointing out the SA. > > What it's saying is that "I'm gonna stick anything I want > into this tunnel > and, likewise, I'll accept anything you choose to stick into > it". Having a policy, and signalling the policy to a remote party, are two separate things. No matter what someone signals, you will always want to check what they actually send. Therefore the "I'll accept anything you choose to stick into it" is not implied. A policy precedes (in time and importance) its signalling in any particular message. Thus it is more along the lines of "I'm not telling you in this message what I'm prepared to receive" [...] > > This is not true > > if there are separate inbound and outbound policies, i.e. > > just because I can receive from 'any' then it does not mean > > that I have to use that SA to send everything. > > But in your example you didn't know that at SA establishment time. How > is this policy established if you didn't know what you could > route to in > the first place? It is no different from any policy / access lists / firewalling capability that I apply today to a link over which I'm routing packets. > Are you dynamically modifying your IPSec policy based > on routing updates? ("danger, danger, Will Robinson!") No - there's no such implication that this is necessary or desirable and I agree that would be a Bad Thing. (even Dr Smith agrees :-) Bryan From owner-ipsec Mon Oct 12 23:48:53 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA19557 for ipsec-outgoing; Mon, 12 Oct 1998 23:48:30 -0400 (EDT) Message-ID: From: Bryan Gleeson To: Richard Draves , "'Frank O'Dwyer'" , Stephen Waters , Bernard Aboba Cc: ipsec@tis.com, l2tp@zendo.com Subject: RE: comments on VPN framework document Date: Mon, 12 Oct 1998 21:05:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Richard, > > Stephen, thanks for clarifying this - use of a virtual > interface does > > sound more like a stack implementation issue than a protocol issue > > though (i.e. not a limitation of IPSEC-tunnel mode > itself?). Or would > > something have to change on the wire protocol before you > > could implement > > that? > > I agree with Stephen on this - I think the security > architecture document > discourages the implementation of tunnel-mode SAs as virtual > interfaces. The architecture document should neither encourage or discourage local implementation choices. > At least for IPv6, there are real wire protocol implications to making > something a virtual interface. IPv6 defines Neighbor > Discovery, and if the > tunnel is a virtual interface then I would expect ND to run > over the tunnel. > I would expect the virtual interface to have address(es) > assigned to it > (different from the IPv6 addresses assigned to the real > interfaces). So at > least with IPv6, there are real interoperability issues wrt > implementing a > tunnel-mode SA as a virtual interface. I don't see the problem. In fact IPV6 explicitly addresses the use of IP as a link layer, and has developed a wider vocabulary to deal with tunneling issues than existed previously ... link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks as well as internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. interface - a node's attachment to a link. > I believe that in > practice, it is not > possible to implement tunnel-mode SAs as virtual interfaces. I know of implementations that do use tunnel mode SAs as virtual interfaces. Whether this is easy or hard depends primarily on where you are starting from. Bryan From owner-ipsec Tue Oct 13 00:11:37 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id AAA19610 for ipsec-outgoing; Tue, 13 Oct 1998 00:11:27 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81435@RED-MSG-50> From: Richard Draves To: "'Bryan Gleeson'" Cc: ipsec@tis.com, l2tp@zendo.com, Stephen Waters , Bernard Aboba , "'Frank O'Dwyer'" Subject: RE: comments on VPN framework document Date: Mon, 12 Oct 1998 21:29:19 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk > link - a communication facility or medium over which nodes > can communicate at the link layer, i.e., the layer > immediately below IP. Examples are Ethernets > (simple or bridged), PPP links, X.25, Frame Relay, > or ATM networks as well as internet (or higher) > layer "tunnels", such as tunnels over IPv4 or IPv6 > itself. > > interface - a node's attachment to a link. These definitions leave open the question of whether Neighbor Discovery (in whole or in part) should be operational over the link. For example, in the Carpenter/Jung "6-over-4" draft (in which IPv6 uses IPv4 as a virtual link layer), Neighbor Discovery in all its aspects is operational. With "configured tunnels" (a different technique that also tunnels v6 packets via v4), Neighbor Discovery is not operational. Implementations must agree on what aspects of ND will operate over the (virtual) link, or they will not interoperate. > > I believe that in > > practice, it is not > > possible to implement tunnel-mode SAs as virtual interfaces. > > I know of implementations that do use tunnel mode SAs as > virtual interfaces. Whether this is easy or hard depends > primarily on where you are starting from. Are these IPv6 implementations? If so, do they implement any aspects of Neighbor Discovery on those virtual interfaces? If they do, they might not interoperate with other implementations. (For example if the "virtual interface" implementation uses Neighbor Unreachability Detection over the tunnel and the other side does not respond appropriately.) Rich From owner-ipsec Tue Oct 13 01:00:19 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id AAA19760 for ipsec-outgoing; Tue, 13 Oct 1998 00:59:29 -0400 (EDT) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81437@RED-MSG-50> From: Richard Draves To: "'Charles Lynn'" Cc: "'IPsec'" Subject: RE: inbound policy verification Date: Mon, 12 Oct 1998 22:17:56 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk Charlie, thanks for your thoughts re my questions! > First, in the common cases, I do not think one should get into the > state described in the example you presented. What has never been > mentioned in any of the discussion on this topic that I've seen, was > how the lower precedence "net" policy SA for the host specified in the > higher precedence "host" policy was created. It seems to me that the > policy module should have told ISAKMP, or whatever KMP was used, to > reject the net policy setup, since the ordered search of the inbound > SPD (at SA setup time) would have first found the matching host entry > and never proceeded to find the net one. Let me restate the example, for those who've forgotten it: the inbound SPD in host H1 contains two policies. Policy P1 has a source address selector for a specific host H2. Policy P2 has a source address selector specifying a net N2. Host H2 belongs to net N2. Finally, the selectors in both policies are "take from policy" NOT "take from packet". So there is one inbound SAD entry corresponding to each policy. The idea is that all hosts in net N2 (except for host H2) should share a single SA1 when sending to host H1. Host H2 should use a different SA2 when sending to H1. I think this inbound policy on H1 should *enforce* this. If somehow H2 should use SA1 to send to H1 (maliciously or accidentally), then H1 should reject the packets. > Do you agree that it net SA should never have been created? If not, > what scenario occurred to create it? My understanding of ISAKMP is very incomplete, but from what I understand, it would not let this situation occur because it can't negotiate an SA that multiple senders can use. So for my example, assume manual configuration or some other KMP. > The basic problem, in my opinion, is that the architecture describes a > unidirectional model, but the KMP uses a bidirectional one. Where are > the mechanisms needed to reconcile these perspectives defined? I agree, the fact the architecture is more general than what ISAKMP can support is a source of confusion. > A third piece of the problem is the desire for "protocol, not > implementation" that we all desire. At one point, there was a SAM and > backpointers to the SPD entries. I think that was removed as being > "implementation", not "protocol". Given that an SA may be shared > between bundles, and a bundle may be used by multiple policies (or SPD > entries), there may well be lists of lists that would need to be > searched (at least if we want to allow sharing either now or in the > future). I guess there is an engineering tradeoff between searching > the SPD until one finds something acceptable and maintaining the > backpointer lists and searching them. Maybe the architecture document > made the wrong choice. > > Assuming that the security implications are the same, what do you > think we should do? The architecture document could specify the > backpointers (whether or not that is how an vendor chose to implement > the functionality they describe). > > However, are the security implications the same? Your point is that > it might be possible to exploit the "keep searching" rule. Would > that, or related, vulnerabilities be reduced by using backpointers? > We'll have to think a bit about that, I suspect. The answer may > depend, in your example, on whether the KMP could have correctly setup > that net SA. I think the security implications are not the same. With the "keep searching" rule, the inbound SPD will not enforce the desired policy for H2 in the above example. I think the architecture should define the desired semantics. Then implementations would be free to achieve those semantics using any optimizations they care to. Here's a modification of the example that might be simpler: suppose inbound policy P1 (for packets from H2) has an IPsec action of "discard" and inbound policy P2 (for packets from N2) has an IPsec action of "bypass". No SAs or KMP involved, just filtering. Then clearly when I receive a packet from H2, I want to stop at the first matching policy (P1) and discard the packet, right? Thanks, Rich From owner-ipsec Tue Oct 13 01:09:41 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id BAA19816 for ipsec-outgoing; Tue, 13 Oct 1998 01:09:34 -0400 (EDT) Message-Id: <199810130516.WAA02253@chip.cisco.com> To: Bryan Gleeson cc: Bernard Aboba , Stephen Waters , "Frank O'Dwyer" , ipsec@tis.com, l2tp@zendo.com, vpn@BayNetworks.COM Subject: Re: comments on VPN framework document In-reply-to: Your message of "Mon, 12 Oct 1998 20:43:21 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2251.908255794.1@cisco.com> Date: Mon, 12 Oct 1998 22:16:34 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan, On Mon, 12 Oct 1998 20:43:21 PDT you wrote > > > This is not true > > > if there are separate inbound and outbound policies, i.e. > > > just because I can receive from 'any' then it does not mean > > > that I have to use that SA to send everything. > > > > But in your example you didn't know that at SA establishment time. How > > is this policy established if you didn't know what you could > > route to in > > the first place? > > It is no different from any policy / access lists / firewalling > capability that I apply today to a link over which I'm routing > packets. I'm missing something here. You said you were establishing an IPSec tunnel as a point-to-point link in which you didn't know and didn't want/need to know what packets were being sent through it. That's *very* different than a typical access-list or firewall policy which cares very much about the addresses and port/protocol of the packets being sent through it. So if you don't know what the IP addresses are going to be apriori (your example that started this) then how are you defining your access-lists? What sort of firewall policy do you have that doesn't care about addressing? "permit all" or "forbid all" are very degenerate and pointless policies. Dan. From owner-ipsec Tue Oct 13 06:51:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id GAA20841 for ipsec-outgoing; Tue, 13 Oct 1998 06:44:30 -0400 (EDT) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB5990@wade.reo.dec.com> From: Stephen Waters To: ipsec@tis.com Subject: Where have you put your IPSEC? Date: Tue, 13 Oct 1998 12:01:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, >From some responses I've had about comments on the 'VPN framework' draft, it seems folk have implemented IPSEC in a number of ways for LAN-to-LAN. I'd be interesting in hearing which was the 'common path'. Let me know if I've missed one 1) IPSEC-tunnel as a 'data link': Virtual IP interface (address 16.36.x.x, RIP) IPSEC-tunnel 'data link' (peer address 192.1.2.3, protection 3DES+SHA1, IPCOMP) Real IP Interface (say the Internet interface) Note - little need for an SPD to build the IPSEC-tunnel datalink. 2) Non-IPSEC tunnel with IPSEC as 'packet-security-filter' Virtual IP interface (address 16.36.x.x, RIP) A Tunnel (GRE,IP-IP,L2TP(with a PPP layer above)...) Real IP Interface (say the Internet interface) - with IPSEC SPD associated Note - since a tunnel-header has already been applied by the time IPSEC SPD is invoked, transport-mode protection seems appropriate. 3) No Tunnel other and that applied by IPSEC as 'packet-security-filter' Real IP Interface (say the Internet interface) - with IPSEC SPD associated Note - IPSEC can be used to create tunnels here, but the tunnels do not constitute (in this model) an IP interface so can't be used to carry routing traffic. This is probably the approach used for remote-access IPSEC concentrators? Which have we done? Option 2. Why? Because I wanted to use the SPD as a security feature on the Internet interface in the same way as packet-filters - in fact to replace packet-filters. We also went for L2TP because we wanted a tunnel that would be suitable for all. Cheers, Steve. From owner-ipsec Tue Oct 13 06:51:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id GAA20860 for ipsec-outgoing; Tue, 13 Oct 1998 06:48:31 -0400 (EDT) Message-Id: <3.0.5.32.19981013130542.009e1660@cale.checkpoint.com> X-Sender: zegman@cale.checkpoint.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 13 Oct 1998 13:05:42 +0200 To: ipsec@tis.com From: Zegman Tamir Subject: Responder Lifetime Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Looking closely at the IPSEC DOI, I found the following paragraph regarding Responder Lifetime: "if the initiator offers an SA lifetime longer than the responder is willing to accept, the responder SHOULD include an ISAKMP Notification Payload in the exchange that includes the responder's IPSEC SA payload. Section 4.6.3.1 defines the payload layout for the RESPONDER-LIFETIME Notification Message type which MUST be used for this purpose." Later on it states: "Notification Status Messages MUST be sent under the protection of an ISAKMP SA: either as a payload in the last Main Mode exchange; in a separate Informational Exchange after Main Mode or Aggressive Mode processing is complete; or as a payload in any Quick Mode exchange. These messages MUST NOT be sent in Aggressive Mode exchange, since Aggressive Mode does not provide the necessary protection to bind the Notify Status Message to the exchange." 1. What is the meaning of "the exchange that includes the responder's IPSEC SA payload" in the case that the RESPONDER-LIFETIME refers to an ISAKMP SA? 2. If I send a RESPONDER-LIFETIME notification payload that refers to an IKE SA within a QM exchange, what should be in the DOI field of the notification payload? Should it be 1 for IPSEC or should it be 0 for ISAKMP? Regards, Tamir. ======================================================================== Zegman Tamir Encryption group, R&D Tel: +972-3-7534606 Check Point Software Tech. Ltd. Fax: +972-3-5759256 3A Jabotinsky St., Diamond Tower Ramat-Gan 52520, ISRAEL e-mail: zegman@checkpoint.com http://www.checkpoint.com ======================================================================== From owner-ipsec Tue Oct 13 08:42:47 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA21272 for ipsec-outgoing; Tue, 13 Oct 1998 08:40:31 -0400 (EDT) Message-Id: <199810131258.IAA20224@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com, vpn@BayNetworks.COM Subject: Re: comments on VPN framework document In-Reply-To: Your message of "Mon, 12 Oct 1998 22:16:34 PDT." <199810130516.WAA02253@chip.cisco.com> Date: Tue, 13 Oct 1998 08:58:27 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Daniel" == Daniel Harkins writes: Daniel> I'm missing something here. You said you were establishing an Daniel> IPSec tunnel as a point-to-point link in which you didn't know Daniel> and didn't want/need to know what packets were being sent through Daniel> it. That's *very* different than a typical access-list or Daniel> firewall policy which cares very much about the addresses and Agreed. Daniel> access-lists? What sort of firewall policy do you have that Daniel> doesn't care about addressing? "permit all" or "forbid all" are Daniel> very degenerate and pointless policies. permit all from interface internal0 forbid all from interface external0 :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Tue Oct 13 08:52:14 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA21500 for ipsec-outgoing; Tue, 13 Oct 1998 08:50:31 -0400 (EDT) From: "Bernard Aboba" To: "Raouf Eldeeb" , "Bryan Gleeson" , "Stephen Waters" Cc: , Subject: Re: comments on VPN framework document Date: Mon, 12 Oct 1998 23:34:39 -0700 Message-Id: <01bdf673$8dcb1310$0f8939cc@e1kj2.internaut.com> 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 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk >Routers are explicitly prohibited from being DHCP clients >The same logic should apply to security gateways. >There is no current configuration mechanism that works without >some tweaking > Routers most certainly function as DHCP relays today, and this is all a security gateway would need to do in order for this to work. The security gateway would not need to function as either a DHCP client or a DHCP server. From owner-ipsec Tue Oct 13 09:20:19 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA21669 for ipsec-outgoing; Tue, 13 Oct 1998 09:18:37 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Date: Tue, 13 Oct 1998 09:26:22 -0400 To: Bryan Gleeson From: Stephen Kent Subject: RE: comments on VPN framework document Cc: Daniel Harkins , Bryan Gleeson , Bernard Aboba , Stephen Waters , "Frank O'Dwyer" , ipsec@tis.com, l2tp@zendo.com, vpn@BayNetworks.COM Sender: owner-ipsec@ex.tis.com Precedence: bulk Bryan, >> > If there was universal agreement on what this meant when you >> > received it, there would not be a problem. However in previous >> > email on this topic it was asserted that this would imply that >> > I had a default route pointing out the SA. >> >> What it's saying is that "I'm gonna stick anything I want >> into this tunnel >> and, likewise, I'll accept anything you choose to stick into >> it". > >Having a policy, and signalling the policy to a remote party, are >two separate things. No matter what someone signals, you will >always want to check what they actually send. Therefore the >"I'll accept anything you choose to stick into it" is not >implied. A policy precedes (in time and importance) its >signalling in any particular message. Thus it is more along >the lines of "I'm not telling you in this message what I'm >prepared to receive" Right now IPsec is limited in how the end points can signal the range of traffic that should be sent and will be accepted over an SA. I agree in principle with your observation, but mismatches between a local policy and what is communicated via IKE are an obvious source of confusion. We'll soon be submitting a proposal for another protocol that can do a better job of communicating policy info, for use in parallel with IKE. That should help close the gap. Steve From owner-ipsec Tue Oct 13 11:50:57 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA22499 for ipsec-outgoing; Tue, 13 Oct 1998 11:48:38 -0400 (EDT) Date: Tue, 13 Oct 1998 12:05:02 -0400 Message-Id: <199810131605.MAA05987@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Stephen Waters Cc: Bernard Aboba , ipsec@tis.com, l2tp@zendo.com In-Reply-To: Stephen Waters's message of Mon, 12 Oct 1998 20:01:08 +0100, <250F9C8DEB9ED011A14D08002BE4F64C01EB598E@wade.reo.dec.com> Subject: Re: comments on VPN framework document Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Stephen Waters Date: Mon, 12 Oct 1998 20:01:08 +0100 There may be no reason why IPSEC/IP can't be treated as a virtual interface, but that is not the model defined in the IPSEC architecture where everything is driven from a security policy databases that are applied to data ON an interface, and a policy within a given SPD calling for tunnel-mode protection does not constitute an interface or anything that is managable as such. This seems to be a common misconception. The model defined in the IPSEC architecture is an abstract architecture; it describes the processing which is needed in order for us to achieve interoperability. Using the abstract model as an physical model results in an example implementation which is provably complaint to the architecture, but it is certainly not the only way you have to implement a compliant implementation. You may have other implementation issues which will require a different implementation strategy. The requirement is that the processing decisions made by your implementation have to comply with the architecture, for interoperability's sake. But the details of the implementation, and whether you have a viritual interface or not, is an implementation issue, not an architecture issue. For example, the elements of the SPD can be spread across multiple OS tables --- one of which might be your routing table which controls which virtual interface is selected for your outging traffic. Just remember, though, that by making the routing table part of the abstract SPD, the routing table now contains security sensitive data, and changes to the routing table will need to be protected appropriately, since changes will now have security impliciations. (This would be especially true for MLS systems, for example.) The moral of the story is that while you do have the freedom to implement different ways of approaching the IPSEC architecture, careful design and thought would be... ah..... strongly advised. - Ted From owner-ipsec Tue Oct 13 13:26:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA22909 for ipsec-outgoing; Tue, 13 Oct 1998 13:24:40 -0400 (EDT) Date: Tue, 13 Oct 1998 10:36:59 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <199810131736.KAA02019@locked.eng.sun.com> To: richdr@microsoft.com Subject: RE: inbound policy verification Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I think this inbound policy on H1 should *enforce* this. > If somehow H2 should use SA1 to send to H1 (maliciously or accidentally), > then H1 should reject the packets. > In Page 17 of the Security Architecture Draft, "Thus, to ensure consistent predictable processing, SPD entries MUST be ordered and the SPD MUST be searched in the same order, so that the first matching entry is consistently selected" In section 5.2.1, there is a "NOTE" which says "The correct matching policy will not be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked". If the entries are "ordered" (as stated by the previous statement), why search till we find a desired one for the packet ? I can take "ordered" as "I have ordered my policy entries. If the first one matches and if required IPSEC processing has not been done, drop the packet". What was the intention behind the NOTE on section 5.2.1 ? In case of wildcard PORTS/addresses would'nt it be nice for the admin to set up the policy in the right order and get a consistent behavior ? -mohan From owner-ipsec Tue Oct 13 19:36:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA24141 for ipsec-outgoing; Tue, 13 Oct 1998 19:34:58 -0400 (EDT) From: "Luis A. Sanchez" Message-Id: <199810131954.TAA02270@nutmeg.bbn.com> Subject: Security Policy Specification Language (SPSL) To: ipsec@tis.com Date: Tue, 13 Oct 1998 19:54:07 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Please check www.net-tech.bbn.com/pbsm/pbsm-index.html for a full specification of a Security Policy Specification Language (SPSL). This language is a vendor and platform independent language for specifying communication security policies, especially those controlling the use of IPSec and ISAKMP protocols. We have written a parser and we will release the code as soon as we can make it available. SPSL was designed to meet the following requirements: * Support for IPSec/ISAKMP and general communication security policy specification, * Support for both node and domain based policy models, * Support for multiple distributed policy enforcement points, * Support for authentication and authorization mechanisms to aid policy management, * Support for flexibility and extensibility of the language Luis From owner-ipsec Wed Oct 14 08:38:08 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA26676 for ipsec-outgoing; Wed, 14 Oct 1998 08:30:06 -0400 (EDT) Message-ID: <2BEB823971E7D11180120000F8B8479B21E767@sbuamalkg2ac.lkg.dec.com> From: Mingtai Chang To: ipsec@tis.com Subject: reading archive??? Date: Wed, 14 Oct 1998 01:14:14 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk A silly question: can someone tell me how I can read the the following ipsec mailing list archive below in its intended format?: Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec Thanks! From owner-ipsec Wed Oct 14 10:19:05 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA27279 for ipsec-outgoing; Wed, 14 Oct 1998 10:18:10 -0400 (EDT) Message-ID: <3624E20C.8@phase2net.com> Date: Wed, 14 Oct 1998 10:40:28 -0700 From: Jeff Pickering Reply-To: jpickering@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: [Fwd: Re: re-keying] Content-Type: multipart/mixed; boundary="------------133A63461D37" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------133A63461D37 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Any ideas on attached from anyone? jeff --------------133A63461D37 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <3623C28A.3BDC@phase2net.com> Date: Tue, 13 Oct 1998 14:13:46 -0700 From: Jeff Pickering Reply-To: jpickering@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: Tim Jenkins Subject: Re: re-keying References: <319A1C5F94C8D11192DE00805FBBADDF458CEA@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tim, Is the concept of simultaneous phase1 intiation supported in the architecture? I dont see anywhere in a spec that disallows this. If this is allowed, it would seem to me that the initial contact notification could cause problems: 1) Both end initiate phase1 at the same time. 2 Main mode exchanges are started. 2) Both ends receive the last initiator packet from the remote while waiting for a response to their own last initiator packet. 3) If these packets contain "intial contact", then both ends delete their own in process SA and get stuck??? It seems some absolute tie-breaker must be provided. For example, bgp uses router id to unambiguously resolve "connection collisions". Or am I missing something entirely??? regards, jeff Tim Jenkins wrote: > > From > > The Internet IP Security Domain of Interpretation for ISAKMP > > > ... > > 4.6.3.3 INITIAL-CONTACT > > The INITIAL-CONTACT status message may be used when one side wishes > > to inform the other that this is the first SA being established > with > the remote system. The receiver of this Notification Message might > > then elect to delete any existing SA's it has for the sending > system > under the assumption that the sending system has rebooted and no > longer has access to the original SA's and their associated keying > material. When used, the content of the Notification Data field > SHOULD be null (i.e. the Payload Length should be set to the fixed > length of Notification Payload). > > When present, the Notification Payload MUST have the following > format: > > o Payload Length - set to length of payload + size of data (0) > o DOI - set to IPSEC DOI (1) > o Protocol ID - set to selected Protocol ID from chosen SA > o SPI Size - set to sixteen (16) (two eight-octet ISAKMP > cookies) > o Notify Message Type - set to INITIAL-CONTACT > o SPI - set to the two ISAKMP cookies > o Notification Data - > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > -----Original Message----- > > From: Jeff Pickering [mailto:jpickering@phase2net.com] > > Sent: Tuesday, October 13, 1998 2:10 PM > > To: tjenkins@timestep.com > > Subject: re-keying > > > > > > Tim, > > > > I dont see "initial contact notification" described in any > > document. Can you give me a pointer? > > > > Thanks, > > jeff > > --------------133A63461D37-- From owner-ipsec Wed Oct 14 13:53:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA28412 for ipsec-outgoing; Wed, 14 Oct 1998 13:52:14 -0400 (EDT) Message-ID: <319A1C5F94C8D11192DE00805FBBADDF483055@exchange> From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Subject: IPSec Policy mailing list Date: Wed, 14 Oct 1998 14:11:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDF79E.093DFE20" Sender: owner-ipsec@ex.tis.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_01BDF79E.093DFE20 Content-Type: text/plain; charset="iso-8859-1" At IETF/Chicago, it was decided to create separate mailing lists for IPSec topics that required individual forums. IPSec Policy was one of those topics and we now have a mailing list dedicated to it. To subscribe to this mailing list, send an email to and include "subscribe ipsec-policy" in the body text. ------------------- SENDING EMAIL TO THE LIST ------------------------- To send email to the mailing list, address your email to: ipsec-policy@mail.timestep.com UNSUBSCRIBING ------------- If you ever want to remove yourself from this mailing list, you can send mail to: listserv@mail.timestep.com with the following command in the body of your email message: unsubscribe ipsec-policy PURPOSE OF LIST --------------- This mailing list is intended for discussions oriented toward policy as it relates to IPSec. "Policy" can include schema, architecture, discovery, distribution and any protocol associated with those functions. INTERNET DRAFTS --------------- Current internet drafts associated with IPSec Policy include: "IPSec Policy Data Model" "An LDAP Schema for Configuration and Administration of IPSec based Virtual Private Networks (VPNs)" "Secure Configuration of IPsec-Enabled Network Devices" "Security Policy Specification Language" RULES ----- (copied from the Firewall-Wizards mailing list) 1. Commercial postings are discouraged unless they are of high technical content. I.e.: it is OK to post a description of a product or how a product could help solve a problem. It is NOT OK to follow up to postings saying "buy our thing! it does that!" 2. It is acceptable to include URLs in postings that point to marketing materials on another website, as long as they are not the primary content of the posting. 3. Spam will be discarded without acknowledgement. 4. Flame wars are discouraged. If they happen, I will contact both parties out of band and ask them to desist. Postings to the effect of "stop this flamewar" will be discarded without acknowledgement but will be taken into consideration by the moderator. ------_=_NextPart_001_01BDF79E.093DFE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPSec Policy mailing list

At IETF/Chicago, it was decided to = create separate mailing lists for IPSec topics that required individual = forums.  IPSec Policy was one of those topics and we now have a = mailing list dedicated to it.

To subscribe to this mailing list, = send an email to <listserv@mail.timestep.com> and include = "subscribe ipsec-policy" in the body text.


-------------------

SENDING EMAIL TO THE LIST
-------------------------

To send email to the mailing list, = address your email to:

  = ipsec-policy@mail.timestep.com


UNSUBSCRIBING
-------------

If you ever want to remove yourself = from this mailing list, you can send mail to:
 
  = listserv@mail.timestep.com

with the following command in the body = of your email message:

  unsubscribe ipsec-policy


PURPOSE OF LIST
---------------

This mailing list is intended for = discussions oriented toward policy as it relates to IPSec.  =
"Policy" can include = schema, architecture, discovery, distribution and any protocol = associated with those functions.


INTERNET DRAFTS
---------------

Current internet drafts associated = with IPSec Policy include:

 "IPSec Policy Data = Model"
    = <draft-ietf-ipsec-policy-model-00.txt>
 "An LDAP Schema for = Configuration and Administration of
  IPSec based Virtual Private = Networks (VPNs)"
    = <draft-ietf-ipsec-vpn-policy-schema-00.txt>
 "Secure Configuration of = IPsec-Enabled Network Devices"
    = <draft-ietf-ipsec-secconf-00.txt>
 "Security Policy = Specification Language"
    = <draft-ietf-ipsec-spsl-00.txt>


RULES
-----

(copied from the Firewall-Wizards = mailing list)

1.  Commercial postings are = discouraged unless they are of
    high technical = content. I.e.: it is OK to post a description of a
    product or how a = product could help solve a problem. It is
    NOT OK to follow = up to postings saying "buy our thing! it
    does that!" =

2.  It is acceptable to include = URLs in postings that point to
    marketing = materials on another website, as long as they are
    not the primary = content of the posting.

3.  Spam will be discarded = without acknowledgement.

4.  Flame wars are discouraged. = If they happen, I will contact
    both parties out = of band and ask them to desist. Postings to
    the effect of = "stop this flamewar" will be discarded without
    acknowledgement = but will be taken into consideration by the
    moderator.




------_=_NextPart_001_01BDF79E.093DFE20-- From owner-ipsec Thu Oct 15 10:30:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA03554 for ipsec-outgoing; Thu, 15 Oct 1998 10:21:50 -0400 (EDT) Message-Id: <199810151439.KAA09375@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-secconf-00.txt Date: Thu, 15 Oct 1998 10:39:26 -0400 Sender: owner-ipsec@ex.tis.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 : Secure Configuration of IPsec-Enabled Network Devices Author(s) : S. Kelly, M. St. Johns Filename : draft-ietf-ipsec-secconf-00.txt Pages : 18 Date : 14-Oct-98 Remote configuration of network devices which implement IPsec- related services is desirable as a matter of convenience and of scale. In some cases, these devices are installed on a network with no prior configuration. In such cases, secure mechanisms for bootstrap configuration are required. In this document the associated issues are examined, and a multi-tiered approach is proposed from which a specific method may be selected based upon the security requirements of the environment in which the security device exists. While the primary devices considered here are security gateways and bump-in-the-wire encryptors, many of the resulting conclusions may extend to other devices, including host IPsec implementations. Internet-Drafts are 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-secconf-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-secconf-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-secconf-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981014151603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-secconf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-secconf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981014151603.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Oct 15 12:18:06 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA04211 for ipsec-outgoing; Thu, 15 Oct 1998 12:15:06 -0400 (EDT) Message-Id: <199810151633.MAA17886@venus.solidum.com> To: ipsec@tis.com CC: skelly@redcreek.com, stjohns@corp.home.net Subject: Re: I-D ACTION:draft-ietf-ipsec-secconf-00.txt In-reply-to: Your message of "Thu, 15 Oct 1998 10:39:26 EDT." <199810151439.KAA09375@ietf.org> Date: Thu, 15 Oct 1998 12:33:09 -0300 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In section 2.1, you write: > Entirely out-of-band configuration represents a seemingly trivial > case, although this process could be compromised in various ways. How could it be compromised? Section 3.1 doesn't really tell me much more. It seems to me that this situation is when you get the device, you plug into a serial port and/or attach to a mgmt network port, and configure things. The comments about securing the device during delivery (if this is done at the factory) seems justified though. Section 5.1 (on SNMPv3) needs to be expanded, and probably needs to borrow or reference specific discussions in the SNMP initial configuration debate. The SNMP WG archives are *full* of this stuff.. start around june 1996 :-) I think that the best (network, network) configuration method involves having a vendor owned key pair that goes into the firmware. You can do whatever initial IP, etc. stuff you need to get online, but to actually get the configuration saved, or examine any of the trusted store, you need to have a certificate, signed by your vendor, attesting to the fact that you own this box. This implies that the boxes need to have serial numbers in the firmware as well: but since this doesn't have to be a shared secret, it can easily go on a bar-coded label that gets processed by your shipping department. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNiYjw25vCG0TOZrRAQEe6wP+JoRca0ZhBCq/clTkRjm6pgywrJhcG1l7 QcJ0TMqqe3zV+WHpVHEu6YPk9IrJq2k0ve0qi2v7Fj+PZeD7apdUhHPg20fY2byR pOL0hdo5TbDV8ouUnqV4JOGHD2oslGHYT00w8teYfJzdxUeHlUAIJr9AHBdMe+t+ FrKc5QdjcwM= =dgEm -----END PGP SIGNATURE----- From owner-ipsec Thu Oct 15 12:56:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA04493 for ipsec-outgoing; Thu, 15 Oct 1998 12:55:07 -0400 (EDT) Message-ID: <36262D87.F4DF3378@redcreek.com> Date: Thu, 15 Oct 1998 10:14:47 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: Michael Richardson CC: ipsec@tis.com, stjohns@corp.home.net, ipsec-policy@mail.timestep.com Subject: Re: I-D ACTION:draft-ietf-ipsec-secconf-00.txt References: <199810151633.MAA17886@venus.solidum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I think we're supposed to discuss this on the new policy list, so I've included a cc: to ipsec-policy@mail.timestep.com. If anyone thinks otherwise, please speak up; otherwise, please delete ipsec@tis.com from the recipient list if you reply. Michael Richardson wrote: > > In section 2.1, you write: > > > Entirely out-of-band configuration represents a seemingly trivial > > case, although this process could be compromised in various ways. > > How could it be compromised? > Section 3.1 doesn't really tell me much more. It seems to me that this > situation is when you get the device, you plug into a serial port and/or > attach to a mgmt network port, and configure things. The comments about > securing the device during delivery (if this is done at the factory) seems > justified though. Section 3.1 notes that the config server could be compromised by installing hostile software. This hostile software could be a modified version of the config software, or it could be a shim which intercepts (and perhaps modifies) socket-layer communications, or it could be a rogue process, or a rogue driver, or it could be . Section 3.1 also notes that the device which is to be configured, if not secured from the point of manufacture to the point of installation, is subject to device substitution or firmware replacement. This probably should be made more clear, but means to point out that with no security precautions, you could be getting a device which has been intercepted and somehow preconfigured or otherwise modified. We can flesh this entire section out a bit more. > Section 5.1 (on SNMPv3) needs to be expanded, and probably needs to borrow > or reference specific discussions in the SNMP initial configuration > debate. The SNMP WG archives are *full* of this stuff.. start around june > 1996 :-) > Yes, there are a number of areas in the doc which need expansion and/or discussion. That's why it was released to the community while incomplete. > I think that the best (network, network) configuration method involves > having a vendor owned key pair that goes into the firmware. You can do > whatever initial IP, etc. stuff you need to get online, but to actually > get the configuration saved, or examine any of the trusted store, you > need to have a certificate, signed by your vendor, attesting to the fact > that you own this box. This implies that the boxes need to have serial > numbers in the firmware as well: but since this doesn't have to be a shared > secret, it can easily go on a bar-coded label that gets processed by your > shipping department. This is one of several cert mechanisms which will be included in a coming document rev, and I agree that it presents a good balance between security and convenience. From owner-ipsec Fri Oct 16 10:02:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA08253 for ipsec-outgoing; Fri, 16 Oct 1998 09:57:30 -0400 (EDT) Message-Id: <199810161415.KAA11705@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-cbc-04.txt Date: Fri, 16 Oct 1998 10:15:14 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. 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 ESP CBC-Mode Cipher Algorithms Author(s) : R. Pereira, R. Adams Filename : draft-ietf-ipsec-ciph-cbc-04.txt Pages : 13 Date : 15-Oct-98 This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. Internet-Drafts are 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-ciph-cbc-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-cbc-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-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: <19981015161552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-cbc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-cbc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981015161552.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Sat Oct 17 09:14:36 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA11496 for ipsec-outgoing; Sat, 17 Oct 1998 09:07:45 -0400 (EDT) Message-ID: <36289793.910F8F90@ire-ma.com> Date: Sat, 17 Oct 1998 09:11:48 -0400 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: "ipsec@tis.com" Subject: Client Identity Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Are there any restriction on the Identification Types of the IDci and IDcr? In other words, can client-initiator in Phase 2 send IDcr as a RANGE, SUBNET, FQDN, etc? I couldn't find any such restrictions in the draft-standards. Slava Kavsan IRE From owner-ipsec Tue Oct 20 08:15:57 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA21098 for ipsec-outgoing; Tue, 20 Oct 1998 08:06:13 -0400 (EDT) Message-ID: <362C8102.BFFDD8F8@Certicom.com> Date: Tue, 20 Oct 1998 08:24:34 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: IKE draft: F2m curves, m composite X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I'd like to get your attention on F2**m curves, m composite, again. IKE draft includes those curves at present, third and fourth Oakley groups specifically. FYI ------------------------------------------------------------------------------------- Miles Smid, NIST, made an announcement on Tuesday 10/13/98 that the DSS FIPS would be extended to include portions of X9.62 ECDSA, specifically when the fields are F2**p, p-prime. ------------------------------------------------------------------------------------- Just to remind you that the composite curves have been pulled from the ATM Forum's security standard as well. There should be a reason for that, shouldn't there. In his e-mail, Dan Harkins wrote > 6. There was also some desire to add new elliptic curve groups for > Diffie-Hellman. Perhaps new groups would be best handled by a > separate document. What do people feel? IKE or seperate document? I've been reading IPSec mailing list and nobody has written about it since then. What do you think? Should we add new EC groups into IKE or write a separate document? I think that in the last case we could move all DH groups into one single document describing DH and groups properties and IKE would just refer to that document as it needs to. Thanks, Yuri Poeluev ---------------- Certicom Corp. E-mail: ypoeluev@certicom.com Web site: http://www.certicom.com From owner-ipsec Tue Oct 20 10:20:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA21700 for ipsec-outgoing; Tue, 20 Oct 1998 10:14:13 -0400 (EDT) Message-Id: <199810201432.KAA19720@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-spsl-00.txt Date: Tue, 20 Oct 1998 10:32:47 -0400 Sender: owner-ipsec@ex.tis.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 : Security Policy Specification Language Author(s) : M. Condell, C. Lynn, J. Zao Filename : draft-ietf-ipsec-spsl-00.txt Pages : 43 Date : 19-Oct-98 This document describes the Security Policy Specification Language (SPSL), a language designed to express security policies, security domains, and the entities that manage the policies and domains. The syntax and semantics of the language are presented here. SPSL currently supports policies for packet filtering, IP Security (IPSec), and ISAKMP exchanges, however, it may easily be extended to express other types of policies. Internet-Drafts are 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-spsl-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-spsl-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-spsl-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981019103023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-spsl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-spsl-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981019103023.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Oct 20 14:21:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA22726 for ipsec-outgoing; Tue, 20 Oct 1998 14:17:23 -0400 (EDT) Message-ID: <00fa01bdfc5a$9dc3c130$0213b726@nt-file-server.dc.frontiertech.com> From: "Nishant Dani" To: , Subject: Re: [Fwd: Re: re-keying] Date: Tue, 20 Oct 1998 14:51:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk Is this a problem only with Phase 1 initiation? Even if we have both ends initiating a simultaneous rekeying, we may end up with an exact situation regarding the Quick Mode SA deletion on both the ends. And then both ends are stuck. I would think that there is more probability of the occurance of a QM deadlock rather than a Phase 1 deadlock, because firstly QM timeouts may be more frequent. So what does one do in such a case - how to detect unambigously the presence of a deadlock, and then how to proceed. Nishant Frontier Technologies Corp. 1. -----Original Message----- From: Jeff Pickering To: ipsec@tis.com Date: Wednesday, October 14, 1998 11:02 AM Subject: [Fwd: Re: re-keying] >Any ideas on attached from anyone? > >jeff > From owner-ipsec Wed Oct 21 10:43:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA26261 for ipsec-outgoing; Wed, 21 Oct 1998 10:36:40 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4AB96D@exchange> From: Tim Jenkins To: Nishant Dani , jpickering@phase2net.com, ipsec@tis.com Subject: RE: [Fwd: Re: re-keying] Date: Tue, 20 Oct 1998 16:30:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDFC68.7D897C80" Sender: owner-ipsec@ex.tis.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_01BDFC68.7D897C80 Content-Type: text/plain; charset="iso-8859-1" There is nothing in the drafts that indicate that this is a problem with quick mode. First, there are no restrictions on the number of phase 2 SAs between peers, even with the same selectors. Second, the initial contact notification is to be used only with phase 1 negotiations. If an implementation is able to simultaneously negotiate multiple phase 2 SAs, then there are no problems with phase 2. There is, of course, the issue of what you do with them once you have them; that's part of the reason for the re-keying document. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Nishant Dani [mailto:nishant@frontiertech.com] > Sent: Tuesday, October 20, 1998 2:51 PM > To: jpickering@phase2net.com; ipsec@tis.com > Subject: Re: [Fwd: Re: re-keying] > > > Is this a problem only with Phase 1 initiation? Even if we > have both ends > initiating a simultaneous > rekeying, we may end up with an exact situation regarding the > Quick Mode SA > deletion on both the ends. And then > both ends are stuck. I would think that there is more > probability of the > occurance of a QM deadlock rather than > a Phase 1 deadlock, because firstly QM timeouts may be more frequent. > > So what does one do in such a case - how to detect > unambigously the presence > of a deadlock, and then how to proceed. > > Nishant > Frontier Technologies Corp. > > > 1. > -----Original Message----- > From: Jeff Pickering > To: ipsec@tis.com > Date: Wednesday, October 14, 1998 11:02 AM > Subject: [Fwd: Re: re-keying] > > > >Any ideas on attached from anyone? > > > >jeff > > > ------_=_NextPart_001_01BDFC68.7D897C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: Re: re-keying]

There is nothing in the drafts that indicate that = this is a problem with quick mode. First, there are no restrictions on = the number of phase 2 SAs between peers, even with the same selectors. = Second, the initial contact notification is to be used only with phase = 1 negotiations.

If an implementation is able to simultaneously = negotiate multiple phase 2 SAs, then there are no problems with phase = 2. There is, of course, the issue of what you do with them once you = have them; that's part of the reason for the re-keying = document.

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Nishant Dani [mailto:nishant@frontiertech.com= ]
> Sent: Tuesday, October 20, 1998 2:51 PM
> To: jpickering@phase2net.com; = ipsec@tis.com
> Subject: Re: [Fwd: Re: re-keying]
>
>
> Is this a problem only with Phase 1 = initiation?  Even if we
> have both ends
> initiating a simultaneous
> rekeying, we may end up with an exact situation = regarding the
> Quick Mode SA
> deletion on both the ends.  And = then
> both ends are stuck.  I would think that = there is more
> probability of the
> occurance of a QM deadlock rather than
> a Phase 1 deadlock, because firstly QM timeouts = may be more frequent.
>
> So what does one do in such a case - how to = detect
> unambigously the presence
> of a deadlock, and then how to proceed.
>
> Nishant
> Frontier Technologies Corp.
>
>
> 1.
> -----Original Message-----
> From: Jeff Pickering = <jpickering@phase2net.com>
> To: ipsec@tis.com <ipsec@tis.com>
> Date: Wednesday, October 14, 1998 11:02 = AM
> Subject: [Fwd: Re: re-keying]
>
>
> >Any ideas on attached from anyone?
> >
> >jeff
> >
>

------_=_NextPart_001_01BDFC68.7D897C80-- From owner-ipsec Thu Oct 22 08:19:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA00372 for ipsec-outgoing; Thu, 22 Oct 1998 08:15:44 -0400 (EDT) Message-ID: <362F4F63.7570@phase2net.com> Date: Thu, 22 Oct 1998 08:29:39 -0700 From: Jeff Pickering Reply-To: jpickering@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: [Fwd: Re: re-keying] References: <319A1C5F94C8D11192DE00805FBBADDF4AB96D@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Deciding what to do when you end up with multiple successful p1 or p2 negotiations is exactly the issue as I see it. The re-keying document attempts to define how SA's get used in order to enable interoperability. I think the issue of simultaneous negotiations is part of this. jeff Tim Jenkins wrote: > > There is nothing in the drafts that indicate that this is a problem > with quick mode. First, there are no restrictions on the number of > phase 2 SAs between peers, even with the same selectors. Second, the > initial contact notification is to be used only with phase 1 > negotiations. > > If an implementation is able to simultaneously negotiate multiple > phase 2 SAs, then there are no problems with phase 2. There is, of > course, the issue of what you do with them once you have them; that's > part of the reason for the re-keying document. > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > -----Original Message----- > > From: Nishant Dani [mailto:nishant@frontiertech.com] > > Sent: Tuesday, October 20, 1998 2:51 PM > > To: jpickering@phase2net.com; ipsec@tis.com > > Subject: Re: [Fwd: Re: re-keying] > > > > > > Is this a problem only with Phase 1 initiation? Even if we > > have both ends > > initiating a simultaneous > > rekeying, we may end up with an exact situation regarding the > > Quick Mode SA > > deletion on both the ends. And then > > both ends are stuck. I would think that there is more > > probability of the > > occurance of a QM deadlock rather than > > a Phase 1 deadlock, because firstly QM timeouts may be more > frequent. > > > > So what does one do in such a case - how to detect > > unambigously the presence > > of a deadlock, and then how to proceed. > > > > Nishant > > Frontier Technologies Corp. > > > > > > 1. > > -----Original Message----- > > From: Jeff Pickering > > To: ipsec@tis.com > > Date: Wednesday, October 14, 1998 11:02 AM > > Subject: [Fwd: Re: re-keying] > > > > > > >Any ideas on attached from anyone? > > > > > >jeff > > > > > From owner-ipsec Thu Oct 22 10:19:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA00754 for ipsec-outgoing; Thu, 22 Oct 1998 10:15:52 -0400 (EDT) Message-Id: <199810221434.KAA20550@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-mib-01.txt Date: Thu, 22 Oct 1998 10:34:15 -0400 Sender: owner-ipsec@ex.tis.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 : IPSec Monitoring MIB Author(s) : T. Jenkins Filename : draft-ietf-ipsec-mib-01.txt Pages : 46 Date : 21-Oct-98 This document defines monitoring and status MIBs for IPSec. It does not define MIBs that may be used for configuring IPSec implementations or for providing low-level diagnostic or debugging information. Further, it does not provide policy information. Those MIBs may be defined in later versions of this document or in other documents. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPSec portion of their network. Statistics are provided as well. Internet-Drafts are 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-mib-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-mib-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-mib-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: <19981022101610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981022101610.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Oct 22 21:28:25 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA03358 for ipsec-outgoing; Thu, 22 Oct 1998 21:23:05 -0400 (EDT) Message-Id: <3.0.5.32.19981022214057.00a0f100@cpcug.org> X-Sender: jaubert@cpcug.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Oct 1998 21:40:57 -0400 To: ipsec@tis.com From: Jack Aubert Subject: Coursework research Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I request the indulgence of this list to ask if anybody can help point me in the right direction. I am doing some grad-school coursework in computer security and hope to do a brief paper on a topic connected with IPSec. Since IPSec is a rather complex group of standards I am still trying to wade through the principal RFCs and drafts and sort out the relationship of all the different parts of IPSec. I am interested in looking at management of the "many-to-many problem" -- a problem which may be faced by my own organization -- where you need to securely configure a potentially large number (e.g. several hundred to a few thousand) devices, each of which may need to communicate bilaterally with any other in the system without a great deal of manual labor. Are there any RFCs or drafts that deal with this issue... and are there alternative approaches? I will greatly appreciate any pointers on this issue. Jack Aubert From owner-ipsec Fri Oct 23 08:36:19 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA05158 for ipsec-outgoing; Fri, 23 Oct 1998 08:32:13 -0400 (EDT) From: dbastien@galea.com X-Lotus-FromDomain: GALEA To: ipsec@tis.com Message-ID: <852566A6.00466685.00@gotlib.galea.com> Date: Fri, 23 Oct 1998 08:49:49 -0400 Subject: Re: I-D ACTION:draft-ietf-ipsec-mib-01.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk I need to know if these two statistics are increment, before or after the processing of the IPsec protocol: ipsecSaInboundTraffic ex: before:897bytes, after:847bytes. ipsecSaOutboundTraffic ex: before:847bytes, after:897bytes. Thanks, Dominique dbastien@galea.com From owner-ipsec Fri Oct 23 08:45:42 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA05182 for ipsec-outgoing; Fri, 23 Oct 1998 08:44:13 -0400 (EDT) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4AC0DC@exchange> From: Tim Jenkins To: dbastien@galea.com, ipsec@tis.com Subject: RE: I-D ACTION:draft-ietf-ipsec-mib-01.txt Date: Fri, 23 Oct 1998 09:03:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDFE85.979C1AF0" Sender: owner-ipsec@ex.tis.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_01BDFE85.979C1AF0 Content-Type: text/plain; charset="iso-8859-1" Those variables use the same definitions as the traffic expiration requirements of the drafts. They should therefore be the amount of data protected/serviced/etc. by the security service. This means the user's packet (or portion after the IP header in transport mode) plus any padding requirements etc. >From your example, I would make that mean after for inbound and before for outbound. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: dbastien@galea.com [mailto:dbastien@galea.com] > Sent: Friday, October 23, 1998 8:50 AM > To: ipsec@tis.com > Subject: Re: I-D ACTION:draft-ietf-ipsec-mib-01.txt > > > > > I need to know if these two statistics are increment, before > or after the > processing of the IPsec protocol: > > ipsecSaInboundTraffic ex: before:897bytes, after:847bytes. > > ipsecSaOutboundTraffic ex: before:847bytes, after:897bytes. > > > Thanks, > > Dominique > dbastien@galea.com > > > > ------_=_NextPart_001_01BDFE85.979C1AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-ipsec-mib-01.txt

Those variables use the same definitions as the = traffic expiration requirements of the drafts. They should therefore be = the amount of data protected/serviced/etc. by the security service. = This means the user's packet (or portion after the IP header in = transport mode) plus any padding requirements etc.

From your example, I would make that mean after for = inbound and before for outbound.

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: dbastien@galea.com [mailto:dbastien@galea.com]=
> Sent: Friday, October 23, 1998 8:50 AM
> To: ipsec@tis.com
> Subject: Re: I-D = ACTION:draft-ietf-ipsec-mib-01.txt
>
>
>
>
> I need to know if these two statistics are = increment, before
> or after the
> processing of the IPsec protocol:
>
> = ipsecSaInboundTraffic        &nb= sp; ex: before:897bytes, after:847bytes.
>
> ipsecSaOutboundTraffic    ex: = before:847bytes, after:897bytes.
>
>
> Thanks,
>
> Dominique
> dbastien@galea.com
>
>
>
>

------_=_NextPart_001_01BDFE85.979C1AF0-- From owner-ipsec Fri Oct 23 10:35:04 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA05687 for ipsec-outgoing; Fri, 23 Oct 1998 10:32:25 -0400 (EDT) Message-ID: <363107E5.D5F25E10@tonghua.com.cn> Date: Fri, 23 Oct 1998 22:49:09 +0000 From: aqzhao X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: about draft "VPN framework" X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear Sir/Madam: In the draft 'A Framework for IP Based Virtual Private Networks' several tunnel protocols have been mentioned, including IP/IP,GRE tunnels,L2TP,MPLS and IPSec. Can anybody tell me the purposes and backgrounds for which these protocols were designed and their use environments. Thank you in advance. From owner-ipsec Fri Oct 23 12:53:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA06361 for ipsec-outgoing; Fri, 23 Oct 1998 12:50:19 -0400 (EDT) Message-ID: <3630B81D.A27B47E8@redcreek.com> Date: Fri, 23 Oct 1998 10:08:45 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.06 [en] (Win95; U) MIME-Version: 1.0 To: Jack Aubert CC: ipsec@tis.com Subject: Re: Coursework research References: <3.0.5.32.19981022214057.00a0f100@cpcug.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Jack Aubert wrote: > I am interested in looking at management of the "many-to-many problem" -- a > problem which may be faced by my own organization -- where you need to > securely configure a potentially large number (e.g. several hundred to a > few thousand) devices, each of which may need to communicate bilaterally > with any other in the system without a great deal of manual labor. Are > there any RFCs or drafts that deal with this issue... and are there > alternative approaches? You are really asking about 2 related issues here. You state one, i.e. secure configuration, and implicitly reference the other, i.e. scalable policy specification and distribution. There are several drafts which discuss these individually (copied from archived message): "IPSec Policy Data Model" "An LDAP Schema for Configuration and Administration of IPSec based Virtual Private Networks (VPNs)" "Secure Configuration of IPsec-Enabled Network Devices" "Security Policy Specification Language" From owner-ipsec Fri Oct 23 13:56:11 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA06699 for ipsec-outgoing; Fri, 23 Oct 1998 13:52:20 -0400 (EDT) Message-ID: <363101FB.2CBD632F@tonghua.com.cn> Date: Fri, 23 Oct 1998 22:23:55 +0000 From: aqzhao X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: about draft "VPN framework" X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear Sir/Madam: In the draft 'A Framework for IP Based Virtual Private Networks' several tunnel protocols have been mentioned, including IP/IP,GRE tunnels,L2TP,MPLS and IPSec. Can anybody tell me the purposes and backgrounds for which these protocols were designed and their use environments. Thank you in advance. From owner-ipsec Wed Oct 28 09:20:55 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA24222 for ipsec-outgoing; Wed, 28 Oct 1998 09:11:02 -0500 (EST) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199810281430.GAA15867@kc.livingston.com> Subject: Comments on draft-ietf-ipsec-pki-req-01.txt To: rodney@unitran.com Date: Wed, 28 Oct 1998 06:30:44 -0800 (PST) Cc: ipsec@tis.com, suresh@livingston.com (Pyda Srisuresh) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, Had a chance to review your draft. Nice and informative. Below are a few comments on the draft. 1. Certificate verification storage requirements In section 2.2, you say the IPsec device MUST support at least 8 signing certificates. Is the requirement necessary? Either you know to verify the signature or you dont. How does the number 8 help? Also, I believe, you neednt make the assumption that the IPSec device (that supports IKE) MUST do the signature verification by itself. It might take recourse of a CA to do the signature verification. Then, it becomes the head-ache of the CA to verify the entire certificate chain. 2. EKU field requirement In section 3.1.1, you state that an EKU entry MUST be set to IKEEnd or IKEIntermidate. Later on, in section 3.4.3, you say this field should be validated, if present. Likewise, in section 4.3 you make requirement for this field, a SHOULD. Clearly, these seem like inconsistencies in the draft. Personally, I dont see a reason for requiring this. Why should you have to create a cert just for IPsec? Are you saying that a certificate created otherwise (for use originally in non-IPsec applications) may not be valid for use by IPsec in some circumstances? How so? 3. SubjectAltName field requirement. In section 3.1.1, you say this is a MUST. Section 3.4.3 states this as a MAY. Section 4.0 (first paragraph) states this field as a required field for IPsec. Section 4.2 states that a Certificate request SHOULD contain this field. Once again, inconsistencies in the requirement terminology. Personally, I think, this is a SHOULD requirement, not a MUST. Here's why. An IKE initiator should be able to obtain peer's IP address from the certificate, in order to initiate a session. Clealry, SubjectAltName field in the cert (with an IP address value) is a requirement here. On the other hand, IKE responder needs to verify its peers's ID by retrieving a certificate of the peer and validating its authenticity. This time, however, the requirement is simply for a certificate that mateches the peer's ID. If the peer's ID happened to be an X.500 DN, which is the SubjectNAme of Certificate, thats all that is needed. Nothing else is required in SubjectAltName field. In other words, IKE initiator requires the peer's Cert to contain SubjctAltName (peer's IP address, really), whereas the responder does not require this always. 5. SubjectAltName values In Section 4.1.2, you state that this field should contain exactly one of IP address or DNS-Name or RFC-822 name. What is the problem in assigning multiple of these values? You will need to assign multiple values, many times. Example: a FQDN-name and an IP address, possibly multiple IP addresses. Also, you state that the DNS-name and RFC-822 names must be checked for their validity. Who should do this? Is this the PKI service provider who is issuing the Certificate? If so, are you suggesting that a secure-DNS and/or Spam-detection techniques are requirements for the CA? 6. Retrieval of a Certificate from PKI service provider (Section 3.2) There is no recommendation of a protocol or an automated means to retrieve certificates from CA. Also, Is there is a way to request a CA to validate a certificate signature chain? 7. Definition of "IPsec Usage Certificate" In section 4.3, your definition of "IPsec Usage certificate" mandates a public key component in a certificate. Are you saying certificates are not an appropriate infrastructure for PSK based IKE authentication? In a PSK based authentication, IKE responder might try to authenticate initiator's ID, by contacting a CA to obtain initiator's certificate. However, only a pre-shared key (not a public key) is required in the certificate. Thanks. Have a nice day. cheers, suresh From owner-ipsec Thu Oct 29 11:23:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA00075 for ipsec-outgoing; Thu, 29 Oct 1998 11:15:18 -0500 (EST) To: ipsec@tis.com Subject: proposal payload ID # X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 cc: itojun@itojun.org X-Mailer: comp (MHng project) version 1998/02/23 14:27:23, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Fri, 30 Oct 1998 01:33:41 +0900 Message-ID: <5126.909678821@turmeric.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipsec@ex.tis.com Precedence: bulk draft-ietf-ipsec-isakmp-10 (section 4.2) says that payload ID # of proposal payload and transform payload has to be "monotonically increasing number", as attached. I noticed that some of existing implementaton barks if we send non-contiguous proposal payload ID #, say 1,3,5. (they are happy with 1,2,3, or 10,11,12) I would like to know if non-contiguous ID # is allowed or not. I feel that, if we are to disallow non-contiguous number, the ID # has almost no meaning at all... Also, "monotonically" does not mean "contiguous". itojun@kame.net jun-ichiro itoh (proposal payload) >The Proposal payload provides the initiating entity with the capability >to present to the responding entity the security protocols and associated >security mechanisms for use with the security association being negoti- >ated. If the SA establishment negotiation is for a combined protection >suite consisting of multiple protocols, then there MUST be multiple Pro- >posal payloads each with the same Proposal number. These proposals MUST >be considered as a unit and MUST NOT be separated by a proposal with a >different proposal number. The use of the same Proposal number in mul- >tiple Proposal payloads provides a logical AND operation, i.e. Protocol >1 AND Protocol 2. The first example below shows an ESP AND AH protection >suite. If the SA establishment negotiation is for different protection >suites, then there MUST be multiple Proposal payloads each with a monoton- ~~~~~~~~ >ically increasing Proposal number. The different proposals MUST be pre- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >sented in the initiator's preference order. The use of different Proposal >numbers in multiple Proposal payloads provides a logical OR operation, >i.e. Proposal 1 OR Proposal 2, where each proposal may have more than one >protocol. The second example below shows either an AH AND ESP protection >suite OR just an ESP protection suite. Note that the Next Payload field >of the Proposal payload points to another Proposal payload (if it exists). >The existence of a Proposal payload implies the existence of one or more >Transform payloads. (transform payload) >The Transform payload provides the initiating entity with the capability >to present to the responding entity multiple mechanisms, or transforms, >for a given protocol. The Proposal payload identifies a Protocol for >which services and mechanisms are being negotiated. The Transform pay- >load allows the initiating entity to present several possible supported >transforms for that proposed protocol. There may be several transforms >associated with a specific Proposal payload each identified in a separate >Transform payload. The multiple transforms MUST be presented with mono- ~~~~~~ >tonically increasing numbers in the initiator's preference order. The ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >receiving entity MUST select a single transform for each protocol in a >proposal or reject the entire proposal. The use of the Transform num- >ber in multiple Transform payloads provides a second level OR operation, >i.e. Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows >two possible transforms for ESP and a single transform for AH. Example 2 >below shows one transform for AH AND one transform for ESP OR two trans- >forms for ESP alone. Note that the Next Payload field of the Transform >payload points to another Transform payload or 0. The Proposal payload >delineates the different proposals.