Re: #22

At Tue, 08 Feb 2005 16:48:57 -0500,
Bill Sommerfeld <[email protected]> wrote:
> 
> On Tue, 2005-02-08 at 16:24, Sam Hartman wrote:
> > >>>>> "Michael" == Michael Thomas <[email protected]> writes:
> > 
> >     Michael> Well, it's pretty simple really: when you get tickets
> >     Michael> from the KDC, they aren't protected by PFS so using PFS
> >     Michael> later is pretty questionable. It's not useless, but it's
> >     Michael> not any huge win either. Until Kerberos itself supports
> >     Michael> PFS, people deploying KINK really ought not get worked up
> >     Michael> into a lather about turning on PFS to improve security
> >     Michael> since it's doesn't to any great degree.
> > 
> > I'm confused.  I thought the point of PFS was to make it impossible to
> > recover session data .  How does the fact that the KDC does not do PFS
> > decrease the value of PFS for Kink?
> 
> I'm also confused by Michael's remarks, but, as I recall, one of the 
> motivations for KINK was to do IPsec SA setup with lower CPU overhead
> by avoiding public key operations.   If you add in a D-H exchange for PFS, 
> you blow away that motivation and this winds up looking like a strange
> way to build a GSS-authenticated IKE..

I agree with Michael that PFS should be provided by Kerberos.
On the other hand, I also agree with Sam and Bill that PFS provided
by KINK has more-than-nominal values.

The issue here is the tradeoff between PFS and low computational cost.
Thinking on the motivation of KINK, which reduce computational cost
to exchange SAs, taking low CPU power at the cost of PFS is
reasonable to me.
So I'd propose an editorial change to the phrase
"it is somewhat questionable whether a system which is heavily
relying on Kerberos benefits from PFS."

-- 
KAMADA Ken'ichi <[email protected]>