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

Re: Granularity of authentication in swIPe




> I fully agree that the SAID is used to select previously negotiated
> options on a host-pair basis. So given that you can negotiate at key
> exchange time a much wider range of possible options than may be
> needed at any moment is it really necessary to have such a large SAID
> field?  Can you show examples of situations where more than O(256)
> such associations are really necessary?

In some applications one SAID per "user" does not seem unreasonable.

Suppose for example, I have a select group of users on machine X
that need to access services behind my firewall F.  Unfortunately,
X is also crawling with users who _dont_ need and shouldn't be
given access to resources behind F.

Let's say F uses swIPe to enforce it's access policy.  A requirement
of the policy is that access must be granted/denied on a per user
basis (not uncommon).  So it makes some sense to integrate key
exchange with user authentication and create one (or more?) SAID
for each user.

The alternative to using per user key exchange and per user SAIDs
would be to use one SAID for all X<->F communications.  But then
I'd have to rely on something like identd to identify individual
users on X, or rely on X itself to screen which users can and can't
use the X<->F tunnel.

Neither of these is acceptable.  For one thing, X may employ weaker
authentication controls than what I consider to be acceptable (e.g.
8 character reusable passwords).  Also, I dont want to futz around
with X specific naming details like usernames or uid's for my access
control lists on F; after all, these things are not under my control.
Lastly, there's no way I'm going to trust someone else to maintain
an access control list for determining who can use this X<->F
tunnel.  Even if I trust the admin of X, it's not her responsibility
to safeguard my network, and so it's unreasonable to make her
maintain my ACL's.

It's not hard to argue that machine X needs to be trusted regardless,
since it's kernel will be managing all security associations.  But
the only time I need to trust it is when one of my authorized users
is running an application that uses the X<->F swIPe tunnel.  If
the authentication elements for the X<->F swIPe tunnel are only
available when someone is using the tunnel there is much less risk
of the tunnel being subverted.

Now suppose one of these authorized users sits down in front of a
machine Z that she feels is trustworthy.  Trustworthy or not, my
firewall has never talked to Z before, so there may be little or
no common ground for a host based key exchange.

If my key exchange is based on per user authentication, then my
roaming user will have no problem establishing a swIPe tunnel
between Z and F even though the two machines have never spoken
before.


brad


References: