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

Re: matching GW addr to ID payload (fwd)



Hi Mike,

Mike Carney wrote:
<trimmed...> 
> Another question of Tylors that I would like to repeat is as follows:
>
> If the authentication method is CERT based and the ID payload is IPV4_ADDR
> what restrictions must we place on the source IP of the packet and why?

I think requiring that the ID payload contents match some field in the
cert (e.g. subjectAltName) is necessary and sufficient.

> Second question:
> 
> If your phase 1 policy (crypto/hash/oakley group) is tied to your phase 1
> identity. How do you handle the problem that your phase 1 parameters are
> negotiated prior to knowing the phase 1 identity (In MM).
> 
> Our current approach has two aspects.
> 
> The first is whenever possible select the phase 1 parameters based on the
> source IP of the ISAKMP packet. This is where we run into problems with
> aliased address and multiple routes from the peer selecting different
> interfaces out of the peer.
> 
> The second is when the remote peer address is not known in advance.  In
> this case we select the highest security level possible and
> verify that the negotiated Phase 1 parameters meet the minimum requirements
> of the policy.  If they don't we abort the negotiation.
> 
> Another approach might be to let the negotiation proceed to the point
> of Phase 1 Identities being exchanged, then if the negotiated Phase 1 does
> not meet the exact requriements, abort the negotiation and turn the responder
> into the initiator (for phase 1), and initiate.  However, this could get one
> into an a never ending cycle if the two sides have conflicting Phase 1
> requirements.
> 

This is a problem we all have, and it would be nice to come up with
something better than our current options. We currently verify that
suggested options are acceptable for *some* SA before responding with
the first message. If possible (i.e. if we have only address-based
policies for that peer), we verify that the parameters match some policy
rule for that particular peer before proceeding.

One recovery strategy if the negotiation fails is to send a notify
message and use one of the new payloads described in the notify messages
draft to give the peer a clue as to an acceptable policy. Obviously,
this has some security implications in terms of exposing your policy,
but I don't think there are any real issues here.

Scott


References: