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

Re: ISAKMP gateway function



  Sorry to jump in so late on this but I've been having trouble getting
IPSec mail lately. In any event...

> Kai Martius <kai@imib.med.tu-dresden.de> writes on Wed, 3 Dec 1997 14:56:48 +0100:
> . > Is this supported by ISAKMP and if so how is this done?
> . 
> . Phase II proxy exchange could handle this, I think. Depending on the 
> interface of the ISAKMP daemon other hosts can request keys from it. 
> However, the problem is that  
> . - the requested keys will be delivered in clear over the local network 
> (regarding to the statement of Mitch Nelson, that  "68-80% of the attacks 
> for which encryption would provide some protection are on the local 
> network." this isn't very nice...)
> . - the host requesting the keys must trust the "ISAKMP-host" because it 
> knows the final keys in every case. 
> . 

Phase II proxy is not for this purpose. The ISAKMP peer always does IPSec.
You never want to have one host obtain authenticated keys and then ship
them over the network to the guy who's going to use them. There's a huge
chicken-and-egg problem there and it also just doesn't make a whole lot of
sense.

If you do IPSec and not ISAKMP then all you can do is manually keyed SAs.
If you do ISAKMP and not IPSec then you don't do much of anything at all.
You can't take a host that only does ISAKMP and have it negotiate for a host
that does not.

Phase II proxy is when the end point of the communication is not doing IPSec.
In that case the gateway constructs a tunnel through which packets destined
to and from that host go. The tunnel terminates at the gateway. 

> This brings up yet another question.  An SA is generated by a KMd on host B
> at the request of host A.  B ships the SA to A.  How do B and A talk with
> one another over the network, do they use AF_KEY?  (Is there any intent to
> standardize this relationship?)  Then, of course, this traffic must be
> secured (regardless of the protocol A and B use), but by definition there
> is no KMd on A to create a secure channel to B...

PF_KEY (or AF_KEY) is a raw socket and is not suitable for host-to-host
communication. It's used for a user-space entity like ISAKMP to communicate
with a kernel space entity like IPSec. Whether it's going to be standardized 
or not, I dunno.

  Dan.



References: