Internet DRAFT - draft-hallambaker-entity
draft-hallambaker-entity
SMIME Working Group
Internet Draft P. Hallam-Baker
Document: draft-hallambaker-entity-00.txt VeriSign Inc.
Expires: October 2004 July 2004
Entity-to-Entity S/MIME
Status of this Memo
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026, and the author does not provide the
IETF with any rights other than to publish as an Internet-Draft
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.
Abstract
This document describes a set of related protocol extensions to
S/MIME, SMTP and DNS that collectively simplify deployment of
S/MIME. Particular attention is given to ensuring that S/MIME
authenticated content is only received by end user clients capable
of presenting the content in an acceptable manner. The proposal
extends the æend-to-endÆ security model of traditional S/MIME to
support end-to-edge, edge-to-end and edge-to-edge use cases.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
Hallam-Baker Expires - January !Undefined Bookmark, SAVEDATE[Page 1]
Entity-to-Entity S/MIME July 2004
Table of Contents
1. Introduction...................................................2
1.1 Brick Wall Deployment Model................................2
1.2 Beyond "End-to-End"........................................4
1.3 Do no harm.................................................5
1.4 The S/MIME Sender Problem..................................5
1.5 Support for S/MIME Without Cryptography....................5
1.6 Locating Public Keys.......................................6
1.7 Validating Public Keys.....................................7
2. Architecture...................................................7
2.1 Authentication.............................................8
2.1.1 Originator 8
2.1.2 Outgoing Edge Server 8
2.1.3 Incoming Edge Server 8
2.1.4 Receiver 8
3. SMTP Extensions................................................9
4. DNS Extension..................................................9
4.1 Policy Element.............................................9
4.2 Key Element...............................................10
4.3 X509 Element..............................................10
4.4 Authentication Policy.....................................11
4.5 Encryption Policy.........................................12
5. S/MIME Extensions.............................................13
5.1 Signed Attribute OIDs.....................................14
5.2 MIME Header...............................................14
6. Client User Interface.........................................14
7. Key Management................................................15
References.......................................................15
Author's Addresses...............................................16
1. Introduction
Despite years of effort S/MIME use lags far behind deployment. This
document examines the reasons behind the failure of S/MIME to
become ubiquitous and proposes a small number of very minor changes
to protocols and user interfaces to remedy these problems.
The proposal is entirely backwards compatible with the legacy base
of email infrastructure, whether S/MIME aware or not.
1.1 Brick Wall Deployment Model
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 2]
Entity-to-Entity S/MIME July 2004
Like many cryptographic security protocols, S/MIME has suffered
from a æbrick wallÆ deployment model that insists that the security
provided must be all or nothing. This approach refuses to accept
deployment strategies that are perceived as detrimental to
security, even when the security benefits are not actually relevant
to the party making the choice to deploy.
A particular problem in this respect has been security
architectures driven largely by ideological concerns rather than a
realistic approach to controlling and mitigating risk.
Deployment of network protocols and in particular security
protocols takes significant time and effort. This often leads to a
belief that a security protocol must be absolutely secure against
all imaginable forms of attack before deployment begins. In some
cases this belief has deployed release of an agreed specification
for over a decade.
Yet this concern for perfection should be compared to the clear
success of SSL and WiFi security protocols. Even though the initial
implementation of these protocols was deeply flawed these errors
were quickly corrected. Today more email messages are secured
using the SSL protocol than by any of the security protocols
designed specifically for use with email. Even the deployment of
large numbers of WiFi hardware devices, which only provide support
for a weak security protocol, has not resulted in disaster. This
situation is certainly undesirable, but there is little doubt that
almost all WiFi users will be using devices that support genuinely
secure protocols long before deployment of IP-Sec achieves close to
the same level of ubiquity.
Far from precluding subsequent deployment of strong cryptographic
protocols, the earlier weak systems paved the way for the strong.
System administrators were used to the fact that these applications
required security configuration. When they discovered that the
security protocols were flawed they insisted that vendors provide
an expeditious correction.
The traditional argument that weak security is worse than no
security at all must be re-evaluated. Over the past ten years
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 3]
Entity-to-Entity S/MIME July 2004
consumers have increasingly relied upon the Internet infrastructure
and made little distinction between those parts secured by
cryptography and those that are insecure. Nor is there any reason
to believe that consumer habits are likely to change through
education. Security is a means of controlling risk and in most
cases consumers have been effective in controlling their risk
exposure by transferring it to other parties.
Since security is risk control, not risk elimination, a protocol
enhancement that can be deployed immediately and mitigate a risk is
attractive even if another possible protocol enhancement might
become available that eliminates that risk.
A distinction must be made between the presence of protocol errors
that entirely eliminate the security of a protocol and understood
limitations of a protocol that mean that it does not provide
protection against every possible attack.
1.2 Beyond "End-to-End"
S/MIME, like PEM before it and also PGP is a product of the end-to-
end security doctrine. The security of a message should be unbroken
from origin through to reception.
The origins of this doctrine are surprisingly difficult to find.
Almost none of the invocations of the end-to-end security principle
contain any form of citation. Those that do contain a citation
usually refer to one of David ClarkÆs paper describing the end-to-
end argument in general. Unfortunately these papers deal with
complexity of protocol design and not security.
The end-to-end security principle appears to be the result of
subsequent efforts to adopt the end-to-end argument as a universal
truth. Unfortunately this claim is simply not substantiated,
particularly in respect of Internet security architecture. The fact
that no true æend-to-endÆ security architecture has been deployed
to date despite ten years of continuous effort requires that this
doctrine be re-examined.
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 4]
Entity-to-Entity S/MIME July 2004
Re-examination of end-to-end is particularly critical when the
widespread success of edge security measures such as VPNs and
Firewalls is considered. Edge security measures have provided
security benefits that are both significant and measurable.
In the case of a personal email sent from one individual to another
the end-to-end principle offers a clear security advantage. In this
case the risk that network administrators at either end of the
communication might read or modify the contents or of an email
message is certainly significant. But this circumstance represents
only one of the many situations in which email is used.
1.3 Do no harm
Sending an S/MIME message today involves an element of risk.
Despite the fact that S/MIME has been an IETF draft standard for
many years, a significant number of email clients do not support
S/MIME and of those that do support S/MIME several provide a user
experience that can only be described as æuser-hostileÆ. Instead of
providing the email recipient with confidence that the message sent
is secure, several email clients æwarnÆ the user when a signed
message is received.
An Internet user should never be placed at a disadvantage when they
choose to enable security.
1.4 The S/MIME Sender Problem
The patchy nature of S/MIME support is a significant factor in
reducing the willingness of users to sign outgoing messages. Unless
the sender knows (and remembers) the capabilities of the
recipientÆs email client it is usually best to avoid use of S/MIME
in case this causes annoyance.
1.5 Support for S/MIME Without Cryptography
The S/MIME specification provides developers with instructions for
implementing cryptographic security. Unfortunately the
specification does not provide guidelines for applications that do
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 5]
Entity-to-Entity S/MIME July 2004
not support cryptography but may nevertheless receive signed
messages.
While support for cryptographic processing inevitably requires the
application developer to spend considerable time and effort,
unpacking a multipart/signed container to display the contents
requires no more effort than the processing of any other MIME type
and developers should be encouraged to provide this minimal level
of support.
1.6 Locating Public Keys
Location of public keys has been a longstanding problem in PKI
deployments. First the client must discover the public key of the
party they wish to communicate with, secondly a trust path must be
constructed that establishes the key as trustworthy.
Location of a signing key is often simplified by including the
certificate of the signing key in the signed message itself. This
is also desirable for security reasons since it ensures that the
certificate subject and any attributes associated with the signing
certificate are strongly bound to the message certificate. If this
is not done there is the potential for a certificate substitution
attack.
Discovery of the trust path is a considerably harder problem,
particularly when cross certification is involved. The sender of a
signed message cannot know the trustworthiness criteria that will
be applied by the recipient. In a cross certification environment
the trust graph is a heterarchy with multiple roots, the sender
cannot know which roots the receiver trusts. It is therefore
necessary for the receiver to perform discovery of the trust path.
Directories based on the X.500 data model have been widely promoted
as a solution to the problem of discovering X.509 certificates. In
practice neither LDAP nor X.500 have provided much value outside
deployment in closed environments. Paradoxically it is the value of
the directory as the central hub of the enterprise information
infrastructure that constrains its use. Enterprises recognize the
value of perimeter security and resist proposals to expose internal
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 6]
Entity-to-Entity S/MIME July 2004
directory services to external parties, whether through a border
directory or any form of data connector. The consensus amongst
network security administrators is that LDAP is not a protocol that
should be allowed to traverse firewalls. This consensus is unlikely
to change at any time.
As with any other routing problem, the trust path discovery problem
is tractable provided the necessary data is available. In the
Internet æend-to-endÆ architecture, routing functions are actually
performed in the network itself and not at the end points. The
trust path discovery problem is tractable when it can be delegated
to a service that maintains the complete
1.7 Validating Public Keys
Once a public key has been located the application should determine
whether it is trustworthy before treating the corresponding
communication as secure.
While X.509 path validation is considerably simpler than path
discovery, a device that cannot perform this service for itself
should have the capability of delegating validation.
2. Architecture
The entity-to-entity security model is entirely pragmatic and
opportunistic in the application of security enhancements.
Any entity in the communication path may apply a security
enhancement provided that the entity knows that a subsequent entity
in the communication path will ensure that the message is delivered
to the recipient in an acceptable form.
Any entity in the communication path may remove any security
enhancement for any reason provided that the enhancement is not
marked as being specifically intended for a subsequent entity in
the communication path.
Any entity in the communication path may remove any security
enhancement if it is known that this is necessary to ensure that
the message is delivered to the recipient in an acceptable form.
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 7]
Entity-to-Entity S/MIME July 2004
2.1 Authentication
A signature may be opportunistic or explicit. An explicit signature
is added by means of explicit user intervention
2.1.1 Originator
An originator may add a signature opportunistically or by means of
explicit user intervention. An opportunistic signature may be added
automatically whenever the incoming edge server or the receiver is
known to provide acceptable support for an end user signature.
End to end security is achieved in the case that the end user is
known to provide acceptable signature support.
2.1.2 Outgoing Edge Server
An outgoing edge server may add a signature opportunistically or by
means of explicit user intervention. An opportunistic signature may
be added automatically whenever the incoming edge server or the
receiver is known to provide acceptable support for a domain
signature.
An outgoing edge server may remove a signature if it is not known
that the incoming edge server provides acceptable support for the
type of signature present.
2.1.3 Incoming Edge Server
An incoming edge server may remove a signature if it is not known
that the receiver provides acceptable support for the type of
signature present.
An incoming edge server may verify the signature and pass this
information on to the receiver using a discretionary header
encoding scheme.
2.1.4 Receiver
A receiver may verify a signature if present.
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 8]
Entity-to-Entity S/MIME July 2004
3. SMTP Extensions
The SMTP option SMIME is used to advertise support for S/MIME
messages.
A server that returns the SMIME option in response to the SMTP EHLO
command undertakes to ensure that any message containing S/MIME
enhancements will be delivered to the user in an acceptable
fashion. In particular:
. The server undertakes to ensure that an S/MIME message is
delivered in an acceptable manner regardless of the
capabilities of the end users MUA.
. Messages that carry an S/MIME signature will be treated as if
they were unsigned if the recipient is unable to verify the
signature for any reason.
A server that returns the SMIME option in response to the SMTP EHLO
command does NOT undertake to verify the signature on any signed
message in any way. In particular:
. A compliant server MAY simply strip the S/MIME package and
deliver the message content.
4. DNS Extension
The MARID policy extension SMIME may be used to specify the email
authentication and encryption policy for all mail originating from
a domain.
4.1 Policy Element
The Policy element specifies the security policy for a DNS domain.
The Policy element may contain the following elements.
Key [Any number]
A signature key that may be used to sign messages from the
domain.
X509 [Any number]
An X.509 cdertificate that may be used to sign messages from
the domain
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE [Page 9]
Entity-to-Entity S/MIME July 2004
AuthenticationPolicy [Any number]
An authentication policy corresponding to the domain
Encryption Policy [Any number]
An encryption policy corresponding to the domain
The following schema defines the Policy element:
[TBS]
4.2 Key Element
The Key element specifies a signature key that may be used to sign
messages from the domain.
The Key element contains the following attributes:
Algorithm [required]
The signature algorithm corresponding to the key
Value [required]
The key value (base 64 encoded)
The following schema defines the Key element:
[TBS]
4.3 X509 Element
The X509 element is used to authenticate an X509 certificate that
is used to sign messages from the domain by means of a message
digest function.
The X509 element contains the following attributes:
X509IssuerAndSerial[Optional]
Specifies the X509 Issuer and Serial number of the
certificate in the same format used in XML Signature.
Type [required]
The type of certificate, valid values are: EndEntity, CA
DigestAlgorithm [required]
The digest algorithm as specified by the S/MIME specification
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 10]
Entity-to-Entity S/MIME July 2004
DigestValue [required]
The result of applying the specified message digest function
to the certificate (base64 encoded)
Locator [optional]
A URI that resolves to the certificate
The following schema defines the Key element:
[TBS]
4.4 Authentication Policy
The AuthenticationPolicy element specifies the authentication
policy of the domain.
If an email message is received that is in violation of the
specified authentication policy for the domain it SHOULD be
rejected. A security notice may be returned to the corresponding
domain.
The following authentication protocols are defined:
SMIME
SMIME security.
PGP
PGP security.
Other
Any other security protocol.
The following authentication policies are defined:
EHLO
The specified authentication protocol will always be applied
whenever the receiving server advertises support in response
to EHLO.
Always
The specified authentication protocol will always be applied.
Never
The specified authentication protocol will never be applied.
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 11]
Entity-to-Entity S/MIME July 2004
Undefined
The specified authentication protocol may or may not be
applied.
The AuthenticationPolicy element contains the following attributes:
Protocol [required]
The authentication protocol, valid values include SMIME and
PGP.
Policy [required]
The authentication policy identifier, valid values include
EHLO, Always, Never and Undefined. If a different policy
identifier is specified it MUST be treated as if it was
Undefined.
The following schema defines the AuthenticationPolicy element:
[TBS]
4.5 Encryption Policy
The EncryptionPolicy element specifies the authentication policy of
the domain.
If an email message is received that is in violation of the
specified authentication policy for the domain it SHOULD be
accepted if the policy would require that the message be sent
encrypted but SHOULD be rejected if the policy would require that
the message be sent plaintext. A security notice SHOULD be returned
to the corresponding domain in either case.
The following encryption protocols are defined:
TLS
TLS security by means of the SMTP STARTTLS command.
SMIME
SMIME security.
PGP
PGP security.
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 12]
Entity-to-Entity S/MIME July 2004
Other
Any other security protocol.
The following encryption policies are defined:
EHLO
The specified encryption protocol will always be applied
whenever the receiving server advertises support in response
to EHLO.
XKMS
The specified encryption protocol will always be applied
whenever the receiving domain advertises the existence of a
corresponding XKMS server by means of the SRV record
specified in the XKMS 2.0 specification.
Always
The specified encryption protocol will always be applied.
Never
The specified encryption protocol will never be applied.
Undefined
The specified encryption protocol may or may not be applied.
The EncryptionPolicy element contains the following attributes:
Protocol [required]
The authentication protocol, valid values include STATLS,
SMIME and PGP.
Policy [required]
The encryption policy identifier, valid values include EHLO,
XKMS, Always, Never and Undefined. If a different policy
identifier is specified it MUST be treated as if it was
Undefined.
The following schema defines the EncryptionPolicy element:
[TBS]
5. S/MIME Extensions
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 13]
Entity-to-Entity S/MIME July 2004
Entity to entity signatures MAY be added automatically or through
the explicit intervention of the user. It is important that
applications are able to distinguish between these cases.
5.1 Signed Attribute OIDs
The use of the following OIDs as signed attributes allows the
status of the signature to be included within the scope of the
signature itself.
[TBS]
5.2 MIME Header
The following MIME header SHOULD be used to allow servers to
determine the status of the signature without decoding the S/MIME
signature package.
[TBS]
6. Client User Interface
All clients should tolerate multipart/signed messages of any form
without negatively impacting the user experience.
Should treat a message with an invalid signature as if it were
unsigned.
Should only warn users of invalid signature if it is known that the
message should have been signed. Rejecting the message is the
preferred course.
Should support the logotypes extension to present trust paths in a
graphical fashion. Important to display CA logos since these serve
as surrogate brands for companies that do not have a well known
logo. Logo display MUST be unspoofable.
Should support the automatic discovery of path discovery and key
registration services. In addition, why not discover the outgoing
MTA and the connection to the incoming MTA automatically?
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 14]
Entity-to-Entity S/MIME July 2004
Should support the use of delegated path discovery. May support
delegated path delegation.
Should support simple registration process using the existing
client credentials used to access the email host to register a key
pair.
7. Key Management
For mechanisms for locating and validating keys see the XKMS
specification [XKMS].
XKMS is a key centric public key infrastructure exposed as a Web
Service. We observe that as far as an application client is
concerned all public key operations involve a question of the form
æwhat is the public key that should be used for cryptographic
operation X when attempting to communicate using protocol Y to
entity Z. The XML Key Information Service Specification (X-KISS)
allows such a client to delegate this question to a Web Service.
References
[SMIME] B. Ramsdell, S/MIME Version 3 Message Specification RFC
2366, http://www.ietf.org/rfc/rfc2633.txt
[XKMS] Hallam-Baker, XML Key Management Specification Version 2.0
(XKMS 2.0), W3C Candidate Recommendation 5 April 2004,
http://www.w3.org/TR/2004/CR-xkms2-bindings-20040405/
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
Acknowledgments
The author acknowledges the contributions made to this proposal by
Nico Popp, Alex Deacon and Jeff Burstein.
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 15]
Entity-to-Entity S/MIME July 2004
Copyright Statement
Copyright (C) The Internet Society (year). 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."
"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."
Author's Addresses
Phillip Hallam-Baker
VeriSign Inc.
Email: pbaker@verisign.com
Hallam-BakerExpires - January !Undefined Bookmark, SAVEDATE[Page 16]
