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

Re: Suggestion for SOI wrt PFS



I sent this already, but forgot to cc the list:

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
>