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

Re: SAs and SPIs

   From: hsw@columbia.sparta.com (Howard Weiss)
   To: jas@shiva.com (John Shriver)
   Date: Tue, 19 Aug 1997 10:51:13 -0400 (EDT)

   [...]

   > 
   > I think that IPsec, AH, ESP, and ISAKMP/Oakley are fundamentally about
   > making a given network connection secure.  They are not about ensuring
   > that the data passed over that connection is the data that user is
   > allowed to pass to the peer.  (If I'm wrong on this, Randall's
   > description of the Security Policy Database is going to grow...)

   But the KM is all about this.  Why would two end-systems negotiate
   keys if they are not allowed to talk to one another.

But, let's suppose that we have ISAKMP/Oakley, and PKIX public keys
for the users.

Suppose that we think we can solve the problem by each system's ISAKMP
daemon having a configured access control list by X.509 usernames.
(Not a bad idea.)

But that still doesn't solve the proposed problem.  User A is in
groups 1 and 2.  User B is in group 1, user C is in group 2.  What is
to keep user A from taking a group 1 secret from B, and transferring
it to group 2 via C.  The same old MLS compartment problem.

Unless you assume that any user in more than one security group is
trusted, limiting SA's is not sufficient to provide the desired
security.  The secrets must be labeled, and that labeling preserved
across the network.

I suppose that since the system will enforce that data received on a
connection uses the right SA's, you could implicitly label the SA and
the socket, and not have to use the IP Security Option.

   If I've got
   sensitive data on my system, I don't want some system in the kiosk at
   Safeway to be able to negotiate an SA with me to be able to obtain my
   sensitive data (even if it will be protected while in transit across
   the murky, unsafe network!).

Well, that already in the SPD.  You can have a security policy of "no
SA's" for a range of IP addresses (like all outside your company).
This is explicit -- the "discard" result.

   Remember, the ISAKMP-DOI spells out the
   use of a security label.  The most recent IPSEC architecture talks
   about selectors for use in establishing SAs - and one of those
   selectors is an optional label.

As I expected.  I presume it's an IP-style one.

   Also, the original architecture doc
   always required per-user level keying - not just machine to machine
   keying.  One could easily extrapolate that the user-to-user keying
   would be based on a security policy which might enforce classification
   level, company proprietary information, need-to-know, etc.

Well, you can do something, as I noted above, but it will not be the
same as MLS without MLS systems everywhere.

Remember, even if the machine is single-user, that user may have
information from seperate compartments.  They still need that level of
MLS.
Follow-Ups: References: