[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Per-socket policy and ISAKMP
Hello IPsec folks!
The IPsec crew here at Sun has been wondering something, and we've decided to
ask you.
Consider the following machine: It supports AH with both HMAC-MD5 and
HMAC-SHA-1, and has a global policy that all traffic except ISAKMP requires
the use of AH, regardless of algorithm. This global policy information is
easily available to ISAKMP so it can negotiate AH services effectively.
Now consider two sessions on this machine, both of which want to strengthen
global policy by specifying using HMAC-SHA-1 for its AH algorithm. The first
is an active session that will invoke ISAKMP as an initiator. Somehow ISAKMP
is notified that a session needs a pair of SAs, and in this notification the
SHA-1-only requirement is expressed. (In a PF_KEY implementation, this is
expressed in the SADB_ACQUIRE message.)
The second session, however, is a passive session (e.g. a TCP or UDP
listener). Some other machine will send the initial packet, and before that,
an ISAKMP request. If some other machine requests HMAC-MD5 for this session,
two things can happen. If my ISAKMP is not aware that the particular passive
session requires SHA-1, the ISAKMP negotiation will succeed, but packets will
be dropped because of per-session policy failure. (I.e. "I got AH with MD5,
but I wanted SHA-1. Drop the packet") Some may view this as an
access-control feature (if they don't know that algorithm my service wants,
they lose), but others may want ISAKMP to reject the request at the
key-exchange, to save pain, anguish and suffering.
My question is, which is preferable? Do per-socket aberrations to global
policy get expressed to key management? Or do they not get expressed?
If the answer is the former, BTW, look for a new PF_KEY message that'll
express this to a KMd. (It'll be a passive-side counterpart to the ACQUIRE
message.)
Thanks,
Dan
Follow-Ups: