Cisco

psaintan@cisco.com

PayPal

Jeff.Hodges@PayPal.com

Applications Internet-Draft Many application technologies enable a secure connection between two entities using certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application servers in such interactions.

When a client wishes to establish a secure communication channel with an application server (e.g., "the HTTP server for example.com"), at a minimum the client needs to verify the identity of the server in order to prevent certain passive and active attacks against the connection. To establish secure connections, many application technologies use Transport Layer Security with certificates issued by certification authorities that are part of the Internet X.509 Public Key Infrastructure (PKI) as described in ; such application technologies include but are not limited to the following: The Hypertext Transfer Protocol , for which see also The Internet Message Access Protocol and the Post Office Protocol , for which see also The Lightweight Directory Access Protocol , for which see also and its predecessor The NETCONF Configuration Protocol , for which see also and The Network News Transfer Protocol , for which see also The Session Initiation Protocol , for which see also The Simple Mail Transfer Protocol , for which see also and The Syslog Protocol , for which see also The Extensible Messaging and Presence Protocol , for which see also Different application protocols have traditionally specified their own rules for representing and verifying server identities. Unfortunately, this divergence of approaches has caused some confusion among certification authorities, protocol designers, and application developers. Futhermore, currently the vast majority of deployed application servers use domain names in their certificates (typically via a subjectAltName extension of dNSName or a subjectName component of Common Name). Ideally, service operators would use application service identities in their certificates (such as an SRVName , a URI, or an application-specific name form), since this would reduce the possibility of attacks against unrelated services at domain names that provide many different application services. To codify secure authentication practices, this document specifies recommended procedures for representing and verifying server identities in certificates intended for use in applications that employ TLS.

This document applies only to server identities associated with domain names, only to TLS, and only to the PKI. Similar considerations might apply to client identities (e.g., for mutual authentication), to identities other than domain names (e.g., IP addresses), to security protocols other than TLS (e.g., and ), and to keys or certificates created outside the context of the PKI (e.g., where a dependency on Certificate Revocation Lists or the Online Certificate Status Protocol might introduce unacceptable latency or denial of service attacks). Although those scenarios might be able to re-use some aspects of the representation and verification rules provided here, they are outside the scope of this document and need to be addressed by separate specifications.

Most security-related terms in this document are to be understood in the sense defined in ; such terms include, but are not limited to, "attack", "authentication", "authorization", "certificate", "credential", "identity", "self-signed certificate", "trust", "trust anchor", "trust chain", "validate", and "verify". The following capitalized keywords are to be interpreted as described in : "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

The following individuals made significant contributions to the text of this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga.

The editors and contributors wish to thank the following individuals for their feedback and suggestions: Dave Crocker, Cyrus Daboo, Philip Guenther, David Harrington, Paul Hoffman, Scott Lawrence, Alexey Melnikov, Tom Petch, Pete Resnick, Joe Salowey, and Dan Wing.

Internet applications often use a client-server architecture in which a client connects to a server in order to retrieve or upload data, access a broader network of services, or communicate with other entities on the network. From the security perspective, a client might be a user agent controlled by a human, an automated process such as a bot, or a peer server. We assume that an application server hosts information, enables a provisioned account to perform authorized services, or provides network access on behalf of a particular organization or service that is canonically identified by a domain name (not, e.g., an IP address). The specific application provided (e.g., a web site or an instant messaging system) might further restrict the identity type that is represented or verified in a TLS interaction; such an identity type is often informal (e.g., most people expect a service that is provided on port 443 to be a web server) but can be specified more formally through the use of DNS SRV records , a Uniform Resource Identifier represented by a subjectAltName of uniformResourceIdentifier, the SRVName certificate extension defined in , or other certificate extensions that have been defined for particular identity types (e.g., the XmppAddr extension for use in ). The certificate presented by an application server might contain one identity or it might contain multiple identities of different types (e.g., one identity might be a simple dNSName and another might be an SRVName that restricts the certificate to use in the context of the specified service). When a client connects to an application server, it has some conception of either the server's identity (e.g., "an XMPP server for example.com") or of the server's location (e.g., "the SMTP server at mail.example.com"). The client expects at least one of the server's presented identities to match this reference identity. It is important to note that the reference identity is provided by a human user or configured into the client application (e.g., in the domain part of an "Application Unique String" as described in ), and is not an identity that is derived from the reference identity in an automated fashion (e.g., an IP address discovered through DNS resolution of the reference identity). Only a match between the reference identity and a presented identity enables the client to be sure that the certificate can legitimately be used to secure the connection. However, a user-oriented client MAY provide a configuration setting that enables a human user to explicitly specify a particular hostname to be checked for connection purposes, thus explicitly overriding matching rules. To summarize, we define the following terms to assist in understanding the process of representing and verifying server identity: The set of identities that are presented by a server to a client (in the form of the server's X.509 certificate) when the client attempts to establish a secure connection with the server. The "natural kind" of identity to which a presented identity or reference identity belongs. For example, the reference identity might be a domain name, an IPv4 or IPv6 address, or a particular service in the sense of or . This specification does not provide a complete taxonomy of identity types but assumes that an application server is identified by a domain name that could be represented in the form of several identity types (e.g., a dNSName and an SRVName). A single member of the identity set. The client's conception of the server's identity before it attempts to establish a secure connection with the server, i.e. the identity that the client expects the server to present and to which the client makes reference when attempting to verify the server's identity. The reference identity MUST be provided by the human user controlling the client (if any), e.g. when specifying the server portion of the user's account name on the server or when explicitly configuring the client to connect to a particular host. The reference identity MAY be reflected in the TLS "server_name" extension as specified in .

The following rules apply to the representation of application server identities in certificates issued by certification authorities, i.e., certificates that are to used for securing connections to application servers such as web sites, email services, and instant messaging services. The certification authority MUST issue the certificate based on the domain name at which the server will provide the relevant service (not an IP address or host name for a specific machine). An identity MAY contain one instance of the wildcard character '*' but only as the left-most label. An application protocol that re-uses the rules specified in this document MUST specify whether the wildcard character is or is not allowed in certificates issued for use with that protocol. If the service at which the certificate will be used deploys a technology that is discovered by means of DNS SRV records , then the certificate SHOULD include an identity of type SRVName . If the service is associated with a particular URI, then the certificate MAY include an identity of type uniformResourceIdentifier (i.e., a subjectAltName extension that includes a uniformResourceIdentifier name form whose authority component is the domain name of the service). Although the certificate MAY include other application-specific identities for types that were defined before specification of the SRVName extension (e.g., XmppAddr for ) or for which service names do not exist, the SRVName extension is preferred. If the certificate does not include an SRVName, uniformResourceIdentifier, or other application-specific identity type, then the certificate MUST include an identity of dNSName. The certificate SHOULD NOT represent the server's domain name in an identity of Common Name (CN) (see ) in the leaf Relative Distinguished Name (RDN) of the subjectName, even though it is recognized that many deployed clients still check this legacy identity. For example, here the CN is the leaf RDN, which is acceptable:

The certificate MUST NOT represent the server's domain name in an identity of Common Name (CN) where the CN is in something other than the "leaf" (left-most) position within the Relative Distinguished Names (RDNs) of the subjectName. For example, here the CN is not the leaf RDN, which is unacceptable:

The certificate MUST NOT represent the server's domain name by means of a series of Domain Component (DC) attributes (because the order of Domain Components is not guaranteed, certain attacks are possible if DC attributes are included).

At a high level, the client verifies the server's identity in accordance with the following rules: Before connecting to the server, the client determines the possible identity type(s) of the reference identity. During the process of attempting to establish a secure connection, the server MUST present its identity set to the client in the form of an X.509 certificate . Upon being presented with the server's identity set, the client MUST check the reference identity against the presented identities for the purpose of finding a match. To do so, the client iterates through all of the subjectAltName extensions it recognizes in the server's certificate and compares the value of each extension to the reference identity until it has either produced a match or exhausted the identities in the identity set (comparison rules for matching particular identity types are provided under , including fallbacks to several subjectName fields). Even if the application technology does not define an application-specific preference order for checking of identities, the client SHOULD check them in order from most specific (e.g., SRVName) to least specific (e.g., dNSName). Before attempting to find a match in relation to a particular presented identity, the client MAY map the reference identity to a different identity type. Such a mapping MAY be performed for any available subjectAltName type to which the reference identity can be mapped; however, the reference identity SHOULD be mapped only to types for which the mapping is inherently secure (e.g., extracting the domain name from a URI to match against a subjectAltName of type dNSName or SRVName). The client MUST NOT attempt to match against an an identity of type SRVName unless the service to which the client has connected deploys a technology that is discovered by means of DNS SRV records . If the identity set has more than one member, a match with any of the presented identities is acceptable. Note: A hostname that is resolved via the Domain Name System MUST NOT be used as the reference identity unless an administrator or human user has explicitly configured an application to associate a particular hostname (and potentially port) with the hostname to which the application connects (e.g., to "hardcode" an association between an original hostname of example.net and a configured hostname of connector.example.com:443). In addition to the identity check described in this section, a client might complete further verification to ensure that the server is authorized to provide the service it is requested to provide. Methods for doing so (which might include consulting local policy information) are out of scope for this document.

This document assumes that the reference identity is a domain name as defined by and for "traditional" domain names or by or for internationalized domain names. The client MUST match the reference identity against subjectAltName extensions of type dNSName and SRVName according to the following rules.

If the reference identity is a "traditional" domain name, then matching of reference identity against the presented identity is performed by comparing the set of domain components using a case-insensitive ASCII comparison (as clarified by ).

Note: This section needs to be updated to reflect . If the reference identity is an internationalized domain name, then an implementation MUST convert the reference identity to the ASCII Compatible Encoding (ACE) format as specified in Section 4 of before comparison with subjectAltName values of type dNSName; specifically, the conversion operation specified in Section 4 of MUST be performed as follows: In step 1, the domain name SHALL be considered a "stored string". In step 3, set the flag called "UseSTD3ASCIIRules". In step 4, process each label with the "ToASCII" operation. In step 5, change all label separators to U+002E (full stop). After performing the "to-ASCII" conversion with regard to an internationalized domain name, the DNS labels and names MUST be compared for equality according to the rules specified in Section 3 of , i.e. once all label separators are replaced with U+002E (dot) they are compared in a case-insensitive manner.

Unless otherwise specified by an application protocol that re-uses the rules specified in this document, the client MAY match against an identity that contains one instance of the wildcard character '*' as the left-most label of the domain name. If it does so, the client MUST match the reference identity against the entire left-most label only (thus *.example.com matches foo.example.com but not bar.foo.example.com or example.com itself). The client MUST ignore a presented identity in which the wildcard character is contained within a label fragment (e.g., baz*.example.net is not allowed and MUST NOT be taken to match baz1.example.net and baz2.example.net).

If and only if the identity set does not include subjectAltName extensions of type dNSName, SRVName, uniformResourceIdentifier (or other application-specific subjectAltName extensions), the client MAY as a fallback check the value of the Common Name (CN) if presented as the leaf (left-most) Relative Distinguished Name (RND) in the subjectName component of the server's X.509 certificate. In existing certificates, the CN is often used for representing a domain name; for example, consider the following subjectName with a leaf RDN of Common Name:

Here the Common Name is "www.example.com" and the client could choose to compare the reference identity against that CN. When doing so, the client MUST follow the comparison rules described above for subjectAltName extensions of type dNSName and SRVName. A client MUST NOT check the Common Name if it is other than the leaf (left-most) Relative Distinguished Name (RDN) in the subjectName.

A client MUST NOT check Relative Distinguished Names (RDNs) other than the Common Name; in particular, this means that a series of Domain Component (DC) attributes MUST NOT be checked (because the order of Domain Components is not guaranteed, certain attacks are possible if DC attributes are checked).

The outcome of the checking procedure is one of the following: The client finds at least one presented identity that matches the reference identity; the entity MUST use this as the validated identity of the server. The client finds no subjectAltName or subjectName that matches the reference identity but a human user has permanently accepted the certificate during a previous connection attempt; the client MUST verify that the cached certificate was presented and MUST notify the user if the certificate has changed since the last time that a secure connection was successfully negotiated. The client finds no subjectAltName or subjectName that matches the reference identity and a human user has not permanently accepted the certificate during a previous connection attempt. The client MUST NOT use the presented identity (if any). Instead, if the client is a user-oriented application, then it MUST either (1) automatically terminate the connection with a bad certificate error or (2) show the certificate (including the entire certificate chain) to the user and give the user the choice of terminating the connecting or accepting the certificate temporarily (i.e., for this connection attempt only) or permanently (i.e., for all future connection attempts) and then continuing with the connection; if a user permanently accepts a certificate in this way, the client MUST cache the certificate (or some non-forgeable representation such as a hash value) and in future connection MUST attempt behave as in Case #2. (It is the resposibility of the human user to verify the hash value or fingerprint of the certificate with the server over a trusted communication layer.) If the client is an automated application, then it SHOULD terminate the connection with a bad certificate error and log the error to an appropriate audit log; an automated application MAY provide a configuration setting that disables this check, but MUST enable the check by default.

This entire document discusses security.

This document has no actions for the IANA.

This document is the revised protocol definition for internationalized domain names (IDNs). The rationale for changes, the relationship to the older specification, and important Information Sciences Institute (ISI) USC/ISI

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS TRACK] Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their 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. Note that the force of these words is modified by the requirement level of the document in which they are used. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS TRACK] Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS TRACK] Troll Tech

Waldemar Thranes gate 98B Oslo N-0175 NO +47 22 806390 +47 22 806380 arnt@troll.no

Internet Software Consortium

950 Charter Street Redwood City CA 94063 US +1 650 779 7001

Microsoft Corporation

One Microsoft Way Redmond WA 98052 US levone@microsoft.com

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS TRACK] This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. [STANDARDS TRACK] Department of Information and Computer Science

University of California, Irvine Irvine CA 92697-3425 +1(949)824-1715 fielding@ics.uci.edu

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 jg@w3.org

Compaq Computer Corporation

Western Research Laboratory 250 University Avenue Palo Alto CA 94305 mogul@wrl.dec.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 frystyk@w3.org

Xerox Corporation

MIT Laboratory for Computer Science, NE43-356 3333 Coyote Hill Road Palo Alto CA 94034 masinter@parc.xerox.com

Microsoft Corporation

1 Microsoft Way Redmond WA 98052 paulle@microsoft.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 timbl@w3.org

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 . This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US

Cisco Systems, Inc.

170 West Tasman Drive San Jose CA 95134-1706 USA +1 408 527 8213 +1 408 527 8254 deering@cisco.com

Nokia

232 Java Drive Sunnyvale CA 94089 USA +1 408 990 2004 +1 408 743 5677 hinden@iprg.nokia.com

Internet internet protocol version 6 IPv6 This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS TRACK] This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). [STANDARDS TRACK] This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.</t><t> This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.</t><t> This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.</t><t> This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. [STANDARDS TRACK] This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. [STANDARDS TRACK] This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP. [STANDARDS TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. [STANDARDS TRACK] This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. [STANDARDS TRACK] The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. [STANDARDS TRACK] The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP. [STANDARDS TRACK] This memo defines an extension to the Network News Transfer Protocol (NNTP) that allows an NNTP client and server to use Transport Layer Security (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. [STANDARDS TRACK] Carnegie-Mellon University

5000 Forbes Ave Pittsburgh PA 15213 US jgm+@cmu.edu

Dover Beach Consulting, Inc.

420 Whisman Court Mountain View CA 94043-2186 US mrose@dbc.mtview.ca.us

SPYRUS

381 Elden Street Suite 1120 Herndon VA 20170 US housley@spyrus.com

VeriSign, Inc.

One Alewife Center Cambridge MA 02140 US wford@verisign.com

NIST

Gaithersburg MD 20899 US wpolk@nist.gov

Citicorp

666 Fifth Ave 3rd Floor New York NY 10103 US david.solo@citicorp.com

This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the approach and model are provided as an introduction. The .509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms (e.g., IP addresses). Standard certificate extensions are described and one new Internet-specific extension is defined. A required set of certificate extensions is specified. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are provided in the appendices. 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. Please send comments on this document to the ietf-pkix@imc.org mail list. This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] This document describes how to construct and interpret certain information in a X.509 PKIX-compliant certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of cetificates. The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS TRACK] This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS TRACK] This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.</t><t> This document obsoletes RFC 2554. [STANDARDS TRACK] This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS TRACK] This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.</t><t> This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS TRACK] This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. [STANDARDS TRACK] This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS TRACK] World Wide Web Consortium

Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge MA 02139 USA +1-617-253-5702 +1-617-258-5999 timbl@w3.org http://www.w3.org/People/Berners-Lee/

Day Software

5251 California Ave., Suite 110 Irvine CA 92617 USA +1-949-679-2960 +1-949-679-2972 fielding@gbiv.com http://roy.gbiv.com/

Adobe Systems Incorporated

345 Park Ave San Jose CA 95110 USA +1-408-536-3024 LMM@acm.org http://larry.masinter.net/

Applications uniform resource identifier URI URL URN WWW resource A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. Innosoft International, Inc.

1050 Lakes Drive West Covina CA 91790 US chris.newman@innosoft.com

Jabber Software Foundation

stpeter@jabber.org

Applications XMPP Working Group RFC Request for Comments I-D Internet-Draft XMPP Extensible Messaging and Presence Protocol Jabber IM Instant Messaging Presence XML Extensible Markup Language This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920.

This section is non-normative. The recommendations in this document are an abstraction from recommendations in specifications for a wide range of application protocols. For the purpose of comparison and to delineate the history of thinking about server identity verification within the IETF, this informative section gathers together prior art by including the exact text from various RFCs (the only modifications are changes to the names of several references to maintain coherence with the main body of this document, and the elision of irrelevant text as marked by the characters "[...]").

In 1999, specified the following text regarding server identity verification in IMAP, POP3, and ACAP: ###### 2.4. Server Identity Check During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules: The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done. If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity. Matching is case-insensitive. A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com. If the certificate contains multiple names (e.g. more than one dNSName field), then a match with any one of the fields is considered acceptable. If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate the server's identity is suspect. ######

In 2000, specified the following text regarding server identity verification in HTTP: ###### 3.1. Server Identity In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack. If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Matching is performed using the matching rules specified by . If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI. If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself obtained without using HTTP/TLS, a man in the middle could have replaced the URI. In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it meets their expectations. ######

