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

RE: Phase 1 KB lifetime

Dan, I think you misunderstood something I said. I was not talking
specifically about responder lifetime notifies. I was talking about the
general issue of phase 1 kb lifetimes (which, you will notice, is the
subject of this thread).

I merely made the observation that phase 1 kb lifetimes have potential
security implications and it's not right to prevent people from using them.


If an implementation decides to enforce kb lifetimes then they must either:

1. Locally enforce the rule without informing the peer.
	OR 
2. Inform the peer (Initiator: put it in the proposal, Responder: send a
lifetime notify).


I can see arguments for doing either:

1. On one hand, I might consider reaching the kb limit an abnormal
situation, in which case there's no need to notify the peer in advance. 

2. On the other hand, there's no harm in sending the lifetime constraint to
the peer if they might cooperate in enforcing it.


But if you:

1. State that "It is _never_ a good idea to just enforce a lifetime without
telling the peer".
	AND
2. Agree that lifetime constraints are a component of policy.
	AND
3. Want to remove the definition of the kb lifetime magic number from IKE.

...then like it or not you ARE legislating policy.

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.


> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
> Sent: Wednesday, January 19, 2000 2:50 PM
> To: Andrew Krywaniuk
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Phase 1 KB lifetime 
> 
> 
> On Wed, 19 Jan 2000 14:24:03 EST you wrote
> > 
> > Fine. As I said, our code has support for the responder 
> lifetime notify. We
> > send it and parse it. If the responder adjusts the 
> lifetime, we honour it
> > AND we send the delete. I'm not arguing with you on this point.
> 
> Bully for you. What your product does is not the issue here.
> 
> > I'm saying that if someone was paranoid enough to want to 
> expire their SAs
> > based on a kb lifetime, which is a possible weakness (even 
> if some consider
> > it too unlikely or too unworthy to protect against), then 
> they should go
> > ahead and delete their SAs regardless of whether there is 
> an assigned magic
> > number for kb lifetimes in the draft.
> > 
> > Should they send a responder lifetime notify regarding this 
> constraint? 
> 
> I don't think you understand what the responder lifetime 
> notify is used for.
> When a lifetime has been reached you don't send the notify, 
> you chain it
> to your Quick Mode message during negotiation so both sides 
> have a consistent
> view of the world at SA establishment time. Whether a magic 
> number exists
> for kb lifetimes in phase 1 is unrelated to the use of 
> responder notifies.
> 
> > On one hand, you are saying that an implementation should 
> notify the peer of
> > all of its lifetime constraints. On the other hand, you 
> want to remove (or
> > at least deprecate) the magic number associated with this lifetime
> > constraint. 
> 
> I'm arguing _against_ ignoring messages from the peer and 
> blithely assuming
> that things are as you believe they are when they aren't 
> (which you'd know
> had you parsed the message). 
> 
> > If the user values strict security over strict standards 
> compliance then
> > they have no choice but to enforce the kb lifetime rule 
> without sending a
> > notify.
> > 
> > If you want to prevent implementations which enforce local 
> kb lifetime rules
> > from sending a notify then fine... just don't try to 
> legislate policy.
> 
> Nobody's "legislating policy". And the enforcement of kb 
> lifetime is not
> related to the use of the responder lifetime. Please read the relevent
> documents.
> 
>   Dan.
>
Follow-Ups: