[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SKIP Design & Applicability Statement
>There is one (important) aspect in which PFS offers a better defense than a
>non-PFS solution. Namely, if the key-compromise is discovered, the keys may
>be revoked, thereby protecting against future impersonation attacks and
>still preserving the secrecy of past encrypted data.
Key compromises don't have to be "discoverable" to make PFS
worthwhile. The PFS "crank" can be "turned" on a regular basis
according to local policy just as symmetric keys are periodically
refreshed. This limits the amount of data that can be compromised at
once to that sent after the last PFS rekey.
It seems to me that with the right protocol, then just having a PFS
update policy in place could create a considerable deterrent to the
active attack that can occur if a long-term authentication key is
compromised. That is, if I steal your long-term authentication key and
use it to impersonate you, I should be stuck. I should be required to
keep you from ever communicating again with the hosts I'm tricking,
because if you do you'll discover the attack and change your keys. I'm
not sure, but this does seem to require more state than SKIP provides.
Phil
From: Rich Skrenta <skrenta@osmosys.incog.com>
Message-Id: <199609092319.QAA13224@miraj.incog.com>
Subject: Re: Status of IPSEC Key Management
To: ipsec@TIS.COM
Date: Mon, 9 Sep 1996 16:19:00 -0700 (PDT)
In-Reply-To: <199609092151.RAA00478@thunk.orchard.medford.ma.us> from "Bill
Sommerfeld" at Sep 9, 96 05:50:58 pm
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
> Has anyone (other than me) considered a scheme whereby in-band
> messages are used to set up a SA, and thereafter omitted from the
> packets?
We've talked about possible optimizations and header compression schemes,
but haven't yet pursued these ideas, mostly because the size of SKIP
packets hasn't been an issue in our actual deployments. Compared with
other impacts on total performance (such as the speed of Triple DES in
software), a few extra bytes in each packet are not noticed.
Date: Mon, 9 Sep 1996 16:15:23 -0700
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199609092315.QAA25197@puli.cisco.com>
To: ipsec@TIS.COM
Subject: Re: bandwidth in the Internet
In-Reply-To: <96Sep9.181528edt.18434-1@janus.border.com>
Organization: cisco Systems, Inc., Menlo Park, Ca.
Cc:
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In article <96Sep9.181528edt.18434-1@janus.border.com>,
Harold Koch <chk@border.com> wrote:
>Are there really places in the Internet where this [bandwidth] is still
>a problem?
Sure. Lots of places.
>I suppose those asymmetric bandwidth cable modems might be a problem;
>any others?
Other current examples of low-bandwidth links in production TCP/IP use:
-- thousands (millions yet ?) of 28.8 modem dialup links
from Windows/Macintosh/etc users who go web surfing and
exchanging email via their Internet providers.
-- Satellite links, which are not that uncommon now and
which are growing rapidly. Hughes Network Systems
(Gaithersburg, MD) and other VSAT terminal manufacturers
are making nice profits selling IP/SATCOM services around
the globe. I even saw a VSAT advertisement in this month's
Computer Shopper. Emerging technologies such as Iridium
(which handles mobility via the link layer, btw) are also
fairly low bandwidth.
-- IP/AX.25 use by Amateur Radio operators. Rates of 2400 bps
are not unusual with IP/AX.25 links, though some are higher.
-- IP/HF Radio links are commonly used by various governmental
and military organisations both US Government and also other
governments. These frequently run at 2400bps.
Ran
rja@cisco.com
From: Dan McDonald <danmcd@pacific-86.eng.sun.com>
Message-Id: <199609092126.OAA28953@kebe.eng.sun.com>
Subject: Re: Everything degenerates to Key Management
To: ipsec@TIS.COM
Date: Mon, 9 Sep 1996 14:26:54 -0800 (PDT)
Cc: Dan McDonald <danmcd@pacific-86.eng.sun.com>
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
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 +
To: HUGO@watson.ibm.com
Cc: kent@bbn.com, ipsec@TIS.COM
Subject: Re: Status of IPSEC Key Management
Date: Tue, 10 Sep 1996 07:29:31 -0400
From: Steven Bellovin <smb@research.att.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609100737.aa24438@neptune.TIS.COM>
Steve, can you point out to what functionality of SKIP you are
referring to: is that the in-line keying or is it the 0-round
key agreement based on DH-certicates? These two aspects are
not necessarily bound together. For example, you can use
in-line keying based on a key-encrypting-key derived in some
other way (Oakley, for example), or you can use
DH-certificates as the basis for a hand-shake to derive fresh
keys.
I'm primarily referring to the in-line keying. The use of D-H is
elegant, though not, of course, necessary. (I proposed an in-line
keying mechanism in a 1990 paper.) But at this point in the game,
there isn't a lot of merit to inventing new protocols that do the
exact same thing as old ones. SKIP is fully developed and implemented;
without a demonstration of major new functionality, I'd be loathe
to pursue another path now.
Also, when you say SKIP you mean plain SKIP or SKIP with PFS?
Plain SKIP. SKIP with PFS demands negotiation. Let's make SKIP as
light-weight as possible, as it originally was, and use it for
a few selected applications. ISAKMP/Oakley is the full-fledged,
heavy-duty protocol that does everything.