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

Re: ISAKMP/Oakley does not allow negotiation on PFS requirement.

  Baiju,

  There's no way to inform the peer of what you want before you inform him
of what you want. If the responder requires PFS and the initiator didn't
offer it I'd imagine a notify message (attributes not supported) would be
sent back. This is the same as an encryption algorithm. If you will only do 
3DES and I send you DES (while I do support 3DES I chose not to offer it
because this is session is not hypercritical and I chose to maximize on
speed) you won't accept it.

  I don't think that information regarding PFS can be exchanged in phase 1
in anticipation of a phase 2 exchange because I don't know what the phase 2
exchange is before it happens. I might have policy configured to require
PFS on telnets to a host behind my IPSec-aware router but not for ftps to a 
different host behind it. If I don't know what the next phase 2 exchange is
going to be for I can't accurately tell you what I want. I might require PFS;
I might not.

  If you, as an initiator, would prefer not to do PFS but would accomodate
a responder's desire to do so there is, indeed, no way for you to do this
since you must already have done a modular exponentiation and passed a
Diffie-Hellman public value to the responder for the exchange to take place.
You could always send a KE payload and double all SA offers-- one with a
group description indicating PFS, another without-- and see what the 
responder decides. This would mean you might do alot of unnecessary 
exponentiation but with your new 300MHz processors it's not a problem, 
right? :-)

  Of course we could add another roundtrip message to Quick Mode as a basic 
"here's what I'm going to ask you for, what do you think about it before
negotiation begins" but it already takes long enough to acquire the SAs and
I'd rather not delay it any more. Since we have a mechanism to deal with this 
issue I'm even more hesitant to change anything.


  Dan.

P.S. You could use SKIP's algorithm discovery protocol to probe the peer 
for what he supports! 

> With ISAKMP/Oakley, we have a choice of requiring PFS. However, it does 
> not provide any means of negotiating PFS.
> 
> So, if initiator would prefer that PFS is not a requirement, but will 
> accommodate responders desires for PFS, there is no easy way of communicating > this to the responder.
> 
> In this situation, initiator has no choice but to require PFS. If it does 
> include KE in the phase 2 message, responder will assume that PFS is required 
> by initiator. If it does not include KE in the message, and responder 
> requires PFS, phase 2 fails.
> 
> It is my opinion that as part of the ISAKMP/Oakley SA negotiation, the 
> requirements for PFS must be negotiated. So that before starting phase 2, 
> the communicating peers know each others requirements for PFS and agree upon 
> on that is acceptable to both.
References: