[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ISAKMP DOI Question (General, Not IP Specific)
In article <199612191714.MAA01212@earth.hpc.org> you write:
>> What worries me a little here (Steve Bellovin, help me out here anytime you
>> wish! :) is that I can specify the actually security association of the
>> outbound traffic.
>
>> On a single-user system, this isn't so bad, but on a multi-user box with
>> malicious users, this could cause all sorts of chosen-plaintext problems.
>
>It depends on your local policy. I've never quite understood why
>SPI's (as names standing for SA's) aren't under access control. If
>Alice creates it, why should Bob be allowed to use it?
The NRL implementation has always permitted IPsec users to request
"session-unique keying" that causes the kernel to enforce access control such
that no two sessions (not even two of Alice's sessions) could share any SA. I
believe that Dan McD's "Simple IPsec API" draft continues to contain this
capability. The NRL implementation permits the existence of shared SAs.
Shared SAs might be useful when manual key distribution is in use (hence the
number of SAs available for use might be smaller than is really desirable) AND
the node's users are not mutually suspicious.
The quoted text above are among the reasons both for this implementation
choice by NRL and also for the implementation requirement for "user-oriented"
(which is an awkward phrase at best) or "session-unique" keying in a node
implementing IPsec.
Ran
rja@cisco.com
Follow-Ups:
References: