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

Re: (IPng) More Endpoint Attributes

Perry Metzger writes:

    Please do not confuse a Security Association with an SAID.  Security
    Associations can have all sorts of arbitrary properties associated
    with them by a key management protocol. An SAID is NOT the same as an
    SA -- it is just an index into a table of SAs. The index is not the
    map which is not the territory.

But that still means that a given transaction carries only a single SAID
which addresses a specific SA. In the MLS CMW world, any or all of the
attributes associates with one or both ends of a connections may modulate.
This means that we need a SAID for all the attribute combinations that
are used during a session. For example, in our (DEC MLS) world using
trusted X-windows, the process privilege set may modulate at a fairly
high frequency. In addition Information Labels may float based upon the 
data accessed and visible in a window at any given time. Now for any
given session there may not be a *lot* of different privileges and/or
information labels, but we still would need a SAID to represent each
combination used and the total number is multiplicative as we add more
users with different privileges, more sensitivity levels, etc.

For example, if a user at say "top secret" references unclassified,
secret and top secret information and the perhaps 2 privilege combinations
are used, then we would end up needing 6 SAID's at the end points.
If we had 10 users who could login at even 2 sensitivity levels and access
that same information, we need 20 times that number of SAID's. It quickly
gets out of hand.

In the TSIG TSIX model, the attributes are carried as 32-bit tokens
(similar in this case to SAID's but not necessarily the same) in a header
that inserted and removed between the user application layer and the
protocol layer.  If a given attribute changes, then only that token is sent.
The number of tokens needed in this case is additive and we only need
2+3+2+20=27.

In an IPv4 world, putting the attributes in the data stream was the
only viable approach, since there is not enough room in the IP header
for the full set of attributes and sending a single id to represent
a combination attributes gets back to the multiplicative problem above.

Now, in an IPv6 world the same approach of putting the attributes in
the data stream could still be taken and would work just as well. But it
is by no means an ideal approach and given the capabilities built into
IPv6 it would certainly seem reasonable to think about including the
attributes in either the authentication header, an ESP header, perhaps
in a separate well-defined header in its own right. Or, heaven-forbid,
using a reserved SAID to indicate in-line attributes. (I am fully prepared,
in light of the recent ipsec diatribes, for the flames to descend up
my head for having said that, but I did need to say it :-)

		/andy
Follow-Ups: