Re: SecurID White Paper - A Comment
"Frederik H. Andersen" <fha@dde.dk> Wed, 11 September 1996 11:33 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa06711; 11 Sep 96 7:33 EDT
Received: by relay.hq.tis.com; id HAA04028; Wed, 11 Sep 1996 07:37:24 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma004011; Wed, 11 Sep 96 07:37:00 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA12562; Wed, 11 Sep 96 07:36:06 EDT
Received: by relay.hq.tis.com; id HAA04007; Wed, 11 Sep 1996 07:36:54 -0400
Received: from dde.dde.dk(152.95.32.2) by relay.tis.com via smap (V3.1.1) id xma003941; Wed, 11 Sep 96 07:34:10 -0400
Received: by dde.dde.dk (5.61/9.3) id AA04210; Wed, 11 Sep 96 13:36:21 +0200
Received: from Knud.dde.dk by dde.dde.dk (5.61/9.3) with SMTP id AA26790; Wed, 11 Sep 96 13:36:21 +0200
Received: by Knud.dde.dk (4.1/9.7) id AA16864; Wed, 11 Sep 96 13:35:50 +0200
Message-Id: <9609111135.AA16864@Knud.dde.dk>
X-Mailer: exmh version 1.6.6 3/24/96
To: Firewalls@greatcircle.com, ipsec@TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Subject: Re: SecurID White Paper - A Comment
In-Reply-To: vin's message of Tue, 10 Sep 1996 13:37:06 -0400. <v02130501ae5a3b32a10e@[204.167.109.37]>
Date: Wed, 11 Sep 1996 13:35:49 +0200
From: "Frederik H. Andersen" <fha@dde.dk>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hi! Have anybody tried or considered to implement encrypted or secure-hashed TCP-checksums of OTP validated connections? This should prevent TCP connection hijacking with a minimum of per packet overhead . The OTP validation phase should be enough for "synchronizing" the endpoints? I heard somebody suggest this once but I've forgotten whom. -- ------------------------------------------------------------------ Frederik H. Andersen Phone: +45 42 84 50 11 Dansk Data Elektronik A/S Fax: +45 42 84 52 20 Herlev Hovedgade 199 Email: fha@dde.dk (MIME accepted) DK-2730 Herlev, DENMARK ------------------------------------------------------------------ To: Tom Markson <markson@osmosys.incog.com> Cc: ipsec@TIS.COM Subject: Re: Status of IPSEC Key Management Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 11 Sep 1996 06:53:55 -0400 From: "Perry E. Metzger" <perry@piermont.com> Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9609110804.aa07041@neptune.TIS.COM> Tom Markson writes: > > [ Dan Harkins writes ] > > > > That's not necessarily true. The general SKIP case requires: 1) Certificate > > Discovery Protocol, two messages; 2) Algorithm Discovery Protocol, two > > messages; and, if PFS is desired, 3) the PFS extension, two more messages. > > A total of 6 messages required-- 4 if PFS is not desired. > > Not true. SKIP requires that communicating parties have each other's > certificates (keys). SKIP does not specify how this happens. > We tried to solve this key distribution problem by creating another > protocol which is not specific to SKIP. True enough. However, let us not pretend it isn't necessary. In most cases, it is necessary, and you have to count it in the overhead. > It is important to understand that once you have this certificate, > you do not need to get it again. Of course you do. Certificates don't exist forever, and you have to check CRLs and such. > > It also renders the SPI useless which makes RSVP support difficult (and > > calls into question full compliance with RFC1826 and RFC1827 since it is > > the MKID + IP address, not the SPI + IP address, that identifies state). > > This is only if you do RSVP based on SPIs. You can do RSVP based > on Master key IDs. I believe that the RSVP wanted a general mechanism, and not one tied to SKIP. Could you please accept that everyone on earth will not be using one key management facility and that the protocols must support this? Perry Date: Tue, 10 Sep 1996 15:01:38 -0700 (PDT) From: Dan McDonald <danmcd@lazlo.steam.com> Message-Id: <199609102201.PAA21461@lazlo.steam.com> To: ipsec@TIS.COM Subject: Re: Everything degenerates to Key Management Cc: danmcd@kebe.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk This is really strange. This is my third retransmit of this note. I'm using another account, just for exhaustiveness's sake. ANYWAY... ------------------ This is in reply to a note sent a bit back by Michael Richardson. <SNIP!> > skrenta> I'll submit that this has more to do with ACL management, i.e. the > skrenta> "naming problem", than the underlying encryption protocol. > > I agree with this. But, if we can not decide on what the underlying > encryption protocol is, then we can not even deploy the *simple* things > that people want to do. Thus the "groundswell" of support on the list for > SKIP. It solves these people's problems *now*. SKIP is not an "underlying encryption protocol." It is a method of transmitting the cryptographic keys so that encryption and decryption can take place, hence the term "key management." > Rather, you have to change your kernel unless someone decides to support > both, and I do not know how the two systems will interact. I have not seen, > for instance extensions to the BSD44 socket API on how SKIP will be > available to user processes wishing keying. (Yes, this is Unix specific, > but how many TCP/IP capable systems do *not* support some kind of BSD-like > socket API?) Network API extensions for having users turn on IP-level encryption or IP-level authentication haven't been thought out, from what I've seen. GSS-API may be useful in such a context, but I found the sheer bulk of it intimidating. The NRL IPv6/IPsec code has a _very_ primitive API for requesting security services. The above paragraph and its issues are ORTHOGONAL to what key management strategy is used. It doesn't matter if you implement one, the other, or both (and you CAN implement both, see below), it's still an issue. > skrenta> Designing crypto exchanges and packet formats is comparatively easy; > skrenta> informing your machine that it's supposed to encrypt with a > particular set > skrenta> of modes+algorithms to a particular (possibly randomly assigned) IP > skrenta> address is hard. But insofar as a workable solution is developed, I > skrenta> believe that it should prove fairly independent of the underlying > skrenta> encryption system. > > skrenta> This problem is really at a different level than the SKIP vs. Oakley > skrenta> debate, since neither set of drafts speak much to this issue. By that, if you mean setting up what ESP/AH algorithms are preferred, perhaps what ESP/AH algorithms are REQUIRED for communications on that machine, yes, it's a different level. It's called POLICY, and policy and mechanism are separate. If you mean what ESP/AH algorithms and modes can be used between a (possibly randomly assigned) IP address and me, there are already solutions for this. SKIP has its {Certificate, Algorithm} Discovery protocols, and the whole idea behind ISAKMP is that these very parameters are NEGOTIATED between the two machines before a session begins. Speaking of certificates, and problems orthogonal to key management debates, here's something I have to ask. _Regardless_ of key management, is it not true that each security endpoint is defined by the certificate associated with it? If so, this may answer questions about "user oriented" or whatever buzzwords you want to use to state that IPsec keys should be unique per session. > I had hoped that the meetings would come up with a way to incorporate > the SKIP header into the IPsec architectural draft (rfc1825). I have some > ideas on how to do this, but I do not have enough experience with both SKIP > and rfc1825 to do this on my own. I have plenty of experience with RFC 1825, and being where I am, I am quickly learning about SKIP. Quite frankly, I'm surprised nobody else has thought of the idea of having a "SKIP transform" that fits the relevant SKIP header information INSIDE a vanilla ESP or AH header. Quite frankly, in highly-modular environments (such as my current one), I can win big in implementation, because I have MUCH MORE control over the interface between transforms and ESP/AH, than I do between putting yet another higher-level protocol on top of IP. This control I mention allows better optimization and other code-reuse issues. In a not-so-modular environment (i.e. BSD) it's a wash, 6 one, half dozen the other. > If the stuff on the wire could be compatible at the "manual keying" > level, and an API similar to PF_KEY could accomodate SKIP keying, then we > could solve the other problems later. Some smart person may come up with a > hybrid solution that looks like neither solution. I have thought quite a bit about how PF_KEY could be made to accomodate SKIP keying. Particularly, the SKIP Kij keys could be computed in user-land, and fed into the kernel via PF_KEY, where they are used for the SKIP packets flowing across the wire. This also means you can build {Cert, Alg.} discovery in user-space as daemons. Unless I'm totally wrong about PF_KEY being able to work with SKIP, then it's VERY FEASIBLE to build SKIP, Oakley, and Photuris into the same box. More on this after I explain in-band vs. out-of-band... As for the stuff on the wire being compatible, the big difference between SKIP and your choice of Photuris or Oakley is that SKIP is in-band keying, where the session key is part of the packet (cryptanalysts, take note), and that both Photuris and Oakley are out-of-band keying, where an exchange (authenticated exchange, I hope :) takes place before data squeezes out of the wire. This difference in approach makes compatibility hard. Now that I've explained that, if you have PF_KEY that works, you can build ARBITRARY out-of-band keying systems. And with your favorite in-band keying system being implemented in-kernel (i.e. SKIP), you have a system that addresses ALL of your key management needs. Manual keying, BTW, is part of RFC 1825. I should be able to manually configure an SPI, with the relevant keying information. Tom Markson at Montreal mentioned that the latest SKIP release for {FreeBSD, SunOS 4.1,x} supports manual SPI's per RFC 1825. I hope this adds useful implementation-oriented data to the discussion. -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | SunSoft Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush + From: Rich Skrenta <skrenta@osmosys.incog.com> Message-Id: <199609102216.PAA14468@miraj.incog.com> Subject: Re: Status of IPSEC Key Management To: ipsec@TIS.COM Date: Tue, 10 Sep 1996 15:16:59 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > That's not necessarily true. The general SKIP case requires: 1) Certificate > Discovery Protocol, two messages; 2) Algorithm Discovery Protocol, two > messages; and, if PFS is desired, 3) the PFS extension, two more messages. > A total of 6 messages required-- 4 if PFS is not desired. CDP is only needed once for the lifetime of the key to obtain the long term certificate. And if DNSSEC is used, CDP isn't even necessary. ADP isn't needed if one has ACLs configured to choose the desired encryption algorithms. I send a triple-DES SKIP packet, if the other side is happy with that, the packet is accepted, and no ADP comes back. It is even possible to achieve PFS with SKIP without a "PFS exchange", by using short-lived keys certified with a long-term secret. One can thus "turn the PFS crank" at an administratively configurable interval. > ISAKMP+Oakley is one single key managment solution, not three. This is some creative line-drawing which lets SKIP be labeled as three separate key management solutions. However, I don't think the union of two independent (by themselves each quite complex) protocols is going to run away with the Simple moniker any time soon. One can of course draw a box around any arbitrarily high stack of paper. > It should also be noted that SKIP PFS and no pre-cached state requires > 2 Diffie-Hellman exponentiations-- once to compute g^xj and again to compute > g^ij. g^xj is only necessary if one is not doing host-host keying, and principal anonymity is desired. From: Tom Markson <markson@osmosys.incog.com> Message-Id: <199609102225.PAA15843@monster.incog.com> Subject: Re: Status of IPSEC Key Management To: Daniel Harkins <dharkins@cisco.com> Date: Tue, 10 Sep 1996 15:25:06 -0700 (PDT) Cc: sommerfeld@apollo.hp.com, smb@research.att.com, perry@piermont.com, kent@bbn.com, ipsec@TIS.COM X-Mailer: ELM [version 2.4 PL24 PGP5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk > [ Dan Harkins writes ] > > That's not necessarily true. The general SKIP case requires: 1) Certificate > Discovery Protocol, two messages; 2) Algorithm Discovery Protocol, two > messages; and, if PFS is desired, 3) the PFS extension, two more messages. > A total of 6 messages required-- 4 if PFS is not desired. Not true. SKIP requires that communicating parties have each other's certificates (keys). SKIP does not specify how this happens. We tried to solve this key distribution problem by creating another protocol which is not specific to SKIP. People naively assume this is a SKIP exchange. Base SKIP allows you to talk without any exchanges if you have a way to distribute keys and algorithm information. This could be done via hardware tokens, CDP, floppies, Directory Servers, Secure DNS or whatever. It is important to understand that once you have this certificate, you do not need to get it again. Algorithm information can be handled in the same way. This is why SKIP works in difficult environments such as one-way satellite broadcasts (where no exchanges are possible). > It also renders the SPI useless which makes RSVP support difficult (and > calls into question full compliance with RFC1826 and RFC1827 since it is > the MKID + IP address, not the SPI + IP address, that identifies state). This is only if you do RSVP based on SPIs. You can do RSVP based on Master key IDs. The master Key ID solves many of the limitations of the 32bit SPI by allowing more flexible naming schemes. > The multicast extension also doesn't scale well to highly dynamic multicast > groups (unicast request/response for every member to group owner to obtain > GIK). Ashar described a scheme in Montreal in which GIKs are distributed by an expanding ring multicast scheme. I believe this solves this problem. > > One way to do this would be to include fields saying "respond to this > > on SPI <NNN> until <expiration>" in the in-band-keying header; once an > > explicit SPI had been set up between peers, the in-band header would > > not be used. So would a message be sent back acknowleging this key change? What would you do if the key change packet was dropped? SKIP sends the key in each packet to avoid the problem with lost and out of order packets (one of the original goals of IP). This would also preclude the one-way Satellite environment I described above. --tom From: Charlie Perkins <charliep@watson.ibm.com> Message-Id: <9609111321.AA30717@hawpub1.watson.ibm.com> To: Stuart Jacobs <sjj0@gte.com> Cc: ipsec@TIS.COM, dbj@cs.cmu.edu Subject: Re: Status of IPSEC Key Management Date: Wed, 11 Sep 96 09:21:26 -0500 Sender: ipsec-approval@neptune.tis.com Precedence: bulk >> == Steve Kent > == Stuart Jacobs > Let me introduce myself. I am looking into ways to provide secure route > optimized mobile IP support for tactical battlefields and large commercial > network deployments. I have been following the mobile ip wp and ipsec wp > lists for a while and have come to believe that your point below is valid > >> but staying within the mobile IP protocol specs, there is no easy way to do >> the initial exchange. However, the fetch of a certificate from some >> database is outside the mobile IP protocol, and thus fits within the spec It's certainly true that mobile IP doesn't provide for fetching certificates. I hope that is viewed as a feature, since within the working group everyone generally felt that doing so was plainly another protocol, not mobile IP. > I also believe that the current mobile IP approaches, using a shared secret > keyed MD5 authentication, just will not scale up to 1000s of mobile hosts > and mobile routers. I don't understand this. Our intention was exactly that the protocol should be scalable to that point and beyond. We only specified that digital signatures be attached to control messages -- not to random data traffic that happens to pass through the home agent. A problem would result if the mobile node was trying to move to new care-of addresses too often, but the protocol is specified to be applicable when such movements occur no more often than once per second. My feeling is that it would generally work even if the registrations resulting from such movements were coming in at several times that rate -- it certainly works at greater speeds in our lab systems. If there are a LOT of mobile nodes, all registering very often, then mobile IP allows them to all use different home agents. We felt that this would enhance the scalability of the protocol. For further enhancements to scalability, I suggest a look at the proposed route optimization methods which would eventually relegate the home agent to a backup role. > The key distribution problem of the current mobile IP drafts seem adequate > for small network deployments. But what will happen when 10,000 mobile > hosts and mobile routers are roaming around in a hostile combat environment? That's a good question. But you have to do _something_ to make sure that those care-of addresses aren't forged, because the alternative problem is a lot worse. And, I would suggest that mobile IP can use whatever key distribution is eventually standardized within the IPsec working group. If not, then we had a serious misunderstanding of how key distribution would eventually work. > I also think that security associations Must exist between MHs and FAs as > well as FAs and HAs in both the military and commercial areas. The > commercial area needs this for non-reputable billing and the military for > network integrity. I'm interested in finding out more details about each of your assertions in the last sentence above. Our philosophy for the foreign agents has been that if an entity does the things that foreign agents are supposed to do, then that's good enough for the operation of the protocol, even if the entity is an intruder. Additional security requirements were supposed to be solved by additional security (or access control) mechanisms outside the mobile IP protocol. Moreover, the existing protocol does seem to provide for the operation you suggest, and if a security association exists between a MH and an FA, it MUST be used to authenticate registration messages. I think the idea was that no one would go to all the trouble of setting up such a security association unless it was really needed. > Stuart Charlie P.
- Re: SecurID White Paper - A Comment Frederik H. Andersen