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