[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
Network Working Group J. Peterson
Internet-Draft NeuStar
Expires: April 18, 2005 October 18, 2004
Security Considerations for Impersonation and Identity in Messaging
Systems
draft-peterson-message-identity-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document provides an overview of the concept of identity in
Internet messaging systems as a means of preventing impersonation.
It describes the architectural roles necessary to provide identity,
and details some approaches to the generation of identity assertions
and the transmission of such assertions within messages. The
trade-offs of various design decisions are explained.
Peterson Expires April 18, 2005 [Page 1]
Internet-Draft Message Identity October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. What is Identity? . . . . . . . . . . . . . . . . . . . . . . 5
3. Roles in an Identity System . . . . . . . . . . . . . . . . . 6
3.1 Identity provider . . . . . . . . . . . . . . . . . . . . 6
3.2 Verifier . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Threat Model of Impersonation in Messaging Systems . . . . . . 8
5. Identity Assertions . . . . . . . . . . . . . . . . . . . . . 10
6. Keying for Assertions . . . . . . . . . . . . . . . . . . . . 11
6.1 Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11
6.1.1 Certificates . . . . . . . . . . . . . . . . . . . . . 12
6.1.2 Uncertified Public Keys . . . . . . . . . . . . . . . 13
6.2 Symmetric Keys . . . . . . . . . . . . . . . . . . . . . . 15
7. User-based and Domain-based Assertions . . . . . . . . . . . . 15
7.1 Name Subordination . . . . . . . . . . . . . . . . . . . . 17
8. Reference Indicators and Replay Protection . . . . . . . . . . 18
8.1 Canonicalization versus Replication . . . . . . . . . . . 19
8.2 Assertion Constraints and Scope . . . . . . . . . . . . . 21
9. Placement of Assertions and Keys in Messages . . . . . . . . . 25
9.1 Assertions in the Envelope . . . . . . . . . . . . . . . . 26
9.2 Assertions in the Content . . . . . . . . . . . . . . . . 27
9.3 Distributing Keys by-Reference or by-Value . . . . . . . . 28
9.4 Distributing Assertions by-Reference . . . . . . . . . . . 31
10. Privacy and Anonymity . . . . . . . . . . . . . . . . . . . 31
11. Conclusion: Consensus Points and Questions . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 36
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
B. Verification Assertions . . . . . . . . . . . . . . . . . . . 37
C. Messaging: Real-Time versus Store-and-Forward . . . . . . . . 37
D. Third-Party Assertions . . . . . . . . . . . . . . . . . . . . 38
E. Alternatives to Identity Assertions . . . . . . . . . . . . . 39
E.1 Trusted Intermediary Networks . . . . . . . . . . . . . . 39
14. Informative References . . . . . . . . . . . . . . . . . . . 34
E.2 Dial-back Identity . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 42
Peterson Expires April 18, 2005 [Page 2]
Internet-Draft Message Identity October 2004
1. Introduction
Widespread forgery of the From header field of email [5] messages is
the most immediate motivation for work on message identity systems.
However, there are numerous other messaging systems used on the
Internet that currently confront similar problems, or are likely to
confront these problems in the future; notably instant messaging
systems and other real-time communications systems that leverage a
messaging architecture as a rendez-vous protocol for session
establishment. All of these systems suffer from a similar threat of
impersonation (as described in Section 4). Messaging identity
mechanisms, as defined in this document, address specifically the
threat of impersonation in messaging systems.
It is unlikely that the diverse identity requirements of these
various messaging systems will admit of any single solution that
could be deployed for all such protocols. However, there is much to
be gained by considering the broad body of work on the messaging
identity problem that has already been done across this wide
selection of protocols. The core commonalities of these systems
permit a high-level analysis of the message identity problem that
could assist all messaging protocols in selecting an appropriate way
of incorporating identity.
This document aspires to apply to messaging systems with the
following architectural qualities:
o The messaging system has the two agents: originators and
recipients. Both originators and recipients interact with the
system through endpoints. Messages sent from endpoints may pass
through multiple intermediaries before arriving at the recipient.
For the purposes of this document, reflectors and similar services
are lumped in with intermediaries, even if from a protocol
perspective they act more like endpoints.
o The messaging system employs names that are constituted of a
'host' portion, which is a DNS [6] name (allocated through the
delegative administration of the DNS) and a 'user' portion which
is administered by the domain indicated in the 'host' portion.
o The messaging system carries messages that are divided into two
major components: envelope and contents. The distinction between
the two is inexact, but primarily the content is intended to be
rendered by the recipient's application, whereas much of the
envelope contains addressing and routing data that is used by
intermediaries. [In deference to the email community, 'envelope'
here should be understood to encompass both the envelope and
header portions of a message.]
o The messaging system is used in an interdomain context. Different
administrative domains may deploy messaging intermediaries and
issue names to valid local users. Administrative domains need to
Peterson Expires April 18, 2005 [Page 3]
Internet-Draft Message Identity October 2004
be capable of exchanging messages with one another if they have no
previous association.
o The messaging system is capable of 'retargeting' a message in
transit, and delivering it a recipient whose name in the system is
not identical to that of the intended recipient specified by the
originator. Primarily, this arises when an intermediary forwards
a message to multiple recipients (in which case the resource
designated as the intended recipient is some sort of reflector).
This document was written based on the author's experience on
developing identity solutions for the Session Initiation Protocol
(SIP, [11]) and on consideration of several proposals circulating to
provide similar features in email.
The scope of this document is limited to the generation, carriage,
and consumption of identity assertions. It does not consider any
authorization decisions that might be made, on the basis of the
identity of the originator, by the consumer of identity assertions.
This document is organized as follows: Section 2 attempts to define
identity, and to demonstrate broadly the current manner in which
identity is communicated in messaging systems. Section 3 describes
the abstract roles that must be instantiated in a system in order to
incorporate identity assertions into a messaging architecture: the
identity provider and the verifier. The threat model for
impersonation in messaging systems is considered in Section 4.
Section 5 defines an identity assertion, and explains the manner in
which cryptography can be leveraged to generate assertions. Section
6 provides an overview of keying and key distribution architectures
that provide a foundation for sharing cryptographic assertions.
Section 7 compares the traditional concept of user-based assertions
with the newer, and perhaps more promising, idea of domain-based
assertions. Section 8 considers the internal composition of an
identity assertion, and the elements in a message which the assertion
must guarantee in order to be correlated with a message. Section 9
considers various ways that an assertion might be added to a message.
Section 10 considers the privacy and anonymity implications of adding
identity assertions to messages. Section 11 attempts to pose the key
questions that should determine how a messaging protocol approaches
the incorporation of an identity mechanism, and to note when this
high-level analysis has revealed any general principles that point
one way or another on these questions. Various appendices discuss
related material that is not directly in the scope of the primary
analysis.
1.1 Terminology
This document intentionally uses core terminology that is to neutral
Peterson Expires April 18, 2005 [Page 4]
Internet-Draft Message Identity October 2004
existing messaging protocols. Terminology specific to email is taken
from [21].
2. What is Identity?
Every communications system has a namespace. For example, the
telephone network uses telephone numbers as a namespace, the postal
system uses postal addresses as a namespace, and the Internet
Protocol uses Internet Protocol addresses as a namespace. In order
for a name to be usable, it must meet the syntactical constraints of
the namespace, and it must be unique within the namespace.
Accordingly, namespaces generally require significant centralization
of administration, though in many cases, delegation can distribute
this work across multiple distinct authorities. In the context of a
particular communications system, the semantics of these names
enables the system to route communications to the appropriate
resources.
In the most common messaging system on the Internet today, email, the
namespace is founded on the Internet Domain Name System (DNS [6]).
Names (in RFC2822 [5] terms, the 'addr-spec') are constituted of a
'host' portion, which is a DNS name (allocated through the delegative
administration of the DNS) and a 'user' or 'local-part' portion which
is administered by the domain indicated in the 'host' portion, and
which designates a particular resource or user in the domain. As the
message transfer service delivers the message, the host portion of
the destination email address is resolved in the DNS (though
practically, a message may pass through many intermediary
administrative domains before reaching its destination). Aside from
email, many other Internet messaging systems have constructed
namespaces with the same components: a domain name host portion and a
domain-specific user portion.
When a message is delivered to its recipient, the recipient has a
strong interest in knowing who the message is from. While the
contents of a message may be sufficient to identify the originator to
the recipient, it is also may happen that:
o the contents of the message do not identify the originator
o the contents of the message fabricate the identity of the
originator
o the recipient does not wish to read the contents of the message
without first identifying the originator
Most protocols therefore provide a field which designates the
originator of a communication. Generally, the originator is
identified by their name in the communication system. For example,
in the postal network, the originator is identified by their return
address; by convention, the return address of the originator appears
Peterson Expires April 18, 2005 [Page 5]
Internet-Draft Message Identity October 2004
on the outside of an envelope. In caller identification systems used
in the telephone network, the telephone number of caller is displayed
to the callee. In email systems, user agents render the contents of
the RFC2822.From header field of an email message as the originator.
Nothing forces the originator of a postal message to supply a genuine
return address on an envelope; originators are incented to provide a
genuine return address only if they want the envelope to be returned
to them if it cannot be delivered. Similarly, the RFC2822.From
header field of an email message can be populated arbitrarily by the
originator (though it is not necessarily the address to which bounces
are sent). Malicious originators may want to provide a misleading or
false return address for their messages, or to withhold a return
address altogether, in order to escape reports of abuse or to mislead
the recipient about the origins of the message. While there are
valid cases where anonymous communication is necessary, impersonation
can be very problematic.
For the purposes of this document, 'identity' refers to mechanisms
that provide an assurance of the originator of a message. An
identity assurance is provided by a party in the messaging
architecture that can prove its authority over a segment of the
namespace. For the identity systems considered in this document,
that may entail proof of authority over DNS names, or it may also be
authority specific to a particular user within a domain. This
assurance is communicated along with the message, and can be verified
by recipients of the message.
3. Roles in an Identity System
This document postulates two fundamental roles in a messaging
identity architecture: an identity provider and a verifier. These
roles might usefully be instantiated by any elements in a messaging
architecture. Most commonly, an originator or a proxy for the
originator of a message will act as an identity provider, and the
recipient or a proxy for the recipient will act as a verifier.
However, this is far from the only valid assignment of these roles.
There are even useful architectures where it is meaningful for the
originator to act both as the identity provider and the verifier
(where token-based assertions are used to authenticate networks
reports of undeliverable messages).
3.1 Identity provider
The role of the identity provider in an identity architecture is to
generate an identity assertion. An identity assertion is a chunk of
information added to a message which can later be verified to assure
Peterson Expires April 18, 2005 [Page 6]
Internet-Draft Message Identity October 2004
the identity of the originator.
An identity provider must be capable of authenticating the originator
of the message. The messaging architecture of the system in
question, and the entity that plays the role of the identity
provider, will largely determine how this authentication takes place.
If the identity provider is instantiated by the endpoint of the
originator, for example, this authentication might be tacitly
assumed, or occur in some application-specific way. If the identity
provider is built into an intermediary, some network authentication
mechanism must be used by the identity provider to ascertain the
identity of the originator.
An identity provider must have some verifiable authority over a
segment of the namespace of this messaging system; that is, it must
be capable of proving to verifiers that it is the appropriate entity
to identify the originator of a particular message. This proof of
authority can come in many forms, depending on the type of assertion
that the identity provider generates.
Once the originator has been authenticated, the identity provider
must furthermore determine whether or not the originator is
authorized to send the message in question; this practice is most
relevant to cases in which the identity provider role is instantiated
by an intermediary, since in those cases where the originator's
endpoint instantiates the identity provider, the originator itself
has authority over the relevant segment of the namespace. When it is
necessary, this authorization decision may be based on a number of
factors; for our purposes, the most important is the identity claimed
by the originator of the message. An originator may be authorized to
claim one identity, or any of a number of identities, in accordance
with the policy of the controller of the namespace containing the
identity. Identity providers only provide identity assertions for
messages in which the originator claims an authorized identity.
Ideally, an identity provider will be last entity in the architecture
that will modify the message in transit. An assertion will create a
signature over certain elements of the message, and if the message is
subsequently modified, it may violate this signature. The severity
of this condition is entirely dependent on the nature of the
assertion, and in the elements of the message which are guaranteed by
the assertion. In practice, most messaging systems modify messages
in some fashion throughout their transit of the network, and
subsequent modification after the generation of an identity assertion
is most likely unavoidable in any practical deployments.
An identity provider must be capable of modifying a message, or
forcing another entity in the architecture to modify the message in a
Peterson Expires April 18, 2005 [Page 7]
Internet-Draft Message Identity October 2004
particular way, in order to incorporate the identity assertion.
Commonly, creating an identity assertion involves the use of
cryptography, and accordingly, generating identity assertions may
slow message creation or processing in the identity provider.
3.2 Verifier
A verifier consumes an identity assertion in order to verify the
identity of the originator of a message. After inspecting an
identity assertion, a verifier may make an authorization decision to
act on the message in any of a number of ways. Authorization
decisions made by verifiers are outside the scope of this document.
In order to perform its function, a verifier must be capable reading
the identity assertion in a message. Depending on the placement of
the assertion in the message, and the underlying architecture of the
messaging system, this may limit the entities that can instantiate
the verifier role.
It is possible that more than one verifier will inspect the same
assertion in a message. In some architectures, it may make sense for
one or more intermediaries to act as verifiers before a message
reaches its recipient, which may also act as a verifier.
Alternatively, an intermediary could reflect a message to a
potentially large list of recipients, in which case each recipient
(and/or intermediaries acting on their behalf) might act as a
verifier. In other architectures, an intermediary acting as a
verifier might strip the identity assertion before forwarding the
message; in such cases, the intermediary might replace the identity
assertion with a verification assertion (see Appendix B).
Verification assertions can also be added without stripping identity
assertions.
Commonly, the verification of an identity assertion involves the use
of cryptography, and accordingly, verifying identity assertions may
slow message processing in the verifier.
4. Threat Model of Impersonation in Messaging Systems
Impersonation is the practice of falsifying the elements of a message
that indicate its originator. This is generally done in order to
mislead a recipient about the origins of the message.
The most common adversary in impersonation threats is a passive
attacker. A passive attacker can capture email messages in some way:
they may see messages in transit, they may see archives of messages
on the web, or they might even be a recipient of a message. By
capturing messages, the impersonator learns how a genuine originator
Peterson Expires April 18, 2005 [Page 8]
Internet-Draft Message Identity October 2004
structures their messages, including the manner in which elements of
the message that indicate the originator are populated. The
impersonator then sends messages that mimic the structures used by
the originator they intend to impersonate, altering the destinations,
contents, and other meaningful headers as needed. In the case of
fictional originators, impersonators merely create plausible-looking
messages based on their experience with typical originators. In many
current messaging systems, there is no need to do anything other than
adopt the name of the desired originator and inject the message into
the messaging system.
The manner in which an impersonator injects messages into the
messaging system admits of varying degrees of sophistication. A
passive attacker may, for example, only be capable of injecting
messages as an originator, or they may control or be capable of
imitating intermediaries in the system. This can have a large impact
on the way that other elements in the messaging system perceive their
forgeries.
Another type of impersonator is an active attacker. An active
attacker can intercept messages in transport, modify them
arbitrarily, and then return them to the message transit system.
This is a harder sort of attack to mount, and a much harder attack to
defeat; consequently it may not be in the scope of identity assertion
systems to prevent this sort of attack. Since many intermediaries
that are not actually attackers exhibit essentially indistinguishable
behavior, designers of identity systems are further disincented from
meeting this threat.
The uses of impersonation are legion. An impersonator may want to
avoid reports or abuse, or accountability for the contents of
messages. Or, an impersonator may want to make a message appear to
come from a particular originator to whom they believe a recipient
will be sympathetic (which may lead the recipient to read a message
and inspect content of the impersonator's choosing).
Primarily, the purpose of an identity assertion is to prevent
impersonation. This means that it must provide the following
qualities:
o In order for an assertion to be valuable, it must provide a
stronger assurance than the return address conventionally attached
to a message. For example, an email identity system would be
totally uninteresting if it allowed any originator to arbitrarily
populate their identity, because this would constitute no
improvement over the existing RFC2822.From header field.
Typically, the strength of the assertion depends on some form of
cryptography, and provable authority over the namespace of the
originator. In some constrained environments, assertions instead
Peterson Expires April 18, 2005 [Page 9]
Internet-Draft Message Identity October 2004
derive their authority from some form of transitive trust (see
Appendix E.1); such assertions are outside the scope of this
document.
o The assertion must have a precise scope and constraints (see
Section 8.2), whether these are explicit in the message or static
and understood implicitly in the messaging protocol. It is
assumed that the means by which a passive attacker collects
messages will also allow them to collect identity assertions, and
impersonators may accordingly attempt to replay them. Constraints
are intended to combat replay attacks.
o The assertion must denote the identity provider in some secure
fashion, and provide any information necessary for the verifier to
validate cryptographic properties of the assertion. Assertions
must provide verifiers with a means of determining whether or not
the identity provider is authoritative for the namespace of the
originator of a message.
5. Identity Assertions
An identity assertion is a piece of information (perhaps a header, a
parameter, or a attached document) added to a message by an identity
provider in order to provide verifiers with identity information
about the originator of the message.
Most existing and proposed identity mechanisms for Internet messaging
systems leverage some form of cryptography. Public key (or
'asymmetric') cryptography is an especially attractive tool in this
context, because it allows a verifier to validate an assertion even
if it has never before been contacted by that originator. Symmetric
key cryptography, by way of contrast, requires that the identity
provider and verifier share some pre-arranged secret.
Cryptographic signatures generated by an asymmetric keying mechanism
provide authentication of the signer and integrity over the signed
information. There are a number of ways that a signature can provide
identity information, depending on the type of key used to generate
the signature, and the identity of the signer.
Providing a signature over an identity string like 'joe@example.com'
alone, however, does not provide a strong assertion of the identity
of the originator of the message. The assertion must contain enough
supplemental information that it is clear that it refers to this
particular message, not just any message in which an attacker might
try to replay the assertion. The constraints and scope of assertions
is discussed further in Section 8.
Assertions may also be encrypted. In some cases, it may be desirable
Peterson Expires April 18, 2005 [Page 10]
Internet-Draft Message Identity October 2004
to hide the identity of the originator of a message from
intermediaries, but to reveal this information only to a particular
recipient, or vice versa. Potentially, this could provide certain
privacy properties to an identity assertion mechanism (see Section
10).
The use of cryptography requires some mechanism for key distribution
and may require a public key infrastructure with widely-distributed
root certificates. Encrypting identity assertions requires more
complex keying systems. The use of certificates, uncertified
asymmetric keys, and symmetric keys is discussed in Section 6.
6. Keying for Assertions
Cryptographic identity assertions require the use of keys. In order
for a cryptographic signature over an assertion created by an
identity provider to be validated by a verifier, both parties must
possess corresponding keying material. Since Internet messaging
systems assume that messages can be sent to arbitrary recipients that
have no previous association with the originator, key distribution is
the primary problem confronting the use of cryptographic identity
assertions.
Note that regardless of the keying mechanism used, an identity
provider may have multiple keys that it employs for various reasons.
Provided that there is way to link an assertion to a particular key
used by the identity provider, this requires no special support from
the identity mechanism.
6.1 Asymmetric Keys
Asymmetric keys are credentials that have been split into two
components, a public and a private key. The holder of the
credentials keeps the private key secret, and widely distributes the
public key. If a document is signed with the private key, the
signature over the document can be validated with the public key.
This signature provides integrity over the document, and
authenticates the signer.
An identity assertion is a type of document that can be signed with a
private key by an identity provider. In order to validate the
signature, the verifier must hold the corresponding public key, and
must have some reason to think that this public key is associated
with the identity provider. In order for that signature to provide
any guarantee of the identity of the originator, the verifier must
also have some assurance that the identity provider is authoritative
for namespace of the originator of a message.
Peterson Expires April 18, 2005 [Page 11]
Internet-Draft Message Identity October 2004
Asymmetric keys may be generated by an identity provider, or acquired
by the identity provider from a third party such as a certificate
authority. Thus, there are two significant varieties of public keys
- uncertified public keys, and public keys within certificates. The
certification status of a public key has a tremendous impact on how
it can be distributed and the manner in which it assures authority
over a namespace.
6.1.1 Certificates
A certificate [12] is a document that binds public keying material to
a particular name, the 'subject' of the certificate. The certificate
is signed by a certificate authority, and accordingly, parties that
validate certificates must possess the public keys of certificate
authorities (and unfortunately, the chain of certification between a
particular certificate and the root certificate authority can include
multiple middleman certificates). For the purposes of this document,
self-signed certificates are simply considered uncertified public
keys.
Certificates support a wide variety of subject formats. Two are
significant to the scope of this document. First, a certificate's
subject can be a valid name in an Internet messaging system, such as
an email address. Second, the certificate's subject can be a domain
name. Depending on the nature of the subject, the certificate can
sign user-based or domain-based assertions; this is discussed further
in Section 7.
Whether user-based or domain-based certificates are used,
certificates have a common set of advantages and drawbacks. The
primary advantage of certificates is that they provide a strong link
between a public key and a subject. Accordingly, by looking at the
subject of a certificate, it is relatively easy to decide whether or
not they are authoritative for the namespace of a particular
originator of a message (bearing in mind the caveats in Section 7.1).
Because a certificate is a signed document, certificates can also be
distributed over the network without requiring integrity over the
transport; e.g., a certificate store for an identity provider could
use an insecure transport like vanilla HTTP to distribute
certificates.
The downside is that certificates do not represent a permanent
binding. Certificates have an expiration date, and consequently
certificates must be periodically renewed, which is an operational
hassle for identity providers. However, parties that rely on
certificates cannot assume that a certificate is still valid simply
because it has not expired. Certificates can also be revoked,
usually as a consequences of the compromise of their corresponding
Peterson Expires April 18, 2005 [Page 12]
Internet-Draft Message Identity October 2004
private key. Relying parties are therefore required to monitor
certificate revocation lists (CRLs) issued by certificate
authorities. Because this entails cumbersome operational procedures,
relying parties rarely adhere to this in practice. With all that in
mind, it must be remembered that uncertified public keys do not
represent a permanent binding either, and that there are no
comparable intrinsic mechanisms for determining the expiry or
compromise of an uncertified public key, even if a relying party was
sufficiently troubled by these concerns to employ them.
6.1.2 Uncertified Public Keys
Public key cryptography can also be used for identity assertions
without certificates; for example, an identity provider may generate
a public/private key pair itself. This requires a mechanism for
distributing public keys in which the identity of the private key
holder is implicitly or explicitly disclosed to potential verifiers,
and verifiers understand unambiguously the namespace for which the
identity provider is responsible.
One way to associate an uncertified public key with a message
originator is to transmit the public key in an initial unsigned
message. The recipient, upon receipt of the public key, could store
it in a local, application-specific keychain, indexed by the
originator's return address (for user-based assertions) or the
originating domain (for domain-based assertions) - the message would
need to make clear precisely who the identity provider is. Future
signed messages received from that originator (or domain) could be
validated with the public key. This mechanism of key distribution
will be referred to in this document as the "leap-of-faith"
mechanism. It merits this particular name because the originator and
recipient must have faith that no man-in-the-middle interfered with
the initial message containing the public key. If an active attacker
were present in the key exchange, they could inject their own public
key and impersonate the originator to that recipient.
The leap-of-faith follows the example of SSH, which is widely
regarded as a vast improvement over insecure telnet-style
applications, and no doubt the leap-of-faith method of distributing
public keys for identity providers would be an improvement over a
lack of identity assertions altogether. Unfortunately, messaging
architectures almost inevitably involve application-layer
intermediaries that could inspect or modify leap-of-faith keys, and
in this respect messaging is significantly distinct from the
traditional client-server architecture of SSH.
The other challenges facing this approach rest largely in associating
the key with a legitimate identity provider, and determining the
Peterson Expires April 18, 2005 [Page 13]
Internet-Draft Message Identity October 2004
namespace for which that identity provider is authoritative.
Practically, there isn't really a way to do so; when a message
arrives with an uncertified public key in it, that key is ultimately
serviceable only as an validation of that particular (anonymous)
identity provider. When future messages are received, the verifier
can prove that these assertions were created by that same identity
provider, but that verification offers no proof of the namespace for
which that identity provider is authoritative. This problem is
severe enough that leap-of-faith key distribution is probably only
meaningful for anonymous user-based assertions. But again, even
anonymous user-based assertions are better than nothing.
The DNS might also be leveraged to bind a public key to an
identifying domain. DNSSEC [23], for example, provides public keys
in a DNS resource record. Those keys are known to be associated with
a particular domain (thanks to the delegative structure of DNSSEC).
Those keys, or some other keying material in the DNS which is signed
via DNSSEC, could be used to provide a domain-based signature in the
request for an identity assertion (see Section 7). Even a simple
hash of the public key used by the identity provider, placed in the
DNS, would enable the transmission of domain-based public keys in
messages without any need for a leap-of-faith.
Note that strictly speaking, the keying material (or a hash of it)
does not need to appear in the DNS in order for the DNS to be
leveraged to bind a public key to an identifying domain. If the
identity provider were to run a key store service (like an HTTP
server) that made its key available, then the identity provider could
include a URI reference to that store with its assertion. Since the
DNS would be used to dereference that URI, the security of that store
is predicated on the security of the DNS. However, the operation of
the store exposes the identity provider to further security risks
(see Section 9.3), and since the DNS needs to be invoked in order to
find the store, using keys or hashes in the DNS is ultimately more
efficient from a messaging perspective.
In the absence of operational DNSSEC, however, using the DNS to find
uncertified keys is insecure. While the technical specifications of
DNSSEC are largely complete, it will likely be some time before
DNSSEC is fully operationalized. There are high-level changes that
would need to sweep through the DNS in order to operationalize
DNSSEC, whereas today individuals within the messaging community can
opt to employ certificates, or not, on an incremental basis. That
much said, it can be argued that the difficulty of subverting the DNS
is sufficiently high that this practice would deter a large number of
potential impersonators; verifiers can make they own policy decisions
about the strength of the assertion based on whether or not the zone
containing the keying material uses DNSSEC. Note, however, that this
Peterson Expires April 18, 2005 [Page 14]
Internet-Draft Message Identity October 2004
approach has no obvious way to support user-based assertions short of
placing many (for large domains, perhaps tens or hundreds of
thousands) of records in the DNS corresponding the keys of particular
individuals; since the identity provider's assurance of the namespace
derives from the DNS zone in which these key records are stored, the
security of providing domain-based assertions is materially the same.
Given either approach, it is desirable for validators to be capable
of caching uncertified public keys. For DNS-based schemes, the cache
duration could presumably be dictated by the time-to-live of the DNS
resource record containing the key or hash of the key. For the
leap-of-faith approach, additional metadata associated with the
public key would presumably dictate the length of time for which it
is safe to cache the key. Some further considerations related to
caching are discussed in Section 9.3.
One example of the leap-of-faith system in an Internet messaging
protocol is given in RFC3261 [11] Section 23.2 (for the case where
unsigned certificates are used).
6.2 Symmetric Keys
The use of symmetric keys for an identity assertion is severely
limited because it requires that the identity provider and verifier
pre-arrange a shared secret, which, for the typical assignment of
these roles, runs contrary to the requirement that the domain of the
originator and recipient of a message require no previous
association. However, depending on the intended applicability of the
assertion, this may not be an unreasonable constraint.
For a case like determining that a bounce resulted from a message
that an originator actually sent, the identity provider and verifier
of a message are the same endpoint (the originator). Since an
endpoint can reasonably be expected to share a secret with itself,
the use of symmetric keys is attractive for this use case.
The interdomain use of symmetric keys is further limited by the
difficulty of key distribution. Asymmetric public keys can be
distributed without fear that any passive attacker will be capable of
leveraging the keys to impersonate the principal. If a symmetric key
used for identity assertions is captured by an attacker, however, the
attacker can impersonate the principal for the lifetime of the key.
Symmetric keys essentially need to be negotiated, in interdomain
cases, through some out-of-band mechanism.
7. User-based and Domain-based Assertions
To understand the distinction between user-based and domain-based
Peterson Expires April 18, 2005 [Page 15]
Internet-Draft Message Identity October 2004
assertions, it is simplest to assume that they are generated by
certificates. Consequently, the discussion in the next few
paragraphs describes only the use of certificates to provide these
assertions; alternatives to certificates are described at the end of
this section.
In the simplest assertion, the identity provider is directly
authoritative for the name of the originator only. For example, the
identity provider holds a certificate with a subject of
'joe@example.com', and provides an identity assertion with the
private key corresponding to that certificate for only for messages
sent by 'joe@example.com'. We will refer to this sort of identity
assertion as a user-based assertion. Usually, the identity provider
is in this instance the endpoint of the originator, though of course
it would also be possible (though probably not very scalable) for an
intermediary to manage a keyring of such certificates for every user
in their domain.
While this case is straightforward, there is no widely-supported
public key infrastructure that issues user-based certificates to
date. The only successful PKI on the Internet today provides
domain-based certificates, primarily for securing web transactions.
These certificates have a hostname subject of the form 'example.com'
(or, more commonly, 'www.example.com'). While there are many reasons
why domain-based certificates are more successful than user-based
certificates, for our purposes the most important is enrollment: it
is very easy for a certificate authority to determine who controls
'www.example.com' (since this is a matter of public record), but very
difficult for a certificate authority to determine to whom
'example.com' has allocated the username 'joe'. The only deployable
means of doing so today (email pings) are essentially leap-of-faith
mechanisms.
Because domain-based certificates are widely available, and the root
certificates of the major certificate authorities that issue these
certificates are installed on almost all Internet-enabled platforms,
the prospect of leveraging domain-based certificates for identity in
messaging systems is very attractive. Compared to user-based
certificates, domain-based certificates are also attractive because
there need to be fewer of them in the overall messaging system, since
there are generally many users to a given domain. This is
advantageous both for identity providers, especially from a cost
perspective, and for verifiers, who will need to persist many
certificates from remote domains.
When domain-based assertions are employ, the certificate itself does
not provide the identity of the originator, but it does prove that
the identity provider is authoritative over a particular segment of
Peterson Expires April 18, 2005 [Page 16]
Internet-Draft Message Identity October 2004
the namespace. Accordingly, the identity provider's signature must
cover some field of the request that contains the identity that the
signer is asserting. In order for the assertion to have any
strength, that identity must be within the segment of the namespace
for which the signer is authoritative; i.e., if the certificate of
the signer proves authority over 'example.com', then the signature
would be valid if the identity of the originator were
'joe@example.com', but not if the signature were over
'alice@example.org'. This gives rise to quite a few subtleties which
are discussed in Section 7.1.
In order to acquire a domain-based identity assertion for a request,
originators would typically need to forward their message to an
intermediary that instantiates the identity provider role (unless the
originator holds a certificate authoritative for its own domain).
This in and of itself can be viewed as a drawback, since in many
messaging architectures originators are not required to send messages
through any specific local intermediary. Moreover, messaging
protocols are used in some environments that constrain the first-hop
local intermediary to which an originator sends a request (e.g.,
blocking outbound SMTP with an enterprise firewall). In those
environments, originators would be unable to acquire an identity
assertion from an intermediary that was unsanctioned by the operator
of the environment.
Note that the considerations applying to domain-based certificates
also apply to most DNS-based mechanisms for public key distribution -
the identity assertions generated by keys distributed on a per-domain
basis through the DNS are domain-based assertions. The distinction
lies in the strength of the assurance - uncertified public keys
distributed through the DNS without DNSSEC are inherently less secure
than certificates, and thus can be said to provide a weaker
domain-based assurance.
7.1 Name Subordination
Identity assertions become harder to verify when the subject of the
signer's certificate does not correspond exactly with the
originator's name. There needs to be a deterministic way of deciding
if an identity provider is authoritative over the namespace
containing an originator's name.
For example, how should a verifier treat an identity assertion
generated by an identity provider with a certificate for
'joe@example.com' when the originator of the associated message is
given as 'joe@mail.example.com'? The problem is more pronounced with
domain-based assertions. How should a verifier treat an identity
assertion generated by 'alice.example.com' for a message whose
Peterson Expires April 18, 2005 [Page 17]
Internet-Draft Message Identity October 2004
originator is 'joe@example.com'? What if the domain were
'joe.example.com', or 'mail.example.com', or 'sip.example.com'?
We are forced to pose this authorization question because the
verifier has no way to know how the identifying domain 'example.com'
has allocated its namespace - which is why these problems are
problems of name subordination. While authorization policy is
outside the scope of this document, there are potentially ways to
design a messaging identity system such that these concerns never
arise. The most obvious way is to be very strict about generating
assertions - to mandate, for example, that identity providers cannot
provide domain-based assertions for messages unless their domain (the
subject of their certificate, or the zone containing their key in the
DNS) corresponds exactly to the host portion of the originator's
return address. But this may be too rigid to support some use cases.
Another possible solution is to leverage the DNS in some new way to
designate the identity provider for a domain. Just as one resource
record type designates the mail exchanger to which mail should be
sent, some other DNS resource record might designate the identity
provider for email messages in a domain (e.g., for 'example.com', the
identity provider for mail messages resides at
'mail-ident.example.com'). Predictably, this solution is limited by
the lack of an operational DNSSEC infrastructure in the DNS. Without
DNSSEC, it is possible that an attacker could spoof DNS responses to
suggest that an inappropriate host is the signer for the domain;
essentially, this grants the attacker the ability to impersonate any
user in the domain.
8. Reference Indicators and Replay Protection
If any attacker can cut an identity assertion from a legitimate
message, paste it into an arbitrary message of their own, and thereby
fool a verifier into believing that the hacked message came from the
originator of the legitimate message, then the value of the identity
assertion is essentially nil, given that it exists primarily to
prevent impersonation. If an identity assertion provided only a
signature over the name of the originator, assertions would be
trivially exploitable in precisely this fashion.
Accordingly, an assertion must cover more than just the originator's
name. It must cover enough additional information that the assertion
cannot be replayed in a substantially message.
Ideally, the identity assertion would provide a signature over the
entire message, envelope and contents alike. If this were the case,
then an attacker could only replay the identity assertion in an
identical message - which would be a duplication rather than an
Peterson Expires April 18, 2005 [Page 18]
Internet-Draft Message Identity October 2004
impersonation. But practically, this wouldn't work for any existing
messaging system. In fact, in most messaging systems, intermediaries
need to modify the envelope in order to perform their duties. While
strictly speaking, intermediary modification of the content is not a
baseline requirement for a messaging system, some intermediaries do
so in order to enforce any of a number of domain-specific policies.
Consequently, were a signature over an entire messages included in
identity assertions, such signature are likely to fail to validate at
verifiers.
Thus, only some subset of the message must be signed. The selection
of the exact subset is a very difficult problem. For the purposes of
this document, the elements of a message that need to be signed in
order to bind an identity assertion to a particular message will be
termed the 'reference indicators'. The manner in which a subset is
identified or carried in the message also admits of more than one
plausible design choice.
8.1 Canonicalization versus Replication
There are two basic approaches to generating a signature over a
subset of a message - canonicalization and replication.
Canonicalization entails the generation of a canonical string from
the reference indicators. The signature is generated over that
string (or a hash of that string), even though the string as such
does not appear in the message. The canonicalization system must
specify the reference indicators that are going to be signed. The
reference indicators can be specified statically, as a component of
the specification of the mechanism, or dynamically, on a per-message
basis. In the former case, every identity assertion for every
message in the system will generate a canonical string containing
exactly the same reference indicators. In the latter case, each
assertion will denote in some manner which reference indicators have
been incorporated within the canonical string. When a verifier
receives the message, it extracts those same reference indicators
from the message, generates the same canonical string, hashes it
where applicable, and then determines whether or not the signature in
the identity assertion is valid for that canonical string.
The most practicable canonicalization procedures incorporate only the
most specific reference indicators from a message. For example,
inclusion of the entire RFC2822.From header field value (including
the header field name, the colon, whitespace, etc) is much more
problematic than the inclusion of only the addr-spec component of the
From header field value. The less specific the reference indicators
are, the harder it is for them to be canonicalized, and the more
Peterson Expires April 18, 2005 [Page 19]
Internet-Draft Message Identity October 2004
likely it is that intermediaries (though munging white-space,
changing line-wrap, and so on) may inadvertently change the canonical
string that will be generated by the verifier, or that the verifier
will miss a blot of whitespace, and so on.
Both dynamic and static reference indicators for canonicalization
have their drawbacks. Static reference indicators can be too
limiting; it is difficult to anticipate the reference integrity needs
of every imaginable message. Dynamic reference indicators, however,
are extremely complicated. The syntactical system required to
describe reference indicators is potentially an exercise in arbitrary
string manipulation, especially when attempting to denote reference
indicators with a high degree of specificity. Dynamic reference
indicators also leave much more room for error in the generation of
the canonical string, and accordingly, more room for discrepancy in
the manner that the verifier generates the canonical string. It is
difficult to strike a balance, and once you allow any reference
indicators to be decided on a per-message basis, the slope becomes
very slippery.
Replication attempts to avoid the difficulties of canonicalization by
providing a copy of the reference indicators that is carried within
the message itself. The simplest form of replication is the
reproduction of the entire message, which is then tunneled within the
message itself. The identity assertion is a signature over the
replication. Of course, if the entire message is carried within
itself, this doubles the size of the message (not even counting the
signature), and so presenting a subset of the message is again
desirable. However, unlike canonicalization, replication does not
require any pre-agreement or denotation of the reference indicators.
The reference indicators that appear in the replicated message are
visible to the verifier, and the verifier validates the signature
over the replication, not over elements in the original message which
need to assembled into a canonical string. If the signature over the
replication is valid, the verifier then compares the values of the
reference indicators in the replication to the corresponding elements
of the message. If these two correspond, then the identity assertion
is valid for this message.
Another significant distinction between canonicalization and
replication is that a verifier inspecting a replication-based
assertion can determine which reference indicators do not correspond
to the received message; a verifier validating a
canonicalization-based assertion can only tell whether or not the
reference indicators as whole exactly match the current message. As
a consequence, a verifier of a replication-based assertion can be
lenient towards minor discrepancies between the message signed by the
identity provider and the received message. If the verifier were
Peterson Expires April 18, 2005 [Page 20]
Internet-Draft Message Identity October 2004
implemented in a endpoint, the endpoint might even render an account
of the discrepancies to a user, who might be able to make an informed
decision about the severity of the differences. Another alternative
is that verifiers might 'clobber' the contents of the outer envelope
with the replicated envelope, treating only the replicated headers as
authoritative and ignoring any discrepancies. Clobbering, however,
only works when the reference indicators are carefully chosen;
otherwise, it may disguise the actions of an impersonator who has
cut-and-pasted the replicated assertion into a message of their
choosing.
Replication furthermore introduces the interesting possibility that
envelope elements intended for end-to-end consumption (that do not
need to be inspected by intermediaries, like the Subject header of
email) might be included in the replicated body, but not in the
headers. The originator might intentionally provide only the minimum
amount of information necessary in the envelope of the message, but
arrange for the identity provider to place detailed end-to-end
information in the assertion. Were the assertion then to be
encrypted, the identity provider could securely tunnel end-to-end
elements to the recipient. This is most meaningful when the
originator acts as the identity provider. Note, however, the
limitations of encryption in Section 10.
A very basic replication scheme deals poorly with the content of the
message. Many messaging protocols allow large content
(multi-megabyte email attachments leap to mind). Replicating this
content is extremely undesirable. In contrast,
canonicalization-based assertions do not become larger as the signed
content grows. Since canonicalization can use a hash of the
canonical string, even if the canonical string is built from the
message body, the size of the hash is unchanged. Traditional
approaches to message content security (including PGP [18] and S/MIME
[17]) sign a hash over the message content. Accordingly, some hybrid
approaches replicate reference indicators in the envelope but
canonicalize content, which can yield the best of both worlds.
One example of a canonicalization-based identity assertion for SIP is
given in sip-identity [25]. The core SIP standard, RFC3261 [11]
Section 23.4.2, provides a replication model that entails tunneling
the entire message; RFC3893 [14] provides a replication model for SIP
which is restricted to reference indicators alone.
8.2 Assertion Constraints and Scope
The choice of reference indicators dictates the constraints and scope
of the assertion. For example, if the reference indicators include
something like the email Date header field, then it is possible,
Peterson Expires April 18, 2005 [Page 21]
Internet-Draft Message Identity October 2004
after verification, to apply authorization policies related to the
time the Date header was created.
Whether canonicalization or replication is used, the selection of a
set of reference indicators must be informed by nature of the
messaging protocols. Which elements of the envelope and content are
necessarily immutable from the identity provider to the verifier
(however those roles are assigned)? Which are always mutable? Which
elements are conceivably reference indicators?
The following may not be a necessary or sufficient list for any given
messaging protocol, but it does exemplify the sort of analysis that
needs to be performed in determining whether or not an element should
be used as a reference indicator.
Beginning with the envelope, at a minimum, the name of the originator
of the message has to be preserved (in email, the addr-spec component
of the RFC2822.From header field).
It is also highly desirable to include some indicator that denotes
the intended recipient(s) of the message. Without such an indicator,
a message containing a valid identity assertion could be replayed to
a different recipient by a passive attacker who captured the message,
and the verifier would be unable to determine that the originator did
not intended to send this message to the designated recipient.
Barring the presence of other reference indicators, even the intended
recipient of the request could act as such a passive attacker.
Constraining the assertion with some sort of unique identifier for
the message is also very desirable. Most messaging protocols provide
a unique message identifier in order to enable the recipient to
detect duplicates, or to enable correspondents to refer to a previous
messages unambiguously. While the presence of a unique identifier in
the constraints does not prevent passive attackers from replaying
assertions to new verifiers, it does change the situation when
impersonators attempt to replay assertions to the same verifier
(which complements selecting the intended destination as a reference
indicator). It enables verifiers to remember unique identifiers for
some period of time. By doing so, verifiers can discover that they
previously verified a message with this unique identifier. This
does, however, have some important limitations. The first is
scalability. Intermediaries that act as verifiers can potentially
process staggering numbers of messages, and recording every passing
unique identifier in such intermediaries is probably infeasible.
However, this does not mean that the presence of a unique identifier
would not be useful for recipients that act as verifiers (who might
persist messages, including the unique identifier, for various
reasons anyway). The second limitation is a race condition. If the
Peterson Expires April 18, 2005 [Page 22]
Internet-Draft Message Identity October 2004
attacker's message is delivered to the verifier before the legitimate
message, a verifier might mistakenly believe that the attacker's
message is the valid one; while active attackers are the most likely
to successfully mount this sort of attack, in store-and-forward
architectures it is possible that a passive attacker might do so
(though not in a deterministic fashion, probably). A third
limitation is that in some architectures, a particularly intrusive
intermediary might alter the unique identifier of a message in the
process of forwarding the message; in these environments, the unique
identifier has little value.
Providing a time-based constraint can complement the use of unique
identifiers and other local policies at the verifier. Virtually all
messaging protocols provide an indicator in the envelope that states
when the message was created (such as the Date header in email).
This can aid verifier policies that help to manage replay protection.
For example, verifiers could be configured with interval of time
derived from some assessment of how long a message can plausible be
supposed to have remained in transit in the message system. If they
receive a message, and the time that has elapsed since the creation
of the message exceeds that interval, they could consider the
assertion invalid, or at least suspect. Obviously, this interval
would be very different depending on whether the messaging
architecture is based on a store-and-forward methodology or a
real-time delivery methodology. In concert with unique identifiers,
this interval of time could be used to determine how long a verifier
needs to remember unique identifiers recorded from valid past
messages. Some ways in which a passive attacker might collect
assertions for replay (from web pages of email archives, for example)
could involve the retrieval of very dated assertions that would be
flagged by this sort of policy.
Some elements of a message are half-way between envelope and content,
such as the typical Subject header field of email and SIP. Since it
is common practice for endpoints to render this element to the user,
and the element can significantly change how recipients understand
the message, it should serve as a reference indicator.
While any single one of the envelope-based reference indicators
described above would be insufficient to provide a strong assurance
of identity, in concert, they can meet the majority of the plausible
threats, and require such a high degree of sophistication from the
attacker that most impersonation would be eliminated. However, it
may not be possible for a verifier instantiated by an intermediary to
make full use of all of these indicators (the message's unique
identifier, for example). Moreover, it may not be possible for an
originator to act as an identity provider for all of these reference
indicators if certain elements (like the message's unique identifier)
Peterson Expires April 18, 2005 [Page 23]
Internet-Draft Message Identity October 2004
are generated by an intermediary.
The content of the message is also apparently a critical reference
indicator. Without a signature over the content, a passive attacker
who captures the message could preserve the envelope of a message but
send a completely different content, which allows the attacker to
impersonate the asserted originator and provide the content of their
choosing. Since in many messaging architectures, intermediaries can
legitimately alter the contents of messages (most commonly, either by
adding to the content or modifying the existing content in some
fashion), defending against replay of a message with a modified
content by a passive attacker is essentially the same level of
difficult as defending against message modifications made by an
active attacker.
In environments where intermediaries do modify message content for
legitimate or at least quasi-legitimate reasons, the issue of
protecting the content is academic. A signature over the content
will be violated if the content is changed. There relatively few
approaches to preventing intermediaries from violating these
signatures; a few examples include:
o If the messages use MIME [8], it is possible to apply MIME-layer
security to particular bodies in the content. If trivial
additions are made by an intermediary (such as appending a few
lines of text to the message), then they will fall out of the
scope of the MIME body or bodies. If one is especially lucky, the
intermediary might even be MIME-aware, and capable of
understanding how to interact with the complex multipart bodies
that MIME-layer security frequently requires.
o If rather than merely adding to the content, the intermediary
seeks to modify existing message content (filtering for content
that appears inappropriate, perhaps), then the only recourse is to
encrypt the content in its entirety. If it is unable to
understand the content, an intermediary will not be able to make
these sorts of alterations.
Neither of these solutions is applicable in all cases. However,
given the use of envelope-based reference indicators described above
in an identity assertion, most impersonations that replayed an
assertion but changed the content would be perceived as duplicates
(based on the unique identifier), outdated, or potentially in
violation of a Subject header constraint; moreover, it could only
impersonate the originator to a specific recipient or specific set of
recipients. It could be argued, therefore, that it is not necessary
to use the content as a reference indicator. But in messaging
systems and environments where it is safe to do so, the value of
including the content as a reference indicator is clear.
Peterson Expires April 18, 2005 [Page 24]
Internet-Draft Message Identity October 2004
An account of the mutable and immutable elements in a SIP message is
given in RFC3261. The most complete analysis of reference indicators
in SIP is given in the Security Considerations of sip-identity [25].
Given the sheer number of possible headers used by email (see [22]),
a complete analysis of mutable and immutable elements is probably a
fool's errand.
The surfeit of possible reference indicators may tempt designers to
punt on deciding, at a protocol level, which ones are appropriate,
and simply to allow identity providers to make this decision based on
domain policy or even on a per-message basis. There are two
disadvantages that this flexibility incurs. In the first place, if
the assertion is based on canonicalization, the assertion must be
accompanied by some sort of description of the reference indicators
that have been used to generate the assertion. Determining how to
describe reference indicators precisely is a significant challenge.
In the second place, it leaves a great deal of ambiguity in
intermediary behavior. How can an identity provider anticipate which
elements an intermediary might want to modify? If the standard is
firm about this matter, and all identity provider rely on the same
reference indicators, then operators of intermediaries will be
incented to phase out any practices that modify those elements. If,
on the other hand, each identity provider does things a little
differently, there could be significant operational turmoil that
could potentially lead to a rollback from the identity mechanism.
In the end analysis, for any given messaging system, there is
probably a finite set of identifiable elements that should be used as
reference indicators. At worst, there should be a set of fixed
reference indicators that can be supplemented with optional, dynamic
reference indicators as needed. Note that other constraints and
reference indicators that might be added by third-parties to the
identity process are described in Appendix D, and should not be
considered a part of the identity assertion created by the identity
provider to identity the originator a message.
9. Placement of Assertions and Keys in Messages
Most Internet messaging systems employ messages that are divided into
two major parts: envelope and contents. The envelope of a message is
typically made up of headers, like the traditional email RFC2822.From
header field, though some messaging systems used alternative schemes
(like XML for XMPP [13]). The contents consist of one or more
message bodies, typically, but not always, MIME bodies.
The division between envelope and contents is imprecise in most
messaging systems. As a general rule, the envelope is used by
endpoints and intermediaries in the addressing and routing of a
Peterson Expires April 18, 2005 [Page 25]
Internet-Draft Message Identity October 2004
message, whereas the content is generated by the originator's
endpoint, consumed by the recipient's endpoint, and rendered to the
recipient's application in some fashion. However, many elements in
the envelope are also rendered to the recipient (a classic example
being the Subject header field of email), and intermediaries have
numerous reasons to inspect or modify the contents of messages.
Given that an identity assertion needs to appear somewhere in a
message, there are two plausible alternatives:
o it could appear in the message content
o it could appear in the message envelope, as a value or parameter
of a new or existing element
The attractiveness of one or another of these options is greatly
dependent on the nature of the assertion, and particularly on the
size and encoding of the assertion. Canonicalization will result in
a smaller assertion than replication. To speak in particulars
briefly, for a base64-encoded assertion based on an RSA signature
(1024 bit key) of a SHA1 hash of the canonical string, the resulting
assertion is 175 bytes long - varying the key length will make the
message proportionally larger or smaller, obviously. It is difficult
to gauge the likely size of an assertion based on replication, since
it is highly dependent on the number of reference indicators
included, but it would be significantly larger. An example in
RFC3893 of a S/MIME-based replication assertion for SIP (containing
six headers) is 913 bytes long, counting the multipart/MIME wrapper
and the signature. A base64 encoded version of that assertion is
1240 bytes long.
9.1 Assertions in the Envelope
An envelope is generally composed of a set of elements that describe
the originator and intended recipient of a message, the subject of
the message, the time the message was created, some unique
identifiers for the message, and so on. It is a common practice for
intermediaries to inspect an envelope's elements in order to make
forwarding decisions, and to add additional elements to the envelope
to reflect various circumstances surrounding the delivery of the
message.
Provided that an assertion is short and syntactically manageable,
there's no reason why it couldn't appear in some new or existing
envelope element. Some messaging systems have a practical (if not
theoretical) limit on the size of envelope elements, in others this
is no cause for concern.
The syntax of the assertion is a more complicated issue. If identity
assertions based on replication are used, and are intended to be
Peterson Expires April 18, 2005 [Page 26]
Internet-Draft Message Identity October 2004
stored in the envelope, it may be syntactically confusing to store a
set of envelope elements within a single envelope element. Worst
case, this confusion could be alleviated by encoding the entire
assertion in some fashion (such as base64), but this would result in
quite a large string. Even in cases where element length is limited,
it is possible that a very large string encoded in this fashion could
be split across multiple envelope elements, and internally ordered in
some way, to meet practical size limits.
Intermediaries generally have an easier time reading and writing
parts of the envelope than the content, and according, if one intends
for intermediaries to instantiate the identity provider or verifier
roles, then placing assertions in the envelope has the distinct
advantage of requiring less changes to intermediary behavior.
Also, some messaging architectures might not guarantee the survival
of particular portions of the message as they traverse
intermediaries. For example, if intermediaries customarily rewrite
or delete particular envelope elements, it would be a poor design
decision to store an identity assertion as a value in those element.
9.2 Assertions in the Content
Given an assertion of large size or cumbersome syntax, storing an
assertion in the envelope might be undesirable. Appending the
assertion to the contents of the message (perhaps using a multipart
MIME body) might therefore seem superior.
However, for some messaging systems, placing identity assertions in
the content may limit the set of entities in the messaging
architecture that can instantiate the identity provider role. It
might be illegal for an intermediary, for example, to modify content.
This is the case with SIP, where an intermediary cannot delete or
modify the contents of a SIP message.
Placing assertions in the content can also limit the set of entities
that can instantiate the verifier role. Email intermediaries are not
required to be capable of understanding or parsing the contents of
email messages (especially MIME bodies), and accordingly, they cannot
be expected to act as verifiers of an identity assertion that appears
as part of the message content without requiring significant changes
to their functionality.
Furthermore, an identity system should be compatible with end-to-end
security of message contents. If the identity system requires that
an intermediary add a body to a message, and the endpoints are using
some end-to-end integrity mechanism like S/MIME or PGP, appending the
assertion to the content may violate that end-to-end integrity. If
Peterson Expires April 18, 2005 [Page 27]
Internet-Draft Message Identity October 2004
MIME is supported by these intermediaries, however, this problem
becomes less pressing, as intermediaries might add the assertion as a
complete MIME body by transposing the existing content into a new
multipart.
Placing assertions in the content is further complicated by the
manner in which the content of a message is rendered to the
recipient. Ultimately, an identity assertion is not a component of
the content that should be blindly rendered to the user. It is more
appropriate for a recipient's endpoint to consume the assertion as an
input to an authorization decision, which may in turn change the
manner in which the message is rendered to the user. The assertion
itself, a collection of cryptographic bits, is not something that
should be intermingled with the content rendered to the recipient.
Endpoints that do not support the identity assertion scheme, however,
are likely to do just that, and accordingly, placing the assertion in
the content leads to serious backwards-compatibility concerns.
A messaging system based entirely on the use of MIME content,
however, overcome these difficulties. Various Content-Dispositions
(see [10]) can inform the recipient's endpoint that it should not
render the content of a body to a user. Moreover, it can flag the
body as specifically containing an identity assertion. One such
Content-Disposition for identity assertions ("aib") is defined in
RFC3893. In messaging systems where multipart MIME support is not
guaranteed in endpoints, however, this would lead to backwards
compatibility issues.
9.3 Distributing Keys by-Reference or by-Value
The various keying schemes described in Section 6 entail a few
high-level models by which keys can be incorporated into requests:
inclusion by-reference and inclusion by-value. In the by-reference
case, some resource in the network would hold the key, and the
message would either explicitly (with something like a URI) or
implicitly (through some understanding built into the identity
architecture and messaging protocols) indicate where the key for a
particular identity provider can be acquired. In the by-value case,
the key would accompany the identity assertion in the message.
When an originator acts as a identity provider, they may not be
capable of operating or contracting with a network service such as a
key store. In those cases, they have no alternative but to include
keys by-value. Intermediary-based identity providers would generally
have no trouble offering keys by-reference.
Including keys by-value is attractive if the keys are self-validating
(as is the case with public keys bound to certificates). If keys are
Peterson Expires April 18, 2005 [Page 28]
Internet-Draft Message Identity October 2004
not self-validating, then clearly an impersonator could trivially
include a key of their own choosing with the request - this is an
instance of the leap-of-faith model described in Section 6.1.2.
Including certificates by-value, however, can be troublesome given
the comparatively greater size of certificates (though in many
messaging architectures, certificates can be incorporated into the
content of the message without dire ramifications). For the purposes
of comparison, an example self-signed certificate constitutes about
1100 bytes of data when base64 encoded; the public key it contains is
about 270 bytes of base64 data (for a 1024 bit RSA key).
The high-level problem with including keys by-reference is that the
verifier must have network access (if they do not already possess the
key) in order to validate the signature within an assertion; this is
not a requirement for verifier by-value assertions, and is important
for recipient-based verifiers in store-and-forward messaging
architectures. There are also potentially non-obvious consequences
of including keys by-reference. Consider, for example, that if the
message is not rendered to a recipient instantiating the identity
provider role for a protracted period of time (weeks or months), it
is possible that the key used by the identity provider will expire or
changed during that time; one interesting property of carrying
certificates by-value is that a verifier can determine, on the basis
of an expired certificate shipped with a message, if the assertion
was valid at the time it was created, provided that the assertion is
constrained by its creation time (though there would be good reasons
to be cautious about this practice).
Also, as another non-obvious consequence of by-reference key
distribution, note that the key store used by the identity provider
will be notified each time that a verifier acquires a key. This can
actually have important privacy implications, because in some cases,
this could reveal most or all of the recipients of the request to the
identity provider. The implications of this are further discussed in
Section 10.
It is important to recall that messages may be reflected to multiple
recipients - potentially, many thousands in some environments. While
it may seem to save message bandwidth to include keys by-reference,
thousands of requests to the key store may result in profoundly
greater network traffic. Note, however, that the impact for
domain-based keys is probably less than the impact for user-based
keys, since domain-based keys need to be acquired on a per-domain
basis, and a domain generally encompasses many users. There's no
question that the impact might be significant in either case.
Comparing the total bandwidth consumed by the two approaches, it is
also important to note that verifiers can cache credentials. So, if
Peterson Expires April 18, 2005 [Page 29]
Internet-Draft Message Identity October 2004
the verifier already has the key, and the key is still valid, a
reference to the key in a message will not necessitate the key's
retrieval. When keys are sent by-value, however, the originator has
no way to know whether or not a potential recipient already possesses
the key; this problem is compounded by the general difficulty of
anticipating who might conceivably receive a message. The only safe
policy is to send the key every time, when keys are distributed
by-value. When compared with the potential for thousands of
recipients to retrieve the key from a key store, however, this is
still comparatively a minor inconvenience.
It is furthermore the case that any network service which distributes
keys to verifiers will add new threats to the overall identity
architecture. The security properties of the protocols used to
implement the service become critical to the strength of the
assertion. Moreover, those services could be subject to
denial-of-service attacks intended to prevent verification of
messages with identity assertions.
Any network service that can provide keys by-reference to verifiers
might also provide keys to originators; originators, in contrast to
verifiers, would only need to access this local service very
infrequently, and at worst, only one originator would need to access
this service per message, which compares very favorably to the
unbounded set of verifiers to which a message might be distributed.
In fact, the manner in which originators authenticate themselves to
identity providers (which is outside the scope of this document) may
innately entail a key exchange - the originator may learn the keys of
their local domain as a matter of course. Provided these keys are
bound in certificates, this could potentially serve as an attractive
manner for originators to learn their identity provider's keys in
order to include them in messages by-value. This may be important in
architectures where it is desirable to add the key to the content of
a message, but intermediaries lack the capability or permissions to
make useful additions to the content.
Too hard to choose? Ultimately, there is an easy way to be flexible
about the incorporation of keys into a message. If there is a field
in the message that provides a URI where the key can be acquired,
this can be purposed to include a key by-reference or by-value. It
can be used by-reference to indicate, for example, an HTTP or HTTPS
URI where the key can be acquired; alternatively, it could use some
form of DNS URL (such as [24]) to denote a particular DNS resource
record where the key is located. If the message uses MIME bodies as
content, it could use the CID URI scheme [9] to designate a
particular MIME body that contains the key. The only option
considered in this document for which a URI does not provide a
solution is carrying they key by-value in the envelope, but of
Peterson Expires April 18, 2005 [Page 30]
Internet-Draft Message Identity October 2004
course, it wouldn't make much sense to have, for example, one header
in a SIP request contain a URI reference to another header in the
same message - a special-purpose header should be used to carry keys
by-value in the envelope.
9.4 Distributing Assertions by-Reference
It is also possible to distribute assertions by-reference; to force
the verifier to contact a service operated by the identity provider
in order to acquire an assertion that would be used to verify the
message. This is identical, from a security perspective, to a
dial-back identity scheme; see Appendix E.2.
10. Privacy and Anonymity
Anonymity plays an important part in communication systems. The
existence of an identity system should not preclude anonymous message
originators. However, it is possible to strike a balance in which
anonymized messages still contain identity assertions, and those
identity assertions are potentially still valuable.
Considering the classic case of an originator wishing to be anonymous
to recipients, there are numerous ways in which this could be
realized in the context of an identity system. If the domain of the
originator permits anonymous messaging, the originator could populate
their return address in the message with, say,
'anonymous@example.com', and send the message through the identity
provider of 'example.com'. This sort of anonymity is meaningful for
domains with a great many users, and less useful as the number of
users in the domain grows smaller. Alternatively, a message
anonymization service unrelated to the originator's usual domain
could act as an identity provider for a message. Receiving a message
signed by 'anonymous@anonymizer.example.org' is still, in all
likelihood, preferably from an authorization perspective to receiving
a message without any identity assertion whatsoever. An assertion
provides a pointer of accountability to the originating domain in
cases of abuse.
Another important form of privacy relates to preventing
intermediaries responsible for message transfer from reading the
identity assertion. Encryption of assertions entails a very
different key distribution problem than identity. In order to send
an encrypted message to a recipient, the recipient must possess a
corresponding decryption key. This key needs to be shared, in some
fashion, with the identity provider before the identity provider can
encrypt the assertion for that recipient. The problem is complicated
by the potential existence of multiple recipients. If the identity
assertion is encrypted for one particular recipient, and ends up
Peterson Expires April 18, 2005 [Page 31]
Internet-Draft Message Identity October 2004
being distributed to multiple recipients by a reflector, the addition
recipients will not be able to read or verify the assertion.
There are at least two strategies for overcoming this problem:
o Encrypt the assertion on a per-recipient basis (i.e., include
multiple versions of the assertion, each one encrypted with a key
corresponding to the decryption key of each recipient).
o Force all recipients to share a common decryption key, and encrypt
the assertion only once with that key.
Both of these approaches are limited by the fact that the identity
provider cannot anticipate who will receive the message. Moreover,
as the list of recipients grows larger, these strategies become
increasingly unmanageable. Even if a message is retargeted to only
one destination, the identity provider has no way to anticipate what
that destination might be. In the end analysis, encryption of
assertions is a very difficult practice to manage in messaging
identity architectures.
When a message is reflected to multiple recipients, this can give
rise to another privacy problem. If the identity provider's keying
material is included in the message by-reference, then the identity
provider will know who the verifiers are when they content the key
store to acquire the key (given that identity providers operates or
has some oversight of the key store). While not all reflectors need
to protect the privacy of their distribution list, it is very
probable that some do. This problem can even arise when a message is
forwarded by one recipient to another recipient, who subsequently
verifiers the message, if the original recipient did not want to
reveal to the originator that their message was forwarded. In an
identity architecture in which keys are always distributed by-value,
this problem never arises; if the originator or identity provider can
choose to include keys by-reference, however, this could be a
material concern. The concern lessen as the number of messages
assured by the identity provider grows larger (i.e., large domains
using domain-based assertions); any individual request becomes a
needle in a haystack. Nothing about a request for a key alone
identifies the message that the verifier is validating - although if
user-based assertions are used, it will reveal the originator of the
message. This is a major distinction between distributing keys
by-reference and distributing assertions by-reference; dial-back
identity schemes (see Appendix E.2) notify the identity provider of
the exact message that the verifier is inspecting.
11. Conclusion: Consensus Points and Questions
If the analysis in this document illustrates anything, it's the sheer
number of moving parts that must be fixed in order to arrive at an
Peterson Expires April 18, 2005 [Page 32]
Internet-Draft Message Identity October 2004
identity solution for a messaging system. It does, however, identify
the core consensus points in arriving at an identity solution. The
following are the major points that require analysis:
o keying: asymmetric keys vs. symmetric keys
o asymmetric keys: certificates vs. uncertified
o assertion structure: canonicalization vs. replication
o reference indicators: static vs. dynamic
o identity providers: originators vs. intermediaries
o verifiers: recipients vs. intermediaries
o content: a reference indicator vs. not a reference indicator
o assertions: domain-based vs. user-based
o assertion placement: envelope vs. content
o key distribution: by-reference vs. by-value
In order to arrive at a consensus on those points, questions like the
following need to be asked.
Do your use cases include identity assertions being validated by
verifiers who have no previous association with the identity
provider? If so, this argues for using asymmetric keys rather than
symmetric keys, since symmetric keys assume some pre-arranged key
exchange between the identity provider and the verifier.
Is the privacy of the recipients of a message with respect to the
identity provider, when a message is forwarded to unanticipated
destinations, important? At a high level, if you believe so, this
argues for supplying keys in messages by-value, rather than
by-reference. Alternatively, if the by-reference key store is the
DNS, one could argue that requests for keys are likely to be lost in
the general mass of queries targeting the DNS server (though this may
not be the case in practice, depending on how the query strings are
formulated).
Do you want recipients of a message to be able to verify messages
off-line? If so, this also argues for supplying keys by-value. If
keys are supplied by-value, it is far better to use certificates than
uncertified public keys, especially if you want domain-based
assertions.
Is it critical that an identity provider be securely associated with
a particular domain? If you say 'yes' to this, this argues for
domain-based assertions. Furthermore, depending on exactly how
critical it is, this argues for using certificates rather than any
system relying on the DNS (given the current state of DNSSEC
deployment) or a leap-of-faith system.
Is it possible to arrive at fixed set of reference indicators for
messages in your messaging system? If so, then this argues for using
Peterson Expires April 18, 2005 [Page 33]
Internet-Draft Message Identity October 2004
canonicalization rather than replication in assertions. If not, then
replication is probably a better bet than dynamic canonicalization.
If you can use canonicalization, then placing assertions in the
envelope is preferable for most messaging systems.
Do you want the use of identity assertions to be opportunistic for
endpoints? If so, then you want intermediaries to instantiate the
identity provider role.
Are you willing to try to prevent active attackers as well as passive
attackers? If so, then you may be willing to try to use message
content as a reference indicator.
12. Security Considerations
This document is entirely concerned with the security of Internet
messaging systems. It provides a survey of existing mechanisms to
provide identity in Internet messaging systems in order to counter
the seminal threat of impersonation. Since it treats messaging in
the abstract, rather than discussing any particular protocol, it
makes no specific recommendation for advancing any particular
approach for the problem. It does, however, show how some
architectural decisions, at a high level, are likely to be more
successful than others. It also suggests a way to divide-and-conquer
decision-making about identity enhancements for applicable messaging
systems.
13. IANA Considerations
This document contains no considerations for the IANA.
14 Informative References
[1] Postel, J., "Simple Mail Transfer Protocol", RFC 821, STD 10,
August 1982.
[2] Crocker, D., "Standard for the format of ARPA Internet text
messages", RFC 822, August 1982.
[3] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC
1459, May 1993.
[4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[5] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[6] Mockapetris, P., "Domain names - concepts and facilities", RFC
Peterson Expires April 18, 2005 [Page 34]
Internet-Draft Message Identity October 2004
1034, STD 13, November 1987.
[7] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures", RFC
1421, February 1993.
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2033, November 1987.
[9] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2111, March 1997.
[10] Troost, R., Dorner, S. and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[12] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[13] St. Andre, P., "Extensible Messaging and Presence Protocol:
Instant Messaging and Presence", RFC 3921, October 2004.
[14] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004.
[15] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
[16] Jennings, C., Peterson, J. and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/
MIME) Version 3.1: Message Specification", RFC 3851, July 2004.
[18] Elkins, M., Del Toro, D., Levien, R. and T. Roesler, "MIME
Security with OpenPGP", RFC 3156, August 2001.
[19] Sparks, R., "The Session Initiation Protocol (SIP) REFER
Method", RFC 3515, April 2003.
[20] Sparks, R., "The Session Initiation Protocol (SIP) Referred-by
Peterson Expires April 18, 2005 [Page 35]
Internet-Draft Message Identity October 2004
Mechanism", RFC 3892, September 2004.
[21] Crocker, D., "Internet Mail Architecture",
draft-crocker-mail-arch-01 (work in progress), July 2004.
[22] Klyne, G. and J. Palme, "Registration of mail and MIME header
fields", draft-klyne-hdrreg-mail-05 (work in progress), May
2004.
[23] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-protocol-09 (work in progress),
October 2004.
[24] Josefsson, S., "Domain Name System Uniform Resource Locators",
draft-josefsson-dns-url-10 (work in progress), September 2004.
[25] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-03 (work in progress), September 2004.
[26] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[27] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
Author's Address
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Appendix A. Acknowledgments
The author drew considerable inspiration for this document from the
longstanding discussion of identity on the SIP mailing list. The IAB
Workshop on Messaging in October of 2004 was also a valuable
influence.
Peterson Expires April 18, 2005 [Page 36]
Internet-Draft Message Identity October 2004
Appendix B. Verification Assertions
A verification assertion is a piece of information added to a message
by an intermediary-based verifier which asserts that an identity
assertion in the message was verified. These assertions are most
useful in architectures in which a recipient cannot be expected to
instantiate the verifier role itself. However, it is also possible
that verification assertions could be inspected by intermediaries
between the verifier and the recipient.
Verification assertions may be cryptographic, but typically they are
not. Usually, the recipient has some specific trust relationship
with the verifier, which may include the use of some other form of
security (for example, network or transport layer security) which
guarantees that the verification assertion was created by the trusted
verifier.
A verifier may strip any identity assertion from a message before
adding a verification assertion, or it may leave the assertion in the
message. The latter option is preferable, in so far as it is
forwards-compatible with recipients instantiating the verifier role.
While verification assertions are probably important for some
architectures, they are not strictly necessary to implement an
identity service. In fact, by rendering the identity architecture
less end-to-end, verification assertions may weaken the overall
security of the architecture.
Appendix C. Messaging: Real-Time versus Store-and-Forward
In most respects, the high-level messaging architectures discussed in
this document share common security properties regardless of whether
they are real-time or store-and-forward. However, there are a few
important respects in which the two differ:
Delay from Computation The instantiation of the verifier and identity
provider roles by the system (more or less irrespective of where
they are located) will incur some delay corresponding to the
complexity of the cryptosystems they employ. While this delay is
not likely to be noticeable in store-and-forward messaging
systems, it may be perceptible (and undesirable) in real-time
communications systems.
Offline Handling Store-and-forward systems allow users to read their
messages offline. Accordingly, if the recipient acts as a
verifier, the verifier might not be online when it reads the
message. This has important implications for any sort keys or
assertions that are carried by-reference (and for dial-back
identity schemes).
Peterson Expires April 18, 2005 [Page 37]
Internet-Draft Message Identity October 2004
Delivery Receipts Real-time messaging protocols tend to provide
real-time acknowledgements of message delivery by default. These
acknowledgements in turn have important identity properties.
While the same is true of various optional delivery
acknowledgement mechanisms that can be used in store-and-forward
systems, in real-time systems the responses returned to a message
can invoke all sorts of behavior on the originator side, including
resubmission of the request to alternate destinations and so on.
Any sort of response identity is outside the scope of this
document, and believed to be separable from the message identity
work described in this document.
By-Value Subversion In order to subvert a request to acquire keys
by-value from a key store, it really helps if the attacker knows
when the verifier will initiate the request. In real-time
messaging architectures, this is relatively clear - it will be
soon after the message has been sent. In store-and-forward
architectures, since the verifier might not validate the message
for hours or days or weeks, it can be very difficult for the
attacker to make this determination. Not that even in
store-and-forward architecture, if an intermediary acts a
verifier, this distinction becomes less acute - there is a
comparatively smaller time-window in zwhich an intermediary is
likely to verify a assertion, and accordingly, it may be easier to
subvert request for a key when an intermediary is the target.
Creation Time as a Reference Indicator In real-time messaging
systems, the creation time of a message is a very strong reference
indicator, since deliver of messages is expected to be very quick.
Accordingly, passive attackers have only a small interval of time
to mount a replay attack using an assertion with a creation time
reference indicator. In store-and-forward architectures, the
delivery window is extremely large, so creation time is a less
valuable reference indicator (though not entirely useless).
Appendix D. Third-Party Assertions
Many messaging architectures assign important roles to third parties.
To take a familiar example, email has the concept of a mailing list
which sends messages on behalf of an originator. For the purposes of
this document, a third-party assertion is differentiated from an
ordinary identity assertion as follows: a third-party assertion is
provided by an identity provider that is not authoritative for the
namespace containing the name of the originator of the message
(following the general constraints of Section 7.1.
Depending on the sorts of authorization decisions that a verifier
might want to perform, the identity of the originator may be
secondary, or even totally irrelevant, when a third-party is
involved. A particular recipient might wish to accept any email
Peterson Expires April 18, 2005 [Page 38]
Internet-Draft Message Identity October 2004
message from a particular mailing list, for example, without regard
to the identity of a particular originator. Other practical examples
include chat-rooms of instant messaging systems, and systems in which
one endpoint can instruct another endpoint to send a message (such as
the SIP REFER [19] method).
Clearly, the manner in which a third-party asserts something about a
message is orthogonal to the broader question of how to identify the
originator of a message. However, it is certainly possible that
third-parties may want to add additional cryptographic information to
a message in order to allow particular authorization decisions to be
made available to recipients. The formulation of third-party
assertions seems to be a problem that is entirely separable from the
identification of the originator, and is thus out of scope of this
document. Future work could identify a means of providing
third-party assertions that was entirely supplemental to the identity
work in this document.
An example of a third-party assertion is the Referred-by [20] token
associated with the SIP REFER method.
Appendix E. Alternatives to Identity Assertions
Identity assertions are not the only means of increasing a
recipient's surety of the identity of an originator of a request.
E.1 Trusted Intermediary Networks
It is important to note that identity assertions are primarily
motivated by the interdomain nature of messaging. Within a single
administrative domain, both the originator and the recipient of any
message must trust the same domain in order for messaging to function
at all. Accordingly, they can assume (perhaps without good
justification) that the domain would not connect them if it had not
properly authenticated them both.
Given this, some messaging architectures try to extend the boundaries
of an administrative domain in order to treat interdomain messaging
as an intradomain problem. In contrast to cryptographic assertions,
these identity systems rely on particular deployment architectures to
guarantee the security properties of the assertion. The only
assertion that is actually carried in the message is a separate
envelope element that provides an 'authoritative' return address.
For example, consider the 'trust domain' concept defined in Section
2.3 of RFC3324. In this messaging architecture, a trusted network is
a set of intermediaries that exchange messages with one another over
a closed network (a network either logically or physically
Peterson Expires April 18, 2005 [Page 39]
Internet-Draft Message Identity October 2004
inaccessible from the Internet, over which intermediaries pass
messages to one another).
Assuming such a trusted network, one can design a very simple
identity assertion. For example, in an email network, one could
introduce a new 'Trusted-From' header field whose contents could only
be set by intermediaries in the trusted network. The identity
information conveyed by such a system is the contents of this trusted
header. Recipients treat this trusted header as the assured identity
of the originator. An example of this sort of trusted assertion is
RFC3325 [16], which defines the P-Asserted-Identity header field for
SIP.
The traditional Internet Relay Chat (IRC [3]) service relied on a
similar concept of trusted intermediaries. Intermediaries formed a
meshed trust network over which messages passed, and each server was
responsible for authenticating its users.
While this model has enjoyed considerable success in closed networks
such as the telephone network, it has a number of limitations which
render it incompatible with widespread Internet deployment of a
messaging architecture. Forming closed overlay networks of providers
that agree on network or transport-layer security standards and
practices does not agree with the general model of Internet
messaging, in which domains may exchange messages without any
previous association.
Other, more sophisticated forms of transitive trust are ad-hoc. For
example, a message could contain an explicit indication that any
intermediary that relays the message needs to use some form of
transport or network-layer security when sending to the next hop.
Assuming a proper keying architecture, intermediaries can mutually
authenticate one another from the originating domain to the domain of
the recipient. The SIPS URI scheme in RFC3261 has this property.
The main drawback to such mechanisms is that it is impossible for any
intermediary or recipient to verify that appropriate lower-layer
security was used over any particular transit hop. This is, in fact,
the main problem with trusted networks in general - a given domain
must trust that the remainder of the domains in the network behave
properly.
E.2 Dial-back Identity
A dial-back identity system for messaging works as follows: when a
verifier receives a message, it inspects the name that identifies the
originator (such as the RFC2822.From header for email), and then
launches a dial-back request to that name. This dial-back request
must contain reference indicators for the request, either by-value or
Peterson Expires April 18, 2005 [Page 40]
Internet-Draft Message Identity October 2004
possibly as a hash of a canonicalization of the reference indicators.
In another variant, the message itself contains such a hash which is
verifiable by the recipient (essentially, an unsigned identity
assertion), and the recipient then sends that hash in the backwards
direction to the identity provider.
Assuming the name of the originator is valid, an identity provider
responsible for the namespace of the originator's name will receive
the request. If this identity provider is the originator, it can
reply to the request with a positive response if it did indeed send
the message in question. If the identity provider is some
intermediary, it would need some way to ascertain that the originator
sent that message; possibly, the originator sent the message through
the identity provider, and the identity provider keeps state for
every message it handled. However the intermediary-based identity
provider learns of the validity of a request, it returns a positive
response if the request was in fact sent from the originator in
question. If the identity provider does not recognize the described
message, it sends a negative response. No response (because the
domain of the originator's name doesn't exist, or exists but has no
identity provider) is assumed to be a negative response.
Depending on the semantics of the request, it may be somewhat
intensive for the identity provider to make a determination of
whether or not the request was actually sent by the originator. If a
message is forwarded to numerous recipients, obviously this
per-message work becomes larger, and for cases like large email
mailing lists, it may become unmanageable. The use of unsigned
hashes in the message moves this work to a phase before the message
is sent, rather than after the dial-back request is received.
In some respects, dial-back has similar properties to DNS-based
mechanisms of keying distribution discussed in Section 6.1.2. Since
these system relies on a request being sent in the backwards
direction using the name of the originator, it would necessarily rely
on the validity of the DNS to reach that name. However, unlike the
DNS-based uncertified keying mechanisms, dial-back requires no
special modifications to the DNS.
Dial-back identity systems have enjoyed some success in real-time
messaging systems, but clearly their applicability to
store-and-forward systems is limited, especially when the identity
provider role is instantiated by originators.
All in all, within their domain of applicability, dial-back identity
systems improve security with little expenditure of design effort.
They are not considered further in this document because they are not
predicated on identity assertions as such.
Peterson Expires April 18, 2005 [Page 41]
Internet-Draft Message Identity October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Peterson Expires April 18, 2005 [Page 42]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/