Re: #22

On Tue, 2005-02-08 at 13:48, Bill Sommerfeld 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..

This all comes down to what constitutes a "session". I'd
argue that it would be a lot better if Kerberos "sessions" (ie, tickets
and their lifetimes) provided the notion of PFS since 
that would cover every protocol that implements kerberos
authentication instead of the piecemeal approach that 
each kerberos application needs to deal with PFS itself. 
That and the place that I'd think you _really_ want PFS
is for the AS-REQ/AS-REP since that's where the most
vulnerable piece of information is exchanged (ie, the
password). 

In fact, I'd be willing to wager that KINK is the _only_ 
Kerberized application that has any notion of PFS right now
which really illustrates why if people think that PFS is
important, it ought to be done up a level.

But.. we are where we are. If the editorial comment is 
really causing mass hysteria, then we should just take
it out because it doesn't affect anything about KINK.

		Mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iQCVAwUAQglIibMsDAj/Eq++AQJd1gP9EbLb+TUcp7V+jyLofrE9MYuowy+B4IHN
djVFLHQrZDecgGiV/bFBphgopz9UjkijnDr35ApslGYFgfy1mFG+Ps4JnnMYW3U6
ALKR+AVHd4YzkSwoci4siEEXZZTc9BZ6TxA5m4OoolLqUu//bUIvNMunZsPqYUst
xb+i95NRRik=
=ZT63
-----END PGP SIGNATURE-----