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

Re: MM with signatures and dynamic IP addresses?

Scott,

   <<
     I think that there must be some implied delegation. The problem here 
     is that if we don't provide some delegation mechanism, we run the risk 
     that some sgw may claim to represent an endpoint with access to our 
     network, and that someone may now put (spoofed) packets into the 
     tunnel. That sgw may be one that is granted access for some purpose, 
     but that we do not expect to represent the particular endpoint that it 
     subsequently impersonates. Nobody else (e.g routers along the way) can 
     see that this is occurring.
   >>
   
I'm not sure I understand all the details of the scenario you are 
describing.  Here are two comments (which may not be applicable if I have 
misunderstood):

(*) If the endpoint trusts the sgw sufficiently to delegate its 
capabilities to it, why wouldn't the peer that is negociating with the sgw 
trust the sgw?

(*) Wouldn't it be simpler set up a tunnel to the sgw, and then go through 
that tunnel to reach the endpoint and do an IKE exchange directly with the 
endpoint?
     
   <<
     By "one policy for phase 1" do you refer only to cryptographic parameters 
     (and not identities or authentication mechanisms), i.e all phase 1 SAs use 
     3DES/SHA1?
   >>
   
I refer to all the attributes that can be negociated in phase 1 using the SA 
payload and associated proposal and transform payloads.  These attributes are 
listed in Appendix A of the 5/99 Ike draft.

In particular, that includes the authentication mechanism.  For example, an 
ipsec administrator of an ipsec peer that implements preshared keys and 
signatures would have four choices for the phase 1 policy concerning the 
authentication mechanism:

(1) Use either preshared keys or signatures, with preshared keys preferred over 
signatures

(2) Use either preshared keys or signatures, with signatures preferred over 
preshared keys

(3) Use only preshared keys

(4) Use only signatures

Now suppose there are two such ipsec peers, and option (1) has been chosen for 
both of them.  Then the initiator will propose preshared keys as first choice, 
and signatures as second choice.  The responder also prefers preshared keys.  
However, the responder should first look up its database of preshared keys and 
check that it has a preshared key with the initiator.  If this is not the case, 
then the responder should choose signatures instead.

Can the responder do the preshared key lookup?  It definitely can in aggressive 
mode, since it has already received the Idi1 payload in message 1 by the time it
has to send the SA payload in message 2.  In main mode, on the other hand, the 
responder does not receive the Idi1 payload until message 5.  

But that's ok, because in main mode with preshared keys, the source IP addresses
are supposed to be used for identification instead of the ID payloads.  The 
responder will use the source IP address of the initiator to look up the 
database of preshared keys.  If a preshared key is not found for the source IP 
address of the initiator, then the responder will choose signatures instead.  
Authentication will then use the ID payloads exchanged in messages 5 and 6.

(By the way, that would not be ok if my recent proposal or other earlier 
proposals to fix main mode with preshared keys had been accepted.  So this could
be an argument against those proposals.  I'm now thinking that the best thing to
do about main mode with preshared keys would be to drop it altogether, since it 
does not seem to serve any useful purpose.  The advantage of main mode over 
aggressive mode is that it provides identity protection, but that advantage goes
away if the identity is the source IP address.  So why use main mode, which 
takes six messages, when aggressive mode does the same job with only three 
messages?)

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 1:44 PM


Hi Francisco,
     
francisco_corella@hp.com wrote:
     
<trimmed...>
     
> The way I interpret the Ike spec, the security gateway is simply trusted to ac
t
> 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.
     
I think that there must be some implied delegation. The problem here is 
that if we don't provide some delegation mechanism, we run the risk that 
some sgw may claim to represent an endpoint with access to our network, 
and that someone may now put (spoofed) packets into the tunnel. That sgw 
may be one that is granted access for some purpose, but that we do not 
expect to represent the particular endpoint that it subsequently 
impersonates. Nobody else (e.g routers along the way) can see that this 
is occurring.
     
One way to provide for such delegation is to configure, as part of the 
phase 2 requirements, some phase 1 requirements including phase 1 
identities.
     
>  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.
     
By "one policy for phase 1" do you refer only to cryptographic 
parameters (and not identities or authentication mechanisms), i.e all 
phase 1 SAs use 3DES/SHA1?
     
Scott
References: