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

Re: Per-socket policy and ISAKMP



> 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.)

Very definitely the former.  Applications have to be able say what
security policy they want on listen()ing sockets.  For example, even
rlogin and rsh are reasonable protocols between trusted hosts *if*
AH is used to verify the identity of the client.