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]