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

Re: SAs and SPIs




--- On Mon, 18 Aug 1997 11:16:54 -0400  Thomas Bartee <tbartee@pop.erols.com> wrote:

There are portions of Tom's original note that I simply do not grok.
Hence, I'll not attempt to discuss those portions of his note.  I'm
happy to listen and happy to be educated, but I don't know how to respond 
meaningfully when I don't understand the question. (Mind, I sometimes
have trouble responding meaningfully even when I _do_ understand the question
on the floor. :-) :-)

> Let us suppose Amgen wants to use IPSEC to control and
> protect its transmitted and received messages. Within Amgen are a number of
> projects and the results and data associated with each project need to be
> protected from outside competitors. Also Amgen employees working on one
> project only in selected cases are allowed to receive results from other
> projects.  There are managers at several levels who have access to varying
> parts of the developments.  There is also a personnel dept., a medical
> dept., and a payroll-financial dept.  In addition, Amgen has research
> arrangements with five other biotech firms which work on several of the
> projects and there is some communication possible between several of them as
> well as with the relevant Amgen projects.

The above describes a security policy at a high level.  The IETF IPsec specs
are designed to support a wide variety of different kinds of policy, but the
IETF does not mandate any particular security policy.

>         Now, how are the SPI-SA combinations set up to handle this traffic
> and how are they (dynamically) controlled?  

Mechanistically, one could state that Key Management ("ISAKMP/Oakley plus the
IPsec DOI for ISAKMP" probably being the best example instance of Key Management)
negotiates the security parameters and creates the IPsec Security Associations
as necessary.  If the question is about mechanism for setting up SAs, this is
the answer (and reading the relevant drafts is the logical next step if one wants 
to understand the gory details)

Less mechanistically, the question above is perhaps considered to mean "How does 
AMGEN's security policy (whatever it happens to be) get implemented ?".  If this is
the question, the answer is that an IPsec/ISAKMP/Oakley/DOI implementation ought
to have some configuration parameters for the administrator of the system that
the IPsec/ISAKMP/Oakley/DOI implementation is running on.  The details of that
configuration is intrinsically an implementation-specific thing, not a matter
of IETF protocols.  

(ASIDE: The IPsec DOI for ISAKMP has a reasonably complete set of items that can be 
negotiated if desired; I'm not aware of any major deficiencies in the DOI draft 
currently online at ftp://ds.internic.net/internet-drafts; I believe that the 
PF_KEYv2 draft can express at least everything in the IPsec DOI for ISAKMP
draft.  NB: PF_KEYv2 is not an IETF thingy since its an
API spec.  The IETF doesn't standardise APIs.).

If one considers the situation where all this happens to be running on an MLS UNIX
box (B1 or better), then one can imagine that the security policy is driven by
(1) the Bell-LaPadula algorithms hardcoded into the Trusted Computing Base and 
(2) the sensitivity/integrity labels associated with objects in the system.  
As that TCB wanted to create network sessions, it could use PF_KEYv2 to request/acquire 
new IPsec SAs from Key Management.  It could use the PF_KEYv2 attributes to express 
the security properties needed for the desired IPsec SAs.  Those in turn could be 
expressed/negotiated securely to/with the remote end via ISAKMP/Oakley.  At that end, 
the KM entity could use PF_KEYv2 to add the appropriate IPsec SAs into that TCB.

Now ISAKMP needs to have authentication to prevent man-in-the-middle attacks; of
course this is already designed-in.  Consider that PK certificates could be used 
for this purpose and that those certificates could have information (signed by
a trusted party) about what kinds of data may be communicated with the identity
bound to that certificate.  Although not especially a fan of X.509, it seems clear
to me that X.509 certificates can contain lots of different kinds of data.

> Is there a methodology associated with this?  

Unclear antecedent "this".  Not sure what you mean.
Please clarify.

NB:  For reference, the examples I give above are JUST examples.  One could easily
imagine different situations, with different security policies, that would be
equally legitimate applications for IPsec/ISAKMP/Oakley/DOI technology.  Not
all IPsec DOI attributes are necessary for all IPsec SAs, either.

Ran
rja@inet.org



Follow-Ups: References: