Internet DRAFT - draft-kent-pervasive-encryption
draft-kent-pervasive-encryption
Network Working Group S. Kent
Internet-Draft BBN Technologies
Intended status: Informational March 18, 2014
Expires: September 19, 2014
Pervasive Encryption as a Countermeasure to Pervasive Monitoring
draft-kent-pervasive-encryption-00
Abstract
This document was prepared as part of the IETF response to concerns
about "pervasive monitoring" as articulated in [I-D.farrell-perpass-
attack]. It begins by exploring terminology that has been used in
IETF standards (and in academic publications) to describe encryption
and key management techniques, with a focus on authentication vs.
anonymity. Based on this analysis, it propose a new term, "pervasive
encryption" (PE) to describe a goal for IETF security protocols, one
countermeasure to pervasive monitoring.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Kent Expires September 19, 2014 [Page 1]
Internet-Draft Pervasive Encryption March 2014
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. What's in a Name (for Encryption)? . . . . . . . . . . . . . 2
2. Terminology (some of these can be removed) . . . . . . . . . 8
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. What's in a Name (for Encryption)?
Recent discussions in the IETF about pervasive monitoring (PM) have
suggested a desire to increase use of encryption, even when the
encrypted communication is unauthenticated. The term "opportunistic
encryption" has been used frequently, but often without a precise
definition. Some have suggested it refers to unauthenticated
encryption, others view it as a shorthand for any set of mechanisms
that encourage more widespread use of encryption, a marketing term
that need not be precisely defined. This document examines a range
of terminology relevant to the topic, and suggests use of a new term:
"pervasive encryption" (PE). It also proposes a definition for the
term, in the belief that the IETF deserves more than a marketing
catchphrase.
PE (for realtime communication) exhibits the following
characteristics:
1. It is invisible to users (so that they do not become confused by
the set of security services they are being offered).
2. It is not a substitute for authenticated, integrity-protected
encryption when that set of security services can be provided to
a user.
3. PE makes use of perfect forward secrecy (PFS) for key agreement.
4. Detection of a man-in-the-middle (MiTM) attacks is a desired,
thought not mandatory, feature.
5. Authentication is a desired, thought not mandatory, feature.
6. Use of PE must not introduce delays in session/connection
establishment that will discourage its use. As a result, MiTM
detection and authentication should take place after an encrypted
Kent Expires September 19, 2014 [Page 2]
Internet-Draft Pervasive Encryption March 2014
session/connection is established. This ordering implies that
some data may be transmitted prior to authentication or detection
of a MiTM.
7. Because PE calls for a new key management paradigm, it requires
new capabilities by peers. Thus, until PE is universally
adopted, an outcome of attempting PE may be a fallback to
plaintext communication.
The term opportunistic encryption (OE) was coined by Michael
Richardson in "Opportunistic Encryption using the Internet Key
Exchange (IKE)" an Informational RFC [RFC4322]. In this RFC the term
is defined as:
... the process of encrypting a session with authenticated
knowledge of who the other party is without prearrangement.
This definition above is a bit opaque. The introduction to RFC 4322
provides a clearer description of the term, by stating the goal of
OE:
The objective of opportunistic encryption is to allow encryption
without any pre-arrangement specific to the pair of systems
involved.
Later the RFC notes:
Opportunistic encryption creates tunnels between nodes that are
essentially strangers. This is done without any prior bilateral
arrangement.
The reference to "prior bilateral arrangement" is relevant to IPsec
but not to most other IETF security protocols. If every pair of
communicating entities were required to make prior bilateral
arrangements to enable encryption between them, a substantial
impediment would exist to widespread use of encryption. However,
other IETF security protocols define ways to enable encryption that
do not require prior bilateral arrangements. Some of these protocols
require that the target of a communication make available a public
key, for use by any initiator of a communication; an example of a
prior unilateral arrangement. The essential difference between IPsec
and most other IETF security protocols is that IPsec intrinsically
incorporates access control; other IETF security protocols do not.
The definition provided in [RFC4322] is specific to the IPsec
[RFC4301] context and ought not be used to describe the goals noted
above, as a countermeasure to PM. Because IPsec implements access
controls, it requires explicit specification (by each peer) of how to
Kent Expires September 19, 2014 [Page 3]
Internet-Draft Pervasive Encryption March 2014
process all traffic that crosses an "IPsec boundary" (inbound and
outbound). Traffic is either discarded, permitted to pass w/o IPsec
protection, or protected using IPsec. The goal of OE (as per
[RFC4322]) is to enable IPsec protected communication without a
priori configuration of access control database entries at each peer
(hence, bilateral). Opportunistic encryption calls for each party to
identify the other, using IKE [RFC2409] (equivalently, IKE v2
[RFC5996]) authentication mechanisms, so it is not an unauthenticated
key management approach. Also note that RFC 4322 describes OE
relative to IKE, as it should; IPsec implements encryption using ESP
[RFC4303]. ESP usually provides data integrity and authentication,
as well as confidentiality, thus the phrase opportunistic encryption
is unduly narrow relative to the anti-PM goal. OE for IPsec is
described in more detail in Section 3.
RFC 4322 also defines anonymous encryption:
Anonymous encryption: the process of encrypting a session without
any knowledge of who the other parties are. No authentication of
identities is done.
Thus, in RFC 4322, the term anonymous encryption refers to encrypted
communication where neither party is authenticated to the other.
Also note that the definition above refers to "the process of
encrypting a session ..." In fact, it the key management process that
causes an encrypted session to be authenticated, or not. Thus it
would be more accurate to refer to "anonymous keying", rather than
anonymous encryption. This document adopts the commonly used
terminology, to maintain compatibility with most IETF security
standards.
One can distinguish two classes of anonymous encryption, based on
whether one party or both are not authenticated. For example, TLS
([RFC2246], [RFC4346], and [RFC5246]) typically is used in a fashion
that provides server, but not client, authenticated communication.
However, TLS also supports two-way authenticated sessions and "pure"
unauthenticated sessions, in which neither party asserts an identity
during the handshake protocol. Thus TLS offers 2-way anonymous
communication and client-anonymous communication. (The same analysis
applies to DTLS [RFC6347].)
Some security experts distinguish between anonymity and pseudonymity.
Pseudonymity [merriam-webster] implies use of a identifier, but one
that represents a "false name" for an entity. Use of pseudonyms is
common in some Internet communication contexts. Many Gmail, Yahoo,
and Hotmail mail addresses likely represent pseudonyms. From a
technical perspective, a pseudonym is an attractive way to provide
"unauthenticated" communication. A pseudonym typically makes use of
Kent Expires September 19, 2014 [Page 4]
Internet-Draft Pervasive Encryption March 2014
the same syntax as a real identity, and thus protocols designed to
make use of authenticated identities are compatible with use of
pseudonyms, to first order.
"Traceable Anonymous Certificate", is an Experimental RFC [RFC5636]
that describes a specific mechanism for a Certification Authority
(CA) [RFC5280] to issue an X.509 certificate with a pseudonym. The
goal of the mechanisms described in that RFC is to conceal a user's
identity in PKI-based application contexts (for privacy), but to
permit authorities to reveal the true identity (under controlled
circumstances). This appears to be the only RFC that explicitly
addresses pseudonymous key management; although it uses the term
"pseudonym" extensively, it also uses the term "anonymous" more
often, treating the two as synonyms.
Self-signed certificates [RFC6818] are often used with TLS in both
browser and non-browser contexts. In the HTTPS (browser) context, a
self-signed certificate typically is accepted after a warning has
been displayed to a user; the HTTPS [RFC2818] requirement to match a
server DNS name against a certificate Subject name does not apply in
non-browser contexts. The Subject name in a self-signed certificate
is completely under the control of the entity that issued it, thus
this is a trivial way to generate a pseudonymous certificate, without
using the mechanisms specified in [RFC5636]. Thus support for
pseudonymous key management is supported in web browsing, as a side
effect of this deviation from [RFC2818]. (Some speculate that most
self-signed certificates contain accurate user or device IDs; the
certificates are used to avoid the costs associated with issuance of
certificates by Web PKI CAs.)
Based on the examples above, one could define an additional term:
"pseudonymous encryption". Pseudonymous encryption is the result of
applying techniques to distribute keys when an authentication
exchange is based on a pseudonym, e.g., a self-signed certificate
containing a pseudonym. As with anonymous encryption, pseudonymous
encryption may apply to one or both parties in an encrypted
communication. One also can imagine mixed mode communications, e.g.,
in which anonymous encryption is employed by one party and
pseudonymous encryption is employed by the other.
An examination of about 70 papers published in ACM, IEEE, and other
security conference proceedings identified numerous uses of the terms
opportunistic and anonymous encryption. Most, though not all, of the
papers used the terms opportunistic encryption and anonymous
encryption as defined in [RFC4322], but in some papers the
terminology was unclear or inconsistent with the [RFC4322]
definition.
Kent Expires September 19, 2014 [Page 5]
Internet-Draft Pervasive Encryption March 2014
Another popular source (Wikipedia) uses a somewhat different
definition for opportunistic encryption. Wikipedia [wikipedia]
provides the following definition:
Opportunistic encryption refers to any system that, when
connecting to another system, attempts to encrypt the
communications channel otherwise falling back to unencrypted
communications. This method requires no pre-arrangement between
the two systems.
This definition shares some aspects of the RFC 4322 definition, but
it is not exactly equivalent; it makes no mention of authentication
or access control, two essential aspects of opportunistic encryption
as per [RFC4322].
The Wikipedia article goes on to state that opportunistic encryption
can be employed with other protocols. The article describes the
potential for opportunistic encryption based on the use of self-
signed certificates with TLS, instead of certificates issued by a
"certificate [sic] authority." This use of the term is at odds with
[RFC4322] and with TLS RFCs, which define anonymous encryption
differently.
The Wikipedia article further notes that use of self-signed
certificates with HTTP [sic] (really HTTPS), will result in warning
to users, unless browser extensions are employed, which makes user
acceptance of such problematic. It cites use of the STARTTLS
extension for SMTP [RFC3207], and use of TLS with IMAP, POP3, and
ACAP [RFC2595], as ways of achieving opportunistic encryption for
these protocols, when self-signed certificates are employed. Use of
a self-signed certificate that does not attest to an authentic
identity is an example of pseudonymous encryption.
ZRTP [RFC6189] is cited in the Wikipedia article as an example of
opportunistic encryption for VoIP. ZRTP uses ephemeral Diffie-
Hellman key management, and thus is more accurately described as
offering two-way anonymous encryption. ZRTP also offers an optional
mode of operation in which X.509 certificates or OpenPGP-formatted
keys are employed to counter MITM attacks. An X.509 certificate used
with ZRTP might be self-signed, which could enable pseudonymous
keying, or it might be issued in PKI context, which would support
authenticated encryption. An OpenPGP-formatted key could offer the
same services. In any case, opportunistic encryption is not the most
appropriate term to describe ZRTP, based on the description in
[RFC4322].
Anonymous encryption is a reasonable term to use when discussing the
result of anonymous key management capabilities of protocols such as
Kent Expires September 19, 2014 [Page 6]
Internet-Draft Pervasive Encryption March 2014
TLS and S/MIME. Access control is not part of these security
protocols and there are explicit anonymous key management mechanisms
that support 1-way or 2-way anonymity (for TLS). Pseudonymous
encryption is the most accurate term to describe secure communication
based on using identifiers that are pseudonyms. Most RFCs use the
term "anonymous" even when the term "pseudonymous" is more accurate,
as noted in the discussion of RFC 5636. This document uses these
terms in a more precise fashion, to avoid confusion and to highlight
the security-relevant differences associated with each.
Most security experts view two-way authenticated, encrypted, and
integrity-protected traffic as the most desirable state for secured
communications. This state allows each communicant to detect (and
reject) man-in-the-middle attacks. It also seems a good match to
what a user expects to be true of a communication, in the absence of
attacks. Most IETF security protocols have been designed to achieve
this state. However, the current concerns about pervasive monitoring
motivate exploring approaches to remove barriers to the widespread
use of encryption. In that light, encrypted communications without
authentication are viewed as a good alternative, when the preferred
approach is not readily achievable.
As noted earlier, the model for PE (for realtime communications) is
to first establish an encrypted session, and then attempt to
"upgrade" it to an authenticated communication. This is analogous to
what IKE [RFC4306] does. As experience with IKE has shown, this
creates a DoS vulnerability, i.e., an attacker can cause the target
of a session/connection to expend resources performing key agreement
operations prior to authenticating the initiator of the
communication. Implementations of PE will have to address this
concern. PE designs also will have to address various flavors of
downgrade attacks, since PE will allow unauthenticated or plaintext
communication. Even though PE assumes that a user is not alerted to
its use, it may be appropriate to alert a user to such attacks, or
provide a means by which a system administrator can become aware of
them. The details of how these concerns are addressed probably will
be specific to the protocol context in which PE is implemented.
The result of an authentication attempt may yield a 1-way or 2-way
authenticated communication, or pseudonymous communication, depending
on details of the protocol. Although the intent of PE should be the
same for all realtime IETF protocols, the means by which each
protocol achieves the goals of PE are likely to differ. So, for
example, in some protocols, one might use DANE [RFC6698] to retrieve
credentials in support of authentication, in others the existing Web
PKI might be employed, etc.
Kent Expires September 19, 2014 [Page 7]
Internet-Draft Pervasive Encryption March 2014
For store-and-forward communication, the situation is more complex.
A sender may choose to be anonymous or pseudonymous or authenticated;
a recipient might be authenticated or pseudonymous. Because a
message is addressed one or more recipients, it seems odd to refer to
the recipient(s) as anonymous. If cryptographic message integrity is
offered, tampering with a message en route is detectable. But, if
the sender's identity is not authenticated, the often murky
distinction between integrity and authentication becomes more
significant.
Pseudonymous, encrypted communication is another potential outcome of
a key management exchange, as noted above. There is an obvious
downside to use of pseudonymous credentials for key management as an
alternative to anonymous key management. Pseudonymous credentials
often employ the same syntax for identifiers as real credentials, and
thus users may be confused by the subtle distinction. Thus it is
preferable to employ anonymous keying when authenticated keying is
not possible, or not desired.
2. Terminology (some of these can be removed)
The following definitions are derived from the Internet Security
Glossary [RFC4949], where applicable.
Anonymous keying A key management technique that enables
unauthenticated, communication between parties. The communication
may be 1-way or 2-way anonymous. If 1-way, the initiator (client)
or the target (server) may be anonymous.
Authentication The process of verifying a claim that a system or
entity has a certain attribute value. In the IETF context,
authentication typically refers to verification of an identity
claim.
Client-anonymous keying A key management technique for client/server
communication in which the server is authenticated by the client,
but the client does not assert its identity and thus is not
authenticated by the server. This is an example of 1-way
authentication.
(Data) Confidentiality The security service that prevents
information becoming available to unauthorized entities.
Encryption is the security mechanism typically used to implement
confidentiality.
(Data) Integrity The security service that enables a recipient of a
message or a packet to determine if the data has been modified or
destroyed in an unauthorized manner.
Kent Expires September 19, 2014 [Page 8]
Internet-Draft Pervasive Encryption March 2014
Key agreement algorithm A key establishment method based on
asymmetric cryptography, in which a pair of entities engage in a
public exchange of data (public keys and associated data), to
generate the same shared secret value. (Thus both entities
contribute secret values to the resulting key.) This value is
later used to create symmetric keys used for encryption and/or
integrity checking.
Key transport A key establishment method by which a secret
(symmetric) key is generated by one entity and securely sent to
another entity. (Thus only one entity contributes secret values
to the resulting key.) Key transport may make use of either
symmetric or asymmetric cryptographic algorithms.
Leap of Faith (LoF) In a protocol, a leap of faith typically
consists of accepting a claimed peer identity, without
authenticating that claim, and caching a key or credential
associated with the claim. Subsequent communication using the
cached key/credential is secure against a MITM attack, if such an
attack did not succeed during the vulnerable initial communication
and if the MITM is not present for all subsequent communications.
The SSH protocol ([RFC4251], [RFC4252], [RFC4253]) makes use of
LoF. See also TOFU, below.
Man-in-the-Middle attack (MITM) A form of active wiretapping attack
in which the attacker intercepts and selectively modifies
communicated data to masquerade as one or more of the entities
involved in a communication association. Masquerading enables the
MITM to violate the confidentiality and/or the integrity of
communicated data passing through it.
Opportunistic Encryption A key management technique that enables
authenticated, communication between parties, and that does not
require a priori, bilateral arrangements. This term is defined
only for IPsec.
Pervasive Encryption (PE) The result of employing a key management
technique that attempts to establish an encrypted communication
automatically and invisibly to a user. PE attempts to upgrade an
encrypted communication to detect MiTM attacks and/or 1-way or
2-way authentication, If PE is unable to create an encrypted
communication, e.g., because the other communicant does not
support PE, unencrypted (plaintext) communication results.
Perfect Forward Secrecy (PFS) For a key management protocol, the
property that compromise of long-term keying material does not
compromise session/traffic keys that were previously derived from
or distributed using the long-term material.
Kent Expires September 19, 2014 [Page 9]
Internet-Draft Pervasive Encryption March 2014
Private key The secret component of a pair of cryptographic keys
used for asymmetric cryptography.
Public key The publicly disclosed component of a pair of
cryptographic keys used for asymmetric cryptography. The phrase
"public key data" includes a public key and any additional
parameters required to perform computation using the public key.
Pseudonymous keying A key management technique that enables
pseudonymous communication between parties, e.g., based on use of
a self-signed certificate. Pseudonymous keying may be one-way or
two-way, depending on details of the key management mechanism
employed.
Session A realtime communication between entities.
Shared secret A value derived from a key agreement algorithm and
used as an input to generate a CEK or traffic encryption key.
Symmetric cryptography A type of cryptography in which the
algorithms employ the same key for encryption and decryption, and
the key is not publically disclosed.
Traffic (encryption) key (TEK) A symmetric key used to encrypt/
decrypt traffic carried via an association.
Trust on First Use (TOFU) In a protocol, TOFU typically consists of
accepting a claimed peer identity, without authenticating that
claim, and caching a key or credential associated with the claimed
identity. Subsequent communication using the cached key/
credential is secure against a MITM attack, if such an attack did
not succeed during the vulnerable, initial communication and if
the MITM is not present for all subsequent communications. The
SSH protocol makes use of this technique. See also Leap of Faith,
above.
3. Acknowledgements
I want to thanks David Mandelberg for his help in generating this
document.
4. Security Considerations
[TBS]
Kent Expires September 19, 2014 [Page 10]
Internet-Draft Pervasive Encryption March 2014
5. References
[I-D.farrell-perpass-attack]
Farrell, S. and H. Tschofenig, "Pervasive Monitoring is an
Attack", draft-farrell-perpass-attack-06 (work in
progress), February 2014.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
2595, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic
Encryption using the Internet Key Exchange (IKE)", RFC
4322, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
Kent Expires September 19, 2014 [Page 11]
Internet-Draft Pervasive Encryption March 2014
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5636] Park, S., Park, H., Won, Y., Lee, J., and S. Kent,
"Traceable Anonymous Certificate", RFC 5636, August 2009.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Unicast Secure RTP", RFC 6189,
April 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 6818, January 2013.
[merriam-webster]
"pseudonymity", March 2014,
<http://www.merriam-webster.com/dictionary/pseudonymity>.
[wikipedia]
"Opportunistic encryption", November 2013,
<http://en.wikipedia.org/w/
index.php?title=Opportunistic_encryption&oldid=581222222>.
Author's Address
Stephen Kent
BBN Technologies
10 Moulton St.
Camridge, MA 02138
US
Email: kent@bbn.com
Kent Expires September 19, 2014 [Page 12]
