Re: Everything degenerates to Key Management
Dan McDonald <danmcd@pacific-86.eng.sun.com> Tue, 10 September 1996 22:15 UTC
Received: from ietf.org by ietf.org id aa27467; 10 Sep 96 18:15 EDT
Received: from cnri by ietf.org id aa27463; 10 Sep 96 18:15 EDT
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa15604; 10 Sep 96 18:15 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa03949; 10 Sep 96 17:54 EDT
Sender: ietf-archive-request@ietf.org
From: Dan McDonald <danmcd@pacific-86.eng.sun.com>
Message-Id: <199609102010.NAA04270@kebe.eng.sun.com>
Subject: Re: Everything degenerates to Key Management
To: ipsec@tis.com
Date: Tue, 10 Sep 1996 13:10:06 -0800
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
X-Orig-Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
<NOTE: This is a retransmit. I haven't seen this note and it's been 24 hours. -- Dan McD.> 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 +
- Everything degenerates to Key Management David Wheeler-P26179
- Re: Everything degenerates to Key Management Robert Moskowitz
- Using SKIP as inspiration, not as gospel John Gilmore
- Re: Everything degenerates to Key Management Dan McDonald
- Re: Everything degenerates to Key Management Dan McDonald
- Re: Using SKIP as inspiration, not as gospel Rich Skrenta
- Re: Using SKIP as inspiration, not as gospel Rich Skrenta
- Re: Everything degenerates to Key Management Michael Richardson
- Re: Everything degenerates to Key Management Phil Karn
- Re: Using SKIP as inspiration, not as gospel ozan s. yigit