The definition in the glossary for the FreeS/WAN Linux IPSEC project is:
A property of systems such as Diffie-Hellman key exchange which use a
long-term key (the shared secret in IKE) and generate short-term keys
as required. If an attacker who acquires the long-term key provably can
neither read previous messages which he may have archived
nor read future messages without performing additional
successful attacks
then the system has PFS. The attacker needs the short-term keys in
order to read the trafiic and merely having the long-term key does
not allow him to infer those. Of course, it may allow him to conduct
another attack (such as man-in-the-middle) which gives him some
short-term keys, but he does not automatically get them just by
acquiring the long-term key.
That glossary:
http://www.freeswan.org/freeswan_trees/freeswan-1.3/doc/glossary.html
has links to several others. Some, such as the NSA Glossary and
Ritter's, do not define the term.
The Internet Draft Security Glossary
http://www.ietf.org/internet-drafts/draft-shirey-security-glossary-02.txt
has this text:
$ public-key forward secrecy (PFS)
(I) For a key agreement protocol based on asymmetric cryptography,
the property that ensures that a session key derived from a set of
long-term public and private keys will not be compromised if one
of the private keys is compromised in the future.
(C) Some existing RFCs use the term "perfect forward secrecy" but
either do not define it or do not define it precisely. While
preparing this Glossary, we tried to find a good definition for
that term, but found this to be a muddled area. Experts did not
agree. For all practical purposes, the literature defines "perfect
forward secrecy" by stating the Diffie-Hellman algorithm. The term
"public-key forward secrecy" (suggested by Hilarie Orman) and the
"I" definition stated for it here were crafted to be compatible
with current Internet documents, yet be narrow and leave room for
improved terminology.
(C) Challenge to the Internet security community: We need a
taxonomy--a family of mutually exclusive and collectively
exhaustive terms and definitions to cover the basic properties
discussed here--for the full range of cryptographic algorithms and
protocols used in Internet Standards:
(C) Involvement of session keys vs. long-term keys: Experts
disagree about the basic ideas involved.
- One concept of "forward secrecy" is that, given observations of
the operation of a key establishment protocol up to time t, and
given some of the session keys derived from those protocol runs,
you cannot derive unknown past session keys or future session
keys.
- A related property is that, given observations of the protocol
and knowledge of the derived session keys, you cannot derive one
or more of the long-term private keys.
- The "I" definition presented above involves a third concept of
"forward secrecy" that refers to the effect of the compromise of
long-term keys.
- All three concepts involve the idea that a compromise of "this"
encryption key is not supposed to compromise the "next" one. There
also is the idea that compromise of a single key will compromise
only the data protected by the single key. In Internet literature,
the focus has been on protection against decryption of back
traffic in the event of a compromise of secret key material held
by one or both parties to a communication.
(C) Forward vs. backward: Experts are unhappy with the word
"forward", because compromise of "this" encryption key also is not
supposed to compromise the "previous" one, which is "backward"
rather than forward. In S/KEY, if the key used at time t is
compromised, then all keys used prior to that are compromised. If
the "long-term" key (i.e., the base of the hashing scheme) is
compromised, then all keys past and future are compromised; thus,
you could say that S/KEY has neither forward nor backward secrecy.
(C) Asymmetric cryptography vs. symmetric: Experts disagree about
forward secrecy in the context of symmetric cryptographic systems.
In the absence of asymmetric cryptography, compromise of any long-
term key seems to compromise any session key derived from the
long-term key. For example, Kerberos isn't forward secret, because
compromising a client's password (thus compromising the key shared
by the client and the authentication server) compromises future
session keys shared by the client and the ticket-granting server.
(C) Ordinary forward secrecy vs. "perfect" forward secret: Experts
disagree about the difference between these two. Some say there is
no difference, and some say that the initial naming was
unfortunate and suggest dropping the word "perfect". Some suggest
using "forward secrecy" for the case where one long-term private
key is compromised, and adding "perfect" for when both private
keys (or, when the protocol is multi-party, all private keys) are
compromised.
(C) Acknowledgements: Bill Burr, Burt Kaliski, Steve Kent, Paul
Van Oorschot, Michael Wiener, and, especially, Hilarie Orman
contributed ideas to this discussion.
