[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MM with signatures and dynamic IP addresses?
Scott,
<<
Now I see where you've been going (at least, now that we've arrived :-)).
<<
I'm delighted to see that we understand each other :-)
>>
I think I like this, but there is still the issue with the binding of the
IDs to the phase 1 SA that I mentioned earlier.
>>
As I said in the other thread, I don't see what the issue is. You can have a
single phase 1 policy even if you and/or your peer have multiple phase 1 IDs.
<<
However, this is resolved by the use of one sgw ID cert with bindings
authorizing the sgw to represent specific endpoints. In that case,
authorized phase 2 IDs (DNs, etc) are included in the phase 2 ID payload,
so that one duly authorized phase 1 SA may be used for any/all of them
provided that PFS is not required. I should note that the sgw cert+bindings
is not my own idea, and that I gleaned it from an off-list email exchange.
>>
The way I interpret the Ike spec, the security gateway is simply trusted to act
on behalf of its clients and to vouch for the identity of its clients, without
any cryptographic delegation of authority. But one could do what you say if
that trust is not there. In any event, I think this is orthogonal to the
question of whether it is OK to have only one policy for phase 1, independent of
the identity of the peer.
Francisco
______________________________ Reply Separator _________________________________
Subject: Re: MM with signatures and dynamic IP addresses?
Author: Non-HP-skelly (skelly@redcreek.com) at HP-ColSprings,mimegw5
Date: 12/22/99 8:50 AM
Hi Francisco,
francisco_corella@hp.com wrote:
>
> Ari,
>
> We were just discussing pretty much this same issue in another thread.
>
> The issue also arises in other scenarios, and there are cases where the
> initiator rather than the responder faces the issue. For example:
>
> (*) The responder has a dynamically assigned IP address. The initiator is a
> security gateway negociating on behalf of a client. The client knows the
> dynamically assigned IP address of the responder, but the gateway does not. T
he
> client requests the establishment of a phase 2 SA with that IP address. The
> gateway must first set up a phase 1 SA with that address, but does not know wh
o
> it is talking to until it has received the ID payload from the responder durin
g
> the phase 1 exchange.
>
> (*) The responder has a perfectly normal statically assigned IP address. The
> intiator is a gateway with a policy for the responder, but the policy is index
ed
> by the distinguished name of the responder rather than by the IP address. A
> client of the gateway requests an SA with the IP address of the responder, and
> the rest is as above.
>
> Notice that the above two cases cannot be solved by the use of aggressive mode
.
For both of these cases, how does the client request the establishment
of a phase 2 SA with that IP address? If this is done via some sort of
signalling protocol, then perhaps the client could give some identity
information along with its request. The case where the negotiation is
activated by the sgw's receipt of a packet from the client to the
responder is less clear. If aggressive (or base) mode were used, it is
possible that that the intitiator would discover upon receipt of the
responder's SA+ID payloads that the selected parameters are not
acceptable, but recovery would not be too complex: fail the negotiation
and re-initiate based upon the supplied ID. However, see further
comments below.
> In my opinion, the solution to this is very simple: have a policy for phase 1
> that is independent of the peer. After all, one of the roles of phase 1 is to
> find out the identity of the peer, so it does not make sense to make phase 1
> policy dependent on who the peer is.
Now I see where you've been going (at least, now that we've arrived :-)).
I think I like this, but there is still the issue with the binding of the
IDs to the phase 1 SA that I mentioned earlier. However, this is resolved
by the use of one sgw ID cert with bindings authorizing the sgw to
represent specific endpoints. In that case, authorized phase 2 IDs (DNs,
etc) are included in the phase 2 ID payload, so that one duly authorized
phase 1 SA may be used for any/all of them provided that PFS is not
required. I should note that the sgw cert+bindings is not my own idea,
and that I gleaned it from an off-list email exchange.
> I believe this solution is consistent with RFC 2401. Perhaps it is even the
> behavior that was intended by the authors of RFC 2401. Am I right? In any
> event, a clarification in RFC 2401 would be useful.
I also believe that this is consistent with RFC2401.
Scott
Follow-Ups:
References: