Server Identity Verification in Application ProtocolsCiscoPeter.SaintAndre@WebEx.comIsode LimitedKurt.Zeilenga@Isode.COMPayPalJeff.Hodges@KingsMountain.comUWashington/Internet2rlmorgan@washington.edu
Applications
NoneInternet-DraftTechnologies such as Transport Layer Security (TLS) and IPsec enable a secure connection between two entities (a "client" and a "server") using X.509 certificates. This document specifies recommended procedures for checking the identity of the server in such an interaction.Technologies such as Transport Layer Security and enable a secure connection between two entities using the Internet X.509 Public Key Infrastructure (PKI) as described in . In such interactions, the entity that initiates the connection is called a "client" and the entity that receives the connection is called a "server".Note: The terms "client" and "server" as used here refer to security roles, not application roles; a server in the context of TLS or IPSec might be a "client" (i.e., a user agent) in the context of an application protocol as deployed on the Internet.If a client wishes to connect to a server securely, it needs to check the identity of the server so that it can determine if the server is what it claims to be, verify that there is no attacker in the middle, and enforce other relevant security considerations. Typically this checking is done by correlating the information presented in the server's certificate with information available about the server contained in the Domain Name System (DNS) or provided by a human user.Different application protocols that make use of the client-server pattern for security purposes have traditionally specified their own procedures for checking server identities. Examples include but are not limited to: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 Unfortunately, this divergence of approaches has caused some confusion among developers and protocol designers. Therefore this document specifies recommended identity checking procedures for application protocols produced within the Internet Standards Process, for the purpose of codifying secure authentication practices.Note: This document is currently limited in scope to the presentation of identities in X.509 certificates as issued in the context of the Public Key Infrastructure (PKI) and as applied to Transport Layer Security ; a future version of this document might address X.509 certificates as issued outside the context of the PKI, non-X.509 public keys such as OpenPGP keys, presentation of identities in ways other than in the certificate itself (e.g., certificate fingerprints for Secure Shell as described in or for Datagram Transport Layer Security DTLS and Secure Real-time Transport Protocol as described in ), and applications that use security technologies other than TLS.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".Most security-related terms are to be understood in the sense defined in ; such terms include, but are not limited to, "attack", "authentication", "authorization", "certificate", "credential", "fingerprint", "identity", "self-signed certificate", "trust", "trust anchor", "trust chain", "validate", and "verify".In addition, we define the following terms to assist in understanding the process of verifying server identity:The set of identities that are presented by the server to the client (in the form of the server's X.509 certificate) when the client attempts to establish a secure connection to 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, an email address, a SIP address, an XMPP address, or some other type (this specification does not yet provide a complete taxonomy of identity types). In the case of domain names, the reference identity MUST NOT contain the wildcard character '*' (ASCII 42) in the left-most (least significant) domain name component or component fragment.A single member of the identity set.The client's conception of the server's identity before it attempts to establish a secure connection to 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. It is either the address to which the client connected or the explicit value of the TLS "server_name" extension as specified in . The reference identity might be based on a DNS lookup, user configuration, or some other mechanism.When a client connects to a server, it MUST verify the server's identity in order to prevent certain passive and active attacks against the connection. By "verify identity" we mean that the client needs to establish that at least one of the presented identities matches the reference identity.At a high level, the client verifies the server identity in accordance with the following rules:Before connecting to the server, the client determines the identity type 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 (potentially in an application-specific preference order) and compares the value of each extension against 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).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 either inherently secure (e.g., extracting the DNS name from a URI to compare with a subjectAltName of type dNSName or SRVName) or for which the mapping is performed in a secure manner (e.g., using , or using a user-configured or admin-configured lookup table for host-to-address or address-to-host translations).If the identity set has more than one member, a match with any of the presented identities is acceptable.Note: Beyond the server identity check described in this section, clients might complete further checking to ensure that the server is authorized to provide the service it is requested to provide. The client might need to make use of local policy information in making this determination.If the reference identity is a domain name as defined by and for "traditional" domain names or by for internationalized domain names, then the client can 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.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 .Unless otherwise specified by an application protocol, the dNSName MAY contain one instance of the wildcard character '*'. The wildcard character applies only to the left-most domain name component and matches any single component (thus a dNSName of *.example.com matches foo.example.com but not bar.foo.example.com or example.com itself). The wildcard character is not allowed in component fragments (thus a dNSName of baz*.example.net is not allowed and shall not be taken to match baz1.example.net and baz2.example.net).In addition to checking the subjectAltName extensions of type dNSName and SRVNAME, the client MAY as a fallback check the value of the Common Name (CN) (see ) as presented in the subjectName component of the server's X.509 certificate. In existing certificates, the CN is often used for encapsulating a domain name; for example, consider the following subjectName:Here the Common Name is "www.example.com" and the client could choose to compare the reference identity against that CN.When comparing the referenced identity against the Common Name, the client MUST follow the comparison rules described above for subjectAltName extensions of type dNSName and SRVName, with the exception that no wildcard matching is allowed.In order to match domain names, 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).If the reference identity is an IP address as defined by or , then the client can match the reference identity against subjectAltName extensions of type iPaddress according to the following rules.The reference identity MUST be converted to the "network byte order" octet string representation; for IP Version 4 the octet string will contain exactly four octets, and for IP Version 6 the octet string will contain exactly sixteen octets. The client then compares this octet string, where a match occurs if the reference identity and presented identity octet strings are identical.If the reference identity is an email address as defined by , then the client SHOULD compare the reference identity against the value of the "rfc822Name" subjectAltName extension described in .The client MAY also compare the reference identity against the value of the "E" attribute of the subjectName as described in .If the reference identity is a SIP address as defined by , then the client SHOULD compare map the reference identity to a domain name or email address and proceed as described for those identity types, or proceed as described in .If the reference identity is an XMPP address ("JabberID") as defined by , then the client SHOULD compare the reference identity against the value of the following subjectAltName extensions, in this order: SRVName, dNSName, and (as defined in ) "id-on-xmppAddr".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 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 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) as the validated identity of the server and instead MUST proceed as described in the next section. 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 attempts 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 peer 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 provide a setting that enables the check.This entire document discusses security.This document has no actions for the IANA.Internationalizing Domain Names in Applications (IDNA)Internet ProtocolUniversity of Southern California (USC)/Information Sciences Institute4676 Admiralty WayMarina del ReyCA90291USInternet Protocol, Version 6 (IPv6) SpecificationCisco Systems, Inc.170 West Tasman DriveSan JoseCA95134-1706USA+1 408 527 8213+1 408 527 8254deering@cisco.comNokia232 Java DriveSunnyvaleCA94089USA+1 408 990 2004+1 408 743 5677hinden@iprg.nokia.com
Internet
internet protocol version 6IPv6
This document specifies version 6 of the Internet Protocol (IPv6),
also sometimes referred to as IP Next Generation or IPng.
Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@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.
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis 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]Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS TRACK]DNS Security Introduction and RequirementsThe 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] Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for secure RTP (SRTP) and secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present.Internet Message FormatQualcomm Incorporated5775 Morehouse DriveSan DiegoCA92121-1714US+1 858 651 4478presnick@qualcomm.comhttp://www.qualcomm.com/~presnick/This document specifies the Internet
Message Format (IMF), a syntax for text messages
that are sent between computer users, within
the framework of "electronic mail"
messages. This specification is a revision of
Request For Comments (RFC) 2822, which
itself superseded Request For Comments (RFC)
822, "Standard for the Format of ARPA
Internet Text Messages", updating it to
reflect current practice and incorporating
incremental changes that were specified in
other RFCs.Hypertext Transfer Protocol -- HTTP/1.1Department of Information and Computer ScienceUniversity of California, IrvineIrvineCA92697-3425+1(949)824-1715fielding@ics.uci.eduWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682jg@w3.orgCompaq Computer CorporationWestern Research Laboratory250 University AvenuePalo AltoCA94305mogul@wrl.dec.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682frystyk@w3.orgXerox CorporationMIT Laboratory for Computer Science, NE43-3563333 Coyote Hill RoadPalo AltoCA94034masinter@parc.xerox.comMicrosoft Corporation1 Microsoft WayRedmondWA98052paulle@microsoft.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682timbl@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 .
HTTP Over TLSThis 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.INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1Security Architecture for the Internet ProtocolThis 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]Lightweight Directory Access Protocol (LDAP): The ProtocolThis 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]Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security MechanismsThis 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]Lightweight Directory Access Protocol (LDAP): Schema for User ApplicationsThis 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]Lightweight Directory Access Protocol (v3): Extension for Transport Layer SecurityThis document defines the "Start Transport Layer Security (TLS) Operation" for LDAP. [STANDARDS TRACK]NETCONF Configuration ProtocolThe 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]Using the NETCONF Configuration Protocol over Secure SHell (SSH)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]NETCONF over Transport Layer Security (TLS)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]Network News Transfer Protocol (NNTP)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]Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)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]Post Office Protocol - Version 3Carnegie-Mellon University5000 Forbes AvePittsburghPA15213USjgm+@cmu.eduDover Beach Consulting, Inc.420 Whisman CourtMountain ViewCA94043-2186USmrose@dbc.mtview.ca.usDomain names - concepts and facilitiesInformation Sciences Institute (ISI)Domain names - implementation and specificationUSC/ISI4676 Admiralty WayMarina del ReyCA90291US+1 213 822 1511Internet X.509 Public Key Infrastructure Certificate and CRL ProfileSPYRUS381 Elden StreetSuite 1120HerndonVA20170UShousley@spyrus.comVeriSign, Inc.One Alewife CenterCambridgeMA02140USwford@verisign.comNISTGaithersburgMD20899USwpolk@nist.govCiticorp666 Fifth Ave3rd FloorNew YorkNY10103USdavid.solo@citicorp.comThis 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.Internet Security Glossary, Version 2This 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.SIP: Session Initiation ProtocolThis 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]Domain Certificates in the Session Initiation Protocol (SIP)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.Simple Mail Transfer ProtocolThis 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]SMTP Service Extension for AuthenticationThis 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]SMTP Service Extension for Secure SMTP over Transport Layer SecurityThis 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]Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service NameThis 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]The Secure Shell (SSH) Protocol ArchitectureThe Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS TRACK]The Syslog ProtocolThis 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]Transport Layer Security (TLS) Transport Mapping for SyslogThis 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]The Transport Layer Security (TLS) Protocol Version 1.2This 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]Using TLS with IMAP, POP3 and ACAPInnosoft International, Inc.1050 Lakes DriveWest CovinaCA91790USchris.newman@innosoft.comExtensible Messaging and Presence Protocol (XMPP): CoreJabber Software Foundationstpeter@jabber.org
Applications
XMPP Working GroupRFCRequest for CommentsI-DInternet-DraftXMPPExtensible Messaging and Presence ProtocolJabberIMInstant MessagingPresenceXMLExtensible Markup LanguageThis 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.Extensible Messaging and Presence Protocol (XMPP): CoreThis 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 CheckDuring 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 IdentityIn 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 CheckThe 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 CheckIn 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 DNSSEC, 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 NamesIf 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; andin 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 AddressesWhen 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 TypesClient 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 ValidationWhen 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.######As of this writing, specified updated text regarding server identity verification in XMPP. However, that specification has not yet been approved by the IESG, and the relevant text might be replaced by a reference to this document.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 ConsiderationsThe 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 IdentityDuring 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 AuthorizationImplementations 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.######As of this writing, specified text regarding server identity verification in SIP. However, that specification has not yet been approved by the IESG, and the relevant text might be replaced by a reference to this document.