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

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



See my comments below.

-----Original Message-----
From:	Daniel Harkins [SMTP:dharkins@cisco.com]
Sent:	Wednesday, October 01, 1997 6:35 PM
To:	baiju@mailbox.jf.intel.com
Cc:	'ipsec'
Subject:	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. 
[Baiju V. Patel]  PFS is not a negotiation attribute (it is not really part of
any payload), so attribute not supported may be misleading. Just as part
of the curiosity, would I use protocol type as ISAKMP?

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.
[Baiju V. Patel]  Not really, the initiator can specify 3DES and DES in order
of preference and the responder can respond with either one. In case of PFS,
you do not have a choice. It also leaves room for confusion.

  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.
[Baiju V. Patel]  Agreed.

  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? :-)
[Baiju V. Patel]  
I guess there are ways of getting where you want to be (as you specified above).
There may still be a clarification needed for the following situation:

Initiator sends KE but responder decides that it does not care to send KE
because PFS is not important to the responder. Since KE is optional in both
cases, this is a legal exchange. 
  a. Does this imply that the if initiator could accommodate
      communication without PFS, both sides MUST compute keying material
      with understanding that PFS is not required.
  b. Sender send a notification saying attribute not supported because 
      the respond did not respond with appropriate KE?
  c. The responder must either include KE in response or send a notification (mandate
      that for exchange to be successful, either KE in first and second message must
      be present or none).
  d. Sender includes in its proposal (SA) in phase 2 a parameter which tells
      the responder that PFS is not required by initiator but is included in the
      message just in case!
  e. Something else (e.g., it is clear to me, leave it alone)!

  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.

[Baiju V. Patel]  Agreed.

  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.