[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: