Re: Suggestion for SOI wrt PFS

["Darren Dukes" <ddukes@cisco.com>]

From: "Jan Vilhuber" <vilhuber@cisco.com>
> On Fri, 29 Mar 2002, Catherine A. Meadows wrote:
>
> > I sent this already, but forgot to cc the list:
> >
>
> And I replied to the one that wasn't cc'd to the list :) Here's the
> reply:
>
>
> As another data point consider VPN client-software, that may have to
> re-prompt the user for new passwords (shared keys or one-time
> passwords) when doing a new phase 1. That MAY be undesireable,
> although I have no evidence on what customers want either
> way.

I know for a fact this is a sticking point with customers, re-sending a
one-time PW every day or two is even met with a great deal of resistance.

> Generally, people do NOT want to be reprompted for passwords in
> the middle of a session, though...
>
> Given that, doing a PFS and feeding it back into the SKEYSEED seems
> favorable..

One difference between the IKEv1 PFS and the mechanism Andrew proposes (or
even rekeying the Phase1 more often) is the inability to generate a new
SKEYSEED_D based on QM traffic unless the QM SAs KByte stats are relayed
back to the IKE SA that created them.  For implementations capable of Gbps
bursts I think this functionality would likely be needed.

Darren

>
> jan
>
>
>
> > I think that this (using phase 2 with D-H
> > to generate a new SKEYSEED_d) works for PFS, but I am worried about the
added
> > complexity.  Adding a new type of phase 2 for calculating the
> > SKEYSEED_d comes dangerously close to shoehorning in a
> >  "phase 1 1/2", which we are trying to avoid.  Are the savings
> > gained from avoiding a new Phase 1 exchange worth this added complexity?
> >
> > I do agree, though, that we need a precise definition of PFS, what
> > we want it to achieve, and where it should go.  The best place
> > for this is probably in the requirements document.  The current
> > draft of the document describes a mechanisms for achieving PFS (use
> > D-H to create a shared key), but doesn't talk about the property itself.
> >
> > Cathy
> >
> > Catherine Meadows
> > Code 5543
> > Center for High Assurance Computer Systems
> > Naval Research Laboratory
> > Washington, DC 20375
> >
> > phone: +1-202-767-3490
> > fax: +1-202-404-7942
> >
> >
> >
> >
> > > From owner-ipsec@lists.tislabs.com  Thu Mar 28 22:26:24 2002
> > > Date: Thu, 28 Mar 2002 19:21:11 -0800 (PST)
> > > From: Jan Vilhuber <vilhuber@cisco.com>
> > > To: Bill Sommerfeld <sommerfeld@east.sun.com>
> > > cc: <andrew.krywaniuk@alcatel.com>, <ipsec@lists.tislabs.com>
> > > Subject: Re: Suggestion for SOI wrt PFS
> > > MIME-Version: 1.0
> > > Sender: owner-ipsec@lists.tislabs.com
> > >
> > > On Thu, 28 Mar 2002, Bill Sommerfeld wrote:
> > >
> > > > > The ideal situation would be that the peers negotiate an IKE SA
(with DH)
> > > > > and one or more IPsec SAs (not using DH). After a specified
timeout (the
> > > > > forward secrecy interval), the peers forget SKEYSEED_d, and the
next phase 2
> > > > > exchange would have to contain a DH. This DH would be used to
generate the
> > > > > new SKEYSEED_d for subsequent exchanges.
> > > >
> > > > So, why not just start a new phase 1 at this point?
> > > >
> > >
> > > Then you'd have to reauthenticate, which you may not want to (public
> > > key operation and all). At least that's the only difference I can
> > > see. This is somewhat lighter weight than a full phase 1.
> > >
> > > [ I haven't thought this proposal through yet, so I'm not coming down
> > > on one side or the other ;) ]
> > >
> > > jan
> > >  --
> > > Jan Vilhuber
vilhuber@cisco.com
> > > Cisco Systems, San Jose                                     (408)
527-0847
> > >
> >
>
>  --
> Jan Vilhuber                                            vilhuber@cisco.com
> Cisco Systems, San Jose                                     (408) 527-0847
>