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

Re: Suggestion for SOI wrt PFS



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. 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..

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