There is a new Internet Draft entitled 'Internet Security Glossary' which
defines terms and provides references. One purpose of the new glossary is
to harmonize usage within Internet standards documents. See end of
message for the URL.
related to the recent discussion on defining 'forward secrecy', this new
glossary has the term 'perfect forward secrecy', but that entry only
directs one to: 'public-key forward secrecy', which has the following
definition (and call for assistance). (The paragraphs denoted 'I' are
Internet related; the ones marked 'C' are comments from the editors.)
$ 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.
---------- Forwarded message ----------
Date: Tue, 30 May 2000 07:55:53 -0700
From: RFC Editor <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RFC 2828 on Internet Security Glossary
A new Request for Comments is now available in online RFC libraries.
FYI 36
RFC 2828
Title: Internet Security Glossary
Author(s): R. Shirey
Status: For Your Information
Date: May 2000
Mailbox: [EMAIL PROTECTED]
Pages: 212
Characters: 489292
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-shirey-security-glossary-02.txt
URL: ftp://ftp.isi.edu/in-notes/rfc2828.txt
This Glossary (191 pages of definitions and 13 pages of references)
provides abbreviations, explanations, and recommendations for use of
information system security terminology. The intent is to improve the
comprehensibility of writing that deals with Internet security,
particularly Internet Standards documents (ISDs). To avoid confusion,
ISDs should use the same term or definition whenever the same concept
is mentioned. To improve international understanding, ISDs should use
terms in their plainest, dictionary sense. ISDs should use terms
established in standards documents and other well-founded
publications and should avoid substituting private or newly made-up
terms. ISDs should avoid terms that are proprietary or otherwise
favor a particular vendor, or that create a bias toward a particular
security technology or mechanism versus other, competing techniques
that already exist or might be developed in the future.
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [EMAIL PROTECTED] Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [EMAIL PROTECTED]
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [EMAIL PROTECTED] with the message body
help: ways_to_get_rfcs. For example:
To: [EMAIL PROTECTED]
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to [EMAIL PROTECTED] Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo
Submissions for Requests for Comments should be sent to
[EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
