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

Re: SAs and SPIs

> But, if:
> 
>   Amgen employees working on one project only in selected cases are
>   allowed to receive results from other projects.  
> 
> To me, first you have to solve that problem on one shared computer.  I
> think that takes B2 or C2 security at that level.  (I don't remember
> which is stricter: I'll assume B2 from here.  I'm sure David knows,
> given his ncsc.mil e-mail address!)

B2 requires more security mechanisms and requires an identifiable
entity that is referred to as a "reference monitor" or "security
kernel."  

What I don't understand is why you think that this must be solved on a
single, shared computer?  MLS has it heritage in the ability to
intermix users with varying clearances and information of varying
sensitivities on the same, single time-sharing system.  However, now
with client-server architectures, as Sun says, "The network is the
computer."  The "network-centric" notion is of a network trusted
computing base where each workstation may be multilevel secure in that
it may handle multiple levels of data depending on who is logged in at
what level(s).  And the file servers will handle everything
simultaneously - but no users are "logged" directly onto the server.

> Then, you add IP security labeling to extend that to connections
> between two B2 secure computers over a non-tappable network.  (Say
> hardware link encryption.)

And these B2 computers could be workstations - not just mini's or
mainframes. 

> Then, finally, you add IPsec AH and/or ESP to make that connection
> secure on a tappable network.
> 
> That's the layering I see.
> 
> 
> 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.  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!).  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.  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.

> Obviously, they must dovetail into the existing protocols and
> extensions that have been developed for TCP/IP to solve that problem.
> 
> 
> Or, is Thomas' message about inadequate integration between the needs
> of MLS (IP security option) and IPsec?  It's possible that that is the
> case, that's not an area I've paid much attention to!  Thomas?  Have I
> mis-interpreted you?
> 


-- 
 ___________________________________________________________________
|                                                                   |
|Howard Weiss                        phone (410) 381-9400 x201      |
|SPARTA, Inc.                              (301) 621-8145 x201 (DC) |
|9861 Broken Land Parkway, suite 300 fax:  (410) 381-5559           |
|Columbia, MD 21046                  email: hsw@columbia.sparta.com |
|___________________________________________________________________|
Follow-Ups: References: