Re: lack of PFS considered harmful

[Jan Vilhuber <vilhuber@xxxxxxxxx>]

That paragraph sounds great to me. I second the motion ;)

jan


On Fri, 13 Oct 2000, Michael Thomas wrote:

> Greg Troxel writes:
>  > Regarding:
>  > 
>  > 	draft-ietf-kink-reqmt-00.txt
>  > 	draft-ietf-kink-kink-00.txt
>  > 
>  > I am concerned about the lack of consideration for PFS.
>  > At a minimum this needs to be in the (currently blank) security
>  > considerations section.
> 
> Greg,
> 
> I agree with David's comments and have nothing to
> add. The security considerations section was left
> blank mainly because we wanted to get the draft
> out as soon as possible. Also: we expected to get
> feedback which we could incorporate into the
> section. 
> 
> What I would propose to add to the security
> considerations on this topic is: "KINK uses
> Kerberos cryptographic mechanisms for key exchange
> and as such is limited to what Kerberos provides.
> These limitations include PFS [, ...].  It is not
> a goal of KINK to address Kerberos issues as they
> would be better addressed by Kerberos itself."
> 
> 	 Mike
> 
> 
>  > 
>  >    It should be noted
>  >    that KINK is a complement to and not a replacement for the Internet
>  >    Key Exchange [IKE], as KINK requires the use of an online
>  >    authentication server and cannot provide identity protection nor
>  >    perfect forward secrecy (as described in [RFC2412]).  There are many
>  >    situations in which centralized key management is desirable.
>  > 
>  > This text can be read to imply that KINK cannot provide identity
>  > provide or PFS because it uses of an online authentication server.
>  > I'm guessing that this isn't what was intended, but a clarification
>  > would be helpful.
>  > 
>  > I believe that the use of centralized key management
>  > (vs. certificates) is orthogonal to PFS.  It appears on quick reading
>  > of the draft that someone who compromises a principal's key years
>  > hence will still be able to recover all plaintext, since the IPsec
>  > session key is encrypted in the krb session key.
>  > 
>  > I'll make my opinion explicit that all interactive login sessions need
>  > PFS protection, and that given how cheap PFS implementation is on
>  > today's machines, it isn't reasonable to omit it.  Since it seems to
>  > be the goal to set up a campus to use KINK instead of IKE, it would be
>  > nice for KINK to be able to meet this requirement.
>  > 
>  > One solution of course is to perform double-ephemeral DH, and
>  > authenticate that with Kerberos.  This gets somewhat closer to IKE
>  > with Kerberos authentication.  Is it the goal of KINK to have a
>  > protocol that does not use public key operations, or one that does not
>  > require them in all cases, or that does not require them in any case?
>  > 
>  > It may also be that adding a PFS option to Kerberos (independently of
>  > kink) is desirable.
>  > 
>  >       Greg
>  > 
> 

 --
Jan Vilhuber                                            vilhuber@xxxxxxxxx
Cisco Systems, San Jose                                     (408) 527-0847