In 2000, specified the following text regarding server identity verification in LDAP: ###### 3.6. Server Identity Check The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules: The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate. The client MUST NOT use the server's canonical DNS name or any other derived form of name. If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity. Matching is case-insensitive. The "*" wildcard character is allowed. If present, it applies only to the left-most name component. E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not bar.com. If more than one identity of a given type is present in the certificate (e.g. more than one dNSName name), a match in any one of the set is considered acceptable. If the hostname does not match the dNSName-based identity in the certificate per the above check, user-oriented clients SHOULD either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection and indicate that the server's identity is suspect. Automated clients SHOULD close the connection, returning and/or logging an error indicating that the server's identity is suspect. Beyond the server identity checks described in this section, clients SHOULD be prepared to do further checking to ensure that the server is authorized to provide the service it is observed to provide. The client MAY need to make use of local policy information. ###### In 2006, specified the following text regarding server identity verification in LDAP: ###### 3.1.3. Server Identity Check In order to prevent man-in-the-middle attacks, the client MUST verify the server's identity (as presented in the server's Certificate message). In this section, the client's understanding of the server's identity (typically the identity used to establish the transport connection) is called the "reference identity". The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types are matched in different ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of various subjectAltName types. The client may map the reference identity to a different type prior to performing a comparison. Mappings may be performed for all available subjectAltName types to which the reference identity can be mapped; however, the reference identity should only be mapped to types for which the mapping is either inherently secure (e.g., extracting the DNS name from a URI to compare with a subjectAltName of type dNSName) or for which the mapping is performed in a secure manner (e.g., using , or using user- or admin-configured host-to-address/address-to-host lookup tables). The server's identity may also be verified by comparing the reference identity to the Common Name (CN) value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate. This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed. Although the use of the Common Name value is existing practice, it is deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead. Note that the TLS implementation may represent DNs in certificates according to X.500 or other conventions. For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right-to-left convention. If the server identity check fails, user-oriented clients SHOULD either notify the user (clients may give the user the opportunity to continue with the LDAP session in this case) or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD close the transport connection and then return or log an error indicating that the server's identity is suspect or both. Beyond the server identity check described in this section, clients should be prepared to do further checking to ensure that the server is authorized to provide the service it is requested to provide. The client may need to make use of local policy information in making this determination. 3.1.3.1. Comparison of DNS Names If the reference identity is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format as specified in Section 4 of RFC 3490 before comparison with subjectAltName values of type dNSName. Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of RFC 3490 as follows: in step 1, the domain name SHALL be considered a "stored string"; in step 3, set the flag called "UseSTD3ASCIIRules"; in step 4, process each label with the "ToASCII" operation; and in step 5, change all label separators to U+002E (full stop). After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality according to the rules specified in Section 3 of RFC3490. The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. 3.1.3.2. Comparison of IP Addresses When the reference identity is an IP address, the identity MUST be converted to the "network byte order" octet string representation . For IP Version 4, as specified in RFC 791, the octet string will contain exactly four octets. For IP Version 6, as specified in RFC 2460, the octet string will contain exactly sixteen octets. This octet string is then compared against subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical. 3.1.3.3. Comparison of Other subjectName Types Client implementations MAY support matching against subjectAltName values of other types as described in other documents. ######

In 2002, specified the following text regarding server identity verification in SMTP: ###### 4.1 Processing After the STARTTLS Command [...] The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, some general rules for the decisions are: A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to. [...] ###### In 2006, specified the following text regarding server identity verification in SMTP: ###### 14. Additional Requirements When Using SASL PLAIN over TLS [...] After a successful negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. If the match fails, the client MUST NOT attempt to authenticate using the SASL PLAIN mechanism. Matching is performed according to the following rules: The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done. If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity. Matching is case-insensitive. A "*" wildcard character MAY be used as the leftmost name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com. If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable. ######

In 2004, specified the following text regarding server identity verification in XMPP: ###### 14.2. Certificate Validation When an XMPP peer communicates with another peer securely, it MUST validate the peer's certificate. There are three possible cases: The peer contains an End Entity certificate which appears to be certified by a chain of certificates terminating in a trust anchor (as described in Section 6.1 of ). The peer certificate is certified by a Certificate Authority not known to the validating peer. The peer certificate is self-signed. In Case #1, the validating peer MUST do one of two things: Verify the peer certificate according to the rules of . The certificate SHOULD then be checked against the expected identity of the peer following the rules described in , except that a subjectAltName extension of type "xmpp" MUST be used as the identity if present. If one of these checks fails, user-oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients SHOULD terminate the connection (with a bad certificate error) and log the error to an appropriate audit log. Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting that enables it. The peer SHOULD show the certificate to a user for approval, including the entire certificate chain. The peer MUST cache the certificate (or some non-forgeable representation such as a hash). In future connections, the peer MUST verify that the same certificate was presented and MUST notify the user if it has changed. In Case #2 and Case #3, implementations SHOULD act as in (2) above. ###### At the time of this writing, refers to this document for rules regarding server identity verification in XMPP.

