"P.J. Ponder" <[EMAIL PROTECTED]> said:
> There is a new Internet Draft entitled 'Internet Security Glossary' which
> defines terms and provides references. One purpose of the new glossary
is
Is there a forum/list to provide feedback (e.g. the commenets below)?
<skip>
> related to the recent discussion on defining 'forward secrecy', this new
<skip>
> $ 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.
This is a reasonable definition. However I think there is a definition for
perfect forward secrecy as used (and defined) in the literature, here is an
attempt:
A communication protocol is said to provide forward secrecy with period T,
if it has the following property: communication between parties using the
protocol at time t will remain secret from an eavesdropper (with polynomial
computational powers) who has access to all the communication between these
parties (at any time) as well as to the entire secret storage of both
parties at time t+T.
A communication protocol is said to provide forward secrecy if it has a
parameter T and for every given T, it provides perfect forward secrecy with
period T.
We will say that the protocol provides perfect forward secrecy (with period
T) if it provides forward secrecy (with period T) even against an attacker
which has unlimited computational abilities.
Notice that this assumes that the parties do not store the messages
transfered between them for long - that is, this definition is really
targeted at encryption devices.
BTW it may be possible (desireable?) to extend the defs above further so
they don't focus on communication protocols.
<skip>
> (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.
This is very close to the def above except... perfect forward secrecy does
not attempt to protect _future_ session keys!! There is a very related
definition/approach that does attempt to achieve such recovery from
penetrations, which we call by the (bad?) name Proactive Security. In
particular in one of our results we do show how to recover communication
security after a penetration. Namely (rough def):
A communication protocol is said to provide proactive secrecy with period
T, if it has the following property: communication between parties using
the protocol at time t will remain secret from eavesdropper who has access
to all the communication between these parties (at any time) as well as to
the entire secret storage of both parties, except during the interval
[t-T,t+T].
For more info see the Proactive Security Homepage from
http://www.hrl.il.ibm.com (I think you need to add proactive - but follow
the link to be sure)
Notice that clearly to achieve proactive security we must assume
something... the standard assumption is that the system contains n machines
and at any interval of length T, less than n/3 machines are corrupted.
Plus, we assume that parties have a secure random generator (we have some
construction to replace this assumption with a weaker adversary who cannot
eavesdrop to all links), as well as secure ROM for the program and one
public key.
> - 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.
This is a weaker notion (IMHO - formally they are incomparable) defined by
Yacobi, I forgot the name he used but it was not forward secrecy.
> - All three concepts involve the idea that a compromise of "this"
> encryption key is not supposed to compromise the "next" one. There
Not true!!! Only proactive security attempts this goal. Ok, Yacobi's def
also has some of this goal (I'm really ashamed, now what was the name of
it?)
> 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.
This is forward secrecy
> (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.
Great confusion here. I hope the defs above will help clear this up.
I'm still unsure what the authors meant by `backwards`...
> (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
Computational forward secrecy (i.e. not perfect) can be achieved by simply
changing keys periodically as a one way function of previous keys, so that
their exposure does not give past keys. This has some synchronization
problems, of course.
But of course Kerberos does not do this.
> (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.
I believe the term `perfect` is from the crypto theory terminology, where
`perfect` is usually associated with information theory security against an
a computationally unbounded adversary. Unfortunately I don't think that
real PFS is possible, definitely the protocols (e.g. Diffie-Hellman based)
proposed do not achieve it, since a computationally unbounded attacker can
break the DH exchange (by doing discrete logs).
So PFS is really a poor name, IMHO. Better drop the `perfect` term which is
misleading. OTOH, it sounds nice :-)
Best Regards,
Amir Herzberg
Special disclaimer: the defs above are not to be taken seriously as were
written in few minutes, I'm afraid.
IBM Research Lab in Haifa (Tel Aviv Office)
http://www.hrl.il.ibm.com
"P.J. Ponder" <[EMAIL PROTECTED]> on 05/30/2000 11:27:19 PM
Please respond to "P.J. Ponder" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Amir Herzberg/Haifa/IBM)
Subject: RFC 2828 on Internet Security Glossary (fwd)
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.
