[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SecurID White Paper - A Comment

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.