In 2006, specified the following text regarding server identity verification in NNTP: ###### 5. Security Considerations [...] During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules: The client MUST use the server hostname it used to open the connection (or the hostname specified in TLS "server_name" extension ) as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done. If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity. Matching is case-insensitive. A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com. If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable. If the match fails, the client SHOULD either ask for explicit user confirmation or terminate the connection with a QUIT command and indicate the server's identity is suspect. Additionally, clients MUST verify the binding between the identity of the servers to which they connect and the public keys presented by those servers. Clients SHOULD implement the algorithm in Section 6 of for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings). ######

In 2006, specified the following text regarding server identity verification in NETCONF: ###### 6. Security Considerations The identity of the server MUST be verified and authenticated by the client according to local policy before password-based authentication data or any configuration or state data is sent to or received from the server. The identity of the client MUST also be verified and authenticated by the server according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client. Neither side should establish a NETCONF over SSH connection with an unknown, unexpected, or incorrect identity on the opposite side. ###### In 2009, specified the following text regarding server identity verification in NETCONF: ###### 3.1. Server Identity During the TLS negotiation, the client MUST carefully examine the certificate presented by the server to determine if it meets the client's expectations. Particularly, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man- in-the-middle attacks. Matching is performed according to the rules below (following the example of ): The client MUST use the server hostname it used to open the connection (or the hostname specified in the TLS "server_name" extension ) as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done. If a subjectAltName extension of type dNSName is present in the certificate, it MUST be used as the source of the server's identity. Matching is case-insensitive. A "*" wildcard character MAY be used as the leftmost name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com. If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable. If the match fails, the client MUST either ask for explicit user confirmation or terminate the connection and indicate the server's identity is suspect. Additionally, clients MUST verify the binding between the identity of the servers to which they connect and the public keys presented by those servers. Clients SHOULD implement the algorithm in Section 6 of for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings). If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. ######

In 2009, specified the following text regarding server identity verification in Syslog: ###### 5.2. Subject Name Authorization Implementations MUST support certification path validation . In addition, they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows. Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), but only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. Locally configured names MAY contain the wildcard character to match a range of values. The types of wildcards supported MAY be more flexible than those allowed in subject names, making it possible to support various policies for different environments. For example, a policy could allow for a trust-root-based authorization where all credentials issued by a particular CA trust root are authorized. If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons, as specified in Section 7 of . Implementations MAY support matching a locally configured IP address against an iPAddress stored in the subjectAltName extension. In this case, the locally configured IP address is converted to an octet string as specified in , Section 4.2.1.6. A match occurs if this octet string is equal to the value of iPAddress in the subjectAltName extension. ######

At the time of this writing, specified text regarding server identity verification in the Session Initiation Protocol (SIP). However, that specification has not yet been approved by the IESG and text cannot be considered final. The relevant text follows. ###### 7.2. Comparing SIP Identities When an implementation (either client or server) compares two values as SIP domain identities: Implementations MUST compare only the DNS name component of each SIP domain identifier; an implementation MUST NOT use any scheme or parameters in the comparison. Implementations MUST compare the values as DNS names, which means that the comparison is case insensitive as specified by . Implementations MUST handle Internationalized Domain Names (IDNs) in accordance with Section 7.2 of . Implementations MUST match the values in their entirety: Implementations MUST NOT match suffixes. For example, "foo.example.com" does not match "example.com". Implemenations MUST NOT match any form of wildcard, such as a leading "." or "*." with any other DNS label or sequence of labels. For example, "*.example.com" matches only "*.example.com" but not "foo.example.com". Similarly, ".example.com" matches only ".example.com", and does not match "foo.example.com." allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". , while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. does not provide any guidelines on the presence of wildcards in certificates. Through the rule above, this document prohibits such wildcards in certificates for SIP domains. ######