From 946483a2f1b26d6132c142639c3991aba040140e Mon Sep 17 00:00:00 2001 From: Wesley Rosenblum <55108558+WesleyRosenblum@users.noreply.github.com> Date: Mon, 10 Jun 2024 11:31:15 -0700 Subject: [PATCH] compliance: update generate_report.sh to point to compliance directory (#4588) --- .github/workflows/ci_compliance.yml | 14 - compliance/generate_report.sh | 1 + .../doc/id/draft-agl-tls-nextprotoneg-03.txt | 784 ++++ .../specs/www.rfc-editor.org/rfc/rfc5077.txt | 1123 ++++++ .../specs/www.rfc-editor.org/rfc/rfc6066.txt | 1403 ++++++++ .../specs/www.rfc-editor.org/rfc/rfc6125.txt | 3195 +++++++++++++++++ .../specs/www.rfc-editor.org/rfc/rfc6960.txt | 2299 ++++++++++++ .../specs/www.rfc-editor.org/rfc/rfc7301.txt | 507 +++ .../specs/www.rfc-editor.org/rfc/rfc8701.txt | 582 +++ .../specs/www.rfc-editor.org/rfc/rfc9001.txt | 2756 ++++++++++++++ .../specs/www.rfc-editor.org/rfc/rfc9151.txt | 711 ++++ 11 files changed, 13361 insertions(+), 14 deletions(-) create mode 100644 compliance/specs/datatracker.ietf.org/doc/id/draft-agl-tls-nextprotoneg-03.txt create mode 100644 compliance/specs/www.rfc-editor.org/rfc/rfc5077.txt create mode 100644 compliance/specs/www.rfc-editor.org/rfc/rfc6066.txt create mode 100644 compliance/specs/www.rfc-editor.org/rfc/rfc6125.txt create mode 100644 compliance/specs/www.rfc-editor.org/rfc/rfc6960.txt create mode 100644 compliance/specs/www.rfc-editor.org/rfc/rfc7301.txt create mode 100644 compliance/specs/www.rfc-editor.org/rfc/rfc8701.txt create mode 100644 compliance/specs/www.rfc-editor.org/rfc/rfc9001.txt create mode 100644 compliance/specs/www.rfc-editor.org/rfc/rfc9151.txt diff --git a/.github/workflows/ci_compliance.yml b/.github/workflows/ci_compliance.yml index f427ae26942..a42720ffb6f 100644 --- a/.github/workflows/ci_compliance.yml +++ b/.github/workflows/ci_compliance.yml @@ -34,14 +34,6 @@ jobs: aws-s3-region: us-west-2 cdn: https://d3fqnyekunr9xg.cloudfront.net - # The `duvet report` command generates some artifacts (specs folder) that - # interfere with detecting uncommitted files. This step cleans up those - # artifacts. Since the cleanup runs prior to the “Extract RFC spec data” - # phase, this is a safe operation. - - name: Cleanup intermediate artifacts - run: rm -r specs - shell: bash - - name: Extract RFC spec data working-directory: ./compliance run: ./initialize_duvet.sh @@ -51,12 +43,6 @@ jobs: run: | # If this fails you need to run `cd compliance && ./compliance/initialize_duvet.sh` # - # FIXME: https://github.com/aws/s2n-tls/issues/4219 - # We generate and commit the spec files to avoid re-downloading them each time in - # the CI (avoid flaky network calls). However, this currently doesn't work in - # s2n-tls since duvet assumes that the specs folder live in the project's base - # folder. - # # Use 'git status --porcelain' instead of 'git diff --exit-code' since git diff # only detects diffs but fails to detect new files. Ignore the s2n-quic dir # `(:!s2n-quic)` since we explicitly clone the repo as part of this job. diff --git a/compliance/generate_report.sh b/compliance/generate_report.sh index cac3c51299e..46d4e9abb30 100755 --- a/compliance/generate_report.sh +++ b/compliance/generate_report.sh @@ -10,6 +10,7 @@ pushd $TOPLEVEL > /dev/null duvet \ report \ + --spec-path 'compliance' \ --spec-pattern 'compliance/specs/**/*.toml' \ --source-pattern '(*=,*#)api/**/*.[ch]' \ --source-pattern '(*=,*#)bin/**/*.[ch]' \ diff --git a/compliance/specs/datatracker.ietf.org/doc/id/draft-agl-tls-nextprotoneg-03.txt b/compliance/specs/datatracker.ietf.org/doc/id/draft-agl-tls-nextprotoneg-03.txt new file mode 100644 index 00000000000..515f39d07f6 --- /dev/null +++ b/compliance/specs/datatracker.ietf.org/doc/id/draft-agl-tls-nextprotoneg-03.txt @@ -0,0 +1,784 @@ + + + +Network Working Group A. Langley +Internet-Draft Google Inc +Expires: October 26, 2012 April 24, 2012 + + + Transport Layer Security (TLS) Next Protocol Negotiation Extension + draft-agl-tls-nextprotoneg-03 + +Abstract + + This document describes a Transport Layer Security (TLS) extension + for application layer protocol negotiation. This allows the + application layer to negotiate which protocol should be performed + over the secure connection. + +Status of this Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on October 26, 2012. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Langley Expires October 26, 2012 [Page 1] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 + 3. Next Protocol Negotiation Extension . . . . . . . . . . . . . 5 + 4. Protocol selection . . . . . . . . . . . . . . . . . . . . . . 8 + 5. Design discussion . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 2] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +1. Introduction + + The Next Protocol Negotiation extension (NPN) is currently used to + negotiate the use of SPDY [spdy] as an application level protocol on + port 443, and to perform SPDY version negotiation. However, it is + not SPDY specific in any way. + + Designers of new application level protocols are faced with a + problem: there are no good options for establishing a clean transport + for a new protocol and negotiating its use. Negotiations on port 80 + will run afoul of intercepting proxies. Ports other than 80 and 443 + are likely to be firewalled without any fast method of detection, and + are also unlikely to traverse HTTP proxies with CONNECT. Negotiating + on port 443 is possible, but may run afoul of MITM proxies and also + uses a round trip for negotiation on top of the round trips for + establishing the TLS connection. Negotiation at that level is also + dependent on the application level protocol, i.e. the real world + tolerance of servers to HTTP Upgrade requests. + + Next Protocol Negotiation allows application level protocols to be + negotiated without additional round trips and with clean fallback in + the case of an unsupportive MITM proxy. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 3] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +2. Requirements Notation + + 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 [RFC2119]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 4] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +3. Next Protocol Negotiation Extension + + A new extension type ("next_protocol_negotiation(13172)") is defined + and MAY be included by the client in its "ClientHello" message. If, + and only if, the server sees this extension in the "ClientHello", it + MAY choose to echo the extension in its "ServerHello". + + enum { + next_protocol_negotiation(13172), (65535) + } ExtensionType; + + The "extension_data" field of a "next_protocol_negotiation" extension + in a "ClientHello" MUST be empty. + + The "extension_data" field of a "next_protocol_negotiation" extension + in a "ServerHello" contains an optional list of protocols advertised + by the server. Protocols are named by opaque, non-empty byte strings + and the list of protocols is serialized as a concatenation of 8-bit, + length prefixed byte strings. Implementations MUST ensure that the + empty string is not included and that no byte strings are truncated. + + A new handshake message type ("next_protocol(67)") is defined. If, + and only if, the server included a "next_protocol_negotiation" + extension in its "ServerHello" message, the client MUST send a + "NextProtocol" message after its "ChangeCipherSpec" and before its + "Finished" message. + + enum { + next_protocol(67), (65535) + } HandshakeType; + + Therefore a full handshake with "NextProtocol" has the following flow + (contrast with section 7.3 of RFC 5246 [RFC5246]): + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 5] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + + Client Server + + ClientHello (NPN extension) --------> + ServerHello + (NPN extension & + list of protocols) + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + NextProtocol + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + An abbreviated handshake with "NextProtocol" has the following flow: + + Client Server + + ClientHello (NPN extension) --------> + ServerHello + (NPN extension & + list of protocols) + [ChangeCipherSpec] + <-------- Finished + [ChangeCipherSpec] + NextProtocol + Finished --------> + Application Data <-------> Application Data + + The "NextProtocol" message has the following format: + + struct { + opaque selected_protocol<0..255>; + opaque padding<0..255>; + } NextProtocol; + + The contents of "selected_protocol" are an opaque protocol string, + but need not have been advertised by the server. The length of + "padding" SHOULD be 32 - ((len(selected_protocol) + 2) % 32). Note + that len(selected_protocol) does not include its length prefix. + + Unlike many other TLS extensions, this extension does not establish + + + +Langley Expires October 26, 2012 [Page 6] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + + properties of the session, only of the connection. When session + resumption or session tickets [RFC5077] are used, the previous + contents of this extension are irrelevant and only the values in the + new handshake messages are considered. + + For the same reasons, after a handshake has been performed for a + given connection, renegotiations on the same connection MUST NOT + include the "next_protocol_negotiation" extension. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 7] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +4. Protocol selection + + It's expected that a client will have a list of protocols that it + supports, in preference order, and will only select a protocol if the + server supports it. In that case, the client SHOULD select the first + protocol advertised by the server that it also supports. In the + event that the client doesn't support any of server's protocols, or + the server doesn't advertise any, it SHOULD select the first protocol + that it supports. + + There may be cases where the client knows, via other means, that a + server supports an unadvertised protocol. In these cases the client + can simply select that protocol. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 8] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +5. Design discussion + + NPN is an outlier from TLS in several respects: firstly that it + introduces a handshake message between the "ChangeCipherSpec" and + "Finished" message, that the handshake message is padded, and that + the negotiation isn't done purely with the hello messages. All these + aspects of the protocol are intended to prevent middle-ware + discrimination based on the negotiated protocol and follow the + general principle that anything that can be encrypted, should be + encrypted. The server's list of advertised protocols is in the clear + as a compromise between performance and robustness. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 9] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +6. Security considerations + + The server's list of supported protocols is still advertised in the + clear with this extension. This may be undesirable for certain + protocols (such as Tor [tor]) where one could imagine that hostile + networks would terminate any TLS connection with a server that + advertised such a capability. In this case, clients may wish to + opportunistically select a protocol that wasn't advertised by the + server. However, the workings of such a scheme are outside the scope + of this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 10] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +7. IANA Considerations + + This document requires IANA to update its registry of TLS extensions + to assign entry 13172 as "next_protocol_negotiation". + + This document also requires IANA to update its registry of TLS + handshake types to assign entry 67 as "next_protocol". + + This document also requires IANA to create a registry of TLS Next + Protocol Negotiation protocol strings on a first come, first served + basis, initially containing the following entries: + + o "http/1.1": HTTP/1.1 [RFC2616] + + o "spdy/1": (obsolete) SPDY version 1 + + o "spdy/2": SPDY version 2 + + o "spdy/3": SPDY version 3 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 11] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +8. Acknowledgments + + This document benefited specifically from discussions with Wan-Teh + Chang and Nagendra Modadugu. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 12] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + +9.2. Informative References + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, + "Transport Layer Security (TLS) Session Resumption without + Server-Side State", RFC 5077, January 2008. + + [tor] Dingledine, R., Matthewson, N., and P. Syverson, "Tor: The + Second-Generation Onion Router", August 2004. + + [spdy] Belshe, M. and R. Peon, "SPDY Protocol (Internet Draft)", + Feb 2012. + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 13] + +Internet-Draft TLS Next Protocol Negotiation April 2012 + + +Author's Address + + Adam Langley + Google Inc + + Email: agl@google.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Langley Expires October 26, 2012 [Page 14] + diff --git a/compliance/specs/www.rfc-editor.org/rfc/rfc5077.txt b/compliance/specs/www.rfc-editor.org/rfc/rfc5077.txt new file mode 100644 index 00000000000..13e7abe66e5 --- /dev/null +++ b/compliance/specs/www.rfc-editor.org/rfc/rfc5077.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group J. Salowey +Request for Comments: 5077 H. Zhou +Obsoletes: 4507 Cisco Systems +Category: Standards Track P. Eronen + Nokia + H. Tschofenig + Nokia Siemens Networks + January 2008 + + + Transport Layer Security (TLS) Session Resumption without + Server-Side State + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes a mechanism that enables the Transport Layer + Security (TLS) server to resume sessions and avoid keeping per-client + session state. The TLS server encapsulates the session state into a + ticket and forwards it to the client. The client can subsequently + resume a session using the obtained ticket. This document obsoletes + RFC 4507. + + + + + + + + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 1] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. SessionTicket TLS Extension . . . . . . . . . . . . . . . 7 + 3.3. NewSessionTicket Handshake Message . . . . . . . . . . . . 8 + 3.4. Interaction with TLS Session ID . . . . . . . . . . . . . 9 + 4. Recommended Ticket Construction . . . . . . . . . . . . . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 5.1. Invalidating Sessions . . . . . . . . . . . . . . . . . . 12 + 5.2. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12 + 5.3. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12 + 5.4. Denial of Service Attacks . . . . . . . . . . . . . . . . 12 + 5.5. Ticket Protection Key Management . . . . . . . . . . . . . 13 + 5.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13 + 5.7. Alternate Ticket Formats and Distribution Schemes . . . . 13 + 5.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 14 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 + Appendix A. Discussion of Changes to RFC 4507 . . . . . . . . . . 17 + + + + + + + + + + + + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 2] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +1. Introduction + + This document defines a way to resume a Transport Layer Security + (TLS) session without requiring session-specific state at the TLS + server. This mechanism may be used with any TLS ciphersuite. This + document applies to both TLS 1.0 defined in [RFC2246], and TLS 1.1 + defined in [RFC4346]. The mechanism makes use of TLS extensions + defined in [RFC4366] and defines a new TLS message type. + + This mechanism is useful in the following situations: + + 1. servers that handle a large number of transactions from different + users + + 2. servers that desire to cache sessions for a long time + + 3. ability to load balance requests across servers + + 4. embedded servers with little memory + + This document obsoletes RFC 4507 [RFC4507] to correct an error in the + encoding that caused the specification to differ from deployed + implementations. At the time of this writing, there are no known + implementations that follow the encoding specified in RFC 4507. This + update to RFC 4507 aligns the document with currently deployed + implementations. More details of the change are given in Appendix A. + +2. Terminology + + Within this document, the term 'ticket' refers to a cryptographically + protected data structure that is created and consumed by the server + to rebuild session-specific state. + + 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 [RFC2119]. + +3. Protocol + + This specification describes a mechanism to distribute encrypted + session-state information to the client in the form of a ticket and a + mechanism to present the ticket back to the server. The ticket is + created by a TLS server and sent to a TLS client. The TLS client + presents the ticket to the TLS server to resume a session. + Implementations of this specification are expected to support both + mechanisms. Other specifications can take advantage of the session + tickets, perhaps specifying alternative means for distribution or + selection. For example, a separate specification may describe an + + + +Salowey, et al. Standards Track [Page 3] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + alternate way to distribute a ticket and use the TLS extension in + this document to resume the session. This behavior is beyond the + scope of the document and would need to be described in a separate + specification. + +3.1. Overview + + The client indicates that it supports this mechanism by including a + SessionTicket TLS extension in the ClientHello message. The + extension will be empty if the client does not already possess a + ticket for the server. The server sends an empty SessionTicket + extension to indicate that it will send a new session ticket using + the NewSessionTicket handshake message. The extension is described + in Section 3.2. + + If the server wants to use this mechanism, it stores its session + state (such as ciphersuite and master secret) to a ticket that is + encrypted and integrity-protected by a key known only to the server. + The ticket is distributed to the client using the NewSessionTicket + TLS handshake message described in Section 3.3. This message is sent + during the TLS handshake before the ChangeCipherSpec message, after + the server has successfully verified the client's Finished message. + + Client Server + + ClientHello + (empty SessionTicket extension)--------> + ServerHello + (empty SessionTicket extension) + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + NewSessionTicket + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + Figure 1: Message Flow for Full Handshake Issuing New Session Ticket + + + + + + + +Salowey, et al. Standards Track [Page 4] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + The client caches this ticket along with the master secret and other + parameters associated with the current session. When the client + wishes to resume the session, it includes the ticket in the + SessionTicket extension within the ClientHello message. Appendix A + provides a detailed description of the encoding of the extension and + changes from RFC 4507. The server then decrypts the received ticket, + verifies the ticket's validity, retrieves the session state from the + contents of the ticket, and uses this state to resume the session. + The interaction with the TLS Session ID is described in Section 3.4. + If the server successfully verifies the client's ticket, then it may + renew the ticket by including a NewSessionTicket handshake message + after the ServerHello. + + Client Server + ClientHello + (SessionTicket extension) --------> + ServerHello + (empty SessionTicket extension) + NewSessionTicket + [ChangeCipherSpec] + <-------- Finished + [ChangeCipherSpec] + Finished --------> + Application Data <-------> Application Data + + Figure 2: Message Flow for Abbreviated Handshake Using New Session + Ticket + + A recommended ticket format is given in Section 4. + + If the server cannot or does not want to honor the ticket, then it + can initiate a full handshake with the client. + + In the case that the server does not wish to issue a new ticket at + this time, it just completes the handshake without including a + SessionTicket extension or NewSessionTicket handshake message. This + is shown below (this flow is identical to Figure 1 in RFC 4346, + except for the SessionTicket extension in the first message): + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 5] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + Client Server + + ClientHello + (SessionTicket extension) --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + Figure 3: Message Flow for Server Completing Full Handshake Without + Issuing New Session Ticket + + It is also permissible to have an exchange similar to Figure 3 using + the abbreviated handshake defined in Figure 2 of RFC 4346, where the + client uses the SessionTicket extension to resume the session, but + the server does not wish to issue a new ticket, and therefore does + not send a SessionTicket extension. + + If the server rejects the ticket, it may still wish to issue a new + ticket after performing the full handshake as shown below (this flow + is identical to Figure 1, except the SessionTicket extension in the + ClientHello is not empty): + + + + + + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 6] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + Client Server + + ClientHello + (SessionTicket extension) --------> + ServerHello + (empty SessionTicket extension) + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + NewSessionTicket + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + Figure 4: Message Flow for Server Rejecting Ticket, Performing Full + Handshake, and Issuing New Session Ticket + +3.2. SessionTicket TLS Extension + + The SessionTicket TLS extension is based on [RFC4366]. The format of + the ticket is an opaque structure used to carry session-specific + state information. This extension may be sent in the ClientHello and + ServerHello. + + If the client possesses a ticket that it wants to use to resume a + session, then it includes the ticket in the SessionTicket extension + in the ClientHello. If the client does not have a ticket and is + prepared to receive one in the NewSessionTicket handshake message, + then it MUST include a zero-length ticket in the SessionTicket + extension. If the client is not prepared to receive a ticket in the + NewSessionTicket handshake message, then it MUST NOT include a + SessionTicket extension unless it is sending a non-empty ticket it + received through some other means from the server. + + The server uses a zero-length SessionTicket extension to indicate to + the client that it will send a new session ticket using the + NewSessionTicket handshake message described in Section 3.3. The + server MUST send this extension in the ServerHello if it wishes to + issue a new ticket to the client using the NewSessionTicket handshake + message. The server MUST NOT send this extension if it does not + receive one in the ClientHello. + + + + +Salowey, et al. Standards Track [Page 7] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + If the server fails to verify the ticket, then it falls back to + performing a full handshake. If the ticket is accepted by the server + but the handshake fails, the client SHOULD delete the ticket. + + The SessionTicket extension has been assigned the number 35. The + extension_data field of SessionTicket extension contains the ticket. + +3.3. NewSessionTicket Handshake Message + + This message is sent by the server during the TLS handshake before + the ChangeCipherSpec message. This message MUST be sent if the + server included a SessionTicket extension in the ServerHello. This + message MUST NOT be sent if the server did not include a + SessionTicket extension in the ServerHello. This message is included + in the hash used to create and verify the Finished message. In the + case of a full handshake, the server MUST verify the client's + Finished message before sending the ticket. The client MUST NOT + treat the ticket as valid until it has verified the server's Finished + message. If the server determines that it does not want to include a + ticket after it has included the SessionTicket extension in the + ServerHello, then it sends a zero-length ticket in the + NewSessionTicket handshake message. + + If the server successfully verifies the client's ticket, then it MAY + renew the ticket by including a NewSessionTicket handshake message + after the ServerHello in the abbreviated handshake. The client + should start using the new ticket as soon as possible after it + verifies the server's Finished message for new connections. Note + that since the updated ticket is issued before the handshake + completes, it is possible that the client may not put the new ticket + into use before it initiates new connections. The server MUST NOT + assume that the client actually received the updated ticket until it + successfully verifies the client's Finished message. + + The NewSessionTicket handshake message has been assigned the number 4 + and its definition is given at the end of this section. The + ticket_lifetime_hint field contains a hint from the server about how + long the ticket should be stored. The value indicates the lifetime + in seconds as a 32-bit unsigned integer in network byte order + relative to when the ticket is received. A value of zero is reserved + to indicate that the lifetime of the ticket is unspecified. A client + SHOULD delete the ticket and associated state when the time expires. + It MAY delete the ticket earlier based on local policy. A server MAY + treat a ticket as valid for a shorter or longer period of time than + what is stated in the ticket_lifetime_hint. + + + + + + +Salowey, et al. Standards Track [Page 8] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + struct { + HandshakeType msg_type; + uint24 length; + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + case session_ticket: NewSessionTicket; /* NEW */ + } body; + } Handshake; + + + struct { + uint32 ticket_lifetime_hint; + opaque ticket<0..2^16-1>; + } NewSessionTicket; + +3.4. Interaction with TLS Session ID + + If a server is planning on issuing a session ticket to a client that + does not present one, it SHOULD include an empty Session ID in the + ServerHello. If the server rejects the ticket and falls back to the + full handshake then it may include a non-empty Session ID to indicate + its support for stateful session resumption. If the client receives + a session ticket from the server, then it discards any Session ID + that was sent in the ServerHello. + + When presenting a ticket, the client MAY generate and include a + Session ID in the TLS ClientHello. If the server accepts the ticket + and the Session ID is not empty, then it MUST respond with the same + Session ID present in the ClientHello. This allows the client to + easily differentiate when the server is resuming a session from when + it is falling back to a full handshake. Since the client generates a + Session ID, the server MUST NOT rely upon the Session ID having a + particular value when validating the ticket. If a ticket is + presented by the client, the server MUST NOT attempt to use the + Session ID in the ClientHello for stateful session resumption. + Alternatively, the client MAY include an empty Session ID in the + ClientHello. In this case, the client ignores the Session ID sent in + the ServerHello and determines if the server is resuming a session by + the subsequent handshake messages. + + + +Salowey, et al. Standards Track [Page 9] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +4. Recommended Ticket Construction + + This section describes a recommended format and protection for the + ticket. Note that the ticket is opaque to the client, so the + structure is not subject to interoperability concerns, and + implementations may diverge from this format. If implementations do + diverge from this format, they must take security concerns seriously. + Clients MUST NOT examine the ticket under the assumption that it + complies with this document. + + The server uses two different keys: one 128-bit key for Advanced + Encryption Standard (AES) [AES] in Cipher Block Chaining (CBC) mode + [CBC] encryption and one 256-bit key for HMAC-SHA-256 [RFC4634]. + + The ticket is structured as follows: + + struct { + opaque key_name[16]; + opaque iv[16]; + opaque encrypted_state<0..2^16-1>; + opaque mac[32]; + } ticket; + + Here, key_name serves to identify a particular set of keys used to + protect the ticket. It enables the server to easily recognize + tickets it has issued. The key_name should be randomly generated to + avoid collisions between servers. One possibility is to generate new + random keys and key_name every time the server is started. + + The actual state information in encrypted_state is encrypted using + 128-bit AES in CBC mode with the given IV. The Message + Authentication Code (MAC) is calculated using HMAC-SHA-256 over + key_name (16 octets) and IV (16 octets), followed by the length of + the encrypted_state field (2 octets) and its contents (variable + length). + + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 10] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + struct { + ProtocolVersion protocol_version; + CipherSuite cipher_suite; + CompressionMethod compression_method; + opaque master_secret[48]; + ClientIdentity client_identity; + uint32 timestamp; + } StatePlaintext; + + enum { + anonymous(0), + certificate_based(1), + psk(2) + } ClientAuthenticationType; + + struct { + ClientAuthenticationType client_authentication_type; + select (ClientAuthenticationType) { + case anonymous: struct {}; + case certificate_based: + ASN.1Cert certificate_list<0..2^24-1>; + case psk: + opaque psk_identity<0..2^16-1>; /* from [RFC4279] */ + }; + } ClientIdentity; + + The structure StatePlaintext stores the TLS session state including + the master_secret. The timestamp within this structure allows the + TLS server to expire tickets. To cover the authentication and key + exchange protocols provided by TLS, the ClientIdentity structure + contains the authentication type of the client used in the initial + exchange (see ClientAuthenticationType). To offer the TLS server + with the same capabilities for authentication and authorization, a + certificate list is included in case of public-key-based + authentication. The TLS server is therefore able to inspect a number + of different attributes within these certificates. A specific + implementation might choose to store a subset of this information or + additional information. Other authentication mechanisms, such as + Kerberos [RFC2712], would require different client identity data. + Other TLS extensions may require the inclusion of additional data in + the StatePlaintext structure. + + + + + + + + + + +Salowey, et al. Standards Track [Page 11] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +5. Security Considerations + + This section addresses security issues related to the usage of a + ticket. Tickets must be authenticated and encrypted to prevent + modification or eavesdropping by an attacker. Several attacks + described below will be possible if this is not carefully done. + + Implementations should take care to ensure that the processing of + tickets does not increase the chance of denial of service as + described below. + +5.1. Invalidating Sessions + + The TLS specification requires that TLS sessions be invalidated when + errors occur. [CSSC] discusses the security implications of this in + detail. In the analysis within this paper, failure to invalidate + sessions does not pose a security risk. This is because the TLS + handshake uses a non-reversible function to derive keys for a session + so information about one session does not provide an advantage to + attack the master secret or a different session. If a session + invalidation scheme is used, the implementation should verify the + integrity of the ticket before using the contents to invalidate a + session to ensure that an attacker cannot invalidate a chosen + session. + +5.2. Stolen Tickets + + An eavesdropper or man-in-the-middle may obtain the ticket and + attempt to use it to establish a session with the server; however, + since the ticket is encrypted and the attacker does not know the + secret key, a stolen ticket does not help an attacker resume a + session. A TLS server MUST use strong encryption and integrity + protection for the ticket to prevent an attacker from using a brute + force mechanism to obtain the ticket's contents. + +5.3. Forged Tickets + + A malicious user could forge or alter a ticket in order to resume a + session, to extend its lifetime, to impersonate another user, or to + gain additional privileges. This attack is not possible if the + ticket is protected using a strong integrity protection algorithm + such as a keyed HMAC-SHA-256. + +5.4. Denial of Service Attacks + + The key_name field defined in the recommended ticket format helps the + server efficiently reject tickets that it did not issue. However, an + adversary could store or generate a large number of tickets to send + + + +Salowey, et al. Standards Track [Page 12] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + to the TLS server for verification. To minimize the possibility of a + denial of service, the verification of the ticket should be + lightweight (e.g., using efficient symmetric key cryptographic + algorithms). + +5.5. Ticket Protection Key Management + + A full description of the management of the keys used to protect the + ticket is beyond the scope of this document. A list of RECOMMENDED + practices is given below. + + o The keys should be generated securely following the randomness + recommendations in [RFC4086]. + + o The keys and cryptographic protection algorithms should be at + least 128 bits in strength. Some ciphersuites and applications + may require cryptographic protection greater than 128 bits in + strength. + + o The keys should not be used for any purpose other than generating + and verifying tickets. + + o The keys should be changed regularly. + + o The keys should be changed if the ticket format or cryptographic + protection algorithms change. + +5.6. Ticket Lifetime + + The TLS server controls the lifetime of the ticket. Servers + determine the acceptable lifetime based on the operational and + security requirements of the environments in which they are deployed. + The ticket lifetime may be longer than the 24-hour lifetime + recommended in [RFC4346]. TLS clients may be given a hint of the + lifetime of the ticket. Since the lifetime of a ticket may be + unspecified, a client has its own local policy that determines when + it discards tickets. + +5.7. Alternate Ticket Formats and Distribution Schemes + + If the ticket format or distribution scheme defined in this document + is not used, then great care must be taken in analyzing the security + of the solution. In particular, if confidential information, such as + a secret key, is transferred to the client, it MUST be done using + secure communication so as to prevent attackers from obtaining or + modifying the key. Also, the ticket MUST have its integrity and + confidentiality protected with strong cryptographic techniques to + prevent a breach in the security of the system. + + + +Salowey, et al. Standards Track [Page 13] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +5.8. Identity Privacy, Anonymity, and Unlinkability + + This document mandates that the content of the ticket is + confidentiality protected in order to avoid leakage of its content, + such as user-relevant information. As such, it prevents disclosure + of potentially sensitive information carried within the ticket. + + The initial handshake exchange, which was used to obtain the ticket, + might not provide identity confidentiality of the client based on the + properties of TLS. Another relevant security threat is the ability + for an on-path adversary to observe multiple TLS handshakes where the + same ticket is used, therefore concluding they belong to the same + communication endpoints. Application designers that use the ticket + mechanism described in this document should consider that + unlinkability [ANON] is not necessarily provided. + + While a full discussion of these topics is beyond the scope of this + document, it should be noted that it is possible to issue a ticket + using a TLS renegotiation handshake that occurs after a secure tunnel + has been established by a previous handshake. This may help address + some privacy and unlinkability issues in some environments. + +6. Acknowledgements + + The authors would like to thank the following people for their help + with preparing and reviewing this document: Eric Rescorla, Mohamad + Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew, + Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and members of + the TLS working group. + + [CSSC] describes a solution that is very similar to the one described + in this document and gives a detailed analysis of the security + considerations involved. [RFC2712] describes a mechanism for using + Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use + of tickets to avoid server state. [RFC4851] makes use of a similar + mechanism to avoid maintaining server state for the cryptographic + tunnel. [SC97] also investigates the concept of stateless sessions. + + The authors would also like to thank Jan Nordqvist, who found the + encoding error in RFC 4507, corrected by this document. In addition + Nagendra Modadugu, Wan-Teh Chang, and Michael D'Errico provided + useful feedback during the review of this document. + + + + + + + + + +Salowey, et al. Standards Track [Page 14] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +7. IANA Considerations + + IANA has assigned a TLS extension number of 35 to the SessionTicket + TLS extension from the TLS registry of ExtensionType values defined + in [RFC4366]. + + IANA has assigned a TLS HandshakeType number 4 to the + NewSessionTicket handshake type from the TLS registry of + HandshakeType values defined in [RFC4346]. + + This document does not require any actions or assignments from IANA. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, April 2006. + + [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 4366, April 2006. + + [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, + "Transport Layer Security (TLS) Session Resumption without + Server-Side State", RFC 4507, May 2006. + +8.2. Informative References + + [AES] National Institute of Standards and Technology, "Advanced + Encryption Standard (AES)", Federal Information Processing + Standards (FIPS) Publication 197, November 2001. + + [ANON] Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability, + Unobservability, Pseudonymity, and Identity Management - A + Consolidated Proposal for Terminology", http:// + dud.inf.tu-dresden.de/literatur/ + Anon_Terminology_v0.26-1.pdf Version 0.26, December 2005. + + + + + + + +Salowey, et al. Standards Track [Page 15] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + [CBC] National Institute of Standards and Technology, + "Recommendation for Block Cipher Modes of Operation - + Methods and Techniques", NIST Special Publication 800-38A, + December 2001. + + [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side + caching for TLS", Transactions on Information and System + Security (TISSEC) , Volume 7, Issue 4, November 2004. + + [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher + Suites to Transport Layer Security (TLS)", RFC 2712, + October 1999. + + [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + + [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites + for Transport Layer Security (TLS)", RFC 4279, + December 2005. + + [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and HMAC-SHA)", RFC 4634, July 2006. + + [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The + Flexible Authentication via Secure Tunneling Extensible + Authentication Protocol Method (EAP-FAST)", RFC 4851, + May 2007. + + [SC97] Aura, T. and P. Nikander, "Stateless Connections", + Proceedings of the First International Conference on + Information and Communication Security (ICICS '97) , 1997. + + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 16] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +Appendix A. Discussion of Changes to RFC 4507 + + RFC 4507 [RFC4507] defines a mechanism to resume a TLS session + without maintaining server side state by specifying an encrypted + ticket that is maintained on the client. The client presents this + ticket to the server in a SessionTicket hello extension. The + encoding in RFC 4507 used the XDR style encoding specified in TLS + [RFC4346]. + + An error in the encoding caused the specification to differ from + deployed implementations. At the time of this writing there are no + known implementations that follow the encoding specified in RFC 4507. + This update to RFC 4507 aligns the document with these currently + deployed implementations. + + Erroneous encoding in RFC 4507 resulted in two length fields; one for + the extension contents and one for the ticket itself. Hence, for a + ticket that is 256 bytes long and begins with the hex value FF FF, + the encoding of the extension would be as follows according to RFC + 4507: + + 00 23 Ticket Extension type 35 + 01 02 Length of extension contents + 01 00 Length of ticket + FF FF .. .. Actual ticket + + The update proposed in this document reflects what implementations + actually encode, namely it removes the redundant length field. So, + for a ticket that is 256 bytes long and begins with the hex value FF + FF, the encoding of the extension would be as follows according to + this update: + + 00 23 Extension type 35 + 01 00 Length of extension contents (ticket) + FF FF .. .. Actual ticket + + A server implemented according to RFC 4507 receiving a ticket + extension from a client conforming to this document would interpret + the first two bytes of the ticket as the length of this ticket. This + will result in either an inconsistent length field or in the + processing of a ticket missing the first two bytes. In the first + case, the server should reject the request based on a malformed + length. In the second case, the server should reject the ticket + based on a malformed ticket, incorrect key version, or failed + decryption. A server implementation based on this update receiving + an RFC 4507 extension would interpret the first length field as the + + + + + +Salowey, et al. Standards Track [Page 17] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + + length of the ticket and include the second two length bytes as the + first bytes in the ticket, resulting in the ticket being rejected + based on a malformed ticket, incorrect key version, or failed + decryption. + + Note that the encoding of an empty SessionTicket extension was + ambiguous in RFC 4507. An RFC 4507 implementation may have encoded + it as: + + 00 23 Extension type 35 + 00 02 Length of extension contents + 00 00 Length of ticket + + or it may have encoded it the same way as this update: + + 00 23 Extension type 35 + 00 00 Length of extension contents + + A server wishing to support RFC 4507 clients should respond to an + empty SessionTicket extension encoded the same way as it received it. + + A server implementation can construct tickets such that it can detect + an RFC 4507 implementation, if one existed, by including a cookie at + the beginning of the tickets that can be differentiated from a valid + length. For example, if an implementation constructed tickets to + start with the hex values FF FF, then it could determine where the + ticket begins and determine the length correctly from the type of + length fields present. + + This document makes a few additional changes to RFC 4507 listed + below. + + o Clarifying that the server can allow session resumption using a + ticket without issuing a new ticket in Section 3.1. + + o Clarifying that the lifetime is relative to when the ticket is + received in section 3.3. + + o Clarifying that the NewSessionTicket handshake message is included + in the hash generated for the Finished messages in Section 3.3. + + o Clarifying the interaction with TLS Session ID in Section 3.4. + + o Recommending the use of SHA-256 for the integrity protection of + the ticket in Section 4. + + o Clarifying that additional data can be included in the + StatePlaintext structure in Section 4. + + + +Salowey, et al. Standards Track [Page 18] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +Authors' Addresses + + Joseph Salowey + Cisco Systems + 2901 3rd Ave + Seattle, WA 98121 + US + + EMail: jsalowey@cisco.com + + + Hao Zhou + Cisco Systems + 4125 Highlander Parkway + Richfield, OH 44286 + US + + EMail: hzhou@cisco.com + + + Pasi Eronen + Nokia Research Center + P.O. Box 407 + FIN-00045 Nokia Group + Finland + + EMail: pasi.eronen@nokia.com + + + Hannes Tschofenig + Nokia Siemens Networks + Otto-Hahn-Ring 6 + Munich, Bayern 81739 + Germany + + EMail: Hannes.Tschofenig@nsn.com + + + + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 19] + +RFC 5077 Stateless TLS Session Resumption January 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Salowey, et al. Standards Track [Page 20] + diff --git a/compliance/specs/www.rfc-editor.org/rfc/rfc6066.txt b/compliance/specs/www.rfc-editor.org/rfc/rfc6066.txt new file mode 100644 index 00000000000..c1b777ca6e5 --- /dev/null +++ b/compliance/specs/www.rfc-editor.org/rfc/rfc6066.txt @@ -0,0 +1,1403 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Eastlake 3rd +Request for Comments: 6066 Huawei +Obsoletes: 4366 January 2011 +Category: Standards Track +ISSN: 2070-1721 + + + Transport Layer Security (TLS) Extensions: Extension Definitions + +Abstract + + This document provides specifications for existing TLS extensions. + It is a companion document for RFC 5246, "The Transport Layer + Security (TLS) Protocol Version 1.2". The extensions specified are + server_name, max_fragment_length, client_certificate_url, + trusted_ca_keys, truncated_hmac, and status_request. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6066. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + +Eastlake Standards Track [Page 1] + +RFC 6066 TLS Extension Definitions January 2011 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Specific Extensions Covered ................................3 + 1.2. Conventions Used in This Document ..........................5 + 2. Extensions to the Handshake Protocol ............................5 + 3. Server Name Indication ..........................................6 + 4. Maximum Fragment Length Negotiation .............................8 + 5. Client Certificate URLs .........................................9 + 6. Trusted CA Indication ..........................................12 + 7. Truncated HMAC .................................................13 + 8. Certificate Status Request .....................................14 + 9. Error Alerts ...................................................16 + 10. IANA Considerations ...........................................17 + 10.1. pkipath MIME Type Registration ...........................17 + 10.2. Reference for TLS Alerts, TLS HandshakeTypes, and + ExtensionTypes ...........................................19 + 11. Security Considerations .......................................19 + 11.1. Security Considerations for server_name ..................19 + 11.2. Security Considerations for max_fragment_length ..........20 + 11.3. Security Considerations for client_certificate_url .......20 + 11.4. Security Considerations for trusted_ca_keys ..............21 + 11.5. Security Considerations for truncated_hmac ...............21 + 11.6. Security Considerations for status_request ...............22 + 12. Normative References ..........................................22 + 13. Informative References ........................................23 + Appendix A. Changes from RFC 4366 .................................24 + Appendix B. Acknowledgements ......................................25 + + + + + + + + + + + +Eastlake Standards Track [Page 2] + +RFC 6066 TLS Extension Definitions January 2011 + + +1. Introduction + + The Transport Layer Security (TLS) Protocol Version 1.2 is specified + in [RFC5246]. That specification includes the framework for + extensions to TLS, considerations in designing such extensions (see + Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the + allocation of new extension code points; however, it does not specify + any particular extensions other than Signature Algorithms (see + Section 7.4.1.4.1 of [RFC5246]). + + This document provides the specifications for existing TLS + extensions. It is, for the most part, the adaptation and editing of + material from RFC 4366, which covered TLS extensions for TLS 1.0 (RFC + 2246) and TLS 1.1 (RFC 4346). + +1.1. Specific Extensions Covered + + The extensions described here focus on extending the functionality + provided by the TLS protocol message formats. Other issues, such as + the addition of new cipher suites, are deferred. + + The extension types defined in this document are: + + enum { + server_name(0), max_fragment_length(1), + client_certificate_url(2), trusted_ca_keys(3), + truncated_hmac(4), status_request(5), (65535) + } ExtensionType; + + Specifically, the extensions described in this document: + + - Allow TLS clients to provide to the TLS server the name of the + server they are contacting. This functionality is desirable in + order to facilitate secure connections to servers that host + multiple 'virtual' servers at a single underlying network address. + + - Allow TLS clients and servers to negotiate the maximum fragment + length to be sent. This functionality is desirable as a result of + memory constraints among some clients, and bandwidth constraints + among some access networks. + + - Allow TLS clients and servers to negotiate the use of client + certificate URLs. This functionality is desirable in order to + conserve memory on constrained clients. + + + + + + + +Eastlake Standards Track [Page 3] + +RFC 6066 TLS Extension Definitions January 2011 + + + - Allow TLS clients to indicate to TLS servers which certification + authority (CA) root keys they possess. This functionality is + desirable in order to prevent multiple handshake failures + involving TLS clients that are only able to store a small number + of CA root keys due to memory limitations. + + - Allow TLS clients and servers to negotiate the use of truncated + Message Authentication Codes (MACs). This functionality is + desirable in order to conserve bandwidth in constrained access + networks. + + - Allow TLS clients and servers to negotiate that the server sends + the client certificate status information (e.g., an Online + Certificate Status Protocol (OCSP) [RFC2560] response) during a + TLS handshake. This functionality is desirable in order to avoid + sending a Certificate Revocation List (CRL) over a constrained + access network and therefore saving bandwidth. + + TLS clients and servers may use the extensions described in this + document. The extensions are designed to be backwards compatible, + meaning that TLS clients that support the extensions can talk to TLS + servers that do not support the extensions, and vice versa. + + Note that any messages associated with these extensions that are sent + during the TLS handshake MUST be included in the hash calculations + involved in "Finished" messages. + + Note also that all the extensions defined in this document are + relevant only when a session is initiated. A client that requests + session resumption does not in general know whether the server will + accept this request, and therefore it SHOULD send the same extensions + as it would send if it were not attempting resumption. When a client + includes one or more of the defined extension types in an extended + client hello while requesting session resumption: + + - The server name indication extension MAY be used by the server + when deciding whether or not to resume a session as described in + Section 3. + + - If the resumption request is denied, the use of the extensions is + negotiated as normal. + + - If, on the other hand, the older session is resumed, then the + server MUST ignore the extensions and send a server hello + containing none of the extension types. In this case, the + functionality of these extensions negotiated during the original + session initiation is applied to the resumed session. + + + + +Eastlake Standards Track [Page 4] + +RFC 6066 TLS Extension Definitions January 2011 + + +1.2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +2. Extensions to the Handshake Protocol + + This document specifies the use of two new handshake messages, + "CertificateURL" and "CertificateStatus". These messages are + described in Sections 5 and 8, respectively. The new handshake + message structure therefore becomes: + + enum { + hello_request(0), client_hello(1), server_hello(2), + certificate(11), server_key_exchange (12), + certificate_request(13), server_hello_done(14), + certificate_verify(15), client_key_exchange(16), + finished(20), certificate_url(21), certificate_status(22), + (255) + } HandshakeType; + + struct { + HandshakeType msg_type; /* handshake type */ + uint24 length; /* bytes in message */ + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + case certificate_url: CertificateURL; + case certificate_status: CertificateStatus; + } body; + } Handshake; + + + + + + + + + + +Eastlake Standards Track [Page 5] + +RFC 6066 TLS Extension Definitions January 2011 + + +3. Server Name Indication + + TLS does not provide a mechanism for a client to tell a server the + name of the server it is contacting. It may be desirable for clients + to provide this information to facilitate secure connections to + servers that host multiple 'virtual' servers at a single underlying + network address. + + In order to provide any of the server names, clients MAY include an + extension of type "server_name" in the (extended) client hello. The + "extension_data" field of this extension SHALL contain + "ServerNameList" where: + + struct { + NameType name_type; + select (name_type) { + case host_name: HostName; + } name; + } ServerName; + + enum { + host_name(0), (255) + } NameType; + + opaque HostName<1..2^16-1>; + + struct { + ServerName server_name_list<1..2^16-1> + } ServerNameList; + + The ServerNameList MUST NOT contain more than one name of the same + name_type. If the server understood the ClientHello extension but + does not recognize the server name, the server SHOULD take one of two + actions: either abort the handshake by sending a fatal-level + unrecognized_name(112) alert or continue the handshake. It is NOT + RECOMMENDED to send a warning-level unrecognized_name(112) alert, + because the client's behavior in response to warning-level alerts is + unpredictable. If there is a mismatch between the server name used + by the client application and the server name of the credential + chosen by the server, this mismatch will become apparent when the + client application performs the server endpoint identification, at + which point the client application will have to decide whether to + proceed with the communication. TLS implementations are encouraged + to make information available to application callers about warning- + level alerts that were received or sent during a TLS handshake. Such + information can be useful for diagnostic purposes. + + + + + +Eastlake Standards Track [Page 6] + +RFC 6066 TLS Extension Definitions January 2011 + + + Note: Earlier versions of this specification permitted multiple + names of the same name_type. In practice, current client + implementations only send one name, and the client cannot + necessarily find out which name the server selected. Multiple + names of the same name_type are therefore now prohibited. + + Currently, the only server names supported are DNS hostnames; + however, this does not imply any dependency of TLS on DNS, and other + name types may be added in the future (by an RFC that updates this + document). The data structure associated with the host_name NameType + is a variable-length vector that begins with a 16-bit length. For + backward compatibility, all future data structures associated with + new NameTypes MUST begin with a 16-bit length field. TLS MAY treat + provided server names as opaque data and pass the names and types to + the application. + + "HostName" contains the fully qualified DNS hostname of the server, + as understood by the client. The hostname is represented as a byte + string using ASCII encoding without a trailing dot. This allows the + support of internationalized domain names through the use of A-labels + defined in [RFC5890]. DNS hostnames are case-insensitive. The + algorithm to compare hostnames is described in [RFC5890], Section + 2.3.2.4. + + Literal IPv4 and IPv6 addresses are not permitted in "HostName". + + It is RECOMMENDED that clients include an extension of type + "server_name" in the client hello whenever they locate a server by a + supported name type. + + A server that receives a client hello containing the "server_name" + extension MAY use the information contained in the extension to guide + its selection of an appropriate certificate to return to the client, + and/or other aspects of security policy. In this event, the server + SHALL include an extension of type "server_name" in the (extended) + server hello. The "extension_data" field of this extension SHALL be + empty. + + When the server is deciding whether or not to accept a request to + resume a session, the contents of a server_name extension MAY be used + in the lookup of the session in the session cache. The client SHOULD + include the same server_name extension in the session resumption + request as it did in the full handshake that established the session. + A server that implements this extension MUST NOT accept the request + to resume the session if the server_name extension contains a + different name. Instead, it proceeds with a full handshake to + establish a new session. When resuming a session, the server MUST + NOT include a server_name extension in the server hello. + + + +Eastlake Standards Track [Page 7] + +RFC 6066 TLS Extension Definitions January 2011 + + + If an application negotiates a server name using an application + protocol and then upgrades to TLS, and if a server_name extension is + sent, then the extension SHOULD contain the same name that was + negotiated in the application protocol. If the server_name is + established in the TLS session handshake, the client SHOULD NOT + attempt to request a different server name at the application layer. + +4. Maximum Fragment Length Negotiation + + Without this extension, TLS specifies a fixed maximum plaintext + fragment length of 2^14 bytes. It may be desirable for constrained + clients to negotiate a smaller maximum fragment length due to memory + limitations or bandwidth limitations. + + In order to negotiate smaller maximum fragment lengths, clients MAY + include an extension of type "max_fragment_length" in the (extended) + client hello. The "extension_data" field of this extension SHALL + contain: + + enum{ + 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) + } MaxFragmentLength; + + whose value is the desired maximum fragment length. The allowed + values for this field are: 2^9, 2^10, 2^11, and 2^12. + + Servers that receive an extended client hello containing a + "max_fragment_length" extension MAY accept the requested maximum + fragment length by including an extension of type + "max_fragment_length" in the (extended) server hello. The + "extension_data" field of this extension SHALL contain a + "MaxFragmentLength" whose value is the same as the requested maximum + fragment length. + + If a server receives a maximum fragment length negotiation request + for a value other than the allowed values, it MUST abort the + handshake with an "illegal_parameter" alert. Similarly, if a client + receives a maximum fragment length negotiation response that differs + from the length it requested, it MUST also abort the handshake with + an "illegal_parameter" alert. + + Once a maximum fragment length other than 2^14 has been successfully + negotiated, the client and server MUST immediately begin fragmenting + messages (including handshake messages) to ensure that no fragment + larger than the negotiated length is sent. Note that TLS already + requires clients and servers to support fragmentation of handshake + messages. + + + + +Eastlake Standards Track [Page 8] + +RFC 6066 TLS Extension Definitions January 2011 + + + The negotiated length applies for the duration of the session + including session resumptions. + + The negotiated length limits the input that the record layer may + process without fragmentation (that is, the maximum value of + TLSPlaintext.length; see [RFC5246], Section 6.2.1). Note that the + output of the record layer may be larger. For example, if the + negotiated length is 2^9=512, then, when using currently defined + cipher suites (those defined in [RFC5246] and [RFC2712]) and null + compression, the record-layer output can be at most 805 bytes: 5 + bytes of headers, 512 bytes of application data, 256 bytes of + padding, and 32 bytes of MAC. This means that in this event a TLS + record-layer peer receiving a TLS record-layer message larger than + 805 bytes MUST discard the message and send a "record_overflow" + alert, without decrypting the message. When this extension is used + with Datagram Transport Layer Security (DTLS), implementations SHOULD + NOT generate record_overflow alerts unless the packet passes message + authentication. + +5. Client Certificate URLs + + Without this extension, TLS specifies that when client authentication + is performed, client certificates are sent by clients to servers + during the TLS handshake. It may be desirable for constrained + clients to send certificate URLs in place of certificates, so that + they do not need to store their certificates and can therefore save + memory. + + In order to negotiate sending certificate URLs to a server, clients + MAY include an extension of type "client_certificate_url" in the + (extended) client hello. The "extension_data" field of this + extension SHALL be empty. + + (Note that it is necessary to negotiate the use of client certificate + URLs in order to avoid "breaking" existing TLS servers.) + + Servers that receive an extended client hello containing a + "client_certificate_url" extension MAY indicate that they are willing + to accept certificate URLs by including an extension of type + "client_certificate_url" in the (extended) server hello. The + "extension_data" field of this extension SHALL be empty. + + After negotiation of the use of client certificate URLs has been + successfully completed (by exchanging hellos including + "client_certificate_url" extensions), clients MAY send a + "CertificateURL" message in place of a "Certificate" message as + follows (see also Section 2): + + + + +Eastlake Standards Track [Page 9] + +RFC 6066 TLS Extension Definitions January 2011 + + + enum { + individual_certs(0), pkipath(1), (255) + } CertChainType; + + struct { + CertChainType type; + URLAndHash url_and_hash_list<1..2^16-1>; + } CertificateURL; + + struct { + opaque url<1..2^16-1>; + unint8 padding; + opaque SHA1Hash[20]; + } URLAndHash; + + Here, "url_and_hash_list" contains a sequence of URLs and hashes. + Each "url" MUST be an absolute URI reference according to [RFC3986] + that can be immediately used to fetch the certificate(s). + + When X.509 certificates are used, there are two possibilities: + + - If CertificateURL.type is "individual_certs", each URL refers to a + single DER-encoded X.509v3 certificate, with the URL for the + client's certificate first. + + - If CertificateURL.type is "pkipath", the list contains a single + URL referring to a DER-encoded certificate chain, using the type + PkiPath described in Section 10.1. + + When any other certificate format is used, the specification that + describes use of that format in TLS should define the encoding format + of certificates or certificate chains, and any constraint on their + ordering. + + The "padding" byte MUST be 0x01. It is present to make the structure + backwards compatible. + + The hash corresponding to each URL is the SHA-1 hash of the + certificate or certificate chain (in the case of X.509 certificates, + the DER-encoded certificate or the DER-encoded PkiPath). + + Note that when a list of URLs for X.509 certificates is used, the + ordering of URLs is the same as that used in the TLS Certificate + message (see [RFC5246], Section 7.4.2), but opposite to the order in + which certificates are encoded in PkiPath. In either case, the self- + signed root certificate MAY be omitted from the chain, under the + assumption that the server must already possess it in order to + validate it. + + + +Eastlake Standards Track [Page 10] + +RFC 6066 TLS Extension Definitions January 2011 + + + Servers receiving "CertificateURL" SHALL attempt to retrieve the + client's certificate chain from the URLs and then process the + certificate chain as usual. A cached copy of the content of any URL + in the chain MAY be used, provided that the SHA-1 hash matches the + hash of the cached copy. + + Servers that support this extension MUST support the 'http' URI + scheme for certificate URLs and MAY support other schemes. Use of + other schemes than 'http', 'https', or 'ftp' may create unexpected + problems. + + If the protocol used is HTTP, then the HTTP server can be configured + to use the Cache-Control and Expires directives described in + [RFC2616] to specify whether and for how long certificates or + certificate chains should be cached. + + The TLS server MUST NOT follow HTTP redirects when retrieving the + certificates or certificate chain. The URLs used in this extension + MUST NOT be chosen to depend on such redirects. + + If the protocol used to retrieve certificates or certificate chains + returns a MIME-formatted response (as HTTP does), then the following + MIME Content-Types SHALL be used: when a single X.509v3 certificate + is returned, the Content-Type is "application/pkix-cert" [RFC2585], + and when a chain of X.509v3 certificates is returned, the Content- + Type is "application/pkix-pkipath" (Section 10.1). + + The server MUST check that the SHA-1 hash of the contents of the + object retrieved from that URL (after decoding any MIME Content- + Transfer-Encoding) matches the given hash. If any retrieved object + does not have the correct SHA-1 hash, the server MUST abort the + handshake with a bad_certificate_hash_value(114) alert. This alert + is always fatal. + + Clients may choose to send either "Certificate" or "CertificateURL" + after successfully negotiating the option to send certificate URLs. + The option to send a certificate is included to provide flexibility + to clients possessing multiple certificates. + + If a server is unable to obtain certificates in a given + CertificateURL, it MUST send a fatal certificate_unobtainable(111) + alert if it requires the certificates to complete the handshake. If + the server does not require the certificates, then the server + continues the handshake. The server MAY send a warning-level alert + in this case. Clients receiving such an alert SHOULD log the alert + and continue with the handshake if possible. + + + + + +Eastlake Standards Track [Page 11] + +RFC 6066 TLS Extension Definitions January 2011 + + +6. Trusted CA Indication + + Constrained clients that, due to memory limitations, possess only a + small number of CA root keys may wish to indicate to servers which + root keys they possess, in order to avoid repeated handshake + failures. + + In order to indicate which CA root keys they possess, clients MAY + include an extension of type "trusted_ca_keys" in the (extended) + client hello. The "extension_data" field of this extension SHALL + contain "TrustedAuthorities" where: + + struct { + TrustedAuthority trusted_authorities_list<0..2^16-1>; + } TrustedAuthorities; + + struct { + IdentifierType identifier_type; + select (identifier_type) { + case pre_agreed: struct {}; + case key_sha1_hash: SHA1Hash; + case x509_name: DistinguishedName; + case cert_sha1_hash: SHA1Hash; + } identifier; + } TrustedAuthority; + + enum { + pre_agreed(0), key_sha1_hash(1), x509_name(2), + cert_sha1_hash(3), (255) + } IdentifierType; + + opaque DistinguishedName<1..2^16-1>; + + Here, "TrustedAuthorities" provides a list of CA root key identifiers + that the client possesses. Each CA root key is identified via + either: + + - "pre_agreed": no CA root key identity supplied. + + - "key_sha1_hash": contains the SHA-1 hash of the CA root key. For + Digital Signature Algorithm (DSA) and Elliptic Curve Digital + Signature Algorithm (ECDSA) keys, this is the hash of the + "subjectPublicKey" value. For RSA keys, the hash is of the big- + endian byte string representation of the modulus without any + initial zero-valued bytes. (This copies the key hash formats + deployed in other environments.) + + + + + +Eastlake Standards Track [Page 12] + +RFC 6066 TLS Extension Definitions January 2011 + + + - "x509_name": contains the DER-encoded X.509 DistinguishedName of + the CA. + + - "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded + Certificate containing the CA root key. + + Note that clients may include none, some, or all of the CA root keys + they possess in this extension. + + Note also that it is possible that a key hash or a Distinguished Name + alone may not uniquely identify a certificate issuer (for example, if + a particular CA has multiple key pairs). However, here we assume + this is the case following the use of Distinguished Names to identify + certificate issuers in TLS. + + The option to include no CA root keys is included to allow the client + to indicate possession of some pre-defined set of CA root keys. + + Servers that receive a client hello containing the "trusted_ca_keys" + extension MAY use the information contained in the extension to guide + their selection of an appropriate certificate chain to return to the + client. In this event, the server SHALL include an extension of type + "trusted_ca_keys" in the (extended) server hello. The + "extension_data" field of this extension SHALL be empty. + +7. Truncated HMAC + + Currently defined TLS cipher suites use the MAC construction HMAC + [RFC2104] to authenticate record-layer communications. In TLS, the + entire output of the hash function is used as the MAC tag. However, + it may be desirable in constrained environments to save bandwidth by + truncating the output of the hash function to 80 bits when forming + MAC tags. + + In order to negotiate the use of 80-bit truncated HMAC, clients MAY + include an extension of type "truncated_hmac" in the extended client + hello. The "extension_data" field of this extension SHALL be empty. + + Servers that receive an extended hello containing a "truncated_hmac" + extension MAY agree to use a truncated HMAC by including an extension + of type "truncated_hmac", with empty "extension_data", in the + extended server hello. + + Note that if new cipher suites are added that do not use HMAC, and + the session negotiates one of these cipher suites, this extension + will have no effect. It is strongly recommended that any new cipher + suites using other MACs consider the MAC size an integral part of the + + + + +Eastlake Standards Track [Page 13] + +RFC 6066 TLS Extension Definitions January 2011 + + + cipher suite definition, taking into account both security and + bandwidth considerations. + + If HMAC truncation has been successfully negotiated during a TLS + handshake, and the negotiated cipher suite uses HMAC, both the client + and the server pass this fact to the TLS record layer along with the + other negotiated security parameters. Subsequently during the + session, clients and servers MUST use truncated HMACs, calculated as + specified in [RFC2104]. That is, SecurityParameters.mac_length is 10 + bytes, and only the first 10 bytes of the HMAC output are transmitted + and checked. Note that this extension does not affect the + calculation of the pseudo-random function (PRF) as part of + handshaking or key derivation. + + The negotiated HMAC truncation size applies for the duration of the + session including session resumptions. + +8. Certificate Status Request + + Constrained clients may wish to use a certificate-status protocol + such as OCSP [RFC2560] to check the validity of server certificates, + in order to avoid transmission of CRLs and therefore save bandwidth + on constrained networks. This extension allows for such information + to be sent in the TLS handshake, saving roundtrips and resources. + + In order to indicate their desire to receive certificate status + information, clients MAY include an extension of type + "status_request" in the (extended) client hello. The + "extension_data" field of this extension SHALL contain + "CertificateStatusRequest" where: + + struct { + CertificateStatusType status_type; + select (status_type) { + case ocsp: OCSPStatusRequest; + } request; + } CertificateStatusRequest; + + enum { ocsp(1), (255) } CertificateStatusType; + + struct { + ResponderID responder_id_list<0..2^16-1>; + Extensions request_extensions; + } OCSPStatusRequest; + + opaque ResponderID<1..2^16-1>; + opaque Extensions<0..2^16-1>; + + + + +Eastlake Standards Track [Page 14] + +RFC 6066 TLS Extension Definitions January 2011 + + + In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP + responders that the client trusts. A zero-length "responder_id_list" + sequence has the special meaning that the responders are implicitly + known to the server, e.g., by prior arrangement. "Extensions" is a + DER encoding of OCSP request extensions. + + Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as + defined in [RFC2560]. "Extensions" is imported from [RFC5280]. A + zero-length "request_extensions" value means that there are no + extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not + valid for the "Extensions" type). + + In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is + unclear about its encoding; for clarification, the nonce MUST be a + DER-encoded OCTET STRING, which is encapsulated as another OCTET + STRING (note that implementations based on an existing OCSP client + will need to be checked for conformance to this requirement). + + Servers that receive a client hello containing the "status_request" + extension MAY return a suitable certificate status response to the + client along with their certificate. If OCSP is requested, they + SHOULD use the information contained in the extension when selecting + an OCSP responder and SHOULD include request_extensions in the OCSP + request. + + Servers return a certificate response along with their certificate by + sending a "CertificateStatus" message immediately after the + "Certificate" message (and before any "ServerKeyExchange" or + "CertificateRequest" messages). If a server returns a + "CertificateStatus" message, then the server MUST have included an + extension of type "status_request" with empty "extension_data" in the + extended server hello. The "CertificateStatus" message is conveyed + using the handshake message type "certificate_status" as follows (see + also Section 2): + + struct { + CertificateStatusType status_type; + select (status_type) { + case ocsp: OCSPResponse; + } response; + } CertificateStatus; + + opaque OCSPResponse<1..2^24-1>; + + An "ocsp_response" contains a complete, DER-encoded OCSP response + (using the ASN.1 type OCSPResponse defined in [RFC2560]). Only one + OCSP response may be sent. + + + + +Eastlake Standards Track [Page 15] + +RFC 6066 TLS Extension Definitions January 2011 + + + Note that a server MAY also choose not to send a "CertificateStatus" + message, even if has received a "status_request" extension in the + client hello message and has sent a "status_request" extension in the + server hello message. + + Note in addition that a server MUST NOT send the "CertificateStatus" + message unless it received a "status_request" extension in the client + hello message and sent a "status_request" extension in the server + hello message. + + Clients requesting an OCSP response and receiving an OCSP response in + a "CertificateStatus" message MUST check the OCSP response and abort + the handshake if the response is not satisfactory with + bad_certificate_status_response(113) alert. This alert is always + fatal. + +9. Error Alerts + + Four new error alerts are defined for use with the TLS extensions + defined in this document. To avoid "breaking" existing clients and + servers, these alerts MUST NOT be sent unless the sending party has + received an extended hello message from the party they are + communicating with. These error alerts are conveyed using the + following syntax. The new alerts are the last four, as indicated by + the comments on the same line as the error alert number. + + enum { + close_notify(0), + unexpected_message(10), + bad_record_mac(20), + decryption_failed(21), + record_overflow(22), + decompression_failure(30), + handshake_failure(40), + /* 41 is not defined, for historical reasons */ + bad_certificate(42), + unsupported_certificate(43), + certificate_revoked(44), + certificate_expired(45), + certificate_unknown(46), + illegal_parameter(47), + unknown_ca(48), + access_denied(49), + decode_error(50), + decrypt_error(51), + export_restriction(60), + protocol_version(70), + insufficient_security(71), + + + +Eastlake Standards Track [Page 16] + +RFC 6066 TLS Extension Definitions January 2011 + + + internal_error(80), + user_canceled(90), + no_renegotiation(100), + unsupported_extension(110), + certificate_unobtainable(111), /* new */ + unrecognized_name(112), /* new */ + bad_certificate_status_response(113), /* new */ + bad_certificate_hash_value(114), /* new */ + (255) + } AlertDescription; + + "certificate_unobtainable" is described in Section 5. + "unrecognized_name" is described in Section 3. + "bad_certificate_status_response" is described in Section 8. + "bad_certificate_hash_value" is described in Section 5. + +10. IANA Considerations + + IANA Considerations for TLS extensions and the creation of a registry + are covered in Section 12 of [RFC5246] except for the registration of + MIME type application/pkix-pkipath, which appears below. + + The IANA TLS extensions and MIME type application/pkix-pkipath + registry entries that reference RFC 4366 have been updated to + reference this document. + +10.1. pkipath MIME Type Registration + + MIME media type name: application + MIME subtype name: pkix-pkipath + Required parameters: none + + Optional parameters: version (default value is "1") + + Encoding considerations: + Binary; this MIME type is a DER encoding of the ASN.1 type + PkiPath, defined as follows: + PkiPath ::= SEQUENCE OF Certificate + PkiPath is used to represent a certification path. Within the + sequence, the order of certificates is such that the subject of + the first certificate is the issuer of the second certificate, + etc. + This is identical to the definition published in [X509-4th-TC1]; + note that it is different from that in [X509-4th]. + + All Certificates MUST conform to [RFC5280]. (This should be + interpreted as a requirement to encode only PKIX-conformant + certificates using this type. It does not necessarily require + + + +Eastlake Standards Track [Page 17] + +RFC 6066 TLS Extension Definitions January 2011 + + + that all certificates that are not strictly PKIX-conformant must + be rejected by relying parties, although the security consequences + of accepting any such certificates should be considered + carefully.) + + DER (as opposed to BER) encoding MUST be used. If this type is + sent over a 7-bit transport, base64 encoding SHOULD be used. + + Security considerations: + The security considerations of [X509-4th] and [RFC5280] (or any + updates to them) apply, as well as those of any protocol that uses + this type (e.g., TLS). + + Note that this type only specifies a certificate chain that can be + assessed for validity according to the relying party's existing + configuration of trusted CAs; it is not intended to be used to + specify any change to that configuration. + + Interoperability considerations: + No specific interoperability problems are known with this type, + but for recommendations relating to X.509 certificates in general, + see [RFC5280]. + + Published specification: This document and [RFC5280]. + + Applications that use this media type: + TLS. It may also be used by other protocols or for general + interchange of PKIX certificate chains. + + Additional information: + Magic number(s): DER-encoded ASN.1 can be easily recognized. + Further parsing is required to distinguish it from other ASN.1 + types. + File extension(s): .pkipath + Macintosh File Type Code(s): not specified + + Person & email address to contact for further information: + Magnus Nystrom + + Intended usage: COMMON + + Change controller: IESG + + + + + + + + + +Eastlake Standards Track [Page 18] + +RFC 6066 TLS Extension Definitions January 2011 + + +10.2. Reference for TLS Alerts, TLS HandshakeTypes, and ExtensionTypes + + The following values in the TLS Alert Registry have been updated to + reference this document: + + 111 certificate_unobtainable + 112 unrecognized_name + 113 bad_certificate_status_response + 114 bad_certificate_hash_value + + The following values in the TLS HandshakeType Registry have been + updated to reference this document: + + 21 certificate_url + 22 certificate_status + + The following ExtensionType values have been updated to reference + this document: + + 0 server_name + 1 max_fragment_length + 2 client_certificate_url + 3 trusted_ca_keys + 4 truncated_hmac + 5 status_request + +11. Security Considerations + + General security considerations for TLS extensions are covered in + [RFC5246]. Security Considerations for particular extensions + specified in this document are given below. + + In general, implementers should continue to monitor the state of the + art and address any weaknesses identified. + +11.1. Security Considerations for server_name + + If a single server hosts several domains, then clearly it is + necessary for the owners of each domain to ensure that this satisfies + their security needs. Apart from this, server_name does not appear + to introduce significant security issues. + + Since it is possible for a client to present a different server_name + in the application protocol, application server implementations that + rely upon these names being the same MUST check to make sure the + client did not present a different name in the application protocol. + + + + + +Eastlake Standards Track [Page 19] + +RFC 6066 TLS Extension Definitions January 2011 + + + Implementations MUST ensure that a buffer overflow does not occur, + whatever the values of the length fields in server_name. + +11.2. Security Considerations for max_fragment_length + + The maximum fragment length takes effect immediately, including for + handshake messages. However, that does not introduce any security + complications that are not already present in TLS, since TLS requires + implementations to be able to handle fragmented handshake messages. + + Note that, as described in Section 4, once a non-null cipher suite + has been activated, the effective maximum fragment length depends on + the cipher suite and compression method, as well as on the negotiated + max_fragment_length. This must be taken into account when sizing + buffers and checking for buffer overflow. + +11.3. Security Considerations for client_certificate_url + + Support for client_certificate_url involves the server's acting as a + client in another URI-scheme-dependent protocol. The server + therefore becomes subject to many of the same security concerns that + clients of the URI scheme are subject to, with the added concern that + the client can attempt to prompt the server to connect to some + (possibly weird-looking) URL. + + In general, this issue means that an attacker might use the server to + indirectly attack another host that is vulnerable to some security + flaw. It also introduces the possibility of denial-of-service + attacks in which an attacker makes many connections to the server, + each of which results in the server's attempting a connection to the + target of the attack. + + Note that the server may be behind a firewall or otherwise able to + access hosts that would not be directly accessible from the public + Internet. This could exacerbate the potential security and denial- + of-service problems described above, as well as allow the existence + of internal hosts to be confirmed when they would otherwise be + hidden. + + The detailed security concerns involved will depend on the URI + schemes supported by the server. In the case of HTTP, the concerns + are similar to those that apply to a publicly accessible HTTP proxy + server. In the case of HTTPS, loops and deadlocks may be created, + and this should be addressed. In the case of FTP, attacks arise that + are similar to FTP bounce attacks. + + + + + + +Eastlake Standards Track [Page 20] + +RFC 6066 TLS Extension Definitions January 2011 + + + As a result of this issue, it is RECOMMENDED that the + client_certificate_url extension should have to be specifically + enabled by a server administrator, rather than be enabled by default. + It is also RECOMMENDED that URI schemes be enabled by the + administrator individually, and only a minimal set of schemes be + enabled. Unusual protocols that offer limited security or whose + security is not well understood SHOULD be avoided. + + As discussed in [RFC3986], URLs that specify ports other than the + default may cause problems, as may very long URLs (which are more + likely to be useful in exploiting buffer overflow bugs). + + This extension continues to use SHA-1 (as in RFC 4366) and does not + provide algorithm agility. The property required of SHA-1 in this + case is second pre-image resistance, not collision resistance. + Furthermore, even if second pre-image attacks against SHA-1 are found + in the future, an attack against client_certificate_url would require + a second pre-image that is accepted as a valid certificate by the + server and contains the same public key. + + Also note that HTTP caching proxies are common on the Internet, and + some proxies do not check for the latest version of an object + correctly. If a request using HTTP (or another caching protocol) + goes through a misconfigured or otherwise broken proxy, the proxy may + return an out-of-date response. + +11.4. Security Considerations for trusted_ca_keys + + Potentially, the CA root keys a client possesses could be regarded as + confidential information. As a result, the CA root key indication + extension should be used with care. + + The use of the SHA-1 certificate hash alternative ensures that each + certificate is specified unambiguously. This context does not + require a cryptographic hash function, so the use of SHA-1 is + considered acceptable, and no algorithm agility is provided. + +11.5. Security Considerations for truncated_hmac + + It is possible that truncated MACs are weaker than "un-truncated" + MACs. However, no significant weaknesses are currently known or + expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. + + Note that the output length of a MAC need not be as long as the + length of a symmetric cipher key, since forging of MAC values cannot + be done off-line: in TLS, a single failed MAC guess will cause the + immediate termination of the TLS session. + + + + +Eastlake Standards Track [Page 21] + +RFC 6066 TLS Extension Definitions January 2011 + + + Since the MAC algorithm only takes effect after all handshake + messages that affect extension parameters have been authenticated by + the hashes in the Finished messages, it is not possible for an active + attacker to force negotiation of the truncated HMAC extension where + it would not otherwise be used (to the extent that the handshake + authentication is secure). Therefore, in the event that any security + problems were found with truncated HMAC in the future, if either the + client or the server for a given session were updated to take the + problem into account, it would be able to veto use of this extension. + +11.6. Security Considerations for status_request + + If a client requests an OCSP response, it must take into account that + an attacker's server using a compromised key could (and probably + would) pretend not to support the extension. In this case, a client + that requires OCSP validation of certificates SHOULD either contact + the OCSP server directly or abort the handshake. + + Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may + improve security against attacks that attempt to replay OCSP + responses; see Section 4.4.1 of [RFC2560] for further details. + +12. Normative References + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and + C. Adams, "X.509 Internet Public Key Infrastructure + Online Certificate Status Protocol - OCSP", RFC 2560, + June 1999. + + [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key + Infrastructure Operational Protocols: FTP and HTTP", + RFC 2585, May 1999. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, + "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, + June 1999. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + + + +Eastlake Standards Track [Page 22] + +RFC 6066 TLS Extension Definitions January 2011 + + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, August + 2008. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 5280, May 2008. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document + Framework", RFC 5890, August 2010. + +13. Informative References + + [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher + Suites to Transport Layer Security (TLS)", RFC 2712, + October 1999. + + [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC + 9594-8:2001, "Information Systems - Open Systems + Interconnection - The Directory: Public key and + attribute certificate frameworks". + + [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | + ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum + 1 to ISO/IEC 9594:8:2001. + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 23] + +RFC 6066 TLS Extension Definitions January 2011 + + +Appendix A. Changes from RFC 4366 + + The significant changes between RFC 4366 and this document are + described below. + + RFC 4366 described both general extension mechanisms (for the TLS + handshake and client and server hellos) as well as specific + extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The + client and server hello extension mechanisms have been moved into RFC + 5246, TLS 1.2, so this document, which is associated with RFC 5246, + includes only the handshake extension mechanisms and the specific + extensions from RFC 4366. RFC 5246 also specifies the unknown + extension error and new extension specification considerations, so + that material has been removed from this document. + + The Server Name extension now specifies only ASCII representation, + eliminating UTF-8. It is provided that the ServerNameList can + contain more than only one name of any particular name_type. If a + server name is provided but not recognized, the server should either + continue the handshake without an error or send a fatal error. + Sending a warning-level message is not recommended because client + behavior will be unpredictable. Provision was added for the user + using the server_name extension in deciding whether or not to resume + a session. Furthermore, this extension should be the same in a + session resumption request as it was in the full handshake that + established the session. Such a resumption request must not be + accepted if the server_name extension is different, but instead a + full handshake must be done to possibly establish a new session. + + The Client Certificate URLs extension has been changed to make the + presence of a hash mandatory. + + For the case of DTLS, the requirement to report an overflow of the + negotiated maximum fragment length is made conditional on passing + authentication. + + TLS servers are now prohibited from following HTTP redirects when + retrieving certificates. + + The material was also re-organized in minor ways. For example, + information as to which errors are fatal is moved from the "Error + Alerts" section to the individual extension specifications. + + + + + + + + + +Eastlake Standards Track [Page 24] + +RFC 6066 TLS Extension Definitions January 2011 + + +Appendix B. Acknowledgements + + This document is based on material from RFC 4366 for which the + authors were S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, + and T. Wright. Other contributors include Joseph Salowey, Alexey + Melnikov, Peter Saint-Andre, and Adrian Farrel. + +Author's Address + + Donald Eastlake 3rd + Huawei + 155 Beaver Street + Milford, MA 01757 USA + + Phone: +1-508-333-2270 + EMail: d3e3e3@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 25] + diff --git a/compliance/specs/www.rfc-editor.org/rfc/rfc6125.txt b/compliance/specs/www.rfc-editor.org/rfc/rfc6125.txt new file mode 100644 index 00000000000..236d5d819c9 --- /dev/null +++ b/compliance/specs/www.rfc-editor.org/rfc/rfc6125.txt @@ -0,0 +1,3195 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Saint-Andre +Request for Comments: 6125 Cisco +Category: Standards Track J. Hodges +ISSN: 2070-1721 PayPal + March 2011 + + + Representation and Verification of Domain-Based Application Service + Identity within Internet Public Key Infrastructure Using X.509 (PKIX) + Certificates in the Context of Transport Layer Security (TLS) + +Abstract + + Many application technologies enable secure communication between two + entities by means of Internet Public Key Infrastructure Using X.509 + (PKIX) certificates in the context of Transport Layer Security (TLS). + This document specifies procedures for representing and verifying the + identity of application services in such interactions. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6125. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Saint-Andre & Hodges Standards Track [Page 1] + +RFC 6125 Service Identity March 2011 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. How to Read This Document . . . . . . . . . . . . . . . . 4 + 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 + 1.5. Overview of Recommendations . . . . . . . . . . . . . . . 5 + 1.6. Generalization from Current Technologies . . . . . . . . . 6 + 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 1.7.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 7 + 1.7.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 7 + 1.8. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 + 2. Naming of Application Services . . . . . . . . . . . . . . . . 13 + 2.1. Naming Application Services . . . . . . . . . . . . . . . 13 + 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 14 + 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 15 + 2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17 + 3. Designing Application Protocols . . . . . . . . . . . . . . . 18 + 4. Representing Server Identity . . . . . . . . . . . . . . . . . 18 + 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 5. Requesting Server Certificates . . . . . . . . . . . . . . . . 21 + 6. Verifying Service Identity . . . . . . . . . . . . . . . . . . 21 + 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 6.2. Constructing a List of Reference Identifiers . . . . . . . 22 + 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 22 + 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 24 + 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25 + 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 26 + 6.4.1. Checking of Traditional Domain Names . . . . . . . . . 27 + 6.4.2. Checking of Internationalized Domain Names . . . . . . 27 + 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27 + 6.4.4. Checking of Common Names . . . . . . . . . . . . . . . 28 + 6.5. Matching the Application Service Type Portion . . . . . . 28 + 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 29 + 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 29 + 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 29 + 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29 + 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 30 + 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 30 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30 + 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 31 + 7.3. Internationalized Domain Names . . . . . . . . . . . . . . 32 + 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 32 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 + + + +Saint-Andre & Hodges Standards Track [Page 2] + +RFC 6125 Service Identity March 2011 + + + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 34 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 34 + Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 40 + Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 42 + B.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 42 + B.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 43 + B.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 44 + B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 47 + B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 49 + B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 50 + B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 51 + B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 52 + B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 54 + B.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 55 + B.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 55 + +1. Introduction + +1.1. Motivation + + The visible face of the Internet largely consists of services that + employ a client-server architecture in which an interactive or + automated client communicates with an application service in order to + retrieve or upload information, communicate with other entities, or + access a broader network of services. When a client communicates + with an application service using Transport Layer Security [TLS] or + Datagram Transport Layer Security [DTLS], it references some notion + of the server's identity (e.g., "the website at example.com") while + attempting to establish secure communication. Likewise, during TLS + negotiation, the server presents its notion of the service's identity + in the form of a public-key certificate that was issued by a + certification authority (CA) in the context of the Internet Public + Key Infrastructure using X.509 [PKIX]. Informally, we can think of + these identities as the client's "reference identity" and the + server's "presented identity" (these rough ideas are defined more + precisely later in this document through the concept of particular + identifiers). In general, a client needs to verify that the server's + presented identity matches its reference identity so it can + authenticate the communication. + + Many application technologies adhere to the pattern just outlined. + Such protocols have traditionally specified their own rules for + representing and verifying application service identity. + Unfortunately, this divergence of approaches has caused some + confusion among certification authorities, application developers, + and protocol designers. + + + +Saint-Andre & Hodges Standards Track [Page 3] + +RFC 6125 Service Identity March 2011 + + + Therefore, to codify secure procedures for the implementation and + deployment of PKIX-based authentication, this document specifies + recommended procedures for representing and verifying application + service identity in certificates intended for use in application + protocols employing TLS. + +1.2. Audience + + The primary audience for this document consists of application + protocol designers, who can reference this document instead of + defining their own rules for the representation and verification of + application service identity. Secondarily, the audience consists of + certification authorities, service providers, and client developers + from technology communities that might reuse the recommendations in + this document when defining certificate issuance policies, generating + certificate signing requests, or writing software algorithms for + identity matching. + +1.3. How to Read This Document + + This document is longer than the authors would have liked because it + was necessary to carefully define terminology, explain the underlying + concepts, define the scope, and specify recommended behavior for both + certification authorities and application software implementations. + The following sections are of special interest to various audiences: + + o Protocol designers might want to first read the checklist in + Section 3. + + o Certification authorities might want to first read the + recommendations for representation of server identity in + Section 4. + + o Service providers might want to first read the recommendations for + requesting of server certificates in Section 5. + + o Software implementers might want to first read the recommendations + for verification of server identity in Section 6. + + The sections on terminology (Section 1.8), naming of application + services (Section 2), document scope (Section 1.7), and the like + provide useful background information regarding the recommendations + and guidelines that are contained in the above-referenced sections, + but are not absolutely necessary for a first reading of this + document. + + + + + + +Saint-Andre & Hodges Standards Track [Page 4] + +RFC 6125 Service Identity March 2011 + + +1.4. Applicability + + This document does not supersede the rules for certificate issuance + or validation provided in [PKIX]. Therefore, [PKIX] is authoritative + on any point that might also be discussed in this document. + Furthermore, [PKIX] also governs any certificate-related topic on + which this document is silent, including but not limited to + certificate syntax, certificate extensions such as name constraints + and extended key usage, and handling of certification paths. + + This document addresses only name forms in the leaf "end entity" + server certificate, not any name forms in the chain of certificates + used to validate the server certificate. Therefore, in order to + ensure proper authentication, application clients need to verify the + entire certification path per [PKIX]. + + This document also does not supersede the rules for verifying service + identity provided in specifications for existing application + protocols published prior to this document, such as those excerpted + under Appendix B. However, the procedures described here can be + referenced by future specifications, including updates to + specifications for existing application protocols if the relevant + technology communities agree to do so. + +1.5. Overview of Recommendations + + To orient the reader, this section provides an informational overview + of the recommendations contained in this document. + + For the primary audience of application protocol designers, this + document provides recommended procedures for the representation and + verification of application service identity within PKIX certificates + used in the context of TLS. + + For the secondary audiences, in essence this document encourages + certification authorities, application service providers, and + application client developers to coalesce on the following practices: + + o Move away from including and checking strings that look like + domain names in the subject's Common Name. + + o Move toward including and checking DNS domain names via the + subjectAlternativeName extension designed for that purpose: + dNSName. + + + + + + + +Saint-Andre & Hodges Standards Track [Page 5] + +RFC 6125 Service Identity March 2011 + + + o Move toward including and checking even more specific + subjectAlternativeName extensions where appropriate for using the + protocol (e.g., uniformResourceIdentifier and the otherName form + SRVName). + + o Move away from the issuance of so-called wildcard certificates + (e.g., a certificate containing an identifier for + "*.example.com"). + + These suggestions are not entirely consistent with all practices that + are currently followed by certification authorities, client + developers, and service providers. However, they reflect the best + aspects of current practices and are expected to become more widely + adopted in the coming years. + +1.6. Generalization from Current Technologies + + This document attempts to generalize best practices from the many + application technologies that currently use PKIX certificates with + TLS. Such technologies include, but are not limited to: + + o The Internet Message Access Protocol [IMAP] and the Post Office + Protocol [POP3]; see also [USINGTLS] + + o The Hypertext Transfer Protocol [HTTP]; see also [HTTP-TLS] + + o The Lightweight Directory Access Protocol [LDAP]; see also + [LDAP-AUTH] and its predecessor [LDAP-TLS] + + o The Simple Mail Transfer Protocol [SMTP]; see also [SMTP-AUTH] and + [SMTP-TLS] + + o The Extensible Messaging and Presence Protocol [XMPP]; see also + [XMPP-OLD] + + o The Network News Transfer Protocol [NNTP]; see also [NNTP-TLS] + + o The NETCONF Configuration Protocol [NETCONF]; see also + [NETCONF-SSH] and [NETCONF-TLS] + + o The Syslog Protocol [SYSLOG]; see also [SYSLOG-TLS] and + [SYSLOG-DTLS] + + o The Session Initiation Protocol [SIP]; see also [SIP-CERTS] + + o The Simple Network Management Protocol [SNMP]; see also [SNMP-TLS] + + o The General Internet Signalling Transport [GIST] + + + +Saint-Andre & Hodges Standards Track [Page 6] + +RFC 6125 Service Identity March 2011 + + + However, as noted, this document does not supersede the rules for + verifying service identity provided in specifications for those + application protocols. + +1.7. Scope + +1.7.1. In Scope + + This document applies only to service identities associated with + fully qualified DNS domain names, only to TLS and DTLS (or the older + Secure Sockets Layer (SSL) technology), and only to PKIX-based + systems. As a result, the scenarios described in the following + section are out of scope for this specification (although they might + be addressed by future specifications). + +1.7.2. Out of Scope + + The following topics are out of scope for this specification: + + o Client or end-user identities. + + Certificates representing client or end-user identities (e.g., the + rfc822Name identifier) can be used for mutual authentication + between a client and server or between two clients, thus enabling + stronger client-server security or end-to-end security. However, + certification authorities, application developers, and service + operators have less experience with client certificates than with + server certificates, thus giving us fewer models from which to + generalize and a less solid basis for defining best practices. + + o Identifiers other than fully qualified DNS domain names. + + Some certification authorities issue server certificates based on + IP addresses, but preliminary evidence indicates that such + certificates are a very small percentage (less than 1%) of issued + certificates. Furthermore, IP addresses are not necessarily + reliable identifiers for application services because of the + existence of private internets [PRIVATE], host mobility, multiple + interfaces on a given host, Network Address Translators (NATs) + resulting in different addresses for a host from different + locations on the network, the practice of grouping many hosts + together behind a single IP address, etc. Most fundamentally, + most users find DNS domain names much easier to work with than IP + addresses, which is why the domain name system was designed in the + first place. We prefer to define best practices for the much more + common use case and not to complicate the rules in this + specification. + + + + +Saint-Andre & Hodges Standards Track [Page 7] + +RFC 6125 Service Identity March 2011 + + + Furthermore, we focus here on application service identities, not + specific resources located at such services. Therefore this + document discusses Uniform Resource Identifiers [URI] only as a + way to communicate a DNS domain name (via the URI "host" component + or its equivalent), not as a way to communicate other aspects of a + service such as a specific resource (via the URI "path" component) + or parameters (via the URI "query" component). + + We also do not discuss attributes unrelated to DNS domain names, + such as those defined in [X.520] and other such specifications + (e.g., organizational attributes, geographical attributes, company + logos, and the like). + + o Security protocols other than [TLS], [DTLS], or the older Secure + Sockets Layer (SSL) technology. + + Although other secure, lower-layer protocols exist and even employ + PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases + can differ from those of TLS-based and DTLS-based application + technologies. Furthermore, application technologies have less + experience with IPsec than with TLS, thus making it more difficult + to gather feedback on proposed best practices. + + o Keys or certificates employed outside the context of PKIX-based + systems. + + Some deployed application technologies use a web of trust model + based on or similar to OpenPGP [OPENPGP], or use self-signed + certificates, or are deployed on networks that are not directly + connected to the public Internet and therefore cannot depend on + Certificate Revocation Lists (CRLs) or the Online Certificate + Status Protocol [OCSP] to check CA-issued certificates. However, + the method for binding a public key to an identifier in OpenPGP + differs essentially from the method in X.509, the data in self- + signed certificates has not been certified by a third party in any + way, and checking of CA-issued certificates via CRLs or OCSP is + critically important to maintaining the security of PKIX-based + systems. Attempting to define best practices for such + technologies would unduly complicate the rules defined in this + specification. + + o Certification authority policies, such as: + + * What types or "classes" of certificates to issue and whether to + apply different policies for them (e.g., allow the wildcard + character in certificates issued to individuals who have + provided proof of identity but do not allow the wildcard + character in "Extended Validation" certificates [EV-CERTS]). + + + +Saint-Andre & Hodges Standards Track [Page 8] + +RFC 6125 Service Identity March 2011 + + + * Whether to issue certificates based on IP addresses (or some + other form, such as relative domain names) in addition to fully + qualified DNS domain names. + + * Which identifiers to include (e.g., whether to include SRV-IDs + or URI-IDs as defined in the body of this specification). + + * How to certify or validate fully qualified DNS domain names and + application service types. + + * How to certify or validate other kinds of information that + might be included in a certificate (e.g., organization name). + + o Resolution of DNS domain names. + + Although the process whereby a client resolves the DNS domain name + of an application service can involve several steps (e.g., this is + true of resolutions that depend on DNS SRV resource records, + Naming Authority Pointer (NAPTR) DNS resource records [NAPTR], and + related technologies such as [S-NAPTR]), for our purposes we care + only about the fact that the client needs to verify the identity + of the entity with which it communicates as a result of the + resolution process. Thus the resolution process itself is out of + scope for this specification. + + o User interface issues. + + In general, such issues are properly the responsibility of client + software developers and standards development organizations + dedicated to particular application technologies (see, for + example, [WSC-UI]). + +1.8. Terminology + + Because many concepts related to "identity" are often too vague to be + actionable in application protocols, we define a set of more concrete + terms for use in this specification. + + application service: A service on the Internet that enables + interactive and automated clients to connect for the purpose of + retrieving or uploading information, communicating with other + entities, or connecting to a broader network of services. + + application service provider: An organization or individual that + hosts or deploys an application service. + + + + + + +Saint-Andre & Hodges Standards Track [Page 9] + +RFC 6125 Service Identity March 2011 + + + application service type: A formal identifier for the application + protocol used to provide a particular kind of application service + at a domain; the application service type typically takes the form + of a Uniform Resource Identifier scheme [URI] or a DNS SRV Service + [DNS-SRV]. + + attribute-type-and-value pair: A colloquial name for the ASN.1-based + construction comprising a Relative Distinguished Name (RDN), which + itself is a building-block component of Distinguished Names. See + Section 2 of [LDAP-DN]. + + automated client: A software agent or device that is not directly + controlled by a human user. + + delegated domain: A domain name or host name that is explicitly + configured for communicating with the source domain, by either (a) + the human user controlling an interactive client or (b) a trusted + administrator. In case (a), one example of delegation is an + account setup that specifies the domain name of a particular host + to be used for retrieving information or connecting to a network, + which might be different from the server portion of the user's + account name (e.g., a server at mailhost.example.com for + connecting to an IMAP server hosting an email address of + juliet@example.com). In case (b), one example of delegation is an + admin-configured host-to-address/address-to-host lookup table. + + derived domain: A domain name or host name that a client has derived + from the source domain in an automated fashion (e.g., by means of + a [DNS-SRV] lookup). + + identifier: A particular instance of an identifier type that is + either presented by a server in a certificate or referenced by a + client for matching purposes. + + identifier type: A formally defined category of identifier that can + be included in a certificate and therefore that can also be used + for matching purposes. For conciseness and convenience, we define + the following identifier types of interest, which are based on + those found in the PKIX specification [PKIX] and various PKIX + extensions. + + * CN-ID = a Relative Distinguished Name (RDN) in the certificate + subject field that contains one and only one attribute-type- + and-value pair of type Common Name (CN), where the value + matches the overall form of a domain name (informally, dot- + separated letter-digit-hyphen labels); see [PKIX] and also + [LDAP-SCHEMA] + + + + +Saint-Andre & Hodges Standards Track [Page 10] + +RFC 6125 Service Identity March 2011 + + + * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX] + + * SRV-ID = a subjectAltName entry of type otherName whose name + form is SRVName; see [SRVNAME] + + * URI-ID = a subjectAltName entry of type + uniformResourceIdentifier whose value includes both (i) a + "scheme" and (ii) a "host" component (or its equivalent) that + matches the "reg-name" rule (where the quoted terms represent + the associated [ABNF] productions from [URI]); see [PKIX] and + [URI] + + interactive client: A software agent or device that is directly + controlled by a human user. (Other specifications related to + security and application protocols, such as [WSC-UI], often refer + to this entity as a "user agent".) + + pinning: The act of establishing a cached name association between + the application service's certificate and one of the client's + reference identifiers, despite the fact that none of the presented + identifiers matches the given reference identifier. Pinning is + accomplished by allowing a human user to positively accept the + mismatch during an attempt to communicate with the application + service. Once a cached name association is established, the + certificate is said to be pinned to the reference identifier and + in future communication attempts the client simply verifies that + the service's presented certificate matches the pinned + certificate, as described under Section 6.6.2. (A similar + definition of "pinning" is provided in [WSC-UI].) + + PKIX: PKIX is a short name for the Internet Public Key + Infrastructure using X.509 defined in RFC 5280 [PKIX], which + comprises a profile of the X.509v3 certificate specifications and + X.509v2 certificate revocation list (CRL) specifications for use + in the Internet. + + PKIX-based system: A software implementation or deployed service + that makes use of X.509v3 certificates and X.509v2 certificate + revocation lists (CRLs). + + PKIX certificate: An X.509v3 certificate generated and employed in + the context of PKIX. + + presented identifier: An identifier that is presented by a server to + a client within a PKIX certificate when the client attempts to + establish secure communication with the server; the certificate + can include one or more presented identifiers of different types, + + + + +Saint-Andre & Hodges Standards Track [Page 11] + +RFC 6125 Service Identity March 2011 + + + and if the server hosts more than one domain then the certificate + might present distinct identifiers for each domain. + + reference identifier: An identifier, constructed from a source + domain and optionally an application service type, used by the + client for matching purposes when examining presented identifiers. + + source domain: The fully qualified DNS domain name that a client + expects an application service to present in the certificate + (e.g., "www.example.com"), typically input by a human user, + configured into a client, or provided by reference such as in a + hyperlink. The combination of a source domain and, optionally, an + application service type enables a client to construct one or more + reference identifiers. + + subjectAltName entry: An identifier placed in a subjectAltName + extension. + + subjectAltName extension: A standard PKIX certificate extension + [PKIX] enabling identifiers of various types to be bound to the + certificate subject -- in addition to, or in place of, identifiers + that may be embedded within or provided as a certificate's subject + field. + + subject field: The subject field of a PKIX certificate identifies + the entity associated with the public key stored in the subject + public key field (see Section 4.1.2.6 of [PKIX]). + + subject name: In an overall sense, a subject's name(s) can be + represented by or in the subject field, the subjectAltName + extension, or both (see [PKIX] for details). More specifically, + the term often refers to the name of a PKIX certificate's subject, + encoded as the X.501 type Name and conveyed in a certificate's + subject field (see Section 4.1.2.6 of [PKIX]). + + TLS client: An entity that assumes the role of a client in a + Transport Layer Security [TLS] negotiation. In this specification + we generally assume that the TLS client is an (interactive or + automated) application client; however, in application protocols + that enable server-to-server communication, the TLS client could + be a peer application service. + + TLS server: An entity that assumes the role of a server in a + Transport Layer Security [TLS] negotiation; in this specification + we assume that the TLS server is an application service. + + + + + + +Saint-Andre & Hodges Standards Track [Page 12] + +RFC 6125 Service Identity March 2011 + + + Most security-related terms in this document are to be understood in + the sense defined in [SECTERMS]; such terms include, but are not + limited to, "attack", "authentication", "authorization", + "certification authority", "certification path", "certificate", + "credential", "identity", "self-signed certificate", "trust", "trust + anchor", "trust chain", "validate", and "verify". + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [KEYWORDS]. + +2. Naming of Application Services + + This section discusses naming of application services on the + Internet, followed by a brief tutorial about subject naming in PKIX. + +2.1. Naming Application Services + + This specification assumes that the name of an application service is + based on a DNS domain name (e.g., "example.com") -- supplemented in + some circumstances by an application service type (e.g., "the IMAP + server at example.com"). + + From the perspective of the application client or user, some names + are direct because they are provided directly by a human user (e.g., + via runtime input, prior configuration, or explicit acceptance of a + client communication attempt), whereas other names are indirect + because they are automatically resolved by the client based on user + input (e.g., a target name resolved from a source name using DNS SRV + or NAPTR records). This dimension matters most for certificate + consumption, specifically verification as discussed in this document. + + From the perspective of the application service, some names are + unrestricted because they can be used in any type of service (e.g., a + certificate might be reused for both the HTTP service and the IMAP + service at example.com), whereas other names are restricted because + they can be used in only one type of service (e.g., a special-purpose + certificate that can be used only for an IMAP service). This + dimension matters most for certificate issuance. + + Therefore, we can categorize the identifier types of interest as + follows: + + o A CN-ID is direct and unrestricted. + + o A DNS-ID is direct and unrestricted. + + + + +Saint-Andre & Hodges Standards Track [Page 13] + +RFC 6125 Service Identity March 2011 + + + o An SRV-ID can be either direct or (more typically) indirect, and + is restricted. + + o A URI-ID is direct and restricted. + + We summarize this taxonomy in the following table. + + +-----------+-----------+---------------+ + | | Direct | Restricted | + +-----------+-----------+---------------+ + | CN-ID | Yes | No | + +-----------+-----------+---------------+ + | DNS-ID | Yes | No | + +-----------+-----------+---------------+ + | SRV-ID | Either | Yes | + +-----------+-----------+---------------+ + | URI-ID | Yes | Yes | + +-----------+-----------+---------------+ + + When implementing software, deploying services, and issuing + certificates for secure PKIX-based authentication, it is important to + keep these distinctions in mind. In particular, best practices + differ somewhat for application server implementations, application + client implementations, application service providers, and + certification authorities. Ideally, protocol specifications that + reference this document will specify which identifiers are mandatory- + to-implement by servers and clients, which identifiers ought to be + supported by certificate issuers, and which identifiers ought to be + requested by application service providers. Because these + requirements differ across applications, it is impossible to + categorically stipulate universal rules (e.g., that all software + implementations, service providers, and certification authorities for + all application protocols need to use or support DNS-IDs as a + baseline for the purpose of interoperability). + + However, it is preferable that each application protocol will at + least define a baseline that applies to the community of software + developers, application service providers, and CAs actively using or + supporting that technology (one such community, the CA/Browser Forum, + has codified such a baseline for "Extended Validation Certificates" + in [EV-CERTS]). + +2.2. DNS Domain Names + + For the purposes of this specification, the name of an application + service is (or is based on) a DNS domain name that conforms to one of + the following forms: + + + + +Saint-Andre & Hodges Standards Track [Page 14] + +RFC 6125 Service Identity March 2011 + + + 1. A "traditional domain name", i.e., a fully qualified DNS domain + name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH + labels" as described in [IDNA-DEFS]. Informally, such labels are + constrained to [US-ASCII] letters, digits, and the hyphen, with + the hyphen prohibited in the first character position. + Additional qualifications apply (please refer to the above- + referenced specifications for details), but they are not relevant + to this specification. + + 2. An "internationalized domain name", i.e., a DNS domain name that + conforms to the overall form of a domain name (informally, dot- + separated letter-digit-hyphen labels) but includes at least one + label containing appropriately encoded Unicode code points + outside the traditional US-ASCII range. That is, it contains at + least one U-label or A-label, but otherwise may contain any + mixture of NR-LDH labels, A-labels, or U-labels, as described in + [IDNA-DEFS] and the associated documents. + +2.3. Subject Naming in PKIX Certificates + + In theory, the Internet Public Key Infrastructure using X.509 [PKIX] + employs the global directory service model defined in [X.500] and + [X.501]. Under that model, information is held in a directory + information base (DIB) and entries in the DIB are organized in a + hierarchy called the directory information tree (DIT). An object or + alias entry in that hierarchy consists of a set of attributes (each + of which has a defined type and one or more values) and is uniquely + identified by a Distinguished Name (DN). The DN of an entry is + constructed by combining the Relative Distinguished Names of its + superior entries in the tree (all the way down to the root of the + DIT) with one or more specially nominated attributes of the entry + itself (which together comprise the Relative Distinguished Name (RDN) + of the entry, so-called because it is relative to the Distinguished + Names of the superior entries in the tree). The entry closest to the + root is sometimes referred to as the "most significant" entry, and + the entry farthest from the root is sometimes referred to as the + "least significant" entry. An RDN is a set (i.e., an unordered + group) of attribute-type-and-value pairs (see also [LDAP-DN]), each + of which asserts some attribute about the entry. + + In practice, the certificates used in [X.509] and [PKIX] borrow key + concepts from X.500 and X.501 (e.g., DNs and RDNs) to identify + entities, but such certificates are not necessarily part of a global + directory information base. Specifically, the subject field of a + PKIX certificate is an X.501 type Name that "identifies the entity + associated with the public key stored in the subject public key + field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly + acceptable for the subject field to be empty, as long as the + + + +Saint-Andre & Hodges Standards Track [Page 15] + +RFC 6125 Service Identity March 2011 + + + certificate contains a subject alternative name ("subjectAltName") + extension that includes at least one subjectAltName entry, because + the subjectAltName extension allows various identities to be bound to + the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName + extension itself is a sequence of typed entries, where each type is a + distinct kind of identifier. + + For our purposes, an application service can be identified by a name + or names carried in the subject field (i.e., a CN-ID) and/or in one + of the following identifier types within subjectAltName entries: + + o DNS-ID + + o SRV-ID + + o URI-ID + + Existing certificates often use a CN-ID in the subject field to + represent a fully qualified DNS domain name; for example, consider + the following three subject names, where the attribute of type Common + Name contains a string whose form matches that of a fully qualified + DNS domain name ("im.example.org", "mail.example.net", and + "www.example.com", respectively): + + CN=im.example.org,O=Example Org,C=GB + + C=CA,O=Example Internetworking,CN=mail.example.net + + O=Examples-R-Us,CN=www.example.com,C=US + + However, the Common Name is not strongly typed because a Common Name + might contain a human-friendly string for the service, rather than a + string whose form matches that of a fully qualified DNS domain name + (a certificate with such a single Common Name will typically have at + least one subjectAltName entry containing the fully qualified DNS + domain name): + + CN=A Free Chat Service,O=Example Org,C=GB + + Or, a certificate's subject might contain both a CN-ID as well as + another common name attribute containing a human-friendly string: + + CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB + + In general, this specification recommends and prefers use of + subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the + subject field (CN-ID) where possible, as more completely described in + the following sections. However, specifications that reuse this one + + + +Saint-Andre & Hodges Standards Track [Page 16] + +RFC 6125 Service Identity March 2011 + + + can legitimately encourage continued support for the CN-ID identifier + type if they have good reasons to do so, such as backward + compatibility with deployed infrastructure (see, for example, + [EV-CERTS]). + +2.3.1. Implementation Notes + + Confusion sometimes arises from different renderings or encodings of + the hierarchical information contained in a certificate. + + Certificates are binary objects and are encoded using the + Distinguished Encoding Rules (DER) specified in [X.690]. However, + some implementations generate displayable (a.k.a. printable) + renderings of the certificate issuer, subject field, and + subjectAltName extension, and these renderings convert the DER- + encoded sequences into a "string representation" before being + displayed. Because a certificate subject field (of type Name + [X.509], the same as for a Distinguished Name (DN) [X.501]) is an + ordered sequence, order is typically preserved in subject string + representations, although the two most prevalent subject (and DN) + string representations differ in employing left-to-right vs. right- + to-left ordering. However, because a Relative Distinguished Name + (RDN) is an unordered group of attribute-type-and-value pairs, the + string representation of an RDN can differ from the canonical DER + encoding (and the order of attribute-type-and-value pairs can differ + in the RDN string representations or display orders provided by + various implementations). Furthermore, various specifications refer + to the order of RDNs in DNs or certificate subject fields using + terminology that is implicitly related to an information hierarchy + (which may or may not actually exist), such as "most specific" vs. + "least specific", "left-most" vs. "right-most", "first" vs. "last", + or "most significant" vs. "least significant" (see, for example, + [LDAP-DN]). + + To reduce confusion, in this specification we avoid such terms and + instead use the terms provided under Section 1.8; in particular, we + do not use the term "(most specific) Common Name field in the subject + field" from [HTTP-TLS] and instead state that a CN-ID is a Relative + Distinguished Name (RDN) in the certificate subject containing one + and only one attribute-type-and-value pair of type Common Name (thus + removing the possibility that an RDN might contain multiple AVAs + (Attribute Value Assertions) of type CN, one of which could be + considered "most specific"). + + Finally, although theoretically some consider the order of RDNs + within a subject field to have meaning, in practice that rule is + often not observed. An AVA of type CN is considered to be valid at + any position within the subject field. + + + +Saint-Andre & Hodges Standards Track [Page 17] + +RFC 6125 Service Identity March 2011 + + +3. Designing Application Protocols + + This section provides guidelines for designers of application + protocols, in the form of a checklist to follow when reusing the + recommendations provided in this document. + + o Does your technology use DNS SRV records to resolve the DNS domain + names of application services? If so, consider recommending or + requiring support for the SRV-ID identifier type in PKIX + certificates issued and used in your technology community. (Note + that many existing application technologies use DNS SRV records to + resolve the DNS domain names of application services, but do not + rely on representations of those records in PKIX certificates by + means of SRV-IDs as defined in [SRVNAME].) + + o Does your technology use URIs to identify application services? + If so, consider recommending or requiring support for the URI-ID + identifier type. (Note that many existing application + technologies use URIs to identify application services, but do not + rely on representation of those URIs in PKIX certificates by means + of URI-IDs.) + + o Does your technology need to use DNS domain names in the Common + Name of certificates for the sake of backward compatibility? If + so, consider recommending support for the CN-ID identifier type as + a fallback. + + o Does your technology need to allow the wildcard character in DNS + domain names? If so, consider recommending support for wildcard + certificates, and specify exactly where the wildcard character is + allowed to occur (e.g., only the complete left-most label of a DNS + domain name). + + Sample text is provided under Appendix A. + +4. Representing Server Identity + + This section provides rules and guidelines for issuers of + certificates. + +4.1. Rules + + When a certification authority issues a certificate based on the + fully qualified DNS domain name at which the application service + provider will provide the relevant application, the following rules + apply to the representation of application service identities. The + + + + + +Saint-Andre & Hodges Standards Track [Page 18] + +RFC 6125 Service Identity March 2011 + + + reader needs to be aware that some of these rules are cumulative and + can interact in important ways that are illustrated later in this + document. + + 1. The certificate SHOULD include a "DNS-ID" if possible as a + baseline for interoperability. + + 2. If the service using the certificate deploys a technology for + which the relevant specification stipulates that certificates + ought to include identifiers of type SRV-ID (e.g., this is true + of [XMPP]), then the certificate SHOULD include an SRV-ID. + + 3. If the service using the certificate deploys a technology for + which the relevant specification stipulates that certificates + ought to include identifiers of type URI-ID (e.g., this is true + of [SIP] as specified by [SIP-CERTS], but not true of [HTTP] + since [HTTP-TLS] does not describe usage of a URI-ID for HTTP + services), then the certificate SHOULD include a URI-ID. The + scheme SHALL be that of the protocol associated with the + application service type and the "host" component (or its + equivalent) SHALL be the fully qualified DNS domain name of the + service. A specification that reuses this one MUST specify which + URI schemes are to be considered acceptable in URI-IDs contained + in PKIX certificates used for the application protocol (e.g., + "sip" but not "sips" or "tel" for SIP as described in [SIP-SIPS], + or perhaps http and https for HTTP as might be described in a + future specification). + + 4. The certificate MAY include other application-specific + identifiers for types that were defined before publication of + [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names + or URI schemes do not exist; however, such application-specific + identifiers are not applicable to all application technologies + and therefore are out of scope for this specification. + + 5. Even though many deployed clients still check for the CN-ID + within the certificate subject field, certification authorities + are encouraged to migrate away from issuing certificates that + represent the server's fully qualified DNS domain name in a + CN-ID. Therefore, the certificate SHOULD NOT include a CN-ID + unless the certification authority issues the certificate in + accordance with a specification that reuses this one and that + explicitly encourages continued support for the CN-ID identifier + type in the context of a given application technology. + + 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or + URI-ID but SHOULD NOT contain more than one CN-ID, as further + explained under Section 7.4. + + + +Saint-Andre & Hodges Standards Track [Page 19] + +RFC 6125 Service Identity March 2011 + + + 7. Unless a specification that reuses this one allows continued + support for the wildcard character '*', the DNS domain name + portion of a presented identifier SHOULD NOT contain the wildcard + character, whether as the complete left-most label within the + identifier (following the description of labels and domain names + in [DNS-CONCEPTS], e.g., "*.example.com") or as a fragment + thereof (e.g., *oo.example.com, f*o.example.com, or + fo*.example.com). A more detailed discussion of so-called + "wildcard certificates" is provided under Section 7.2. + +4.2. Examples + + Consider a simple website at "www.example.com", which is not + discoverable via DNS SRV lookups. Because HTTP does not specify the + use of URIs in server certificates, a certificate for this service + might include only a DNS-ID of "www.example.com". It might also + include a CN-ID of "www.example.com" for backward compatibility with + deployed infrastructure. + + Consider an IMAP-accessible email server at the host + "mail.example.net" servicing email addresses of the form + "user@example.net" and discoverable via DNS SRV lookups on the + application service name of "example.net". A certificate for this + service might include SRV-IDs of "_imap.example.net" and + "_imaps.example.net" (see [EMAIL-SRV]) along with DNS-IDs of + "example.net" and "mail.example.net". It might also include CN-IDs + of "example.net" and "mail.example.net" for backward compatibility + with deployed infrastructure. + + Consider a SIP-accessible voice-over-IP (VoIP) server at the host + "voice.example.edu" servicing SIP addresses of the form + "user@voice.example.edu" and identified by a URI of . A certificate for this service would include a + URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]) along with a + DNS-ID of "voice.example.edu". It might also include a CN-ID of + "voice.example.edu" for backward compatibility with deployed + infrastructure. + + Consider an XMPP-compatible instant messaging (IM) server at the host + "im.example.org" servicing IM addresses of the form + "user@im.example.org" and discoverable via DNS SRV lookups on the + "im.example.org" domain. A certificate for this service might + include SRV-IDs of "_xmpp-client.im.example.org" and + "_xmpp-server.im.example.org" (see [XMPP]), a DNS-ID of + "im.example.org", and an XMPP-specific "XmppAddr" of "im.example.org" + (see [XMPP]). It might also include a CN-ID of "im.example.org" for + backward compatibility with deployed infrastructure. + + + + +Saint-Andre & Hodges Standards Track [Page 20] + +RFC 6125 Service Identity March 2011 + + +5. Requesting Server Certificates + + This section provides rules and guidelines for service providers + regarding the information to include in certificate signing requests + (CSRs). + + In general, service providers are encouraged to request certificates + that include all of the identifier types that are required or + recommended for the application service type that will be secured + using the certificate to be issued. + + If the certificate might be used for any type of application service, + then the service provider is encouraged to request a certificate that + includes only a DNS-ID. + + If the certificate will be used for only a single type of application + service, then the service provider is encouraged to request a + certificate that includes a DNS-ID and, if appropriate for the + application service type, an SRV-ID or URI-ID that limits the + deployment scope of the certificate to only the defined application + service type. + + If a service provider offering multiple application service types + (e.g., a World Wide Web service, an email service, and an instant + messaging service) wishes to limit the applicability of certificates + using SRV-IDs or URI-IDs, then the service provider is encouraged to + request multiple certificates, i.e., one certificate per application + service type. Conversely, the service provider is discouraged from + requesting a single certificate containing multiple SRV-IDs or URI- + IDs identifying each different application service type. This + guideline does not apply to application service type "bundles" that + are used to identify manifold distinct access methods to the same + underlying application (e.g., an email application with access + methods denoted by the application service types of "imap", "imaps", + "pop3", "pop3s", and "submission" as described in [EMAIL-SRV]). + +6. Verifying Service Identity + + This section provides rules and guidelines for implementers of + application client software regarding algorithms for verification of + application service identity. + +6.1. Overview + + At a high level, the client verifies the application service's + identity by performing the actions listed below (which are defined in + the following subsections of this document): + + + + +Saint-Andre & Hodges Standards Track [Page 21] + +RFC 6125 Service Identity March 2011 + + + 1. The client constructs a list of acceptable reference identifiers + based on the source domain and, optionally, the type of service + to which the client is connecting. + + 2. The server provides its identifiers in the form of a PKIX + certificate. + + 3. The client checks each of its reference identifiers against the + presented identifiers for the purpose of finding a match. + + 4. When checking a reference identifier against a presented + identifier, the client matches the source domain of the + identifiers and, optionally, their application service type. + + Naturally, in addition to checking identifiers, a client might + complete further checks to ensure that the server is authorized to + provide the requested service. However, such checking is not a + matter of verifying the application service identity presented in a + certificate, and therefore methods for doing so (e.g., consulting + local policy information) are out of scope for this document. + +6.2. Constructing a List of Reference Identifiers + +6.2.1. Rules + + The client MUST construct a list of acceptable reference identifiers, + and MUST do so independently of the identifiers presented by the + service. + + The inputs used by the client to construct its list of reference + identifiers might be a URI that a user has typed into an interface + (e.g., an HTTPS URL for a website), configured account information + (e.g., the domain name of a particular host or URI used for + retrieving information or connecting to a network, which might be + different from the DNS domain name portion of a username), a + hyperlink in a web page that triggers a browser to retrieve a media + object or script, or some other combination of information that can + yield a source domain and an application service type. + + The client might need to extract the source domain and application + service type from the input(s) it has received. The extracted data + MUST include only information that can be securely parsed out of the + inputs (e.g., parsing the fully qualified DNS domain name out of the + "host" component (or its equivalent) of a URI or deriving the + application service type from the scheme of a URI) or information + that is derived in a manner not subject to subversion by network + attackers (e.g., pulling the data from a delegated domain that is + explicitly established via client or system configuration, resolving + + + +Saint-Andre & Hodges Standards Track [Page 22] + +RFC 6125 Service Identity March 2011 + + + the data via [DNSSEC], or obtaining the data from a third-party + domain mapping service in which a human user has explicitly placed + trust and with which the client communicates over a connection or + association that provides both mutual authentication and integrity + checking). These considerations apply only to extraction of the + source domain from the inputs; naturally, if the inputs themselves + are invalid or corrupt (e.g., a user has clicked a link provided by a + malicious entity in a phishing attack), then the client might end up + communicating with an unexpected application service. + + Example: Given an input URI of , a client + would derive the application service type "sip" from the "scheme" + and parse the domain name "example.net" from the "host" component + (or its equivalent). + + Each reference identifier in the list SHOULD be based on the source + domain and SHOULD NOT be based on a derived domain (e.g., a host name + or domain name discovered through DNS resolution of the source + domain). This rule is important because only a match between the + user inputs and a presented identifier enables the client to be sure + that the certificate can legitimately be used to secure the client's + communication with the server. There is only one scenario in which + it is acceptable for an interactive client to override the + recommendation in this rule and therefore communicate with a domain + name other than the source domain: because a human user has "pinned" + the application service's certificate to the alternative domain name + as further discussed under Section 6.6.4 and Section 7.1. In this + case, the inputs used by the client to construct its list of + reference identifiers might include more than one fully qualified DNS + domain name, i.e., both (a) the source domain and (b) the alternative + domain contained in the pinned certificate. + + Using the combination of fully qualified DNS domain name(s) and + application service type, the client constructs a list of reference + identifiers in accordance with the following rules: + + o The list SHOULD include a DNS-ID. A reference identifier of type + DNS-ID can be directly constructed from a fully qualified DNS + domain name that is (a) contained in or securely derived from the + inputs (i.e., the source domain), or (b) explicitly associated + with the source domain by means of user configuration (i.e., a + derived domain). + + o If a server for the application service type is typically + discovered by means of DNS SRV records, then the list SHOULD + include an SRV-ID. + + + + + +Saint-Andre & Hodges Standards Track [Page 23] + +RFC 6125 Service Identity March 2011 + + + o If a server for the application service type is typically + associated with a URI for security purposes (i.e., a formal + protocol document specifies the use of URIs in server + certificates), then the list SHOULD include a URI-ID. + + o The list MAY include a CN-ID, mainly for the sake of backward + compatibility with deployed infrastructure. + + Which identifier types a client includes in its list of reference + identifiers is a matter of local policy. For example, in certain + deployment environments, a client that is built to connect only to a + particular kind of service (e.g., only IM services) might be + configured to accept as valid only certificates that include an + SRV-ID for that application service type; in this case, the client + would include only SRV-IDs matching the application service type in + its list of reference identifiers (not, for example, DNS-IDs). By + contrast, a more lenient client (even one built to connect only to a + particular kind of service) might include both SRV-IDs and DNS-IDs in + its list of reference identifiers. + + Implementation Note: It is highly likely that implementers of + client software will need to support CN-IDs for the foreseeable + future, because certificates containing CN-IDs are so widely + deployed. Implementers are advised to monitor the state of the + art with regard to certificate issuance policies and migrate away + from support CN-IDs in the future if possible. + + Implementation Note: The client does not need to construct the + foregoing identifiers in the actual formats found in a certificate + (e.g., as ASN.1 types); it only needs to construct the functional + equivalent of such identifiers for matching purposes. + + Security Warning: A client MUST NOT construct a reference + identifier corresponding to Relative Distinguished Names (RDNs) + other than those of type Common Name and MUST NOT check for RDNs + other than those of type Common Name in the presented identifiers. + +6.2.2. Examples + + A web browser that is connecting via HTTPS to the website at + "www.example.com" might have two reference identifiers: a DNS-ID of + "www.example.com" and, as a fallback, a CN-ID of "www.example.com". + + A mail user agent that is connecting via IMAPS to the email service + at "example.net" (resolved as "mail.example.net") might have five + reference identifiers: an SRV-ID of "_imaps.example.net" (see + [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, + as a fallback, CN-IDs of "example.net" and "mail.example.net". (A + + + +Saint-Andre & Hodges Standards Track [Page 24] + +RFC 6125 Service Identity March 2011 + + + legacy email user agent would not support [EMAIL-SRV] and therefore + would probably be explicitly configured to connect to + "mail.example.net", whereas an SRV-aware user agent would derive + "example.net" from an email address of the form "user@example.net" + but might also accept "mail.example.net" as the DNS domain name + portion of reference identifiers for the service.) + + A voice-over-IP (VoIP) user agent that is connecting via SIP to the + voice service at "voice.example.edu" might have only one reference + identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). + + An instant messaging (IM) client that is connecting via XMPP to the + IM service at "im.example.org" might have three reference + identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), + a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of + "im.example.org" (see [XMPP]). + +6.3. Preparing to Seek a Match + + Once the client has constructed its list of reference identifiers and + has received the server's presented identifiers in the form of a PKIX + certificate, the client checks its reference identifiers against the + presented identifiers for the purpose of finding a match. The search + fails if the client exhausts its list of reference identifiers + without finding a match. The search succeeds if any presented + identifier matches one of the reference identifiers, at which point + the client SHOULD stop the search. + + Implementation Note: A client might be configured to perform + multiple searches, i.e., to match more than one reference + identifier. Although such behavior is not forbidden by this + specification, rules for matching multiple reference identifiers + are a matter for implementation or future specification. + + Security Warning: A client MUST NOT seek a match for a reference + identifier of CN-ID if the presented identifiers include a DNS-ID, + SRV-ID, URI-ID, or any application-specific identifier types + supported by the client. + + Before applying the comparison rules provided in the following + sections, the client might need to split the reference identifier + into its DNS domain name portion and its application service type + portion, as follows: + + o A reference identifier of type DNS-ID does not include an + application service type portion and thus can be used directly as + the DNS domain name for comparison purposes. As an example, a + + + + +Saint-Andre & Hodges Standards Track [Page 25] + +RFC 6125 Service Identity March 2011 + + + DNS-ID of "www.example.com" would result in a DNS domain name + portion of "www.example.com". + + o A reference identifier of type CN-ID also does not include an + application service type portion and thus can be used directly as + the DNS domain name for comparison purposes. As previously + mentioned, this document specifies that a CN-ID always contains a + string whose form matches that of a DNS domain name (thus + differentiating a CN-ID from a Common Name containing a human- + friendly name). + + o For a reference identifier of type SRV-ID, the DNS domain name + portion is the Name and the application service type portion is + the Service. As an example, an SRV-ID of "_imaps.example.net" + would be split into a DNS domain name portion of "example.net" and + an application service type portion of "imaps" (mapping to an + application protocol of IMAP as explained in [EMAIL-SRV]). + + o For a reference identifier of type URI-ID, the DNS domain name + portion is the "reg-name" part of the "host" component (or its + equivalent) and the application service type portion is the + application service type associated with the scheme name matching + the [ABNF] "scheme" rule from [URI] (not including the ':' + separator). As previously mentioned, this document specifies that + a URI-ID always contains a "host" component (or its equivalent) + containing a "reg-name". (Matching only the "reg-name" rule from + [URI] limits verification to DNS domain names, thereby + differentiating a URI-ID from a uniformResourceIdentifier entry + that contains an IP address or a mere host name, or that does not + contain a "host" component at all.) Furthermore, note that + extraction of the "reg-name" might necessitate normalization of + the URI (as explained in [URI]). As an example, a URI-ID of "sip: + voice.example.edu" would be split into a DNS domain name portion + of "voice.example.edu" and an application service type of "sip" + (associated with an application protocol of SIP as explained in + [SIP-CERTS]). + + Detailed comparison rules for matching the DNS domain name portion + and application service type portion of the reference identifier are + provided in the following sections. + +6.4. Matching the DNS Domain Name Portion + + The client MUST match the DNS domain name portion of a reference + identifier according to the following rules (and SHOULD also check + the application service type as described under Section 6.5). The + rules differ depending on whether the domain to be checked is a + "traditional domain name" or an "internationalized domain name" (as + + + +Saint-Andre & Hodges Standards Track [Page 26] + +RFC 6125 Service Identity March 2011 + + + defined under Section 2.2). Furthermore, to meet the needs of + clients that support presented identifiers containing the wildcard + character '*', we define a supplemental rule for so-called "wildcard + certificates". Finally, we also specify the circumstances under + which it is acceptable to check the "CN-ID" identifier type. + +6.4.1. Checking of Traditional Domain Names + + If the DNS domain name portion of a reference identifier is a + "traditional domain name", then matching of the reference identifier + against the presented identifier is performed by comparing the set of + domain name labels using a case-insensitive ASCII comparison, as + clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased + to "www.example.com" for comparison purposes). Each label MUST match + in order for the names to be considered to match, except as + supplemented by the rule about checking of wildcard labels + (Section 6.4.3). + +6.4.2. Checking of Internationalized Domain Names + + If the DNS domain name portion of a reference identifier is an + internationalized domain name, then an implementation MUST convert + any U-labels [IDNA-DEFS] in the domain name to A-labels before + checking the domain name. In accordance with [IDNA-PROTO], A-labels + MUST be compared as case-insensitive ASCII. Each label MUST match in + order for the domain names to be considered to match, except as + supplemented by the rule about checking of wildcard labels + (Section 6.4.3; but see also Section 7.2 regarding wildcards in + internationalized domain names). + +6.4.3. Checking of Wildcard Certificates + + A client employing this specification's rules MAY match the reference + identifier against a presented identifier whose DNS domain name + portion contains the wildcard character '*' as part or all of a label + (following the description of labels and domain names in + [DNS-CONCEPTS]). + + For information regarding the security characteristics of wildcard + certificates, see Section 7.2. + + If a client matches the reference identifier against a presented + identifier whose DNS domain name portion contains the wildcard + character '*', the following rules apply: + + 1. The client SHOULD NOT attempt to match a presented identifier in + which the wildcard character comprises a label other than the + left-most label (e.g., do not match bar.*.example.net). + + + +Saint-Andre & Hodges Standards Track [Page 27] + +RFC 6125 Service Identity March 2011 + + + 2. If the wildcard character is the only character of the left-most + label in the presented identifier, the client SHOULD NOT compare + against anything but the left-most label of the reference + identifier (e.g., *.example.com would match foo.example.com but + not bar.foo.example.com or example.com). + + 3. The client MAY match a presented identifier in which the wildcard + character is not the only character of the label (e.g., + baz*.example.net and *baz.example.net and b*z.example.net would + be taken to match baz1.example.net and foobaz.example.net and + buzz.example.net, respectively). However, the client SHOULD NOT + attempt to match a presented identifier where the wildcard + character is embedded within an A-label or U-label [IDNA-DEFS] of + an internationalized domain name [IDNA-PROTO]. + +6.4.4. Checking of Common Names + + As noted, a client MUST NOT seek a match for a reference identifier + of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, + URI-ID, or any application-specific identifier types supported by the + client. + + Therefore, if and only if the presented identifiers do not include a + DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types + supported by the client, then the client MAY as a last resort check + for a string whose form matches that of a fully qualified DNS domain + name in a Common Name field of the subject field (i.e., a CN-ID). If + the client chooses to compare a reference identifier of type CN-ID + against that string, it MUST follow the comparison rules for the DNS + domain name portion of an identifier of type DNS-ID, SRV-ID, or + URI-ID, as described under Section 6.4.1, Section 6.4.2, and + Section 6.4.3. + +6.5. Matching the Application Service Type Portion + + When a client checks identifiers of type SRV-ID and URI-ID, it MUST + check not only the DNS domain name portion of the identifier but also + the application service type portion. The client does this by + splitting the identifier into the DNS domain name portion and the + application service type portion (as described under Section 6.3), + then checking both the DNS domain name portion (as described under + Section 6.4) and the application service type portion as described in + the following subsections. + + Implementation Note: An identifier of type SRV-ID or URI-ID + provides an application service type portion to be checked, but + that portion is combined only with the DNS domain name portion of + the SRV-ID or URI-ID itself. For example, if a client's list of + + + +Saint-Andre & Hodges Standards Track [Page 28] + +RFC 6125 Service Identity March 2011 + + + reference identifiers includes an SRV-ID of "_xmpp- + client.im.example.org" and a DNS-ID of "apps.example.net", the + client would check (a) the combination of an application service + type of "xmpp-client" and a DNS domain name of "im.example.org" + and (b) a DNS domain name of "apps.example.net". However, the + client would not check (c) the combination of an application + service type of "xmpp-client" and a DNS domain name of + "apps.example.net" because it does not have an SRV-ID of "_xmpp- + client.apps.example.net" in its list of reference identifiers. + +6.5.1. SRV-ID + + The application service name portion of an SRV-ID (e.g., "imaps") + MUST be matched in a case-insensitive manner, in accordance with + [DNS-SRV]. Note that the "_" character is prepended to the service + identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and + thus does not need to be included in any comparison. + +6.5.2. URI-ID + + The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in + a case-insensitive manner, in accordance with [URI]. Note that the + ":" character is a separator between the scheme name and the rest of + the URI, and thus does not need to be included in any comparison. + +6.6. Outcome + + The outcome of the matching procedure is one of the following cases. + +6.6.1. Case #1: Match Found + + If the client has found a presented identifier that matches a + reference identifier, then the service identity check has succeeded. + In this case, the client MUST use the matched reference identifier as + the validated identity of the application service. + +6.6.2. Case #2: No Match Found, Pinned Certificate + + If the client does not find a presented identifier matching any of + the reference identifiers but the client has previously pinned the + application service's certificate to one of the reference identifiers + in the list it constructed for this communication attempt (as + "pinning" is explained under Section 1.8), and the presented + certificate matches the pinned certificate (including the context as + described under Section 7.1), then the service identity check has + succeeded. + + + + + +Saint-Andre & Hodges Standards Track [Page 29] + +RFC 6125 Service Identity March 2011 + + +6.6.3. Case #3: No Match Found, No Pinned Certificate + + If the client does not find a presented identifier matching any of + the reference identifiers and the client has not previously pinned + the certificate to one of the reference identifiers in the list it + constructed for this communication attempt, then the client MUST + proceed as described under Section 6.6.4. + +6.6.4. Fallback + + If the client is an interactive client that is directly controlled by + a human user, then it SHOULD inform the user of the identity mismatch + and automatically terminate the communication attempt with a bad + certificate error; this behavior is preferable because it prevents + users from inadvertently bypassing security protections in hostile + situations. + + Security Warning: Some interactive clients give advanced users the + option of proceeding with acceptance despite the identity + mismatch, thereby "pinning" the certificate to one of the + reference identifiers in the list constructed by the client for + this communication attempt. Although this behavior can be + appropriate in certain specialized circumstances, in general it + ought to be exposed only to advanced users. Even then it needs to + be handled with extreme caution, for example by first encouraging + even an advanced user to terminate the communication attempt and, + if the advanced user chooses to proceed anyway, by forcing the + user to view the entire certification path and only then allowing + the user to pin the certificate (on a temporary or permanent + basis, at the user's option). + + Otherwise, if the client is an automated application not directly + controlled by a human user, then it SHOULD terminate the + communication attempt with a bad certificate error and log the error + appropriately. An automated application MAY provide a configuration + setting that disables this behavior, but MUST enable the behavior by + default. + +7. Security Considerations + +7.1. Pinned Certificates + + As defined under Section 1.8, a certificate is said to be "pinned" to + a DNS domain name when a user has explicitly chosen to associate a + service's certificate with that DNS domain name despite the fact that + the certificate contains some other DNS domain name (e.g., the user + has explicitly approved "apps.example.net" as a domain associated + with a source domain of "example.com"). The cached name association + + + +Saint-Andre & Hodges Standards Track [Page 30] + +RFC 6125 Service Identity March 2011 + + + MUST take account of both the certificate presented and the context + in which it was accepted or configured (where the "context" includes + the chain of certificates from the presented certificate to the trust + anchor, the source domain, the application service type, the + service's derived domain and port number, and any other relevant + information provided by the user or associated by the client). + +7.2. Wildcard Certificates + + This document states that the wildcard character '*' SHOULD NOT be + included in presented identifiers but MAY be checked by application + clients (mainly for the sake of backward compatibility with deployed + infrastructure). As a result, the rules provided in this document + are more restrictive than the rules for many existing application + technologies (such as those excerpted under Appendix B). Several + security considerations justify tightening the rules: + + o Wildcard certificates automatically vouch for any and all host + names within their domain. This can be convenient for + administrators but also poses the risk of vouching for rogue or + buggy hosts. See for example [Defeating-SSL] (beginning at slide + 91) and [HTTPSbytes] (slides 38-40). + + o Specifications for existing application technologies are not clear + or consistent about the allowable location of the wildcard + character, such as whether it can be: + + * only the complete left-most label (e.g., *.example.com) + + * some fragment of the left-most label (e.g., fo*.example.com, + f*o.example.com, or *oo.example.com) + + * all or part of a label other than the left-most label (e.g., + www.*.example.com or www.foo*.example.com) + + * all or part of a label that identifies a so-called "public + suffix" (e.g., *.co.uk or *.com) + + * included more than once in a given label (e.g., + f*b*r.example.com + + * included as all or part of more than one label (e.g., + *.*.example.com) + + These ambiguities might introduce exploitable differences in + identity checking behavior among client implementations and + necessitate overly complex and inefficient identity checking + algorithms. + + + +Saint-Andre & Hodges Standards Track [Page 31] + +RFC 6125 Service Identity March 2011 + + + o There is no specification that defines how the wildcard character + may be embedded within the A-labels or U-labels [IDNA-DEFS] of an + internationalized domain name [IDNA-PROTO]; as a result, + implementations are strongly discouraged from including or + attempting to check for the wildcard character embedded within the + A-labels or U-labels of an internationalized domain name (e.g., + "xn--kcry6tjko*.example.org"). Note, however, that a presented + domain name identifier MAY contain the wildcard character as long + as that character occupies the entire left-most label position, + where all of the remaining labels are valid NR-LDH labels, + A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org"). + + Notwithstanding the foregoing security considerations, specifications + that reuse this one can legitimately encourage continued support for + the wildcard character if they have good reasons to do so, such as + backward compatibility with deployed infrastructure (see, for + example, [EV-CERTS]). + +7.3. Internationalized Domain Names + + Allowing internationalized domain names can lead to the inclusion of + visually similar (so-called "confusable") characters in certificates; + for discussion, see for example [IDNA-DEFS]. + +7.4. Multiple Identifiers + + A given application service might be addressed by multiple DNS domain + names for a variety of reasons, and a given deployment might service + multiple domains (e.g., in so-called "virtual hosting" environments). + In the default TLS handshake exchange, the client is not able to + indicate the DNS domain name with which it wants to communicate, and + the TLS server returns only one certificate for itself. Absent an + extension to TLS, a typical workaround used to facilitate mapping an + application service to multiple DNS domain names is to embed all of + the domain names into a single certificate. + + A more recent approach, formally specified in [TLS-EXT], is for the + client to use the TLS "Server Name Indication" (SNI) extension when + sending the client_hello message, stipulating the DNS domain name it + desires or expects of the service. The service can then return the + appropriate certificate in its Certificate message, and that + certificate can represent a single DNS domain name. + + To accommodate the workaround that was needed before the development + of the SNI extension, this specification allows multiple DNS-IDs, + SRV-IDs, or URI-IDs in a certificate; however, it explicitly + discourages multiple CN-IDs. Although it would be preferable to + forbid multiple CN-IDs entirely, there are several reasons at this + + + +Saint-Andre & Hodges Standards Track [Page 32] + +RFC 6125 Service Identity March 2011 + + + time why this specification states that they SHOULD NOT (instead of + MUST NOT) be included: + + o At least one significant technology community of interest + explicitly allows multiple CN-IDs [EV-CERTS]. + + o At least one significant certification authority is known to issue + certificates containing multiple CN-IDs. + + o Many service providers often deem inclusion of multiple CN-IDs + necessary in virtual hosting environments because at least one + widely deployed operating system does not yet support the SNI + extension. + + It is hoped that the recommendation regarding multiple CN-IDs can be + further tightened in the future. + +8. Contributors + + The following individuals made important contributions to the text of + this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. + +9. Acknowledgements + + The editors and contributors wish to thank the following individuals + for their feedback and suggestions: Bernard Aboba, Richard Barnes, + Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Scott + Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave Crocker, Cyrus + Daboo, Charles Gardiner, Philip Guenther, Phillip Hallam-Baker, Bruno + Harbulot, Wes Hardaker, David Harrington, Paul Hoffman, Love + Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey Hutzelman, + Cullen Jennings, Simon Josefsson, Geoff Keating, John Klensin, Scott + Lawrence, Matt McCutchen, Alexey Melnikov, Subramanian Moonesamy, + Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngve N. Pettersen, + Tim Polk, Robert Relyea, Eric Rescorla, Pete Resnick, Martin Rex, Joe + Salowey, Stefan Santesson, Jim Schaad, Rob Stradling, Michael + Stroeder, Andrew Sullivan, Peter Sylvester, Martin Thomson, Paul + Tiemann, Sean Turner, Nicolas Williams, Dan Wing, Dan Winship, and + Stefan Winter. + + Thanks also to Barry Leiba and Ben Campbell for their reviews on + behalf of the Security Directorate and the General Area Review Team, + respectively. + + The responsible Area Director was Alexey Melnikov. + + + + + + +Saint-Andre & Hodges Standards Track [Page 33] + +RFC 6125 Service Identity March 2011 + + +10. References + +10.1. Normative References + + [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR + for specifying the location of services (DNS SRV)", + RFC 2782, February 2000. + + [IDNA-DEFS] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document + Framework", RFC 5890, August 2010. + + [IDNA-PROTO] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + August 2010. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access + Protocol (LDAP): String Representation of + Distinguished Names", RFC 4514, June 2006. + + [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate + Revocation List (CRL) Profile", RFC 5280, May 2008. + + [SRVNAME] Santesson, S., "Internet X.509 Public Key + Infrastructure Subject Alternative Name for + Expression of Service Name", RFC 4985, August 2007. + + [URI] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + +10.2. Informative References + + [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + January 2008. + + [DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case + Insensitivity Clarification", RFC 4343, + January 2006. + + + +Saint-Andre & Hodges Standards Track [Page 34] + +RFC 6125 Service Identity March 2011 + + + [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "DNS Security Introduction and + Requirements", RFC 4033, March 2005. + + [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport + Layer Security", RFC 4347, April 2006. + + [Defeating-SSL] Marlinspike, M., "New Tricks for Defeating SSL in + Practice", BlackHat DC, February 2009, + . + + [EMAIL-SRV] Daboo, C., "Use of SRV Records for Locating Email + Submission/Access Services", RFC 6186, March 2011. + + [EV-CERTS] CA/Browser Forum, "Guidelines For The Issuance And + Management Of Extended Validation Certificates", + October 2009, + . + + [GIST] Schulzrinne, H. and R. Hancock, "GIST: General + Internet Signalling Transport", RFC 5971, + October 2010. + + [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, + "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, + June 1999. + + [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [HTTPSbytes] Sokol, J. and R. Hansen, "HTTPS Can Byte Me", + BlackHat Abu Dhabi, November 2010, + . + + [IDNA2003] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications + (IDNA)", RFC 3490, March 2003. + + [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - + VERSION 4rev1", RFC 3501, March 2003. + + [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + + + +Saint-Andre & Hodges Standards Track [Page 35] + +RFC 6125 Service Identity March 2011 + + + [IPSEC] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [IPv6] Deering, S. and R. Hinden, "Internet Protocol, + Version 6 (IPv6) Specification", RFC 2460, + December 1998. + + [LDAP] Sermersheim, J., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [LDAP-AUTH] Harrison, R., "Lightweight Directory Access Protocol + (LDAP): Authentication Methods and Security + Mechanisms", RFC 4513, June 2006. + + [LDAP-SCHEMA] Sciberras, A., Ed., "Lightweight Directory Access + Protocol (LDAP): Schema for User Applications", + RFC 4519, June 2006. + + [LDAP-TLS] Hodges, J., Morgan, R., and M. Wahl, "Lightweight + Directory Access Protocol (v3): Extension for + Transport Layer Security", RFC 2830, May 2000. + + [NAPTR] Mealling, M., "Dynamic Delegation Discovery System + (DDDS) Part Three: The Domain Name System (DNS) + Database", RFC 3403, October 2002. + + [NETCONF] Enns, R., Ed., "NETCONF Configuration Protocol", + RFC 4741, December 2006. + + [NETCONF-SSH] Wasserman, M. and T. Goddard, "Using the NETCONF + Configuration Protocol over Secure SHell (SSH)", + RFC 4742, December 2006. + + [NETCONF-TLS] Badra, M., "NETCONF over Transport Layer Security + (TLS)", RFC 5539, May 2009. + + [NNTP] Feather, C., "Network News Transfer Protocol + (NNTP)", RFC 3977, October 2006. + + [NNTP-TLS] Murchison, K., Vinocur, J., and C. Newman, "Using + Transport Layer Security (TLS) with Network News + Transfer Protocol (NNTP)", RFC 4642, October 2006. + + [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., + and C. Adams, "X.509 Internet Public Key + Infrastructure Online Certificate Status Protocol - + OCSP", RFC 2560, June 1999. + + + + +Saint-Andre & Hodges Standards Track [Page 36] + +RFC 6125 Service Identity March 2011 + + + [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., + and R. Thayer, "OpenPGP Message Format", RFC 4880, + November 2007. + + [PKIX-OLD] Housley, R., Ford, W., Polk, T., and D. Solo, + "Internet X.509 Public Key Infrastructure + Certificate and CRL Profile", RFC 2459, + January 1999. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol - + Version 3", STD 53, RFC 1939, May 1996. + + [PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, + G., and E. Lear, "Address Allocation for Private + Internets", BCP 5, RFC 1918, February 1996. + + [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application + Service Location Using SRV RRs and the Dynamic + Delegation Discovery Service (DDDS)", RFC 3958, + January 2005. + + [SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", + RFC 4949, August 2007. + + [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, M., + and E. Schooler, "SIP: Session Initiation Protocol", + RFC 3261, June 2002. + + [SIP-CERTS] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain + Certificates in the Session Initiation Protocol + (SIP)", RFC 5922, June 2010. + + [SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the + Session Initiation Protocol (SIP)", RFC 5630, + October 2009. + + [SMTP] Klensin, J., "Simple Mail Transfer Protocol", + RFC 5321, October 2008. + + [SMTP-AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP + Service Extension for Authentication", RFC 4954, + July 2007. + + [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP + over Transport Layer Security", RFC 3207, + February 2002. + + + + +Saint-Andre & Hodges Standards Track [Page 37] + +RFC 6125 Service Identity March 2011 + + + [SNMP] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network + Management Protocol (SNMP) Management Frameworks", + STD 62, RFC 3411, December 2002. + + [SNMP-TLS] Hardaker, W., "Transport Layer Security (TLS) + Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5953, August 2010. + + [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, + March 2009. + + [SYSLOG-DTLS] Salowey, J., Petch, T., Gerhards, R., and H. Feng, + "Datagram Transport Layer Security (DTLS) Transport + Mapping for Syslog", RFC 6012, October 2010. + + [SYSLOG-TLS] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed., + "Transport Layer Security (TLS) Transport Mapping + for Syslog", RFC 5425, March 2009. + + [TLS] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) + Extensions: Extension Definitions", RFC 6066, + January 2011. + + [US-ASCII] American National Standards Institute, "Coded + Character Set - 7-bit American Standard Code for + Information Interchange", ANSI X3.4, 1986. + + [USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", + RFC 2595, June 1999. + + [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: + User Interface Guidelines", World Wide Web + Consortium LastCall WD-wsc-ui-20100309, March 2010, + . + + [X.500] International Telecommunications Union, "Information + Technology - Open Systems Interconnection - The + Directory: Overview of concepts, models and + services", ITU-T Recommendation X.500, ISO Standard + 9594-1, August 2005. + + + + + + +Saint-Andre & Hodges Standards Track [Page 38] + +RFC 6125 Service Identity March 2011 + + + [X.501] International Telecommunications Union, "Information + Technology - Open Systems Interconnection - The + Directory: Models", ITU-T Recommendation X.501, + ISO Standard 9594-2, August 2005. + + [X.509] International Telecommunications Union, "Information + Technology - Open Systems Interconnection - The + Directory: Public-key and attribute certificate + frameworks", ITU-T Recommendation X.509, + ISO Standard 9594-8, August 2005. + + [X.520] International Telecommunications Union, "Information + Technology - Open Systems Interconnection - The + Directory: Selected attribute types", ITU- + T Recommendation X.509, ISO Standard 9594-6, + August 2005. + + [X.690] International Telecommunications Union, "Information + Technology - ASN.1 encoding rules: Specification of + Basic Encoding Rules (BER), Canonical Encoding Rules + (CER) and Distinguished Encoding Rules (DER)", ITU- + T Recommendation X.690, ISO Standard 8825-1, + August 2008. + + [XMPP] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Core", RFC 6120, March 2011. + + [XMPP-OLD] Saint-Andre, P., Ed., "Extensible Messaging and + Presence Protocol (XMPP): Core", RFC 3920, + October 2004. + + + + + + + + + + + + + + + + + + + + + +Saint-Andre & Hodges Standards Track [Page 39] + +RFC 6125 Service Identity March 2011 + + +Appendix A. Sample Text + + At the time of this writing, two application technologies reuse the + recommendations in this specification: email [EMAIL-SRV] and XMPP + [XMPP]. Here we include the text from [XMPP] to illustrate the + thought process that might be followed by protocol designers for + other application technologies. Specifically, because XMPP uses DNS + SRV records for resolution of the DNS domain names for application + services, the XMPP specification recommends the use of SRV-IDs. + + The text regarding certificate issuance is as follows: + + ###### + + In a PKIX certificate to be presented by an XMPP server (i.e., a + "server certificate"), the certificate MUST include one or more XMPP + addresses (i.e., domainparts) associated with XMPP services hosted at + the server. The rules and guidelines defined in [this specification] + apply to XMPP server certificates, with the following XMPP-specific + considerations: + + o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP + client and server software implementations. Certification + authorities that issue XMPP-specific certificates MUST support the + DNS-ID identifier type. XMPP service providers SHOULD include the + DNS-ID identifier type in certificate requests. + + o Support for the SRV-ID identifier type [SRVNAME] is REQUIRED for + XMPP client and server software implementations (for verification + purposes XMPP client implementations need to support only the + "_xmpp-client" application service type, whereas XMPP server + implementations need to support both the "_xmpp-client" and + "_xmpp-server" application service types). Certification + authorities that issue XMPP-specific certificates SHOULD support + the SRV-ID identifier type. XMPP service providers SHOULD include + the SRV-ID identifier type in certificate requests. + + o Support for the XmppAddr identifier type is encouraged in XMPP + client and server software implementations for the sake of + backward-compatibility, but is no longer encouraged in + certificates issued by certification authorities or requested by + XMPP service providers. + + o DNS domain names in server certificates MAY contain the wildcard + character '*' as the complete left-most label within the + identifier. + + ###### + + + +Saint-Andre & Hodges Standards Track [Page 40] + +RFC 6125 Service Identity March 2011 + + + The text regarding certificate verification is as follows: + + ###### + + For server certificates, the rules and guidelines defined in [this + specification] apply, with the proviso that the XmppAddr identifier + is allowed as a reference identifier. + + The identities to be checked are set as follows: + + o The initiating entity sets its reference identifier to the 'to' + address it communicates in the initial stream header; i.e., this + is the identity it expects the receiving entity to provide in a + PKIX certificate. + + o The receiving entity sets its reference identifier to the 'from' + address communicated by the initiating entity in the initial + stream header; i.e., this is the identity that the initiating + entity is trying to assert. + + ###### + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre & Hodges Standards Track [Page 41] + +RFC 6125 Service Identity March 2011 + + +Appendix B. Prior Art + + (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 application service 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 "[...]"). + +B.1. IMAP, POP3, and ACAP (1999) + + In 1999, [USINGTLS] specified the following text regarding + application service 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: + + o 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. + + o If a subjectAltName extension of type dNSName is present in the + certificate, it SHOULD be used as the source of the server's + identity. + + o Matching is case-insensitive. + + o 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. + + o 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. + + + +Saint-Andre & Hodges Standards Track [Page 42] + +RFC 6125 Service Identity March 2011 + + + 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. + + ###### + +B.2. HTTP (2000) + + In 2000, [HTTP-TLS] specified the following text regarding + application service 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 + [PKIX-OLD]. 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. + + + +Saint-Andre & Hodges Standards Track [Page 43] + +RFC 6125 Service Identity March 2011 + + + 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. + + ###### + +B.3. LDAP (2000/2006) + + In 2000, [LDAP-TLS] specified the following text regarding + application service 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: + + o 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. + + o If a subjectAltName extension of type dNSName is present in the + certificate, it SHOULD be used as the source of the server's + identity. + + o Matching is case-insensitive. + + o The "*" wildcard character is allowed. If present, it applies + only to the left-most name component. + + + +Saint-Andre & Hodges Standards Track [Page 44] + +RFC 6125 Service Identity March 2011 + + + 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, [LDAP-AUTH] specified the following text regarding + application service 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 + + + +Saint-Andre & Hodges Standards Track [Page 45] + +RFC 6125 Service Identity March 2011 + + + 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) [LDAP-SCHEMA] value in the last + Relative Distinguished Name (RDN) of the subject field of the + server's certificate (where "last" refers to the DER-encoded order, + not the order of presentation in a string representation of DER- + encoded data). 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 + [IDNA2003] 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: + + o in step 1, the domain name SHALL be considered a "stored string"; + + o in step 3, set the flag called "UseSTD3ASCIIRules"; + + o in step 4, process each label with the "ToASCII" operation; and + + + +Saint-Andre & Hodges Standards Track [Page 46] + +RFC 6125 Service Identity March 2011 + + + o 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 + [IP] [IPv6]. 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. + + ###### + +B.4. SMTP (2002/2007) + + In 2002, [SMTP-TLS] specified the following text regarding + application service 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: + + + + + + +Saint-Andre & Hodges Standards Track [Page 47] + +RFC 6125 Service Identity March 2011 + + + o 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, [SMTP-AUTH] specified the following text regarding + application service identity verification in SMTP: + + ###### + + 14. Additional Requirements When Using SASL PLAIN over TLS + + [...] + + After a successful [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. 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. + + ###### + + + + + +Saint-Andre & Hodges Standards Track [Page 48] + +RFC 6125 Service Identity March 2011 + + +B.5. XMPP (2004) + + In 2004, [XMPP-OLD] specified the following text regarding + application service 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: + + Case #1: The peer contains an End Entity certificate which appears + to be certified by a certification path terminating in a trust + anchor (as described in Section 6.1 of [PKIX]). + + Case #2: The peer certificate is certified by a Certificate + Authority not known to the validating peer. + + Case #3: The peer certificate is self-signed. + + In Case #1, the validating peer MUST do one of two things: + + 1. Verify the peer certificate according to the rules of [PKIX]. + The certificate SHOULD then be checked against the expected + identity of the peer following the rules described in [HTTP-TLS], + 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. + + 2. The peer SHOULD show the certificate to a user for approval, + including the entire certification path. 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. + + ###### + + + + + +Saint-Andre & Hodges Standards Track [Page 49] + +RFC 6125 Service Identity March 2011 + + + Although [XMPP-OLD] defined its own rules, [XMPP] reuses the rules in + this document regarding application service identity verification in + XMPP. + +B.6. NNTP (2006) + + In 2006, [NNTP-TLS] specified the following text regarding + application service 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: + + o The client MUST use the server hostname it used to open the + connection (or the hostname specified in TLS "server_name" + extension [TLS]) 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. + + o If a subjectAltName extension of type dNSName is present in the + certificate, it SHOULD be used as the source of the server's + identity. + + o Matching is case-insensitive. + + o 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. + + o 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. + + + + + +Saint-Andre & Hodges Standards Track [Page 50] + +RFC 6125 Service Identity March 2011 + + + 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 [PKIX] 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). + + ###### + +B.7. NETCONF (2006/2009) + + In 2006, [NETCONF-SSH] specified the following text regarding + application service 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, [NETCONF-TLS] specified the following text regarding + application service 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. + + + + + + +Saint-Andre & Hodges Standards Track [Page 51] + +RFC 6125 Service Identity March 2011 + + + Matching is performed according to the rules below (following the + example of [NNTP-TLS]): + + o The client MUST use the server hostname it used to open the + connection (or the hostname specified in the TLS "server_name" + extension [TLS]) 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. + + o If a subjectAltName extension of type dNSName is present in the + certificate, it MUST be used as the source of the server's + identity. + + o Matching is case-insensitive. + + o 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. + + o 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 [PKIX] 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. + + ###### + +B.8. Syslog (2009) + + In 2009, [SYSLOG-TLS] specified the following text regarding + application service identity verification in Syslog: + + + +Saint-Andre & Hodges Standards Track [Page 52] + +RFC 6125 Service Identity March 2011 + + + ###### + + 5.2. Subject Name Authorization + + Implementations MUST support certification path validation [PKIX]. + In addition, they MUST support specifying the authorized peers using + locally configured host names and matching the name against the + certificate as follows. + + o 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. + + o 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. + + o 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. + + o 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 [PKIX]. + + o 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 [PKIX], Section + 4.2.1.6. A match occurs if this octet string is equal to the + value of iPAddress in the subjectAltName extension. + + ###### + + + + + + +Saint-Andre & Hodges Standards Track [Page 53] + +RFC 6125 Service Identity March 2011 + + +B.9. SIP (2010) + + In 2010, [SIP-CERTS] specified the following text regarding + application service identity verification in SIP: + + ###### + + 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 + [DNS-CASE]. Implementations MUST handle Internationalized Domain + Names (IDNs) in accordance with Section 7.2 of [PKIX]. + + Implementations MUST match the values in their entirety: + + Implementations MUST NOT match suffixes. For example, + "foo.example.com" does not match "example.com". + + Implementations 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." + + [HTTP-TLS] allows the dNSName component to contain a + wildcard; e.g., "DNS:*.example.com". [PKIX], while not + disallowing this explicitly, leaves the interpretation of + wildcards to the individual specification. [SIP] 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. + + ###### + + + + + + + + + +Saint-Andre & Hodges Standards Track [Page 54] + +RFC 6125 Service Identity March 2011 + + +B.10. SNMP (2010) + + In 2010, [SNMP-TLS] specified the following text regarding + application service identity verification in SNMP: + + ###### + + If the server's presented certificate has passed certification path + validation [PKIX] to a configured trust anchor, and an active row + exists with a zero-length snmpTlstmAddrServerFingerprint value, then + the snmpTlstmAddrServerIdentity column contains the expected host + name. This expected host name is then compared against the server's + certificate as follows: + + o Implementations MUST support matching the expected host name + against a dNSName in the subjectAltName extension field and MAY + support checking the name against the CommonName portion of the + subject distinguished name. + + o The '*' (ASCII 0x2a) 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. + + o 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 [PKIX]. + + If the expected host name fails these conditions then the connection + MUST be closed. + + ###### + +B.11. GIST (2010) + + In 2010, [GIST] specified the following text regarding application + service identity verification in the General Internet Signalling + Transport: + + + + + + +Saint-Andre & Hodges Standards Track [Page 55] + +RFC 6125 Service Identity March 2011 + + + ###### + + 5.7.3.1. Identity Checking in TLS + + After TLS authentication, a node MUST check the identity presented by + the peer in order to avoid man-in-the-middle attacks, and verify that + the peer is authorised to take part in signalling at the GIST layer. + The authorisation check is carried out by comparing the presented + identity with each Authorised Peer Database (APD) entry in turn, as + discussed in Section 4.4.2. This section defines the identity + comparison algorithm for a single APD entry. + + For TLS authentication with X.509 certificates, an identity from the + DNS namespace MUST be checked against each subjectAltName extension + of type dNSName present in the certificate. If no such extension is + present, then the identity MUST be compared to the (most specific) + Common Name in the Subject field of the certificate. When matching + DNS names against dNSName or Common Name fields, matching is case- + insensitive. Also, a "*" wildcard character MAY be used as the left- + most name component in the certificate or identity in the APD. For + example, *.example.com in the APD would match certificates for + a.example.com, foo.example.com, *.example.com, etc., but would not + match example.com. Similarly, a certificate for *.example.com would + be valid for APD identities of a.example.com, foo.example.com, + *.example.com, etc., but not example.com. + + Additionally, a node MUST verify the binding between the identity of + the peer to which it connects and the public key presented by that + peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX] + 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). + + For TLS authentication with pre-shared keys, the identity in the + psk_identity_hint (for the server identity, i.e. the Responding node) + or psk_identity (for the client identity, i.e. the Querying node) + MUST be compared to the identities in the APD. + + ###### + + + + + + + + + + + +Saint-Andre & Hodges Standards Track [Page 56] + +RFC 6125 Service Identity March 2011 + + +Authors' Addresses + + Peter Saint-Andre + Cisco + 1899 Wyknoop Street, Suite 600 + Denver, CO 80202 + USA + + Phone: +1-303-308-3282 + EMail: psaintan@cisco.com + + + Jeff Hodges + PayPal + 2211 North First Street + San Jose, California 95131 + US + + EMail: Jeff.Hodges@PayPal.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre & Hodges Standards Track [Page 57] + diff --git a/compliance/specs/www.rfc-editor.org/rfc/rfc6960.txt b/compliance/specs/www.rfc-editor.org/rfc/rfc6960.txt new file mode 100644 index 00000000000..9faf9b5c143 --- /dev/null +++ b/compliance/specs/www.rfc-editor.org/rfc/rfc6960.txt @@ -0,0 +1,2299 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Santesson +Request for Comments: 6960 3xA Security +Obsoletes: 2560, 6277 M. Myers +Updates: 5912 TraceRoute Security +Category: Standards Track R. Ankney +ISSN: 2070-1721 + A. Malpani + CA Technologies + S. Galperin + A9 + C. Adams + University of Ottawa + June 2013 + + + X.509 Internet Public Key Infrastructure + Online Certificate Status Protocol - OCSP + +Abstract + + This document specifies a protocol useful in determining the current + status of a digital certificate without requiring Certificate + Revocation Lists (CRLs). Additional mechanisms addressing PKIX + operational requirements are specified in separate documents. This + document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6960. + + + + + + + + + + + + +Santesson, et al. Standards Track [Page 1] + +RFC 6960 PKIX OCSP June 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Requirements Language ......................................5 + 2. Protocol Overview ...............................................5 + 2.1. Request ....................................................5 + 2.2. Response ...................................................6 + 2.3. Exception Cases ............................................8 + 2.4. Semantics of thisUpdate, nextUpdate, and producedAt ........9 + 2.5. Response Pre-Production ....................................9 + 2.6. OCSP Signature Authority Delegation .......................10 + 2.7. CA Key Compromise .........................................10 + 3. Functional Requirements ........................................10 + 3.1. Certificate Content .......................................10 + 3.2. Signed Response Acceptance Requirements ...................10 + 4. Details of the Protocol ........................................11 + 4.1. Request Syntax ............................................11 + 4.1.1. ASN.1 Specification of the OCSP Request ............11 + 4.1.2. Notes on OCSP Requests .............................13 + 4.2. Response Syntax ...........................................14 + 4.2.1. ASN.1 Specification of the OCSP Response ...........14 + 4.2.2. Notes on OCSP Responses ............................16 + 4.2.2.1. Time ......................................16 + 4.2.2.2. Authorized Responders .....................16 + 4.2.2.2.1. Revocation Checking of + an Authorized Responder ........17 + 4.2.2.3. Basic Response ............................18 + 4.3. Mandatory and Optional Cryptographic Algorithms ...........19 + + + + + + + + +Santesson, et al. Standards Track [Page 2] + +RFC 6960 PKIX OCSP June 2013 + + + 4.4. Extensions ................................................19 + 4.4.1. Nonce ..............................................20 + 4.4.2. CRL References .....................................20 + 4.4.3. Acceptable Response Types ..........................20 + 4.4.4. Archive Cutoff .....................................21 + 4.4.5. CRL Entry Extensions ...............................21 + 4.4.6. Service Locator ....................................22 + 4.4.7. Preferred Signature Algorithms .....................22 + 4.4.7.1. Extension Syntax ..........................23 + 4.4.7.2. Responder Signature Algorithm Selection ...24 + 4.4.7.2.1. Dynamic Response ...............24 + 4.4.7.2.2. Static Response ................25 + 4.4.8. Extended Revoked Definition ........................25 + 5. Security Considerations ........................................26 + 5.1. Preferred Signature Algorithms ............................27 + 5.1.1. Use of Insecure Algorithms .........................27 + 5.1.2. Man-in-the-Middle Downgrade Attack .................27 + 5.1.3. Denial-of-Service Attack ...........................28 + 6. IANA Considerations ............................................28 + 7. References .....................................................28 + 7.1. Normative References ......................................28 + 7.2. Informative References ....................................29 + 8. Acknowledgements ...............................................29 + Appendix A. OCSP over HTTP ........................................30 + A.1. Request ....................................................30 + A.2. Response ...................................................30 + Appendix B. ASN.1 Modules .........................................30 + B.1. OCSP in ASN.1 - 1998 Syntax ................................31 + B.2. OCSP in ASN.1 - 2008 Syntax ................................34 + Appendix C. MIME Registrations ....................................39 + C.1. application/ocsp-request ...................................39 + C.2. application/ocsp-response ..................................40 + + + + + + + + + + + + + + + + + + + +Santesson, et al. Standards Track [Page 3] + +RFC 6960 PKIX OCSP June 2013 + + +1. Introduction + + This document specifies a protocol useful in determining the current + status of a digital certificate without requiring CRLs. Additional + mechanisms addressing PKIX operational requirements are specified in + separate documents. + + This specification obsoletes [RFC2560] and [RFC6277]. The primary + reason for the publication of this document is to address ambiguities + that have been found since the publication of RFC 2560. This + document differs from RFC 2560 in only a few areas: + + o Section 2.2 extends the use of the "revoked" response to allow + this response status for certificates that have never been issued. + + o Section 2.3 extends the use of the "unauthorized" error response, + as specified in [RFC5019]. + + o Sections 4.2.1 and 4.2.2.3 state that a response may include + revocation status information for certificates that were not + included in the request, as permitted in [RFC5019]. + + o Section 4.2.2.2 clarifies when a responder is considered an + Authorized Responder. + + o Section 4.2.2.3 clarifies that the ResponderID field corresponds + to the OCSP responder signer certificate. + + o Section 4.3 changes the set of cryptographic algorithms that + clients must support and the set of cryptographic algorithms that + clients should support as specified in [RFC6277]. + + o Section 4.4.1 specifies, for the nonce extension, ASN.1 syntax + that was missing in RFC 2560. + + o Section 4.4.7 specifies a new extension that may be included in a + request message to specify signature algorithms the client would + prefer the server use to sign the response as specified in + [RFC6277]. + + o Section 4.4.8 specifies a new extension that indicates that the + responder supports the extended use of the "revoked" response for + non-issued certificates defined in Section 2.2. + + o Appendix B.2 provides an ASN.1 module using the 2008 syntax of + ASN.1, which updates [RFC5912]. + + + + + +Santesson, et al. Standards Track [Page 4] + +RFC 6960 PKIX OCSP June 2013 + + + An overview of the protocol is provided in Section 2. Functional + requirements are specified in Section 3. Details of the protocol are + discussed in Section 4. We cover security issues with the protocol + in Section 5. Appendix A defines OCSP over HTTP, Appendix B provides + ASN.1 syntactic elements, and Appendix C specifies the MIME types for + the messages. + +1.1. Requirements Language + + 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 [RFC2119]. + +2. Protocol Overview + + In lieu of, or as a supplement to, checking against a periodic CRL, + it may be necessary to obtain timely information regarding the + revocation status of certificates (cf. [RFC5280], Section 3.3). + Examples include high-value funds transfers or large stock trades. + + The Online Certificate Status Protocol (OCSP) enables applications to + determine the (revocation) state of identified certificates. OCSP + may be used to satisfy some of the operational requirements of + providing more timely revocation information than is possible with + CRLs and may also be used to obtain additional status information. + An OCSP client issues a status request to an OCSP responder and + suspends acceptance of the certificates in question until the + responder provides a response. + + This protocol specifies the data that needs to be exchanged between + an application checking the status of one or more certificates and + the server providing the corresponding status. + +2.1. Request + + An OCSP request contains the following data: + + - protocol version + + - service request + + - target certificate identifier + + - optional extensions, which MAY be processed by the OCSP responder + + + + + + + +Santesson, et al. Standards Track [Page 5] + +RFC 6960 PKIX OCSP June 2013 + + + Upon receipt of a request, an OCSP responder determines if: + + 1. the message is well formed, + + 2. the responder is configured to provide the requested service, and + + 3. the request contains the information needed by the responder. + + If any one of these conditions is not met, the OCSP responder + produces an error message; otherwise, it returns a definitive + response. + +2.2. Response + + OCSP responses can be of various types. An OCSP response consists of + a response type and the bytes of the actual response. There is one + basic type of OCSP response that MUST be supported by all OCSP + servers and clients. The rest of this section pertains only to this + basic response type. + + All definitive response messages SHALL be digitally signed. The key + used to sign the response MUST belong to one of the following: + + - the CA who issued the certificate in question + + - a Trusted Responder whose public key is trusted by the requestor + + - a CA Designated Responder (Authorized Responder, defined in + Section 4.2.2.2) who holds a specially marked certificate issued + directly by the CA, indicating that the responder may issue OCSP + responses for that CA + + A definitive response message is composed of: + + - version of the response syntax + + - identifier of the responder + + - time when the response was generated + + - responses for each of the certificates in a request + + - optional extensions + + - signature algorithm OID + + - signature computed across a hash of the response + + + + +Santesson, et al. Standards Track [Page 6] + +RFC 6960 PKIX OCSP June 2013 + + + The response for each of the certificates in a request consists of: + + - target certificate identifier + + - certificate status value + + - response validity interval + + - optional extensions + + This specification defines the following definitive response + indicators for use in the certificate status value: + + - good + + - revoked + + - unknown + + The "good" state indicates a positive response to the status inquiry. + At a minimum, this positive response indicates that no certificate + with the requested certificate serial number currently within its + validity interval is revoked. This state does not necessarily mean + that the certificate was ever issued or that the time at which the + response was produced is within the certificate's validity interval. + Response extensions may be used to convey additional information on + assertions made by the responder regarding the status of the + certificate, such as a positive statement about issuance, validity, + etc. + + The "revoked" state indicates that the certificate has been revoked, + either temporarily (the revocation reason is certificateHold) or + permanently. This state MAY also be returned if the associated CA + has no record of ever having issued a certificate with the + certificate serial number in the request, using any current or + previous issuing key (referred to as a "non-issued" certificate in + this document). + + The "unknown" state indicates that the responder doesn't know about + the certificate being requested, usually because the request + indicates an unrecognized issuer that is not served by this + responder. + + NOTE: The "revoked" status indicates that a certificate with the + requested serial number should be rejected, while the "unknown" + status indicates that the status could not be determined by + this responder, thereby allowing the client to decide whether + it wants to try another source of status information (such as a + + + +Santesson, et al. Standards Track [Page 7] + +RFC 6960 PKIX OCSP June 2013 + + + CRL). This makes the "revoked" response suitable for + non-issued certificates (as defined above) where the intention + of the responder is to cause the client to reject the + certificate rather than trying another source of status + information. The "revoked" status is still optional for + non-issued certificates in order to maintain backwards + compatibility with deployments of RFC 2560. For example, the + responder may not have any knowledge about whether a requested + serial number has been assigned to any issued certificate, or + the responder may provide pre-produced responses in accordance + with RFC 5019 and, for that reason, is not capable of providing + a signed response for all non-issued certificate serial + numbers. + + When a responder sends a "revoked" response to a status request for a + non-issued certificate, the responder MUST include the extended + revoked definition response extension (Section 4.4.8) in the + response, indicating that the OCSP responder supports the extended + definition of the "revoked" state to also cover non-issued + certificates. In addition, the SingleResponse related to this + non-issued certificate: + + - MUST specify the revocation reason certificateHold (6), + + - MUST specify the revocationTime January 1, 1970, and + + - MUST NOT include a CRL references extension (Section 4.4.2) or any + CRL entry extensions (Section 4.4.5). + +2.3. Exception Cases + + In case of errors, the OCSP responder may return an error message. + These messages are not signed. Errors can be of the following types: + + - malformedRequest + + - internalError + + - tryLater + + - sigRequired + + - unauthorized + + A server produces the "malformedRequest" response if the request + received does not conform to the OCSP syntax. + + + + + +Santesson, et al. Standards Track [Page 8] + +RFC 6960 PKIX OCSP June 2013 + + + The response "internalError" indicates that the OCSP responder + reached an inconsistent internal state. The query should be retried, + potentially with another responder. + + In the event that the OCSP responder is operational but unable to + return a status for the requested certificate, the "tryLater" + response can be used to indicate that the service exists but is + temporarily unable to respond. + + The response "sigRequired" is returned in cases where the server + requires that the client sign the request in order to construct a + response. + + The response "unauthorized" is returned in cases where the client is + not authorized to make this query to this server or the server is not + capable of responding authoritatively (cf. [RFC5019], Section 2.2.3). + +2.4. Semantics of thisUpdate, nextUpdate, and producedAt + + Responses defined in this document can contain four times -- + thisUpdate, nextUpdate, producedAt, and revocationTime. The + semantics of these fields are: + + thisUpdate The most recent time at which the status being + indicated is known by the responder to have been + correct. + + nextUpdate The time at or before which newer information will be + available about the status of the certificate. + + producedAt The time at which the OCSP responder signed this + response. + + revocationTime The time at which the certificate was revoked or + placed on hold. + +2.5. Response Pre-Production + + OCSP responders MAY pre-produce signed responses specifying the + status of certificates at a specified time. The time at which the + status was known to be correct SHALL be reflected in the thisUpdate + field of the response. The time at or before which newer information + will be available is reflected in the nextUpdate field, while the + time at which the response was produced will appear in the producedAt + field of the response. + + + + + + +Santesson, et al. Standards Track [Page 9] + +RFC 6960 PKIX OCSP June 2013 + + +2.6. OCSP Signature Authority Delegation + + The key that signs a certificate's status information need not be the + same key that signed the certificate. A certificate's issuer + explicitly delegates OCSP signing authority by issuing a certificate + containing a unique value for the extended key usage extension + (defined in [RFC5280], Section 4.2.1.12) in the OCSP signer's + certificate. This certificate MUST be issued directly to the + responder by the cognizant CA. See Section 4.2.2.2 for details. + +2.7. CA Key Compromise + + If an OCSP responder knows that a particular CA's private key has + been compromised, it MAY return the "revoked" state for all + certificates issued by that CA. + +3. Functional Requirements + +3.1. Certificate Content + + In order to convey to OCSP clients a well-known point of information + access, CAs SHALL provide the capability to include the authority + information access extension (defined in [RFC5280], Section 4.2.2.1) + in certificates that can be checked using OCSP. Alternatively, the + accessLocation for the OCSP provider may be configured locally at the + OCSP client. + + CAs that support an OCSP service, either hosted locally or provided + by an Authorized Responder, MUST provide for the inclusion of a value + for a Uniform Resource Identifier (URI) [RFC3986] accessLocation and + the OID value id-ad-ocsp for the accessMethod in the + AccessDescription SEQUENCE. + + The value of the accessLocation field in the subject certificate + defines the transport (e.g., HTTP) used to access the OCSP responder + and may contain other transport-dependent information (e.g., a URL). + +3.2. Signed Response Acceptance Requirements + + Prior to accepting a signed response for a particular certificate as + valid, OCSP clients SHALL confirm that: + + 1. The certificate identified in a received response corresponds to + the certificate that was identified in the corresponding request; + + 2. The signature on the response is valid; + + + + + +Santesson, et al. Standards Track [Page 10] + +RFC 6960 PKIX OCSP June 2013 + + + 3. The identity of the signer matches the intended recipient of the + request; + + 4. The signer is currently authorized to provide a response for the + certificate in question; + + 5. The time at which the status being indicated is known to be + correct (thisUpdate) is sufficiently recent; + + 6. When available, the time at or before which newer information will + be available about the status of the certificate (nextUpdate) is + greater than the current time. + +4. Details of the Protocol + + The ASN.1 syntax imports terms defined in [RFC5280]. For signature + calculation, the data to be signed is encoded using the ASN.1 + distinguished encoding rules (DER) [X.690]. + + ASN.1 EXPLICIT tagging is used as a default unless specified + otherwise. + + The terms imported from elsewhere are Extensions, + CertificateSerialNumber, SubjectPublicKeyInfo, Name, + AlgorithmIdentifier, and CRLReason. + +4.1. Request Syntax + + This section specifies the ASN.1 specification for a confirmation + request. The actual formatting of the message could vary, depending + on the transport mechanism used (HTTP, SMTP, LDAP, etc.). + +4.1.1. ASN.1 Specification of the OCSP Request + + The ASN.1 structure corresponding to the OCSPRequest is: + + OCSPRequest ::= SEQUENCE { + tbsRequest TBSRequest, + optionalSignature [0] EXPLICIT Signature OPTIONAL } + + TBSRequest ::= SEQUENCE { + version [0] EXPLICIT Version DEFAULT v1, + requestorName [1] EXPLICIT GeneralName OPTIONAL, + requestList SEQUENCE OF Request, + requestExtensions [2] EXPLICIT Extensions OPTIONAL } + + + + + + +Santesson, et al. Standards Track [Page 11] + +RFC 6960 PKIX OCSP June 2013 + + + Signature ::= SEQUENCE { + signatureAlgorithm AlgorithmIdentifier, + signature BIT STRING, + certs [0] EXPLICIT SEQUENCE OF Certificate + OPTIONAL} + + Version ::= INTEGER { v1(0) } + + Request ::= SEQUENCE { + reqCert CertID, + singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } + + CertID ::= SEQUENCE { + hashAlgorithm AlgorithmIdentifier, + issuerNameHash OCTET STRING, -- Hash of issuer's DN + issuerKeyHash OCTET STRING, -- Hash of issuer's public key + serialNumber CertificateSerialNumber } + + The fields in OCSPRequest have the following meanings: + + o tbsRequest is the optionally signed OCSP request. + + o optionalSignature contains the algorithm identifier and any + associated algorithm parameters in signatureAlgorithm; the + signature value in signature; and, optionally, certificates the + server needs to verify the signed response (normally up to but not + including the client's root certificate). + + The contents of TBSRequest include the following fields: + + o version indicates the version of the protocol, which for this + document is v1(0). + + o requestorName is OPTIONAL and indicates the name of the OCSP + requestor. + + o requestList contains one or more single certificate status + requests. + + o requestExtensions is OPTIONAL and includes extensions applicable + to the requests found in reqCert. See Section 4.4. + + + + + + + + + + +Santesson, et al. Standards Track [Page 12] + +RFC 6960 PKIX OCSP June 2013 + + + The contents of Request include the following fields: + + o reqCert contains the identifier of a target certificate. + + o singleRequestExtensions is OPTIONAL and includes extensions + applicable to this single certificate status request. See + Section 4.4. + + The contents of CertID include the following fields: + + o hashAlgorithm is the hash algorithm used to generate the + issuerNameHash and issuerKeyHash values. + + o issuerNameHash is the hash of the issuer's distinguished name + (DN). The hash shall be calculated over the DER encoding of the + issuer's name field in the certificate being checked. + + o issuerKeyHash is the hash of the issuer's public key. The hash + shall be calculated over the value (excluding tag and length) of + the subject public key field in the issuer's certificate. + + o serialNumber is the serial number of the certificate for which + status is being requested. + +4.1.2. Notes on OCSP Requests + + The primary reason to use the hash of the CA's public key in addition + to the hash of the CA's name to identify the issuer is that it is + possible that two CAs may choose to use the same Name (uniqueness in + the Name is a recommendation that cannot be enforced). Two CAs will + never, however, have the same public key unless the CAs either + explicitly decided to share their private key or the key of one of + the CAs was compromised. + + Support for any specific extension is OPTIONAL. The critical flag + SHOULD NOT be set for any of them. Section 4.4 suggests several + useful extensions. Additional extensions MAY be defined in + additional RFCs. Unrecognized extensions MUST be ignored (unless + they have the critical flag set and are not understood). + + The requestor MAY choose to sign the OCSP request. In that case, the + signature is computed over the tbsRequest structure. If the request + is signed, the requestor SHALL specify its name in the requestorName + field. Also, for signed requests, the requestor MAY include + certificates that help the OCSP responder verify the requestor's + signature in the certs field of Signature. + + + + + +Santesson, et al. Standards Track [Page 13] + +RFC 6960 PKIX OCSP June 2013 + + +4.2. Response Syntax + + This section specifies the ASN.1 specification for a confirmation + response. The actual formatting of the message could vary, depending + on the transport mechanism used (HTTP, SMTP, LDAP, etc.). + +4.2.1. ASN.1 Specification of the OCSP Response + + An OCSP response at a minimum consists of a responseStatus field + indicating the processing status of the prior request. If the value + of responseStatus is one of the error conditions, the responseBytes + field is not set. + + OCSPResponse ::= SEQUENCE { + responseStatus OCSPResponseStatus, + responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } + + OCSPResponseStatus ::= ENUMERATED { + successful (0), -- Response has valid confirmations + malformedRequest (1), -- Illegal confirmation request + internalError (2), -- Internal error in issuer + tryLater (3), -- Try again later + -- (4) is not used + sigRequired (5), -- Must sign the request + unauthorized (6) -- Request unauthorized + } + + The value for responseBytes consists of an OBJECT IDENTIFIER and a + response syntax identified by that OID encoded as an OCTET STRING. + + ResponseBytes ::= SEQUENCE { + responseType OBJECT IDENTIFIER, + response OCTET STRING } + + For a basic OCSP responder, responseType will be id-pkix-ocsp-basic. + + id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } + id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } + + OCSP responders SHALL be capable of producing responses of the + id-pkix-ocsp-basic response type. Correspondingly, OCSP clients + SHALL be capable of receiving and processing responses of the + id-pkix-ocsp-basic response type. + + + + + + + + +Santesson, et al. Standards Track [Page 14] + +RFC 6960 PKIX OCSP June 2013 + + + The value for response SHALL be the DER encoding of + BasicOCSPResponse. + + BasicOCSPResponse ::= SEQUENCE { + tbsResponseData ResponseData, + signatureAlgorithm AlgorithmIdentifier, + signature BIT STRING, + certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } + + The value for signature SHALL be computed on the hash of the DER + encoding of ResponseData. The responder MAY include certificates in + the certs field of BasicOCSPResponse that help the OCSP client verify + the responder's signature. If no certificates are included, then + certs SHOULD be absent. + + ResponseData ::= SEQUENCE { + version [0] EXPLICIT Version DEFAULT v1, + responderID ResponderID, + producedAt GeneralizedTime, + responses SEQUENCE OF SingleResponse, + responseExtensions [1] EXPLICIT Extensions OPTIONAL } + + ResponderID ::= CHOICE { + byName [1] Name, + byKey [2] KeyHash } + + KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key + (excluding the tag and length fields) + + SingleResponse ::= SEQUENCE { + certID CertID, + certStatus CertStatus, + thisUpdate GeneralizedTime, + nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, + singleExtensions [1] EXPLICIT Extensions OPTIONAL } + + CertStatus ::= CHOICE { + good [0] IMPLICIT NULL, + revoked [1] IMPLICIT RevokedInfo, + unknown [2] IMPLICIT UnknownInfo } + + RevokedInfo ::= SEQUENCE { + revocationTime GeneralizedTime, + revocationReason [0] EXPLICIT CRLReason OPTIONAL } + + UnknownInfo ::= NULL + + + + + +Santesson, et al. Standards Track [Page 15] + +RFC 6960 PKIX OCSP June 2013 + + +4.2.2. Notes on OCSP Responses + +4.2.2.1. Time + + Responses can contain four times -- thisUpdate, nextUpdate, + producedAt, and revocationTime. The semantics of these fields are + defined in Section 2.4. The format for GeneralizedTime is as + specified in Section 4.1.2.5.2 of [RFC5280]. + + The thisUpdate and nextUpdate fields define a recommended validity + interval. This interval corresponds to the {thisUpdate, nextUpdate} + interval in CRLs. Responses whose nextUpdate value is earlier than + the local system time value SHOULD be considered unreliable. + Responses whose thisUpdate time is later than the local system time + SHOULD be considered unreliable. + + If nextUpdate is not set, the responder is indicating that newer + revocation information is available all the time. + +4.2.2.2. Authorized Responders + + The key that signs a certificate's status information need not be the + same key that signed the certificate. It is necessary, however, to + ensure that the entity signing this information is authorized to do + so. Therefore, a certificate's issuer MUST do one of the following: + + - sign the OCSP responses itself, or + + - explicitly designate this authority to another entity + + OCSP signing delegation SHALL be designated by the inclusion of + id-kp-OCSPSigning in an extended key usage certificate extension + included in the OCSP response signer's certificate. This certificate + MUST be issued directly by the CA that is identified in the request. + + The CA SHOULD use the same issuing key to issue a delegation + certificate as that used to sign the certificate being checked for + revocation. Systems relying on OCSP responses MUST recognize a + delegation certificate as being issued by the CA that issued the + certificate in question only if the delegation certificate and the + certificate being checked for revocation were signed by the same key. + + + + + + + + + + +Santesson, et al. Standards Track [Page 16] + +RFC 6960 PKIX OCSP June 2013 + + + Note: For backwards compatibility with RFC 2560 [RFC2560], it is not + prohibited to issue a certificate for an Authorized Responder + using a different issuing key than the key used to issue the + certificate being checked for revocation. However, such a + practice is strongly discouraged, since clients are not + required to recognize a responder with such a certificate as an + Authorized Responder. + + id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} + + Systems or applications that rely on OCSP responses MUST be capable + of detecting and enforcing the use of the id-kp-OCSPSigning value as + described above. They MAY provide a means of locally configuring one + or more OCSP signing authorities and specifying the set of CAs for + which each signing authority is trusted. They MUST reject the + response if the certificate required to validate the signature on the + response does not meet at least one of the following criteria: + + 1. Matches a local configuration of OCSP signing authority for the + certificate in question, or + + 2. Is the certificate of the CA that issued the certificate in + question, or + + 3. Includes a value of id-kp-OCSPSigning in an extended key usage + extension and is issued by the CA that issued the certificate in + question as stated above. + + Additional acceptance or rejection criteria may apply to either the + response itself or to the certificate used to validate the signature + on the response. + +4.2.2.2.1. Revocation Checking of an Authorized Responder + + Since an authorized OCSP responder provides status information for + one or more CAs, OCSP clients need to know how to check that an + Authorized Responder's certificate has not been revoked. CAs may + choose to deal with this problem in one of three ways: + + - A CA may specify that an OCSP client can trust a responder for the + lifetime of the responder's certificate. The CA does so by + including the extension id-pkix-ocsp-nocheck. This SHOULD be a + non-critical extension. The value of the extension SHALL be NULL. + CAs issuing such a certificate should realize that a compromise of + the responder's key is as serious as the compromise of a CA key + + + + + + +Santesson, et al. Standards Track [Page 17] + +RFC 6960 PKIX OCSP June 2013 + + + used to sign CRLs, at least for the validity period of this + certificate. CAs may choose to issue this type of certificate with + a very short lifetime and renew it frequently. + + id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } + + - A CA may specify how the responder's certificate is to be checked + for revocation. This can be done by using CRL Distribution Points + if the check should be done using CRLs, or by using Authority + Information Access if the check should be done in some other way. + Details for specifying either of these two mechanisms are available + in [RFC5280]. + + - A CA may choose not to specify any method of revocation checking + for the responder's certificate, in which case it would be up to + the OCSP client's local security policy to decide whether that + certificate should be checked for revocation or not. + +4.2.2.3. Basic Response + + The basic response type contains: + + o the version of the response syntax, which MUST be v1 (value is 0) + for this version of the basic response syntax; + + o either the name of the responder or a hash of the responder's + public key as the ResponderID; + + o the time at which the response was generated; + + o responses for each of the certificates in a request; + + o optional extensions; + + o a signature computed across a hash of the response; and + + o the signature algorithm OID. + + The purpose of the ResponderID information is to allow clients to + find the certificate used to sign a signed OCSP response. Therefore, + the information MUST correspond to the certificate that was used to + sign the response. + + The responder MAY include certificates in the certs field of + BasicOCSPResponse that help the OCSP client verify the responder's + signature. + + + + + +Santesson, et al. Standards Track [Page 18] + +RFC 6960 PKIX OCSP June 2013 + + + The response for each of the certificates in a request consists of: + + o an identifier of the certificate for which revocation status + information is being provided (i.e., the target certificate); + + o the revocation status of the certificate (good, revoked, or + unknown); if revoked, it indicates the time at which the + certificate was revoked and, optionally, the reason why it was + revoked; + + o the validity interval of the response; and + + o optional extensions. + + The response MUST include a SingleResponse for each certificate in + the request. The response SHOULD NOT include any additional + SingleResponse elements, but, for example, OCSP responders that + pre-generate status responses might include additional SingleResponse + elements if necessary to improve response pre-generation performance + or cache efficiency (according to [RFC5019], Section 2.2.1). + +4.3. Mandatory and Optional Cryptographic Algorithms + + Clients that request OCSP services SHALL be capable of processing + responses signed using RSA with SHA-256 (identified by the + sha256WithRSAEncryption OID specified in [RFC4055]). Clients SHOULD + also be capable of processing responses signed using RSA with SHA-1 + (identified by the sha1WithRSAEncryption OID specified in [RFC3279]) + and the Digital Signature Algorithm (DSA) with SHA-1 (identified by + the id-dsa-with-sha1 OID specified in [RFC3279]). Clients MAY + support other algorithms. + +4.4. Extensions + + This section defines some standard extensions, based on the extension + model employed in X.509 version 3 certificates (see [RFC5280]). + Support for all extensions is optional for both clients and + responders. For each extension, the definition indicates its syntax, + processing performed by the OCSP responder, and any extensions that + are included in the corresponding response. + + + + + + + + + + + +Santesson, et al. Standards Track [Page 19] + +RFC 6960 PKIX OCSP June 2013 + + +4.4.1. Nonce + + The nonce cryptographically binds a request and a response to prevent + replay attacks. The nonce is included as one of the + requestExtensions in requests, while in responses it would be + included as one of the responseExtensions. In both the request and + the response, the nonce will be identified by the object identifier + id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. + + id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } + id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } + + Nonce ::= OCTET STRING + +4.4.2. CRL References + + It may be desirable for the OCSP responder to indicate the CRL on + which a revoked or onHold certificate is found. This can be useful + where OCSP is used between repositories, and also as an auditing + mechanism. The CRL may be specified by a URL (the URL at which the + CRL is available), a number (CRL number), or a time (the time at + which the relevant CRL was created). These extensions will be + specified as singleExtensions. The identifier for this extension + will be id-pkix-ocsp-crl, while the value will be CrlID. + + id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } + + CrlID ::= SEQUENCE { + crlUrl [0] EXPLICIT IA5String OPTIONAL, + crlNum [1] EXPLICIT INTEGER OPTIONAL, + crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } + + For the choice crlUrl, the IA5String will specify the URL at which + the CRL is available. For crlNum, the INTEGER will specify the value + of the CRL number extension of the relevant CRL. For crlTime, the + GeneralizedTime will indicate the time at which the relevant CRL was + issued. + +4.4.3. Acceptable Response Types + + An OCSP client MAY wish to specify the kinds of response types it + understands. To do so, it SHOULD use an extension with the OID + id-pkix-ocsp-response and the value AcceptableResponses. This + extension is included as one of the requestExtensions in requests. + The OIDs included in AcceptableResponses are the OIDs of the various + response types this client can accept (e.g., id-pkix-ocsp-basic). + + + + + +Santesson, et al. Standards Track [Page 20] + +RFC 6960 PKIX OCSP June 2013 + + + id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } + + AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER + + As noted in Section 4.2.1, OCSP responders SHALL be capable of + responding with responses of the id-pkix-ocsp-basic response type. + Correspondingly, OCSP clients SHALL be capable of receiving and + processing responses of the id-pkix-ocsp-basic response type. + +4.4.4. Archive Cutoff + + An OCSP responder MAY choose to retain revocation information beyond + a certificate's expiration. The date obtained by subtracting this + retention interval value from the producedAt time in a response is + defined as the certificate's "archive cutoff" date. + + OCSP-enabled applications would use an OCSP archive cutoff date to + contribute to a proof that a digital signature was (or was not) + reliable on the date it was produced even if the certificate needed + to validate the signature has long since expired. + + OCSP servers that provide support for such a historical reference + SHOULD include an archive cutoff date extension in responses. If + included, this value SHALL be provided as an OCSP singleExtensions + extension identified by id-pkix-ocsp-archive-cutoff and of syntax + GeneralizedTime. + + id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= {id-pkix-ocsp 6} + + ArchiveCutoff ::= GeneralizedTime + + To illustrate, if a server is operated with a 7-year retention + interval policy and status was produced at time t1, then the value + for ArchiveCutoff in the response would be (t1 - 7 years). + +4.4.5. CRL Entry Extensions + + All the extensions specified as CRL entry extensions -- in + Section 5.3 of [RFC5280] -- are also supported as singleExtensions. + + + + + + + + + + + + +Santesson, et al. Standards Track [Page 21] + +RFC 6960 PKIX OCSP June 2013 + + +4.4.6. Service Locator + + An OCSP server may be operated in a mode whereby the server receives + a request and routes it to the OCSP server that is known to be + authoritative for the identified certificate. The serviceLocator + request extension is defined for this purpose. This extension is + included as one of the singleRequestExtensions in requests. + + id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp 7} + + ServiceLocator ::= SEQUENCE { + issuer Name, + locator AuthorityInfoAccessSyntax OPTIONAL } + + Values for these fields are obtained from the corresponding fields in + the subject certificate. + +4.4.7. Preferred Signature Algorithms + + Since algorithms other than the mandatory-to-implement algorithms are + allowed, and since a client currently has no mechanism to indicate + its algorithm preferences, there is always a risk that a server + choosing a non-mandatory algorithm will generate a response that the + client may not support. + + While an OCSP responder may apply rules for algorithm selection, + e.g., using the signature algorithm employed by the CA for signing + CRLs and certificates, such rules may fail in common situations: + + o The algorithm used to sign the CRLs and certificates may not be + consistent with the key pair being used by the OCSP responder to + sign responses. + + o A request for an unknown certificate provides no basis for a + responder to select from among multiple algorithm options. + + The last criterion cannot be resolved through the information + available from in-band signaling using the RFC 2560 [RFC2560] + protocol without modifying the protocol. + + + + + + + + + + + + +Santesson, et al. Standards Track [Page 22] + +RFC 6960 PKIX OCSP June 2013 + + + In addition, an OCSP responder may wish to employ different signature + algorithms than the one used by the CA to sign certificates and CRLs + for two reasons: + + o The responder may employ an algorithm for certificate status + response that is less computationally demanding than for signing + the certificate itself. + + o An implementation may wish to guard against the possibility of a + compromise resulting from a signature algorithm compromise by + employing two separate signature algorithms. + + This section describes: + + o An extension that allows a client to indicate the set of preferred + signature algorithms. + + o Rules for signature algorithm selection that maximize the + probability of successful operation in the case that no supported + preferred algorithm(s) are specified. + +4.4.7.1. Extension Syntax + + A client MAY declare a preferred set of algorithms in a request by + including a preferred signature algorithms extension in + requestExtensions of the OCSPRequest. + + id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } + + PreferredSignatureAlgorithms ::= SEQUENCE OF + PreferredSignatureAlgorithm + + PreferredSignatureAlgorithm ::= SEQUENCE { + sigIdentifier AlgorithmIdentifier, + pubKeyAlgIdentifier SMIMECapability OPTIONAL + } + + The syntax of AlgorithmIdentifier is defined in Section 4.1.1.2 of + RFC 5280 [RFC5280]. The syntax of SMIMECapability is defined in + RFC 5751 [RFC5751]. + + sigIdentifier specifies the signature algorithm the client prefers, + e.g., algorithm=ecdsa-with-sha256. Parameters are absent for most + common signature algorithms. + + + + + + + +Santesson, et al. Standards Track [Page 23] + +RFC 6960 PKIX OCSP June 2013 + + + pubKeyAlgIdentifier specifies the subject public key algorithm + identifier the client prefers in the server's certificate used to + validate the OCSP response, e.g., algorithm=id-ecPublicKey and + parameters= secp256r1. + + pubKeyAlgIdentifier is OPTIONAL and provides a means to specify + parameters necessary to distinguish among different usages of a + particular algorithm, e.g., it may be used by the client to specify + what curve it supports for a given elliptic curve algorithm. + + The client MUST support each of the specified preferred signature + algorithms, and the client MUST specify the algorithms in the order + of preference, from the most preferred to the least preferred. + + Section 4.4.7.2 of this document describes how a server selects an + algorithm for signing OCSP responses to the requesting client. + +4.4.7.2. Responder Signature Algorithm Selection + + RFC 2560 [RFC2560] did not specify a mechanism for deciding the + signature algorithm to be used in an OCSP response. This does not + provide a sufficient degree of certainty as to the algorithm selected + to facilitate interoperability. + +4.4.7.2.1. Dynamic Response + + A responder MAY maximize the potential for ensuring interoperability + by selecting a supported signature algorithm using the following + order of precedence, as long as the selected algorithm meets all + security requirements of the OCSP responder, where the first + selection mechanism has the highest precedence: + + 1. Select an algorithm specified as a preferred signature algorithm + in the client request. + + 2. Select the signature algorithm used to sign a certificate + revocation list (CRL) issued by the certificate issuer providing + status information for the certificate specified by CertID. + + 3. Select the signature algorithm used to sign the OCSPRequest. + + 4. Select a signature algorithm that has been advertised as being the + default signature algorithm for the signing service using an + out-of-band mechanism. + + 5. Select a mandatory or recommended signature algorithm specified + for the version of OCSP in use. + + + + +Santesson, et al. Standards Track [Page 24] + +RFC 6960 PKIX OCSP June 2013 + + + A responder SHOULD always apply the lowest-numbered selection + mechanism that results in the selection of a known and supported + algorithm that meets the responder's criteria for cryptographic + algorithm strength. + +4.4.7.2.2. Static Response + + For purposes of efficiency, an OCSP responder is permitted to + generate static responses in advance of a request. The case may not + permit the responder to make use of the client request data during + the response generation; however, the responder SHOULD still use the + client request data during the selection of the pre-generated + response to be returned. Responders MAY use the historical client + requests as part of the input to the decisions of what different + algorithms should be used to sign the pre-generated responses. + +4.4.8. Extended Revoked Definition + + This extension indicates that the responder supports the extended + definition of the "revoked" status to also include non-issued + certificates according to Section 2.2. One of its main purposes is + to allow audits to determine the responder's type of operation. + Clients do not have to parse this extension in order to determine the + status of certificates in responses. + + This extension MUST be included in the OCSP response when that + response contains a "revoked" status for a non-issued certificate. + This extension MAY be present in other responses to signal that the + responder implements the extended revoked definition. When included, + this extension MUST be placed in responseExtensions, and it MUST NOT + appear in singleExtensions. + + This extension is identified by the object identifier + id-pkix-ocsp-extended-revoke. + + id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= {id-pkix-ocsp 9} + + The value of the extension SHALL be NULL. This extension MUST NOT be + marked critical. + + + + + + + + + + + + +Santesson, et al. Standards Track [Page 25] + +RFC 6960 PKIX OCSP June 2013 + + +5. Security Considerations + + For this service to be effective, certificate-using systems must + connect to the certificate status service provider. In the event + such a connection cannot be obtained, certificate-using systems could + implement CRL processing logic as a fall-back position. + + A vulnerability to denial of service is evident with respect to a + flood of queries. The production of a cryptographic signature + significantly affects response generation cycle time, thereby + exacerbating the situation. Unsigned error responses open up the + protocol to another denial-of-service attack, where the attacker + sends false error responses. + + The use of precomputed responses allows replay attacks in which an + old (good) response is replayed prior to its expiration date but + after the certificate has been revoked. Deployments of OCSP should + carefully evaluate the benefit of precomputed responses against the + probability of a replay attack and the costs associated with its + successful execution. + + Requests do not contain the responder they are directed to. This + allows an attacker to replay a request to any number of OCSP + responders. + + The reliance of HTTP caching in some deployment scenarios may result + in unexpected results if intermediate servers are incorrectly + configured or are known to possess cache management faults. + Implementors are advised to take the reliability of HTTP cache + mechanisms into account when deploying OCSP over HTTP. + + Responding with a "revoked" state to a certificate that has never + been issued may enable someone to obtain a revocation response for a + certificate that is not yet issued, but soon will be issued, if the + certificate serial number of the certificate that will be issued can + be predicted or guessed by the requestor. Such a prediction is easy + for a CA that issues certificates using sequential certificate serial + number assignment. This risk is handled in the specification by + requiring compliant implementations to use the certificateHold reason + code, which avoids permanently revoking the serial number. For CAs + that support "revoked" responses to status requests for non-issued + certificates, one way to completely avoid this issue is to assign + random certificate serial number values with high entropy. + + + + + + + + +Santesson, et al. Standards Track [Page 26] + +RFC 6960 PKIX OCSP June 2013 + + +5.1. Preferred Signature Algorithms + + The mechanism used to choose the response signing algorithm MUST be + considered to be sufficiently secure against cryptanalytic attack for + the intended application. + + In most applications, it is sufficient for the signing algorithm to + be at least as secure as the signing algorithm used to sign the + original certificate whose status is being queried. However, this + criterion may not hold in long-term archival applications, in which + the status of a certificate is being queried for a date in the + distant past, long after the signing algorithm has ceased being + considered trustworthy. + +5.1.1. Use of Insecure Algorithms + + It is not always possible for a responder to generate a response that + the client is expected to understand and that meets contemporary + standards for cryptographic security. In such cases, an OCSP + responder operator MUST balance the risk of employing a compromised + security solution and the cost of mandating an upgrade, including the + risk that the alternative chosen by end users will offer even less + security or no security. + + In archival applications, it is quite possible that an OCSP responder + might be asked to report the validity of a certificate on a date in + the distant past. Such a certificate might employ a signing method + that is no longer considered acceptably secure. In such + circumstances, the responder MUST NOT generate a signature using a + signing mechanism that is not considered acceptably secure. + + A client MUST accept any signing algorithm in a response that it + specified as a preferred signing algorithm in the request. It + follows, therefore, that a client MUST NOT specify as a preferred + signing algorithm any algorithm that is either not supported or not + considered acceptably secure. + +5.1.2. Man-in-the-Middle Downgrade Attack + + The mechanism to support client indication of preferred signature + algorithms is not protected against a man-in-the-middle downgrade + attack. This constraint is not considered to be a significant + security concern, since the OCSP responder MUST NOT sign OCSP + responses using weak algorithms even if requested by the client. In + addition, the client can reject OCSP responses that do not meet its + own criteria for acceptable cryptographic security no matter what + mechanism is used to determine the signing algorithm of the response. + + + + +Santesson, et al. Standards Track [Page 27] + +RFC 6960 PKIX OCSP June 2013 + + +5.1.3. Denial-of-Service Attack + + Algorithm agility mechanisms defined in this document introduce a + slightly increased attack surface for denial-of-service attacks where + the client request is altered to require algorithms that are not + supported by the server. Denial-of-service considerations as + discussed in RFC 4732 [RFC4732] are relevant for this document. + +6. IANA Considerations + + This document includes media type registrations (in Appendix C) for + ocsp-request and ocsp-response that were registered when RFC 2560 was + published. Because this document obsoletes RFC 2560, IANA has + updated the references in the "Application Media Types" registry for + ocsp-request and ocsp-response to point to this document. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and + Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 3279, April 2002. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional + Algorithms and Identifiers for RSA Cryptography for use in + the Internet X.509 Public Key Infrastructure Certificate + and Certificate Revocation List (CRL) Profile", RFC 4055, + June 2005. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, May 2008. + + + + + +Santesson, et al. Standards Track [Page 28] + +RFC 6960 PKIX OCSP June 2013 + + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet + Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, January 2010. + + [RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate + Status Protocol Algorithm Agility", RFC 6277, June 2011. + + [X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, + "Information Technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER)", November 2008. + +7.2. Informative References + + [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. + Adams, "X.509 Internet Public Key Infrastructure Online + Certificate Status Protocol - OCSP", RFC 2560, June 1999. + + [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet + Denial-of-Service Considerations", RFC 4732, + December 2006. + + [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online + Certificate Status Protocol (OCSP) Profile for High-Volume + Environments", RFC 5019, September 2007. + + [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the + Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, + June 2010. + +8. Acknowledgements + + Development of this document has been made possible thanks to + extensive inputs from members of the PKIX working group. + + Jim Schaad provided valuable support by compiling and checking the + ASN.1 modules of this specification. + + + + + + + + + + + + + +Santesson, et al. Standards Track [Page 29] + +RFC 6960 PKIX OCSP June 2013 + + +Appendix A. OCSP over HTTP + + This section describes the formatting that will be done to the + request and response to support HTTP [RFC2616]. + +A.1. Request + + HTTP-based OCSP requests can use either the GET or the POST method to + submit their requests. To enable HTTP caching, small requests (that + after encoding are less than 255 bytes) MAY be submitted using GET. + If HTTP caching is not important or if the request is greater than + 255 bytes, the request SHOULD be submitted using POST. Where privacy + is a requirement, OCSP transactions exchanged using HTTP MAY be + protected using either Transport Layer Security/Secure Socket Layer + (TLS/SSL) or some other lower-layer protocol. + + An OCSP request using the GET method is constructed as follows: + + GET {url}/{url-encoding of base-64 encoding of the DER encoding of + the OCSPRequest} + + where {url} may be derived from the value of the authority + information access extension in the certificate being checked for + revocation, or other local configuration of the OCSP client. + + An OCSP request using the POST method is constructed as follows: The + Content-Type header has the value "application/ocsp-request", while + the body of the message is the binary value of the DER encoding of + the OCSPRequest. + +A.2. Response + + An HTTP-based OCSP response is composed of the appropriate HTTP + headers, followed by the binary value of the DER encoding of the + OCSPResponse. The Content-Type header has the value + "application/ocsp-response". The Content-Length header SHOULD + specify the length of the response. Other HTTP headers MAY be + present and MAY be ignored if not understood by the requestor. + +Appendix B. ASN.1 Modules + + This appendix includes the ASN.1 modules for OCSP. Appendix B.1 + includes an ASN.1 module that conforms to the 1998 version of ASN.1 + for all syntax elements of OCSP, including the preferred signature + algorithms extension that was defined in [RFC6277]. This module + replaces the modules in Appendix B of [RFC2560] and Appendix A.2 of + [RFC6277]. Appendix B.2 includes an ASN.1 module, corresponding to + the module present in B.1, that conforms to the 2008 version of + + + +Santesson, et al. Standards Track [Page 30] + +RFC 6960 PKIX OCSP June 2013 + + + ASN.1. This module replaces the modules in Section 12 of [RFC5912] + and Appendix A.1 of [RFC6277]. Although a 2008 ASN.1 module is + provided, the module in Appendix B.1 remains the normative module as + per the policy of the PKIX working group. + +B.1. OCSP in ASN.1 - 1998 Syntax + +OCSP-2013-88 + {iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-ocsp-2013-88(81)} + +DEFINITIONS EXPLICIT TAGS ::= + +BEGIN + +IMPORTS + + -- PKIX Certificate Extensions + AuthorityInfoAccessSyntax, CRLReason, GeneralName + FROM PKIX1Implicit88 { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) + id-mod(0) id-pkix1-implicit(19) } + + Name, CertificateSerialNumber, Extensions, + id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier + FROM PKIX1Explicit88 { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) + id-mod(0) id-pkix1-explicit(18) }; + +OCSPRequest ::= SEQUENCE { + tbsRequest TBSRequest, + optionalSignature [0] EXPLICIT Signature OPTIONAL } + +TBSRequest ::= SEQUENCE { + version [0] EXPLICIT Version DEFAULT v1, + requestorName [1] EXPLICIT GeneralName OPTIONAL, + requestList SEQUENCE OF Request, + requestExtensions [2] EXPLICIT Extensions OPTIONAL } + +Signature ::= SEQUENCE { + signatureAlgorithm AlgorithmIdentifier, + signature BIT STRING, + certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } + +Version ::= INTEGER { v1(0) } + + + + + +Santesson, et al. Standards Track [Page 31] + +RFC 6960 PKIX OCSP June 2013 + + +Request ::= SEQUENCE { + reqCert CertID, + singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } + +CertID ::= SEQUENCE { + hashAlgorithm AlgorithmIdentifier, + issuerNameHash OCTET STRING, -- Hash of issuer's DN + issuerKeyHash OCTET STRING, -- Hash of issuer's public key + serialNumber CertificateSerialNumber } + +OCSPResponse ::= SEQUENCE { + responseStatus OCSPResponseStatus, + responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } + +OCSPResponseStatus ::= ENUMERATED { + successful (0), -- Response has valid confirmations + malformedRequest (1), -- Illegal confirmation request + internalError (2), -- Internal error in issuer + tryLater (3), -- Try again later + -- (4) is not used + sigRequired (5), -- Must sign the request + unauthorized (6) -- Request unauthorized +} + +ResponseBytes ::= SEQUENCE { + responseType OBJECT IDENTIFIER, + response OCTET STRING } + +BasicOCSPResponse ::= SEQUENCE { + tbsResponseData ResponseData, + signatureAlgorithm AlgorithmIdentifier, + signature BIT STRING, + certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } + +ResponseData ::= SEQUENCE { + version [0] EXPLICIT Version DEFAULT v1, + responderID ResponderID, + producedAt GeneralizedTime, + responses SEQUENCE OF SingleResponse, + responseExtensions [1] EXPLICIT Extensions OPTIONAL } + +ResponderID ::= CHOICE { + byName [1] Name, + byKey [2] KeyHash } + + + + + + + +Santesson, et al. Standards Track [Page 32] + +RFC 6960 PKIX OCSP June 2013 + + +KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key + -- (i.e., the SHA-1 hash of the value of the + -- BIT STRING subjectPublicKey [excluding + -- the tag, length, and number of unused + -- bits] in the responder's certificate) + +SingleResponse ::= SEQUENCE { + certID CertID, + certStatus CertStatus, + thisUpdate GeneralizedTime, + nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, + singleExtensions [1] EXPLICIT Extensions OPTIONAL } + +CertStatus ::= CHOICE { + good [0] IMPLICIT NULL, + revoked [1] IMPLICIT RevokedInfo, + unknown [2] IMPLICIT UnknownInfo } + +RevokedInfo ::= SEQUENCE { + revocationTime GeneralizedTime, + revocationReason [0] EXPLICIT CRLReason OPTIONAL } + +UnknownInfo ::= NULL + +ArchiveCutoff ::= GeneralizedTime + +AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER + +ServiceLocator ::= SEQUENCE { + issuer Name, + locator AuthorityInfoAccessSyntax } + +CrlID ::= SEQUENCE { + crlUrl [0] EXPLICIT IA5String OPTIONAL, + crlNum [1] EXPLICIT INTEGER OPTIONAL, + crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } + +PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm + +PreferredSignatureAlgorithm ::= SEQUENCE { + sigIdentifier AlgorithmIdentifier, + certIdentifier AlgorithmIdentifier OPTIONAL } + + + + + + + + + +Santesson, et al. Standards Track [Page 33] + +RFC 6960 PKIX OCSP June 2013 + + +-- Object Identifiers + +id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } +id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } +id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } +id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } +id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } +id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } +id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } +id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } +id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } +id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } +id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 } + +END + +B.2. OCSP in ASN.1 - 2008 Syntax + +OCSP-2013-08 + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-2013-08(82)} + +DEFINITIONS EXPLICIT TAGS ::= + +BEGIN + +IMPORTS + +Extensions{}, EXTENSION, ATTRIBUTE +FROM PKIX-CommonTypes-2009 -- From [RFC5912] + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} + +AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY +FROM AlgorithmInformation-2009 -- From [RFC5912] + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) + id-mod-algorithmInformation-02(58)} + +AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions +FROM PKIX1Implicit-2009 -- From [RFC5912] + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} + +Name, CertificateSerialNumber, id-kp, id-ad-ocsp, Certificate +FROM PKIX1Explicit-2009 -- From [RFC5912] + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} + + + +Santesson, et al. Standards Track [Page 34] + +RFC 6960 PKIX OCSP June 2013 + + +sa-dsaWithSHA1, sa-rsaWithMD2, sa-rsaWithMD5, sa-rsaWithSHA1 +FROM PKIXAlgs-2009 -- From [RFC5912] + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-algorithms2008-02(56)}; + +OCSPRequest ::= SEQUENCE { + tbsRequest TBSRequest, + optionalSignature [0] EXPLICIT Signature OPTIONAL } + +TBSRequest ::= SEQUENCE { + version [0] EXPLICIT Version DEFAULT v1, + requestorName [1] EXPLICIT GeneralName OPTIONAL, + requestList SEQUENCE OF Request, + requestExtensions [2] EXPLICIT Extensions {{re-ocsp-nonce | + re-ocsp-response, ..., + re-ocsp-preferred-signature-algorithms}} OPTIONAL } + +Signature ::= SEQUENCE { + signatureAlgorithm AlgorithmIdentifier + { SIGNATURE-ALGORITHM, {...}}, + signature BIT STRING, + certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } + +Version ::= INTEGER { v1(0) } + +Request ::= SEQUENCE { + reqCert CertID, + singleRequestExtensions [0] EXPLICIT Extensions + { {re-ocsp-service-locator, + ...}} OPTIONAL } + +CertID ::= SEQUENCE { + hashAlgorithm AlgorithmIdentifier + {DIGEST-ALGORITHM, {...}}, + issuerNameHash OCTET STRING, -- Hash of issuer's DN + issuerKeyHash OCTET STRING, -- Hash of issuer's public key + serialNumber CertificateSerialNumber } + +OCSPResponse ::= SEQUENCE { + responseStatus OCSPResponseStatus, + responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } + + + + + + + + + +Santesson, et al. Standards Track [Page 35] + +RFC 6960 PKIX OCSP June 2013 + + +OCSPResponseStatus ::= ENUMERATED { + successful (0), -- Response has valid confirmations + malformedRequest (1), -- Illegal confirmation request + internalError (2), -- Internal error in issuer + tryLater (3), -- Try again later + -- (4) is not used + sigRequired (5), -- Must sign the request + unauthorized (6) -- Request unauthorized +} + +RESPONSE ::= TYPE-IDENTIFIER + +ResponseSet RESPONSE ::= {basicResponse, ...} + +ResponseBytes ::= SEQUENCE { + responseType RESPONSE. + &id ({ResponseSet}), + response OCTET STRING (CONTAINING RESPONSE. + &Type({ResponseSet}{@responseType}))} + +basicResponse RESPONSE ::= + { BasicOCSPResponse IDENTIFIED BY id-pkix-ocsp-basic } + +BasicOCSPResponse ::= SEQUENCE { + tbsResponseData ResponseData, + signatureAlgorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM, + {sa-dsaWithSHA1 | sa-rsaWithSHA1 | + sa-rsaWithMD5 | sa-rsaWithMD2, ...}}, + signature BIT STRING, + certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } + +ResponseData ::= SEQUENCE { + version [0] EXPLICIT Version DEFAULT v1, + responderID ResponderID, + producedAt GeneralizedTime, + responses SEQUENCE OF SingleResponse, + responseExtensions [1] EXPLICIT Extensions + {{re-ocsp-nonce, ..., + re-ocsp-extended-revoke}} OPTIONAL } + +ResponderID ::= CHOICE { + byName [1] Name, + byKey [2] KeyHash } + +KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key + -- (excluding the tag and length fields) + + + + + +Santesson, et al. Standards Track [Page 36] + +RFC 6960 PKIX OCSP June 2013 + + +SingleResponse ::= SEQUENCE { + certID CertID, + certStatus CertStatus, + thisUpdate GeneralizedTime, + nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, + singleExtensions [1] EXPLICIT Extensions{{re-ocsp-crl | + re-ocsp-archive-cutoff | + CrlEntryExtensions, ...} + } OPTIONAL } + +CertStatus ::= CHOICE { + good [0] IMPLICIT NULL, + revoked [1] IMPLICIT RevokedInfo, + unknown [2] IMPLICIT UnknownInfo } + +RevokedInfo ::= SEQUENCE { + revocationTime GeneralizedTime, + revocationReason [0] EXPLICIT CRLReason OPTIONAL } + +UnknownInfo ::= NULL + +ArchiveCutoff ::= GeneralizedTime + +AcceptableResponses ::= SEQUENCE OF RESPONSE.&id({ResponseSet}) + +ServiceLocator ::= SEQUENCE { + issuer Name, + locator AuthorityInfoAccessSyntax } + +CrlID ::= SEQUENCE { + crlUrl [0] EXPLICIT IA5String OPTIONAL, + crlNum [1] EXPLICIT INTEGER OPTIONAL, + crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } + +PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm + +PreferredSignatureAlgorithm ::= SEQUENCE { + sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}}, + certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL +} + +-- Certificate Extensions + +ext-ocsp-nocheck EXTENSION ::= { SYNTAX NULL IDENTIFIED + BY id-pkix-ocsp-nocheck } + + + + + + +Santesson, et al. Standards Track [Page 37] + +RFC 6960 PKIX OCSP June 2013 + + +-- Request Extensions + +re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED + BY id-pkix-ocsp-nonce } + +re-ocsp-response EXTENSION ::= { SYNTAX AcceptableResponses IDENTIFIED + BY id-pkix-ocsp-response } + +re-ocsp-service-locator EXTENSION ::= { SYNTAX ServiceLocator + IDENTIFIED BY + id-pkix-ocsp-service-locator } + +re-ocsp-preferred-signature-algorithms EXTENSION ::= { + SYNTAX PreferredSignatureAlgorithms + IDENTIFIED BY id-pkix-ocsp-pref-sig-algs } + +-- Response Extensions + +re-ocsp-crl EXTENSION ::= { SYNTAX CrlID IDENTIFIED BY + id-pkix-ocsp-crl } + +re-ocsp-archive-cutoff EXTENSION ::= { SYNTAX ArchiveCutoff + IDENTIFIED BY + id-pkix-ocsp-archive-cutoff } + +re-ocsp-extended-revoke EXTENSION ::= { SYNTAX NULL IDENTIFIED BY + id-pkix-ocsp-extended-revoke } + +-- Object Identifiers + +id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } +id-pkix-ocsp OBJECT IDENTIFIER ::= id-ad-ocsp +id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } +id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } +id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } +id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } +id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } +id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } +id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } +id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } +id-pkix-ocsp-extended-revoke OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 } + +END + + + + + + + + +Santesson, et al. Standards Track [Page 38] + +RFC 6960 PKIX OCSP June 2013 + + +Appendix C. MIME Registrations + +C.1. application/ocsp-request + + To: ietf-types@iana.org + Subject: Registration of MIME media type application/ocsp-request + + MIME media type name: application + + MIME subtype name: ocsp-request + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries a request for information. This + request may optionally be cryptographically signed. + + Interoperability considerations: None + + Published specification: IETF PKIX Working Group document on the + Online Certificate Status Protocol - OCSP + + Applications which use this media type: OCSP clients + + Additional information: + + Magic number(s): None + File extension(s): .ORQ + Macintosh File Type Code(s): none + + Person & email address to contact for further information: + Stefan Santesson + + Intended usage: COMMON + + Author/Change controller: IETF + + + + + + + + + + + + +Santesson, et al. Standards Track [Page 39] + +RFC 6960 PKIX OCSP June 2013 + + +C.2. application/ocsp-response + + To: ietf-types@iana.org + Subject: Registration of MIME media type application/ocsp-response + + MIME media type name: application + + MIME subtype name: ocsp-response + + Required parameters: None + + Optional parameters: None + + Encoding considerations: binary + + Security considerations: Carries a cryptographically signed response. + + Interoperability considerations: None + + Published specification: IETF PKIX Working Group document on the + Online Certificate Status Protocol - OCSP + + Applications which use this media type: OCSP servers + + Additional information: + + Magic number(s): None + File extension(s): .ORS + Macintosh File Type Code(s): none + + Person & email address to contact for further information: + Stefan Santesson + + Intended usage: COMMON + + Author/Change controller: IETF + + + + + + + + + + + + + + + +Santesson, et al. Standards Track [Page 40] + +RFC 6960 PKIX OCSP June 2013 + + +Authors' Addresses + + Stefan Santesson + 3xA Security AB + Scheelev. 17 + 223 70 Lund + Sweden + + EMail: sts@aaa-sec.com + + + Michael Myers + TraceRoute Security + + EMail: mmyers@fastq.com + + + Rich Ankney + + + Ambarish Malpani + CA Technologies + 455 West Maude Ave. Suite 210 + Sunnyvale, CA 94085 + United States + + EMail: ambarish@gmail.com + + + Slava Galperin + A9.com Inc. + 130 Lytton Ave. Suite 300 + Palo Alto, CA 94301 + United States + + EMail: slava.galperin@gmail.com + + + Carlisle Adams + University of Ottawa + 800 King Edward Avenue + Ottawa ON K1N 6N5 + Canada + + EMail: cadams@eecs.uottawa.ca + + + + + + +Santesson, et al. Standards Track [Page 41] + diff --git a/compliance/specs/www.rfc-editor.org/rfc/rfc7301.txt b/compliance/specs/www.rfc-editor.org/rfc/rfc7301.txt new file mode 100644 index 00000000000..717f9f4c74e --- /dev/null +++ b/compliance/specs/www.rfc-editor.org/rfc/rfc7301.txt @@ -0,0 +1,507 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Friedl +Request for Comments: 7301 Cisco Systems, Inc. +Category: Standards Track A. Popov +ISSN: 2070-1721 Microsoft Corp. + A. Langley + Google Inc. + E. Stephan + Orange + July 2014 + + + Transport Layer Security (TLS) + Application-Layer Protocol Negotiation Extension + +Abstract + + This document describes a Transport Layer Security (TLS) extension + for application-layer protocol negotiation within the TLS handshake. + For instances in which multiple application protocols are supported + on the same TCP or UDP port, this extension allows the application + layer to negotiate which protocol will be used within the TLS + connection. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7301. + + + + + + + + + + + + + + + +Friedl, et al. Standards Track [Page 1] + +RFC 7301 TLS App-Layer Protocol Negotiation Ext July 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 + 3. Application-Layer Protocol Negotiation . . . . . . . . . . . 3 + 3.1. The Application-Layer Protocol Negotiation Extension . . 3 + 3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 5 + 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 6 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 8.2. Informative References . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + Increasingly, application-layer protocols are encapsulated in the TLS + protocol [RFC5246]. This encapsulation enables applications to use + the existing, secure communications links already present on port 443 + across virtually the entire global IP infrastructure. + + When multiple application protocols are supported on a single server- + side port number, such as port 443, the client and the server need to + negotiate an application protocol for use with each connection. It + is desirable to accomplish this negotiation without adding network + round-trips between the client and the server, as each round-trip + will degrade an end-user's experience. Further, it would be + advantageous to allow certificate selection based on the negotiated + application protocol. + + + + + + +Friedl, et al. Standards Track [Page 2] + +RFC 7301 TLS App-Layer Protocol Negotiation Ext July 2014 + + + This document specifies a TLS extension that permits the application + layer to negotiate protocol selection within the TLS handshake. This + work was requested by the HTTPbis WG to address the negotiation of + HTTP/2 ([HTTP2]) over TLS; however, ALPN facilitates negotiation of + arbitrary application-layer protocols. + + With ALPN, the client sends the list of supported application + protocols as part of the TLS ClientHello message. The server chooses + a protocol and sends the selected protocol as part of the TLS + ServerHello message. The application protocol negotiation can thus + be accomplished within the TLS handshake, without adding network + round-trips, and allows the server to associate a different + certificate with each application protocol, if desired. + +2. Requirements Language + + 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 [RFC2119]. + +3. Application-Layer Protocol Negotiation + +3.1. The Application-Layer Protocol Negotiation Extension + + A new extension type ("application_layer_protocol_negotiation(16)") + is defined and MAY be included by the client in its "ClientHello" + message. + + enum { + application_layer_protocol_negotiation(16), (65535) + } ExtensionType; + + The "extension_data" field of the + ("application_layer_protocol_negotiation(16)") extension SHALL + contain a "ProtocolNameList" value. + + opaque ProtocolName<1..2^8-1>; + + struct { + ProtocolName protocol_name_list<2..2^16-1> + } ProtocolNameList; + + "ProtocolNameList" contains the list of protocols advertised by the + client, in descending order of preference. Protocols are named by + IANA-registered, opaque, non-empty byte strings, as described further + in Section 6 ("IANA Considerations") of this document. Empty strings + MUST NOT be included and byte strings MUST NOT be truncated. + + + + +Friedl, et al. Standards Track [Page 3] + +RFC 7301 TLS App-Layer Protocol Negotiation Ext July 2014 + + + Servers that receive a ClientHello containing the + "application_layer_protocol_negotiation" extension MAY return a + suitable protocol selection response to the client. The server will + ignore any protocol name that it does not recognize. A new + ServerHello extension type + ("application_layer_protocol_negotiation(16)") MAY be returned to the + client within the extended ServerHello message. The "extension_data" + field of the ("application_layer_protocol_negotiation(16)") extension + is structured the same as described above for the client + "extension_data", except that the "ProtocolNameList" MUST contain + exactly one "ProtocolName". + + Therefore, a full handshake with the + "application_layer_protocol_negotiation" extension in the ClientHello + and ServerHello messages has the following flow (contrast with + Section 7.3 of [RFC5246]): + + Client Server + + ClientHello --------> ServerHello + (ALPN extension & (ALPN extension & + list of protocols) selected protocol) + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + Figure 1 + + * Indicates optional or situation-dependent messages that are not + always sent. + + + + + + + + + + + + +Friedl, et al. Standards Track [Page 4] + +RFC 7301 TLS App-Layer Protocol Negotiation Ext July 2014 + + + An abbreviated handshake with the + "application_layer_protocol_negotiation" extension has the following + flow: + + Client Server + + ClientHello --------> ServerHello + (ALPN extension & (ALPN extension & + list of protocols) selected protocol) + [ChangeCipherSpec] + <-------- Finished + [ChangeCipherSpec] + Finished --------> + Application Data <-------> Application Data + + Figure 2 + + Unlike many other TLS extensions, this extension does not establish + properties of the session, only of the connection. When session + resumption or session tickets [RFC5077] are used, the previous + contents of this extension are irrelevant, and only the values in the + new handshake messages are considered. + +3.2. Protocol Selection + + It is expected that a server will have a list of protocols that it + supports, in preference order, and will only select a protocol if the + client supports it. In that case, the server SHOULD select the most + highly preferred protocol that it supports and that is also + advertised by the client. In the event that the server supports no + protocols that the client advertises, then the server SHALL respond + with a fatal "no_application_protocol" alert. + + enum { + no_application_protocol(120), + (255) + } AlertDescription; + + The protocol identified in the + "application_layer_protocol_negotiation" extension type in the + ServerHello SHALL be definitive for the connection, until + renegotiated. The server SHALL NOT respond with a selected protocol + and subsequently use a different protocol for application data + exchange. + + + + + + + +Friedl, et al. Standards Track [Page 5] + +RFC 7301 TLS App-Layer Protocol Negotiation Ext July 2014 + + +4. Design Considerations + + The ALPN extension is intended to follow the typical design of TLS + protocol extensions. Specifically, the negotiation is performed + entirely within the client/server hello exchange in accordance with + the established TLS architecture. The + "application_layer_protocol_negotiation" ServerHello extension is + intended to be definitive for the connection (until the connection is + renegotiated) and is sent in plaintext to permit network elements to + provide differentiated service for the connection when the TCP or UDP + port number is not definitive for the application-layer protocol to + be used in the connection. By placing ownership of protocol + selection on the server, ALPN facilitates scenarios in which + certificate selection or connection rerouting may be based on the + negotiated protocol. + + Finally, by managing protocol selection in the clear as part of the + handshake, ALPN avoids introducing false confidence with respect to + the ability to hide the negotiated protocol in advance of + establishing the connection. If hiding the protocol is required, + then renegotiation after connection establishment, which would + provide true TLS security guarantees, would be a preferred + methodology. + +5. Security Considerations + + The ALPN extension does not impact the security of TLS session + establishment or application data exchange. ALPN serves to provide + an externally visible marker for the application-layer protocol + associated with the TLS connection. Historically, the application- + layer protocol associated with a connection could be ascertained from + the TCP or UDP port number in use. + + Implementers and document editors who intend to extend the protocol + identifier registry by adding new protocol identifiers should + consider that in TLS versions 1.2 and below the client sends these + identifiers in the clear. They should also consider that, for at + least the next decade, it is expected that browsers would normally + use these earlier versions of TLS in the initial ClientHello. + + Care must be taken when such identifiers may leak personally + identifiable information, or when such leakage may lead to profiling + or to leaking of sensitive information. If any of these apply to + this new protocol identifier, the identifier SHOULD NOT be used in + TLS configurations where it would be visible in the clear, and + documents specifying such protocol identifiers SHOULD recommend + against such unsafe use. + + + + +Friedl, et al. Standards Track [Page 6] + +RFC 7301 TLS App-Layer Protocol Negotiation Ext July 2014 + + +6. IANA Considerations + + The IANA has updated its "ExtensionType Values" registry to include + the following entry: + + 16 application_layer_protocol_negotiation + + This document establishes a registry for protocol identifiers + entitled "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" + under the existing "Transport Layer Security (TLS) Extensions" + heading. + + Entries in this registry require the following fields: + + o Protocol: The name of the protocol. + o Identification Sequence: The precise set of octet values that + identifies the protocol. This could be the UTF-8 encoding + [RFC3629] of the protocol name. + o Reference: A reference to a specification that defines the + protocol. + + This registry operates under the "Expert Review" policy as defined in + [RFC5226]. The designated expert is advised to encourage the + inclusion of a reference to a permanent and readily available + specification that enables the creation of interoperable + implementations of the identified protocol. + + The initial set of registrations for this registry is as follows: + + Protocol: HTTP/1.1 + Identification Sequence: + 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1") + Reference: [RFC7230] + + Protocol: SPDY/1 + Identification Sequence: + 0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1") + Reference: + http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1 + + Protocol: SPDY/2 + Identification Sequence: + 0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2") + Reference: + http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2 + + + + + + +Friedl, et al. Standards Track [Page 7] + +RFC 7301 TLS App-Layer Protocol Negotiation Ext July 2014 + + + Protocol: SPDY/3 + Identification Sequence: + 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3") + Reference: + http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3 + +7. Acknowledgements + + This document benefitted specifically from the Next Protocol + Negotiation (NPN) extension document authored by Adam Langley and + from discussions with Tom Wesselman and Cullen Jennings, both of + Cisco. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol + (HTTP/1.1): Message Syntax and Routing", RFC 7230, June + 2014. + +8.2. Informative References + + [HTTP2] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer + Protocol version 2", Work in Progress, June 2014. + + [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, + "Transport Layer Security (TLS) Session Resumption without + Server-Side State", RFC 5077, January 2008. + + + + + + + + + +Friedl, et al. Standards Track [Page 8] + +RFC 7301 TLS App-Layer Protocol Negotiation Ext July 2014 + + +Authors' Addresses + + Stephan Friedl + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134 + USA + + Phone: (720)562-6785 + EMail: sfriedl@cisco.com + + + Andrei Popov + Microsoft Corp. + One Microsoft Way + Redmond, WA 98052 + USA + + EMail: andreipo@microsoft.com + + + Adam Langley + Google Inc. + USA + + EMail: agl@google.com + + + Emile Stephan + Orange + 2 avenue Pierre Marzin + Lannion F-22307 + France + + EMail: emile.stephan@orange.com + + + + + + + + + + + + + + + + +Friedl, et al. Standards Track [Page 9] + diff --git a/compliance/specs/www.rfc-editor.org/rfc/rfc8701.txt b/compliance/specs/www.rfc-editor.org/rfc/rfc8701.txt new file mode 100644 index 00000000000..90e0d102416 --- /dev/null +++ b/compliance/specs/www.rfc-editor.org/rfc/rfc8701.txt @@ -0,0 +1,582 @@ + + + + +Internet Engineering Task Force (IETF) D. Benjamin +Request for Comments: 8701 Google LLC +Category: Informational January 2020 +ISSN: 2070-1721 + + + Applying Generate Random Extensions And Sustain Extensibility (GREASE) + to TLS Extensibility + +Abstract + + This document describes GREASE (Generate Random Extensions And + Sustain Extensibility), a mechanism to prevent extensibility failures + in the TLS ecosystem. It reserves a set of TLS protocol values that + may be advertised to ensure peers correctly handle unknown values. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8701. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 1.1. Requirements Language + 2. GREASE Values + 3. Client-Initiated Extension Points + 3.1. Client Behavior + 3.2. Server Behavior + 4. Server-Initiated Extension Points + 4.1. Server Behavior + 4.2. Client Behavior + 5. Sending GREASE Values + 6. IANA Considerations + 7. Security Considerations + 8. Normative References + Acknowledgments + Author's Address + +1. Introduction + + The TLS protocol [RFC8446] includes several points of extensibility, + including the list of cipher suites and several lists of extensions. + The values transmitted in these lists identify implementation + capabilities. TLS follows a model where one side, usually the + client, advertises capabilities, and the peer, usually the server, + selects them. The responding side must ignore unknown values so that + new capabilities may be introduced to the ecosystem while maintaining + interoperability. + + However, bugs may cause an implementation to reject unknown values. + It will interoperate with existing peers, so the mistake may spread + through the ecosystem unnoticed. Later, when new values are defined, + updated peers will discover that the metaphorical joint in the + protocol has rusted shut and the new values cannot be deployed + without interoperability failures. + + To avoid this problem, this document reserves some currently unused + values for TLS implementations to advertise at random. Correctly + implemented peers will ignore these values and interoperate. Peers + that do not tolerate unknown values will fail to interoperate, + revealing the mistake before it is widespread. + + In keeping with the rusted joint metaphor, this technique is called + "GREASE" (Generate Random Extensions And Sustain Extensibility). + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. GREASE Values + + This document reserves a number of TLS protocol values, referred to + as GREASE values. These values were allocated sparsely to discourage + server implementations from conditioning on them. For convenience, + they were also chosen so all types share a number scheme with a + consistent pattern while avoiding collisions with any existing + applicable registries in TLS. + + The following values are reserved as GREASE values for cipher suites + and Application-Layer Protocol Negotiation (ALPN) [RFC7301] + identifiers: + + {0x0A,0x0A} + + {0x1A,0x1A} + + {0x2A,0x2A} + + {0x3A,0x3A} + + {0x4A,0x4A} + + {0x5A,0x5A} + + {0x6A,0x6A} + + {0x7A,0x7A} + + {0x8A,0x8A} + + {0x9A,0x9A} + + {0xAA,0xAA} + + {0xBA,0xBA} + + {0xCA,0xCA} + + {0xDA,0xDA} + + {0xEA,0xEA} + + {0xFA,0xFA} + + The following values are reserved as GREASE values for extensions, + named groups, signature algorithms, and versions: + + 0x0A0A + + 0x1A1A + + 0x2A2A + + 0x3A3A + + 0x4A4A + + 0x5A5A + + 0x6A6A + + 0x7A7A + + 0x8A8A + + 0x9A9A + + 0xAAAA + + 0xBABA + + 0xCACA + + 0xDADA + + 0xEAEA + + 0xFAFA + + The values allocated above are thus no longer available for use as + TLS or DTLS [RFC6347] version numbers. + + The following values are reserved as GREASE values for + PskKeyExchangeModes: + + 0x0B + + 0x2A + + 0x49 + + 0x68 + + 0x87 + + 0xA6 + + 0xC5 + + 0xE4 + +3. Client-Initiated Extension Points + + Most extension points in TLS are offered by the client and selected + by the server. This section details client and server behavior + around GREASE values for these. + +3.1. Client Behavior + + When sending a ClientHello, a client MAY behave as follows: + + * A client MAY select one or more GREASE cipher suite values and + advertise them in the "cipher_suites" field. + + * A client MAY select one or more GREASE extension values and + advertise them as extensions with varying length and contents. + + * A client MAY select one or more GREASE named group values and + advertise them in the "supported_groups" extension, if sent. It + MAY also send KeyShareEntry values for a subset of those selected + in the "key_share" extension. For each of these, the + "key_exchange" field MAY be any value. + + * A client MAY select one or more GREASE signature algorithm values + and advertise them in the "signature_algorithms" or + "signature_algorithms_cert" extensions, if sent. + + * A client MAY select one or more GREASE version values and + advertise them in the "supported_versions" extension, if sent. + + * A client MAY select one or more GREASE PskKeyExchangeMode values + and advertise them in the "psk_key_exchange_modes" extension, if + sent. + + * A client MAY select one or more GREASE ALPN identifiers and + advertise them in the "application_layer_protocol_negotiation" + extension, if sent. + + Clients MUST reject GREASE values when negotiated by the server. In + particular, the client MUST fail the connection if a GREASE value + appears in any of the following: + + * The "version" value in a ServerHello or HelloRetryRequest + + * The "cipher_suite" value in a ServerHello + + * Any ServerHello extension + + * Any HelloRetryRequest, EncryptedExtensions, or Certificate + extension in TLS 1.3 + + * The "namedcurve" value in a ServerKeyExchange for an Ephemeral + Elliptic Curve Diffie-Hellman (ECDHE) cipher in TLS 1.2 [RFC5246] + or earlier + + * The signature algorithm in a ServerKeyExchange signature in TLS + 1.2 or earlier + + * The signature algorithm in a server CertificateVerify signature in + TLS 1.3 + + Note that this can be implemented without special processing on the + client. The client is already required to reject unknown server- + selected values, so it may leave GREASE values as unknown and reuse + the existing logic. + +3.2. Server Behavior + + When processing a ClientHello, servers MUST NOT treat GREASE values + differently from any unknown value. Servers MUST NOT negotiate any + GREASE value when offered in a ClientHello. Servers MUST correctly + ignore unknown values in a ClientHello and attempt to negotiate with + one of the remaining parameters. (There may not be any known + parameters remaining, in which case parameter negotiation will fail.) + + Note that these requirements are restatements or corollaries of + existing server requirements in TLS. + +4. Server-Initiated Extension Points + + Some extension points are offered by the server and selected by the + client. This section details client and server behavior around + GREASE values for these. + +4.1. Server Behavior + + When sending a CertificateRequest in TLS 1.3, a server MAY behave as + follows: + + * A server MAY select one or more GREASE extension values and + advertise them as extensions with varying length and contents. + + * A server MAY select one or more GREASE signature algorithm values + and advertise them in the "signature_algorithms" or + "signature_algorithms_cert" extensions, if present. + + When sending a NewSessionTicket message in TLS 1.3, a server MAY + select one or more GREASE extension values and advertise them as + extensions with varying length and contents. + + Servers MUST reject GREASE values when negotiated by the client. In + particular, the server MUST fail the connection if a GREASE value + appears in any of the following: + + * Any Certificate extension in TLS 1.3 + + * The signature algorithm in a client CertificateVerify signature + + Note that this can be implemented without special processing on the + server. The server is already required to reject unknown client- + selected values, so it may leave GREASE values as unknown and reuse + the existing logic. + +4.2. Client Behavior + + When processing a CertificateRequest or NewSessionTicket, clients + MUST NOT treat GREASE values differently from any unknown value. + Clients MUST NOT negotiate any GREASE value when offered by the + server. Clients MUST correctly ignore unknown values offered by the + server and attempt to negotiate with one of the remaining parameters. + (There may not be any known parameters remaining, in which case + parameter negotiation will fail.) + + Note that these requirements are restatements or corollaries of + existing client requirements in TLS. + +5. Sending GREASE Values + + Implementations advertising GREASE values SHOULD select them at + random. This is intended to encourage implementations to ignore all + unknown values rather than any individual value. Implementations + MUST honor protocol specifications when sending GREASE values. For + instance, Section 4.2 of [RFC8446] forbids duplicate extension types + within a single extension block. Implementations sending multiple + GREASE extensions in a single block must therefore ensure the same + value is not selected twice. + + Implementations SHOULD balance diversity in GREASE advertisements + with determinism. For example, a client that randomly varies GREASE + value positions for each connection may only fail against a broken + server with some probability. This risks the failure being masked by + automatic retries. A client that positions GREASE values + deterministically over a period of time (such as a single software + release) stresses fewer cases but is more likely to detect bugs from + those cases. + +6. IANA Considerations + + This document updates the "TLS Cipher Suites" registry, available at + : + + +-------------+-------------+---------+-------------+-----------+ + | Value | Description | DTLS-OK | Recommended | Reference | + +=============+=============+=========+=============+===========+ + | {0x0A,0x0A} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0x1A,0x1A} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0x2A,0x2A} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0x3A,0x3A} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0x4A,0x4A} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0x5A,0x5A} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0x6A,0x6A} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0x7A,0x7A} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0x8A,0x8A} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0x9A,0x9A} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0xAA,0xAA} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0xBA,0xBA} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0xCA,0xCA} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0xDA,0xDA} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0xEA,0xEA} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + | {0xFA,0xFA} | Reserved | Y | N | [RFC8701] | + +-------------+-------------+---------+-------------+-----------+ + + Table 1: Additions to the TLS Cipher Suites Registry + + This document updates the "TLS Supported Groups" registry, available + at : + + +-------+-------------+---------+-------------+-----------+ + | Value | Description | DTLS-OK | Recommended | Reference | + +=======+=============+=========+=============+===========+ + | 2570 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 6682 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 10794 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 14906 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 19018 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 23130 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 27242 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 31354 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 35466 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 39578 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 43690 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 47802 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 51914 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 56026 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 60138 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + | 64250 | Reserved | Y | N | [RFC8701] | + +-------+-------------+---------+-------------+-----------+ + + Table 2: Additions to the TLS Supported Groups Registry + + This document updates the "TLS ExtensionType Values" registry, + available at : + + +-------+----------------+-------------+-------------+-----------+ + | Value | Extension Name | TLS 1.3 | Recommended | Reference | + +=======+================+=============+=============+===========+ + | 2570 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 6682 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 10794 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 14906 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 19018 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 23130 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 27242 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 31354 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 35466 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 39578 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 43690 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 47802 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 51914 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 56026 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 60138 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + | 64250 | Reserved | CH, CR, NST | N | [RFC8701] | + +-------+----------------+-------------+-------------+-----------+ + + Table 3: Additions to the TLS ExtensionType Values Registry + + This document updates the "TLS Application-Layer Protocol Negotiation + (ALPN) Protocol IDs" registry, available at + : + + +----------+-------------------------+-----------+ + | Protocol | Identification Sequence | Reference | + +==========+=========================+===========+ + | Reserved | 0x0A 0x0A | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0x1A 0x1A | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0x2A 0x2A | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0x3A 0x3A | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0x4A 0x4A | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0x5A 0x5A | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0x6A 0x6A | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0x7A 0x7A | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0x8A 0x8A | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0x9A 0x9A | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0xAA 0xAA | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0xBA 0xBA | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0xCA 0xCA | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0xDA 0xDA | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0xEA 0xEA | [RFC8701] | + +----------+-------------------------+-----------+ + | Reserved | 0xFA 0xFA | [RFC8701] | + +----------+-------------------------+-----------+ + + Table 4: Additions to the TLS Application- + Layer Protocol Negotiation (ALPN) Protocol IDs + Registry + +7. Security Considerations + + GREASE values cannot be negotiated, so they do not directly impact + the security of TLS connections. + + Historically, when interoperability problems arise in deploying new + TLS features, implementations have used a fallback retry on error + with the feature disabled. This allows an active attacker to + silently disable the new feature. By preventing a class of such + interoperability problems, GREASE reduces the need for this kind of + fallback. Implementations SHOULD NOT retry with GREASE disabled on + connection failure. While allowing an attacker to disable GREASE is + unlikely to have immediate security consequences, such a fallback + would prevent GREASE from defending against extensibility failures. + + If an implementation does not select GREASE values at random, it is + possible it will allow for fingerprinting of the implementation or + perhaps even of individual users. This can result in a negative + impact to a user's privacy. + +8. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, . + + [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, + "Transport Layer Security (TLS) Application-Layer Protocol + Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, + July 2014, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + +Acknowledgments + + The author would like to thank Adam Langley, Nick Harper, and Steven + Valdez for their feedback and suggestions. In addition, the rusted + joint metaphor is originally due to Adam Langley. + +Author's Address + + David Benjamin + Google LLC + + Email: davidben@google.com diff --git a/compliance/specs/www.rfc-editor.org/rfc/rfc9001.txt b/compliance/specs/www.rfc-editor.org/rfc/rfc9001.txt new file mode 100644 index 00000000000..331e4420723 --- /dev/null +++ b/compliance/specs/www.rfc-editor.org/rfc/rfc9001.txt @@ -0,0 +1,2756 @@ + + + + +Internet Engineering Task Force (IETF) M. Thomson, Ed. +Request for Comments: 9001 Mozilla +Category: Standards Track S. Turner, Ed. +ISSN: 2070-1721 sn3rd + May 2021 + + + Using TLS to Secure QUIC + +Abstract + + This document describes how Transport Layer Security (TLS) is used to + secure QUIC. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9001. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Notational Conventions + 2.1. TLS Overview + 3. Protocol Overview + 4. Carrying TLS Messages + 4.1. Interface to TLS + 4.1.1. Handshake Complete + 4.1.2. Handshake Confirmed + 4.1.3. Sending and Receiving Handshake Messages + 4.1.4. Encryption Level Changes + 4.1.5. TLS Interface Summary + 4.2. TLS Version + 4.3. ClientHello Size + 4.4. Peer Authentication + 4.5. Session Resumption + 4.6. 0-RTT + 4.6.1. Enabling 0-RTT + 4.6.2. Accepting and Rejecting 0-RTT + 4.6.3. Validating 0-RTT Configuration + 4.7. HelloRetryRequest + 4.8. TLS Errors + 4.9. Discarding Unused Keys + 4.9.1. Discarding Initial Keys + 4.9.2. Discarding Handshake Keys + 4.9.3. Discarding 0-RTT Keys + 5. Packet Protection + 5.1. Packet Protection Keys + 5.2. Initial Secrets + 5.3. AEAD Usage + 5.4. Header Protection + 5.4.1. Header Protection Application + 5.4.2. Header Protection Sample + 5.4.3. AES-Based Header Protection + 5.4.4. ChaCha20-Based Header Protection + 5.5. Receiving Protected Packets + 5.6. Use of 0-RTT Keys + 5.7. Receiving Out-of-Order Protected Packets + 5.8. Retry Packet Integrity + 6. Key Update + 6.1. Initiating a Key Update + 6.2. Responding to a Key Update + 6.3. Timing of Receive Key Generation + 6.4. Sending with Updated Keys + 6.5. Receiving with Different Keys + 6.6. Limits on AEAD Usage + 6.7. Key Update Error Code + 7. Security of Initial Messages + 8. QUIC-Specific Adjustments to the TLS Handshake + 8.1. Protocol Negotiation + 8.2. QUIC Transport Parameters Extension + 8.3. Removing the EndOfEarlyData Message + 8.4. Prohibit TLS Middlebox Compatibility Mode + 9. Security Considerations + 9.1. Session Linkability + 9.2. Replay Attacks with 0-RTT + 9.3. Packet Reflection Attack Mitigation + 9.4. Header Protection Analysis + 9.5. Header Protection Timing Side Channels + 9.6. Key Diversity + 9.7. Randomness + 10. IANA Considerations + 11. References + 11.1. Normative References + 11.2. Informative References + Appendix A. Sample Packet Protection + A.1. Keys + A.2. Client Initial + A.3. Server Initial + A.4. Retry + A.5. ChaCha20-Poly1305 Short Header Packet + Appendix B. AEAD Algorithm Analysis + B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage + Limits + B.1.1. Confidentiality Limit + B.1.2. Integrity Limit + B.2. Analysis of AEAD_AES_128_CCM Usage Limits + Contributors + Authors' Addresses + +1. Introduction + + This document describes how QUIC [QUIC-TRANSPORT] is secured using + TLS [TLS13]. + + TLS 1.3 provides critical latency improvements for connection + establishment over previous versions. Absent packet loss, most new + connections can be established and secured within a single round + trip; on subsequent connections between the same client and server, + the client can often send application data immediately, that is, + using a zero round-trip setup. + + This document describes how TLS acts as a security component of QUIC. + +2. Notational Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + This document uses the terminology established in [QUIC-TRANSPORT]. + + For brevity, the acronym TLS is used to refer to TLS 1.3, though a + newer version could be used; see Section 4.2. + +2.1. TLS Overview + + TLS provides two endpoints with a way to establish a means of + communication over an untrusted medium (for example, the Internet). + TLS enables authentication of peers and provides confidentiality and + integrity protection for messages that endpoints exchange. + + Internally, TLS is a layered protocol, with the structure shown in + Figure 1. + + +-------------+------------+--------------+---------+ + Content | | | Application | | + Layer | Handshake | Alerts | Data | ... | + | | | | | + +-------------+------------+--------------+---------+ + Record | | + Layer | Records | + | | + +---------------------------------------------------+ + + Figure 1: TLS Layers + + Each content-layer message (e.g., handshake, alerts, and application + data) is carried as a series of typed TLS records by the record + layer. Records are individually cryptographically protected and then + transmitted over a reliable transport (typically TCP), which provides + sequencing and guaranteed delivery. + + The TLS authenticated key exchange occurs between two endpoints: + client and server. The client initiates the exchange and the server + responds. If the key exchange completes successfully, both client + and server will agree on a secret. TLS supports both pre-shared key + (PSK) and Diffie-Hellman over either finite fields or elliptic curves + ((EC)DHE) key exchanges. PSK is the basis for Early Data (0-RTT); + the latter provides forward secrecy (FS) when the (EC)DHE keys are + destroyed. The two modes can also be combined to provide forward + secrecy while using the PSK for authentication. + + After completing the TLS handshake, the client will have learned and + authenticated an identity for the server, and the server is + optionally able to learn and authenticate an identity for the client. + TLS supports X.509 [RFC5280] certificate-based authentication for + both server and client. When PSK key exchange is used (as in + resumption), knowledge of the PSK serves to authenticate the peer. + + The TLS key exchange is resistant to tampering by attackers, and it + produces shared secrets that cannot be controlled by either + participating peer. + + TLS provides two basic handshake modes of interest to QUIC: + + * A full 1-RTT handshake, in which the client is able to send + application data after one round trip and the server immediately + responds after receiving the first handshake message from the + client. + + * A 0-RTT handshake, in which the client uses information it has + previously learned about the server to send application data + immediately. This application data can be replayed by an + attacker, so 0-RTT is not suitable for carrying instructions that + might initiate any action that could cause unwanted effects if + replayed. + + A simplified TLS handshake with 0-RTT application data is shown in + Figure 2. + + Client Server + + ClientHello + (0-RTT Application Data) --------> + ServerHello + {EncryptedExtensions} + {Finished} + <-------- [Application Data] + {Finished} --------> + + [Application Data] <-------> [Application Data] + + () Indicates messages protected by Early Data (0-RTT) Keys + {} Indicates messages protected using Handshake Keys + [] Indicates messages protected using Application Data + (1-RTT) Keys + + Figure 2: TLS Handshake with 0-RTT + + Figure 2 omits the EndOfEarlyData message, which is not used in QUIC; + see Section 8.3. Likewise, neither ChangeCipherSpec nor KeyUpdate + messages are used by QUIC. ChangeCipherSpec is redundant in TLS 1.3; + see Section 8.4. QUIC has its own key update mechanism; see + Section 6. + + Data is protected using a number of encryption levels: + + * Initial keys + + * Early data (0-RTT) keys + + * Handshake keys + + * Application data (1-RTT) keys + + Application data can only appear in the early data and application + data levels. Handshake and alert messages may appear in any level. + + The 0-RTT handshake can be used if the client and server have + previously communicated. In the 1-RTT handshake, the client is + unable to send protected application data until it has received all + of the handshake messages sent by the server. + +3. Protocol Overview + + QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality + and integrity protection of packets. For this it uses keys derived + from a TLS handshake [TLS13], but instead of carrying TLS records + over QUIC (as with TCP), TLS handshake and alert messages are carried + directly over the QUIC transport, which takes over the + responsibilities of the TLS record layer, as shown in Figure 3. + + +--------------+--------------+ +-------------+ + | TLS | TLS | | QUIC | + | Handshake | Alerts | | Applications| + | | | | (h3, etc.) | + +--------------+--------------+-+-------------+ + | | + | QUIC Transport | + | (streams, reliability, congestion, etc.) | + | | + +---------------------------------------------+ + | | + | QUIC Packet Protection | + | | + +---------------------------------------------+ + + Figure 3: QUIC Layers + + QUIC also relies on TLS for authentication and negotiation of + parameters that are critical to security and performance. + + Rather than a strict layering, these two protocols cooperate: QUIC + uses the TLS handshake; TLS uses the reliability, ordered delivery, + and record layer provided by QUIC. + + At a high level, there are two main interactions between the TLS and + QUIC components: + + * The TLS component sends and receives messages via the QUIC + component, with QUIC providing a reliable stream abstraction to + TLS. + + * The TLS component provides a series of updates to the QUIC + component, including (a) new packet protection keys to install and + (b) state changes such as handshake completion, the server + certificate, etc. + + Figure 4 shows these interactions in more detail, with the QUIC + packet protection being called out specially. + + +------------+ +------------+ + | |<---- Handshake Messages ----->| | + | |<- Validate 0-RTT Parameters ->| | + | |<--------- 0-RTT Keys ---------| | + | QUIC |<------- Handshake Keys -------| TLS | + | |<--------- 1-RTT Keys ---------| | + | |<------- Handshake Done -------| | + +------------+ +------------+ + | ^ + | Protect | Protected + v | Packet + +------------+ + | QUIC | + | Packet | + | Protection | + +------------+ + + Figure 4: QUIC and TLS Interactions + + Unlike TLS over TCP, QUIC applications that want to send data do not + send it using TLS Application Data records. Rather, they send it as + QUIC STREAM frames or other frame types, which are then carried in + QUIC packets. + +4. Carrying TLS Messages + + QUIC carries TLS handshake data in CRYPTO frames, each of which + consists of a contiguous block of handshake data identified by an + offset and length. Those frames are packaged into QUIC packets and + encrypted under the current encryption level. As with TLS over TCP, + once TLS handshake data has been delivered to QUIC, it is QUIC's + responsibility to deliver it reliably. Each chunk of data that is + produced by TLS is associated with the set of keys that TLS is + currently using. If QUIC needs to retransmit that data, it MUST use + the same keys even if TLS has already updated to newer keys. + + Each encryption level corresponds to a packet number space. The + packet number space that is used determines the semantics of frames. + Some frames are prohibited in different packet number spaces; see + Section 12.5 of [QUIC-TRANSPORT]. + + Because packets could be reordered on the wire, QUIC uses the packet + type to indicate which keys were used to protect a given packet, as + shown in Table 1. When packets of different types need to be sent, + endpoints SHOULD use coalesced packets to send them in the same UDP + datagram. + + +=====================+=================+==================+ + | Packet Type | Encryption Keys | PN Space | + +=====================+=================+==================+ + | Initial | Initial secrets | Initial | + +=====================+-----------------+------------------+ + | 0-RTT Protected | 0-RTT | Application data | + +=====================+-----------------+------------------+ + | Handshake | Handshake | Handshake | + +=====================+-----------------+------------------+ + | Retry | Retry | N/A | + +=====================+-----------------+------------------+ + | Version Negotiation | N/A | N/A | + +=====================+-----------------+------------------+ + | Short Header | 1-RTT | Application data | + +=====================+-----------------+------------------+ + + Table 1: Encryption Keys by Packet Type + + Section 17 of [QUIC-TRANSPORT] shows how packets at the various + encryption levels fit into the handshake process. + +4.1. Interface to TLS + + As shown in Figure 4, the interface from QUIC to TLS consists of four + primary functions: + + * Sending and receiving handshake messages + + * Processing stored transport and application state from a resumed + session and determining if it is valid to generate or accept 0-RTT + data + + * Rekeying (both transmit and receive) + + * Updating handshake state + + Additional functions might be needed to configure TLS. In + particular, QUIC and TLS need to agree on which is responsible for + validation of peer credentials, such as certificate validation + [RFC5280]. + +4.1.1. Handshake Complete + + In this document, the TLS handshake is considered complete when the + TLS stack has reported that the handshake is complete. This happens + when the TLS stack has both sent a Finished message and verified the + peer's Finished message. Verifying the peer's Finished message + provides the endpoints with an assurance that previous handshake + messages have not been modified. Note that the handshake does not + complete at both endpoints simultaneously. Consequently, any + requirement that is based on the completion of the handshake depends + on the perspective of the endpoint in question. + +4.1.2. Handshake Confirmed + + In this document, the TLS handshake is considered confirmed at the + server when the handshake completes. The server MUST send a + HANDSHAKE_DONE frame as soon as the handshake is complete. At the + client, the handshake is considered confirmed when a HANDSHAKE_DONE + frame is received. + + Additionally, a client MAY consider the handshake to be confirmed + when it receives an acknowledgment for a 1-RTT packet. This can be + implemented by recording the lowest packet number sent with 1-RTT + keys and comparing it to the Largest Acknowledged field in any + received 1-RTT ACK frame: once the latter is greater than or equal to + the former, the handshake is confirmed. + +4.1.3. Sending and Receiving Handshake Messages + + In order to drive the handshake, TLS depends on being able to send + and receive handshake messages. There are two basic functions on + this interface: one where QUIC requests handshake messages and one + where QUIC provides bytes that comprise handshake messages. + + Before starting the handshake, QUIC provides TLS with the transport + parameters (see Section 8.2) that it wishes to carry. + + A QUIC client starts TLS by requesting TLS handshake bytes from TLS. + The client acquires handshake bytes before sending its first packet. + A QUIC server starts the process by providing TLS with the client's + handshake bytes. + + At any time, the TLS stack at an endpoint will have a current sending + encryption level and a receiving encryption level. TLS encryption + levels determine the QUIC packet type and keys that are used for + protecting data. + + Each encryption level is associated with a different sequence of + bytes, which is reliably transmitted to the peer in CRYPTO frames. + When TLS provides handshake bytes to be sent, they are appended to + the handshake bytes for the current encryption level. The encryption + level then determines the type of packet that the resulting CRYPTO + frame is carried in; see Table 1. + + Four encryption levels are used, producing keys for Initial, 0-RTT, + Handshake, and 1-RTT packets. CRYPTO frames are carried in just + three of these levels, omitting the 0-RTT level. These four levels + correspond to three packet number spaces: Initial and Handshake + encrypted packets use their own separate spaces; 0-RTT and 1-RTT + packets use the application data packet number space. + + QUIC takes the unprotected content of TLS handshake records as the + content of CRYPTO frames. TLS record protection is not used by QUIC. + QUIC assembles CRYPTO frames into QUIC packets, which are protected + using QUIC packet protection. + + QUIC CRYPTO frames only carry TLS handshake messages. TLS alerts are + turned into QUIC CONNECTION_CLOSE error codes; see Section 4.8. TLS + application data and other content types cannot be carried by QUIC at + any encryption level; it is an error if they are received from the + TLS stack. + + When an endpoint receives a QUIC packet containing a CRYPTO frame + from the network, it proceeds as follows: + + * If the packet uses the current TLS receiving encryption level, + sequence the data into the input flow as usual. As with STREAM + frames, the offset is used to find the proper location in the data + sequence. If the result of this process is that new data is + available, then it is delivered to TLS in order. + + * If the packet is from a previously installed encryption level, it + MUST NOT contain data that extends past the end of previously + received data in that flow. Implementations MUST treat any + violations of this requirement as a connection error of type + PROTOCOL_VIOLATION. + + * If the packet is from a new encryption level, it is saved for + later processing by TLS. Once TLS moves to receiving from this + encryption level, saved data can be provided to TLS. When TLS + provides keys for a higher encryption level, if there is data from + a previous encryption level that TLS has not consumed, this MUST + be treated as a connection error of type PROTOCOL_VIOLATION. + + Each time that TLS is provided with new data, new handshake bytes are + requested from TLS. TLS might not provide any bytes if the handshake + messages it has received are incomplete or it has no data to send. + + The content of CRYPTO frames might either be processed incrementally + by TLS or buffered until complete messages or flights are available. + TLS is responsible for buffering handshake bytes that have arrived in + order. QUIC is responsible for buffering handshake bytes that arrive + out of order or for encryption levels that are not yet ready. QUIC + does not provide any means of flow control for CRYPTO frames; see + Section 7.5 of [QUIC-TRANSPORT]. + + Once the TLS handshake is complete, this is indicated to QUIC along + with any final handshake bytes that TLS needs to send. At this + stage, the transport parameters that the peer advertised during the + handshake are authenticated; see Section 8.2. + + Once the handshake is complete, TLS becomes passive. TLS can still + receive data from its peer and respond in kind, but it will not need + to send more data unless specifically requested -- either by an + application or QUIC. One reason to send data is that the server + might wish to provide additional or updated session tickets to a + client. + + When the handshake is complete, QUIC only needs to provide TLS with + any data that arrives in CRYPTO streams. In the same manner that is + used during the handshake, new data is requested from TLS after + providing received data. + +4.1.4. Encryption Level Changes + + As keys at a given encryption level become available to TLS, TLS + indicates to QUIC that reading or writing keys at that encryption + level are available. + + The availability of new keys is always a result of providing inputs + to TLS. TLS only provides new keys after being initialized (by a + client) or when provided with new handshake data. + + However, a TLS implementation could perform some of its processing + asynchronously. In particular, the process of validating a + certificate can take some time. While waiting for TLS processing to + complete, an endpoint SHOULD buffer received packets if they might be + processed using keys that are not yet available. These packets can + be processed once keys are provided by TLS. An endpoint SHOULD + continue to respond to packets that can be processed during this + time. + + After processing inputs, TLS might produce handshake bytes, keys for + new encryption levels, or both. + + TLS provides QUIC with three items as a new encryption level becomes + available: + + * A secret + + * An Authenticated Encryption with Associated Data (AEAD) function + + * A Key Derivation Function (KDF) + + These values are based on the values that TLS negotiates and are used + by QUIC to generate packet and header protection keys; see Section 5 + and Section 5.4. + + If 0-RTT is possible, it is ready after the client sends a TLS + ClientHello message or the server receives that message. After + providing a QUIC client with the first handshake bytes, the TLS stack + might signal the change to 0-RTT keys. On the server, after + receiving handshake bytes that contain a ClientHello message, a TLS + server might signal that 0-RTT keys are available. + + Although TLS only uses one encryption level at a time, QUIC may use + more than one level. For instance, after sending its Finished + message (using a CRYPTO frame at the Handshake encryption level) an + endpoint can send STREAM data (in 1-RTT encryption). If the Finished + message is lost, the endpoint uses the Handshake encryption level to + retransmit the lost message. Reordering or loss of packets can mean + that QUIC will need to handle packets at multiple encryption levels. + During the handshake, this means potentially handling packets at + higher and lower encryption levels than the current encryption level + used by TLS. + + In particular, server implementations need to be able to read packets + at the Handshake encryption level at the same time as the 0-RTT + encryption level. A client could interleave ACK frames that are + protected with Handshake keys with 0-RTT data, and the server needs + to process those acknowledgments in order to detect lost Handshake + packets. + + QUIC also needs access to keys that might not ordinarily be available + to a TLS implementation. For instance, a client might need to + acknowledge Handshake packets before it is ready to send CRYPTO + frames at that encryption level. TLS therefore needs to provide keys + to QUIC before it might produce them for its own use. + +4.1.5. TLS Interface Summary + + Figure 5 summarizes the exchange between QUIC and TLS for both client + and server. Solid arrows indicate packets that carry handshake data; + dashed arrows show where application data can be sent. Each arrow is + tagged with the encryption level used for that transmission. + + Client Server + ====== ====== + + Get Handshake + Initial -------------> + Install tx 0-RTT keys + 0-RTT - - - - - - - -> + + Handshake Received + Get Handshake + <------------- Initial + Install rx 0-RTT keys + Install Handshake keys + Get Handshake + <----------- Handshake + Install tx 1-RTT keys + <- - - - - - - - 1-RTT + + Handshake Received (Initial) + Install Handshake keys + Handshake Received (Handshake) + Get Handshake + Handshake -----------> + Handshake Complete + Install 1-RTT keys + 1-RTT - - - - - - - -> + + Handshake Received + Handshake Complete + Handshake Confirmed + Install rx 1-RTT keys + <--------------- 1-RTT + (HANDSHAKE_DONE) + Handshake Confirmed + + Figure 5: Interaction Summary between QUIC and TLS + + Figure 5 shows the multiple packets that form a single "flight" of + messages being processed individually, to show what incoming messages + trigger different actions. This shows multiple "Get Handshake" + invocations to retrieve handshake messages at different encryption + levels. New handshake messages are requested after incoming packets + have been processed. + + Figure 5 shows one possible structure for a simple handshake + exchange. The exact process varies based on the structure of + endpoint implementations and the order in which packets arrive. + Implementations could use a different number of operations or execute + them in other orders. + +4.2. TLS Version + + This document describes how TLS 1.3 [TLS13] is used with QUIC. + + In practice, the TLS handshake will negotiate a version of TLS to + use. This could result in a version of TLS newer than 1.3 being + negotiated if both endpoints support that version. This is + acceptable provided that the features of TLS 1.3 that are used by + QUIC are supported by the newer version. + + Clients MUST NOT offer TLS versions older than 1.3. A badly + configured TLS implementation could negotiate TLS 1.2 or another + older version of TLS. An endpoint MUST terminate the connection if a + version of TLS older than 1.3 is negotiated. + +4.3. ClientHello Size + + The first Initial packet from a client contains the start or all of + its first cryptographic handshake message, which for TLS is the + ClientHello. Servers might need to parse the entire ClientHello + (e.g., to access extensions such as Server Name Identification (SNI) + or Application-Layer Protocol Negotiation (ALPN)) in order to decide + whether to accept the new incoming QUIC connection. If the + ClientHello spans multiple Initial packets, such servers would need + to buffer the first received fragments, which could consume excessive + resources if the client's address has not yet been validated. To + avoid this, servers MAY use the Retry feature (see Section 8.1 of + [QUIC-TRANSPORT]) to only buffer partial ClientHello messages from + clients with a validated address. + + QUIC packet and framing add at least 36 bytes of overhead to the + ClientHello message. That overhead increases if the client chooses a + Source Connection ID field longer than zero bytes. Overheads also do + not include the token or a Destination Connection ID longer than 8 + bytes, both of which might be required if a server sends a Retry + packet. + + A typical TLS ClientHello can easily fit into a 1200-byte packet. + However, in addition to the overheads added by QUIC, there are + several variables that could cause this limit to be exceeded. Large + session tickets, multiple or large key shares, and long lists of + supported ciphers, signature algorithms, versions, QUIC transport + parameters, and other negotiable parameters and extensions could + cause this message to grow. + + For servers, in addition to connection IDs and tokens, the size of + TLS session tickets can have an effect on a client's ability to + connect efficiently. Minimizing the size of these values increases + the probability that clients can use them and still fit their entire + ClientHello message in their first Initial packet. + + The TLS implementation does not need to ensure that the ClientHello + is large enough to meet QUIC's requirements for datagrams that carry + Initial packets; see Section 14.1 of [QUIC-TRANSPORT]. QUIC + implementations use PADDING frames or packet coalescing to ensure + that datagrams are large enough. + +4.4. Peer Authentication + + The requirements for authentication depend on the application + protocol that is in use. TLS provides server authentication and + permits the server to request client authentication. + + A client MUST authenticate the identity of the server. This + typically involves verification that the identity of the server is + included in a certificate and that the certificate is issued by a + trusted entity (see for example [RFC2818]). + + | Note: Where servers provide certificates for authentication, + | the size of the certificate chain can consume a large number of + | bytes. Controlling the size of certificate chains is critical + | to performance in QUIC as servers are limited to sending 3 + | bytes for every byte received prior to validating the client + | address; see Section 8.1 of [QUIC-TRANSPORT]. The size of a + | certificate chain can be managed by limiting the number of + | names or extensions; using keys with small public key + | representations, like ECDSA; or by using certificate + | compression [COMPRESS]. + + A server MAY request that the client authenticate during the + handshake. A server MAY refuse a connection if the client is unable + to authenticate when requested. The requirements for client + authentication vary based on application protocol and deployment. + + A server MUST NOT use post-handshake client authentication (as + defined in Section 4.6.2 of [TLS13]) because the multiplexing offered + by QUIC prevents clients from correlating the certificate request + with the application-level event that triggered it (see + [HTTP2-TLS13]). More specifically, servers MUST NOT send post- + handshake TLS CertificateRequest messages, and clients MUST treat + receipt of such messages as a connection error of type + PROTOCOL_VIOLATION. + +4.5. Session Resumption + + QUIC can use the session resumption feature of TLS 1.3. It does this + by carrying NewSessionTicket messages in CRYPTO frames after the + handshake is complete. Session resumption can be used to provide + 0-RTT and can also be used when 0-RTT is disabled. + + Endpoints that use session resumption might need to remember some + information about the current connection when creating a resumed + connection. TLS requires that some information be retained; see + Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state + being retained when resuming a connection unless 0-RTT is also used; + see Section 7.4.1 of [QUIC-TRANSPORT] and Section 4.6.1. Application + protocols could depend on state that is retained between resumed + connections. + + Clients can store any state required for resumption along with the + session ticket. Servers can use the session ticket to help carry + state. + + Session resumption allows servers to link activity on the original + connection with the resumed connection, which might be a privacy + issue for clients. Clients can choose not to enable resumption to + avoid creating this correlation. Clients SHOULD NOT reuse tickets as + that allows entities other than the server to correlate connections; + see Appendix C.4 of [TLS13]. + +4.6. 0-RTT + + The 0-RTT feature in QUIC allows a client to send application data + before the handshake is complete. This is made possible by reusing + negotiated parameters from a previous connection. To enable this, + 0-RTT depends on the client remembering critical parameters and + providing the server with a TLS session ticket that allows the server + to recover the same information. + + This information includes parameters that determine TLS state, as + governed by [TLS13], QUIC transport parameters, the chosen + application protocol, and any information the application protocol + might need; see Section 4.6.3. This information determines how 0-RTT + packets and their contents are formed. + + To ensure that the same information is available to both endpoints, + all information used to establish 0-RTT comes from the same + connection. Endpoints cannot selectively disregard information that + might alter the sending or processing of 0-RTT. + + [TLS13] sets a limit of seven days on the time between the original + connection and any attempt to use 0-RTT. There are other constraints + on 0-RTT usage, notably those caused by the potential exposure to + replay attack; see Section 9.2. + +4.6.1. Enabling 0-RTT + + The TLS early_data extension in the NewSessionTicket message is + defined to convey (in the max_early_data_size parameter) the amount + of TLS 0-RTT data the server is willing to accept. QUIC does not use + TLS early data. QUIC uses 0-RTT packets to carry early data. + Accordingly, the max_early_data_size parameter is repurposed to hold + a sentinel value 0xffffffff to indicate that the server is willing to + accept QUIC 0-RTT data. To indicate that the server does not accept + 0-RTT data, the early_data extension is omitted from the + NewSessionTicket. The amount of data that the client can send in + QUIC 0-RTT is controlled by the initial_max_data transport parameter + supplied by the server. + + Servers MUST NOT send the early_data extension with a + max_early_data_size field set to any value other than 0xffffffff. A + client MUST treat receipt of a NewSessionTicket that contains an + early_data extension with any other value as a connection error of + type PROTOCOL_VIOLATION. + + A client that wishes to send 0-RTT packets uses the early_data + extension in the ClientHello message of a subsequent handshake; see + Section 4.2.10 of [TLS13]. It then sends application data in 0-RTT + packets. + + A client that attempts 0-RTT might also provide an address validation + token if the server has sent a NEW_TOKEN frame; see Section 8.1 of + [QUIC-TRANSPORT]. + +4.6.2. Accepting and Rejecting 0-RTT + + A server accepts 0-RTT by sending an early_data extension in the + EncryptedExtensions; see Section 4.2.10 of [TLS13]. The server then + processes and acknowledges the 0-RTT packets that it receives. + + A server rejects 0-RTT by sending the EncryptedExtensions without an + early_data extension. A server will always reject 0-RTT if it sends + a TLS HelloRetryRequest. When rejecting 0-RTT, a server MUST NOT + process any 0-RTT packets, even if it could. When 0-RTT was + rejected, a client SHOULD treat receipt of an acknowledgment for a + 0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it + is able to detect the condition. + + When 0-RTT is rejected, all connection characteristics that the + client assumed might be incorrect. This includes the choice of + application protocol, transport parameters, and any application + configuration. The client therefore MUST reset the state of all + streams, including application state bound to those streams. + + A client MAY reattempt 0-RTT if it receives a Retry or Version + Negotiation packet. These packets do not signify rejection of 0-RTT. + +4.6.3. Validating 0-RTT Configuration + + When a server receives a ClientHello with the early_data extension, + it has to decide whether to accept or reject 0-RTT data from the + client. Some of this decision is made by the TLS stack (e.g., + checking that the cipher suite being resumed was included in the + ClientHello; see Section 4.2.10 of [TLS13]). Even when the TLS stack + has no reason to reject 0-RTT data, the QUIC stack or the application + protocol using QUIC might reject 0-RTT data because the configuration + of the transport or application associated with the resumed session + is not compatible with the server's current configuration. + + QUIC requires additional transport state to be associated with a + 0-RTT session ticket. One common way to implement this is using + stateless session tickets and storing this state in the session + ticket. Application protocols that use QUIC might have similar + requirements regarding associating or storing state. This associated + state is used for deciding whether 0-RTT data must be rejected. For + example, HTTP/3 settings [QUIC-HTTP] determine how 0-RTT data from + the client is interpreted. Other applications using QUIC could have + different requirements for determining whether to accept or reject + 0-RTT data. + +4.7. HelloRetryRequest + + The HelloRetryRequest message (see Section 4.1.4 of [TLS13]) can be + used to request that a client provide new information, such as a key + share, or to validate some characteristic of the client. From the + perspective of QUIC, HelloRetryRequest is not differentiated from + other cryptographic handshake messages that are carried in Initial + packets. Although it is in principle possible to use this feature + for address verification, QUIC implementations SHOULD instead use the + Retry feature; see Section 8.1 of [QUIC-TRANSPORT]. + +4.8. TLS Errors + + If TLS experiences an error, it generates an appropriate alert as + defined in Section 6 of [TLS13]. + + A TLS alert is converted into a QUIC connection error. The + AlertDescription value is added to 0x0100 to produce a QUIC error + code from the range reserved for CRYPTO_ERROR; see Section 20.1 of + [QUIC-TRANSPORT]. The resulting value is sent in a QUIC + CONNECTION_CLOSE frame of type 0x1c. + + QUIC is only able to convey an alert level of "fatal". In TLS 1.3, + the only existing uses for the "warning" level are to signal + connection close; see Section 6.1 of [TLS13]. As QUIC provides + alternative mechanisms for connection termination and the TLS + connection is only closed if an error is encountered, a QUIC endpoint + MUST treat any alert from TLS as if it were at the "fatal" level. + + QUIC permits the use of a generic code in place of a specific error + code; see Section 11 of [QUIC-TRANSPORT]. For TLS alerts, this + includes replacing any alert with a generic alert, such as + handshake_failure (0x0128 in QUIC). Endpoints MAY use a generic + error code to avoid possibly exposing confidential information. + +4.9. Discarding Unused Keys + + After QUIC has completed a move to a new encryption level, packet + protection keys for previous encryption levels can be discarded. + This occurs several times during the handshake, as well as when keys + are updated; see Section 6. + + Packet protection keys are not discarded immediately when new keys + are available. If packets from a lower encryption level contain + CRYPTO frames, frames that retransmit that data MUST be sent at the + same encryption level. Similarly, an endpoint generates + acknowledgments for packets at the same encryption level as the + packet being acknowledged. Thus, it is possible that keys for a + lower encryption level are needed for a short time after keys for a + newer encryption level are available. + + An endpoint cannot discard keys for a given encryption level unless + it has received all the cryptographic handshake messages from its + peer at that encryption level and its peer has done the same. + Different methods for determining this are provided for Initial keys + (Section 4.9.1) and Handshake keys (Section 4.9.2). These methods do + not prevent packets from being received or sent at that encryption + level because a peer might not have received all the acknowledgments + necessary. + + Though an endpoint might retain older keys, new data MUST be sent at + the highest currently available encryption level. Only ACK frames + and retransmissions of data in CRYPTO frames are sent at a previous + encryption level. These packets MAY also include PADDING frames. + +4.9.1. Discarding Initial Keys + + Packets protected with Initial secrets (Section 5.2) are not + authenticated, meaning that an attacker could spoof packets with the + intent to disrupt a connection. To limit these attacks, Initial + packet protection keys are discarded more aggressively than other + keys. + + The successful use of Handshake packets indicates that no more + Initial packets need to be exchanged, as these keys can only be + produced after receiving all CRYPTO frames from Initial packets. + Thus, a client MUST discard Initial keys when it first sends a + Handshake packet and a server MUST discard Initial keys when it first + successfully processes a Handshake packet. Endpoints MUST NOT send + Initial packets after this point. + + This results in abandoning loss recovery state for the Initial + encryption level and ignoring any outstanding Initial packets. + +4.9.2. Discarding Handshake Keys + + An endpoint MUST discard its Handshake keys when the TLS handshake is + confirmed (Section 4.1.2). + +4.9.3. Discarding 0-RTT Keys + + 0-RTT and 1-RTT packets share the same packet number space, and + clients do not send 0-RTT packets after sending a 1-RTT packet + (Section 5.6). + + Therefore, a client SHOULD discard 0-RTT keys as soon as it installs + 1-RTT keys as they have no use after that moment. + + Additionally, a server MAY discard 0-RTT keys as soon as it receives + a 1-RTT packet. However, due to packet reordering, a 0-RTT packet + could arrive after a 1-RTT packet. Servers MAY temporarily retain + 0-RTT keys to allow decrypting reordered packets without requiring + their contents to be retransmitted with 1-RTT keys. After receiving + a 1-RTT packet, servers MUST discard 0-RTT keys within a short time; + the RECOMMENDED time period is three times the Probe Timeout (PTO, + see [QUIC-RECOVERY]). A server MAY discard 0-RTT keys earlier if it + determines that it has received all 0-RTT packets, which can be done + by keeping track of missing packet numbers. + +5. Packet Protection + + As with TLS over TCP, QUIC protects packets with keys derived from + the TLS handshake, using the AEAD algorithm [AEAD] negotiated by TLS. + + QUIC packets have varying protections depending on their type: + + * Version Negotiation packets have no cryptographic protection. + + * Retry packets use AEAD_AES_128_GCM to provide protection against + accidental modification and to limit the entities that can produce + a valid Retry; see Section 5.8. + + * Initial packets use AEAD_AES_128_GCM with keys derived from the + Destination Connection ID field of the first Initial packet sent + by the client; see Section 5.2. + + * All other packets have strong cryptographic protections for + confidentiality and integrity, using keys and algorithms + negotiated by TLS. + + This section describes how packet protection is applied to Handshake + packets, 0-RTT packets, and 1-RTT packets. The same packet + protection process is applied to Initial packets. However, as it is + trivial to determine the keys used for Initial packets, these packets + are not considered to have confidentiality or integrity protection. + Retry packets use a fixed key and so similarly lack confidentiality + and integrity protection. + +5.1. Packet Protection Keys + + QUIC derives packet protection keys in the same way that TLS derives + record protection keys. + + Each encryption level has separate secret values for protection of + packets sent in each direction. These traffic secrets are derived by + TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all + encryption levels except the Initial encryption level. The secrets + for the Initial encryption level are computed based on the client's + initial Destination Connection ID, as described in Section 5.2. + + The keys used for packet protection are computed from the TLS secrets + using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label + function described in Section 7.1 of [TLS13] is used with the hash + function from the negotiated cipher suite. All uses of HKDF-Expand- + Label in QUIC use a zero-length Context. + + Note that labels, which are described using strings, are encoded as + bytes using ASCII [ASCII] without quotes or any trailing NUL byte. + + Other versions of TLS MUST provide a similar function in order to be + used with QUIC. + + The current encryption level secret and the label "quic key" are + input to the KDF to produce the AEAD key; the label "quic iv" is used + to derive the Initialization Vector (IV); see Section 5.3. The + header protection key uses the "quic hp" label; see Section 5.4. + Using these labels provides key separation between QUIC and TLS; see + Section 9.6. + + Both "quic key" and "quic hp" are used to produce keys, so the Length + provided to HKDF-Expand-Label along with these labels is determined + by the size of keys in the AEAD or header protection algorithm. The + Length provided with "quic iv" is the minimum length of the AEAD + nonce or 8 bytes if that is larger; see [AEAD]. + + The KDF used for initial secrets is always the HKDF-Expand-Label + function from TLS 1.3; see Section 5.2. + +5.2. Initial Secrets + + Initial packets apply the packet protection process, but use a secret + derived from the Destination Connection ID field from the client's + first Initial packet. + + This secret is determined by using HKDF-Extract (see Section 2.2 of + [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and + the input keying material (IKM) of the Destination Connection ID + field. This produces an intermediate pseudorandom key (PRK) that is + used to derive two separate secrets for sending and receiving. + + The secret used by clients to construct Initial packets uses the PRK + and the label "client in" as input to the HKDF-Expand-Label function + from TLS [TLS13] to produce a 32-byte secret. Packets constructed by + the server use the same process with the label "server in". The hash + function for HKDF when deriving initial secrets and keys is SHA-256 + [SHA]. + + This process in pseudocode is: + + initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a + initial_secret = HKDF-Extract(initial_salt, + client_dst_connection_id) + + client_initial_secret = HKDF-Expand-Label(initial_secret, + "client in", "", + Hash.length) + server_initial_secret = HKDF-Expand-Label(initial_secret, + "server in", "", + Hash.length) + + The connection ID used with HKDF-Expand-Label is the Destination + Connection ID in the Initial packet sent by the client. This will be + a randomly selected value unless the client creates the Initial + packet after receiving a Retry packet, where the Destination + Connection ID is selected by the server. + + Future versions of QUIC SHOULD generate a new salt value, thus + ensuring that the keys are different for each version of QUIC. This + prevents a middlebox that recognizes only one version of QUIC from + seeing or modifying the contents of packets from future versions. + + The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for + Initial packets even where the TLS versions offered do not include + TLS 1.3. + + The secrets used for constructing subsequent Initial packets change + when a server sends a Retry packet to use the connection ID value + selected by the server. The secrets do not change when a client + changes the Destination Connection ID it uses in response to an + Initial packet from the server. + + | Note: The Destination Connection ID field could be any length + | up to 20 bytes, including zero length if the server sends a + | Retry packet with a zero-length Source Connection ID field. + | After a Retry, the Initial keys provide the client no assurance + | that the server received its packet, so the client has to rely + | on the exchange that included the Retry packet to validate the + | server address; see Section 8.1 of [QUIC-TRANSPORT]. + + Appendix A contains sample Initial packets. + +5.3. AEAD Usage + + The Authenticated Encryption with Associated Data (AEAD) function + (see [AEAD]) used for QUIC packet protection is the AEAD that is + negotiated for use with the TLS connection. For example, if TLS is + using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM + function is used. + + QUIC can use any of the cipher suites defined in [TLS13] with the + exception of TLS_AES_128_CCM_8_SHA256. A cipher suite MUST NOT be + negotiated unless a header protection scheme is defined for the + cipher suite. This document defines a header protection scheme for + all cipher suites defined in [TLS13] aside from + TLS_AES_128_CCM_8_SHA256. These cipher suites have a 16-byte + authentication tag and produce an output 16 bytes larger than their + input. + + An endpoint MUST NOT reject a ClientHello that offers a cipher suite + that it does not support, or it would be impossible to deploy a new + cipher suite. This also applies to TLS_AES_128_CCM_8_SHA256. + + When constructing packets, the AEAD function is applied prior to + applying header protection; see Section 5.4. The unprotected packet + header is part of the associated data (A). When processing packets, + an endpoint first removes the header protection. + + The key and IV for the packet are computed as described in + Section 5.1. The nonce, N, is formed by combining the packet + protection IV with the packet number. The 62 bits of the + reconstructed QUIC packet number in network byte order are left- + padded with zeros to the size of the IV. The exclusive OR of the + padded packet number and the IV forms the AEAD nonce. + + The associated data, A, for the AEAD is the contents of the QUIC + header, starting from the first byte of either the short or long + header, up to and including the unprotected packet number. + + The input plaintext, P, for the AEAD is the payload of the QUIC + packet, as described in [QUIC-TRANSPORT]. + + The output ciphertext, C, of the AEAD is transmitted in place of P. + + Some AEAD functions have limits for how many packets can be encrypted + under the same key and IV; see Section 6.6. This might be lower than + the packet number limit. An endpoint MUST initiate a key update + (Section 6) prior to exceeding any limit set for the AEAD that is in + use. + +5.4. Header Protection + + Parts of QUIC packet headers, in particular the Packet Number field, + are protected using a key that is derived separately from the packet + protection key and IV. The key derived using the "quic hp" label is + used to provide confidentiality protection for those fields that are + not exposed to on-path elements. + + This protection applies to the least significant bits of the first + byte, plus the Packet Number field. The four least significant bits + of the first byte are protected for packets with long headers; the + five least significant bits of the first byte are protected for + packets with short headers. For both header forms, this covers the + reserved bits and the Packet Number Length field; the Key Phase bit + is also protected for packets with a short header. + + The same header protection key is used for the duration of the + connection, with the value not changing after a key update (see + Section 6). This allows header protection to be used to protect the + key phase. + + This process does not apply to Retry or Version Negotiation packets, + which do not contain a protected payload or any of the fields that + are protected by this process. + +5.4.1. Header Protection Application + + Header protection is applied after packet protection is applied (see + Section 5.3). The ciphertext of the packet is sampled and used as + input to an encryption algorithm. The algorithm used depends on the + negotiated AEAD. + + The output of this algorithm is a 5-byte mask that is applied to the + protected header fields using exclusive OR. The least significant + bits of the first byte of the packet are masked by the least + significant bits of the first mask byte, and the packet number is + masked with the remaining bytes. Any unused bytes of mask that might + result from a shorter packet number encoding are unused. + + Figure 6 shows a sample algorithm for applying header protection. + Removing header protection only differs in the order in which the + packet number length (pn_length) is determined (here "^" is used to + represent exclusive OR). + + mask = header_protection(hp_key, sample) + + pn_length = (packet[0] & 0x03) + 1 + if (packet[0] & 0x80) == 0x80: + # Long header: 4 bits masked + packet[0] ^= mask[0] & 0x0f + else: + # Short header: 5 bits masked + packet[0] ^= mask[0] & 0x1f + + # pn_offset is the start of the Packet Number field. + packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length] + + Figure 6: Header Protection Pseudocode + + Specific header protection functions are defined based on the + selected cipher suite; see Section 5.4.3 and Section 5.4.4. + + Figure 7 shows an example long header packet (Initial) and a short + header packet (1-RTT). Figure 7 shows the fields in each header that + are covered by header protection and the portion of the protected + packet payload that is sampled. + + Initial Packet { + Header Form (1) = 1, + Fixed Bit (1) = 1, + Long Packet Type (2) = 0, + Reserved Bits (2), # Protected + Packet Number Length (2), # Protected + Version (32), + DCID Len (8), + Destination Connection ID (0..160), + SCID Len (8), + Source Connection ID (0..160), + Token Length (i), + Token (..), + Length (i), + Packet Number (8..32), # Protected + Protected Payload (0..24), # Skipped Part + Protected Payload (128), # Sampled Part + Protected Payload (..) # Remainder + } + + 1-RTT Packet { + Header Form (1) = 0, + Fixed Bit (1) = 1, + Spin Bit (1), + Reserved Bits (2), # Protected + Key Phase (1), # Protected + Packet Number Length (2), # Protected + Destination Connection ID (0..160), + Packet Number (8..32), # Protected + Protected Payload (0..24), # Skipped Part + Protected Payload (128), # Sampled Part + Protected Payload (..), # Remainder + } + + Figure 7: Header Protection and Ciphertext Sample + + Before a TLS cipher suite can be used with QUIC, a header protection + algorithm MUST be specified for the AEAD used with that cipher suite. + This document defines algorithms for AEAD_AES_128_GCM, + AEAD_AES_128_CCM, AEAD_AES_256_GCM (all these AES AEADs are defined + in [AEAD]), and AEAD_CHACHA20_POLY1305 (defined in [CHACHA]). Prior + to TLS selecting a cipher suite, AES header protection is used + (Section 5.4.3), matching the AEAD_AES_128_GCM packet protection. + +5.4.2. Header Protection Sample + + The header protection algorithm uses both the header protection key + and a sample of the ciphertext from the packet Payload field. + + The same number of bytes are always sampled, but an allowance needs + to be made for the removal of protection by a receiving endpoint, + which will not know the length of the Packet Number field. The + sample of ciphertext is taken starting from an offset of 4 bytes + after the start of the Packet Number field. That is, in sampling + packet ciphertext for header protection, the Packet Number field is + assumed to be 4 bytes long (its maximum possible encoded length). + + An endpoint MUST discard packets that are not long enough to contain + a complete sample. + + To ensure that sufficient data is available for sampling, packets are + padded so that the combined lengths of the encoded packet number and + protected payload is at least 4 bytes longer than the sample required + for header protection. The cipher suites defined in [TLS13] -- other + than TLS_AES_128_CCM_8_SHA256, for which a header protection scheme + is not defined in this document -- have 16-byte expansions and + 16-byte header protection samples. This results in needing at least + 3 bytes of frames in the unprotected payload if the packet number is + encoded on a single byte, or 2 bytes of frames for a 2-byte packet + number encoding. + + The sampled ciphertext can be determined by the following pseudocode: + + # pn_offset is the start of the Packet Number field. + sample_offset = pn_offset + 4 + + sample = packet[sample_offset..sample_offset+sample_length] + + Where the packet number offset of a short header packet can be + calculated as: + + pn_offset = 1 + len(connection_id) + + And the packet number offset of a long header packet can be + calculated as: + + pn_offset = 7 + len(destination_connection_id) + + len(source_connection_id) + + len(payload_length) + if packet_type == Initial: + pn_offset += len(token_length) + + len(token) + + For example, for a packet with a short header, an 8-byte connection + ID, and protected with AEAD_AES_128_GCM, the sample takes bytes 13 to + 28 inclusive (using zero-based indexing). + + Multiple QUIC packets might be included in the same UDP datagram. + Each packet is handled separately. + +5.4.3. AES-Based Header Protection + + This section defines the packet protection algorithm for + AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. + AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES in Electronic + Codebook (ECB) mode. AEAD_AES_256_GCM uses 256-bit AES in ECB mode. + AES is defined in [AES]. + + This algorithm samples 16 bytes from the packet ciphertext. This + value is used as the input to AES-ECB. In pseudocode, the header + protection function is defined as: + + header_protection(hp_key, sample): + mask = AES-ECB(hp_key, sample) + +5.4.4. ChaCha20-Based Header Protection + + When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw + ChaCha20 function as defined in Section 2.4 of [CHACHA]. This uses a + 256-bit key and 16 bytes sampled from the packet protection output. + + The first 4 bytes of the sampled ciphertext are the block counter. A + ChaCha20 implementation could take a 32-bit integer in place of a + byte sequence, in which case, the byte sequence is interpreted as a + little-endian value. + + The remaining 12 bytes are used as the nonce. A ChaCha20 + implementation might take an array of three 32-bit integers in place + of a byte sequence, in which case, the nonce bytes are interpreted as + a sequence of 32-bit little-endian integers. + + The encryption mask is produced by invoking ChaCha20 to protect 5 + zero bytes. In pseudocode, the header protection function is defined + as: + + header_protection(hp_key, sample): + counter = sample[0..3] + nonce = sample[4..15] + mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0}) + +5.5. Receiving Protected Packets + + Once an endpoint successfully receives a packet with a given packet + number, it MUST discard all packets in the same packet number space + with higher packet numbers if they cannot be successfully unprotected + with either the same key, or -- if there is a key update -- a + subsequent packet protection key; see Section 6. Similarly, a packet + that appears to trigger a key update but cannot be unprotected + successfully MUST be discarded. + + Failure to unprotect a packet does not necessarily indicate the + existence of a protocol error in a peer or an attack. The truncated + packet number encoding used in QUIC can cause packet numbers to be + decoded incorrectly if they are delayed significantly. + +5.6. Use of 0-RTT Keys + + If 0-RTT keys are available (see Section 4.6.1), the lack of replay + protection means that restrictions on their use are necessary to + avoid replay attacks on the protocol. + + Of the frames defined in [QUIC-TRANSPORT], the STREAM, RESET_STREAM, + STOP_SENDING, and CONNECTION_CLOSE frames are potentially unsafe for + use with 0-RTT as they carry application data. Application data that + is received in 0-RTT could cause an application at the server to + process the data multiple times rather than just once. Additional + actions taken by a server as a result of processing replayed + application data could have unwanted consequences. A client + therefore MUST NOT use 0-RTT for application data unless specifically + requested by the application that is in use. + + An application protocol that uses QUIC MUST include a profile that + defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to + carry QUIC frames that do not carry application data. For example, a + profile for HTTP is described in [HTTP-REPLAY] and used for HTTP/3; + see Section 10.9 of [QUIC-HTTP]. + + Though replaying packets might result in additional connection + attempts, the effect of processing replayed frames that do not carry + application data is limited to changing the state of the affected + connection. A TLS handshake cannot be successfully completed using + replayed packets. + + A client MAY wish to apply additional restrictions on what data it + sends prior to the completion of the TLS handshake. + + A client otherwise treats 0-RTT keys as equivalent to 1-RTT keys, + except that it cannot send certain frames with 0-RTT keys; see + Section 12.5 of [QUIC-TRANSPORT]. + + A client that receives an indication that its 0-RTT data has been + accepted by a server can send 0-RTT data until it receives all of the + server's handshake messages. A client SHOULD stop sending 0-RTT data + if it receives an indication that 0-RTT data has been rejected. + + A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT + keys to protect acknowledgments of 0-RTT packets. A client MUST NOT + attempt to decrypt 0-RTT packets it receives and instead MUST discard + them. + + Once a client has installed 1-RTT keys, it MUST NOT send any more + 0-RTT packets. + + | Note: 0-RTT data can be acknowledged by the server as it + | receives it, but any packets containing acknowledgments of + | 0-RTT data cannot have packet protection removed by the client + | until the TLS handshake is complete. The 1-RTT keys necessary + | to remove packet protection cannot be derived until the client + | receives all server handshake messages. + +5.7. Receiving Out-of-Order Protected Packets + + Due to reordering and loss, protected packets might be received by an + endpoint before the final TLS handshake messages are received. A + client will be unable to decrypt 1-RTT packets from the server, + whereas a server will be able to decrypt 1-RTT packets from the + client. Endpoints in either role MUST NOT decrypt 1-RTT packets from + their peer prior to completing the handshake. + + Even though 1-RTT keys are available to a server after receiving the + first handshake messages from a client, it is missing assurances on + the client state: + + * The client is not authenticated, unless the server has chosen to + use a pre-shared key and validated the client's pre-shared key + binder; see Section 4.2.11 of [TLS13]. + + * The client has not demonstrated liveness, unless the server has + validated the client's address with a Retry packet or other means; + see Section 8.1 of [QUIC-TRANSPORT]. + + * Any received 0-RTT data that the server responds to might be due + to a replay attack. + + Therefore, the server's use of 1-RTT keys before the handshake is + complete is limited to sending data. A server MUST NOT process + incoming 1-RTT protected packets before the TLS handshake is + complete. Because sending acknowledgments indicates that all frames + in a packet have been processed, a server cannot send acknowledgments + for 1-RTT packets until the TLS handshake is complete. Received + packets protected with 1-RTT keys MAY be stored and later decrypted + and used once the handshake is complete. + + | Note: TLS implementations might provide all 1-RTT secrets prior + | to handshake completion. Even where QUIC implementations have + | 1-RTT read keys, those keys are not to be used prior to + | completing the handshake. + + The requirement for the server to wait for the client Finished + message creates a dependency on that message being delivered. A + client can avoid the potential for head-of-line blocking that this + implies by sending its 1-RTT packets coalesced with a Handshake + packet containing a copy of the CRYPTO frame that carries the + Finished message, until one of the Handshake packets is acknowledged. + This enables immediate server processing for those packets. + + A server could receive packets protected with 0-RTT keys prior to + receiving a TLS ClientHello. The server MAY retain these packets for + later decryption in anticipation of receiving a ClientHello. + + A client generally receives 1-RTT keys at the same time as the + handshake completes. Even if it has 1-RTT secrets, a client MUST NOT + process incoming 1-RTT protected packets before the TLS handshake is + complete. + +5.8. Retry Packet Integrity + + Retry packets (see Section 17.2.5 of [QUIC-TRANSPORT]) carry a Retry + Integrity Tag that provides two properties: it allows the discarding + of packets that have accidentally been corrupted by the network, and + only an entity that observes an Initial packet can send a valid Retry + packet. + + The Retry Integrity Tag is a 128-bit field that is computed as the + output of AEAD_AES_128_GCM [AEAD] used with the following inputs: + + * The secret key, K, is 128 bits equal to + 0xbe0c690b9f66575a1d766b54e368c84e. + + * The nonce, N, is 96 bits equal to 0x461599d35d632bf2239825bb. + + * The plaintext, P, is empty. + + * The associated data, A, is the contents of the Retry Pseudo- + Packet, as illustrated in Figure 8: + + The secret key and the nonce are values derived by calling HKDF- + Expand-Label using + 0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as + the secret, with labels being "quic key" and "quic iv" (Section 5.1). + + Retry Pseudo-Packet { + ODCID Length (8), + Original Destination Connection ID (0..160), + Header Form (1) = 1, + Fixed Bit (1) = 1, + Long Packet Type (2) = 3, + Unused (4), + Version (32), + DCID Len (8), + Destination Connection ID (0..160), + SCID Len (8), + Source Connection ID (0..160), + Retry Token (..), + } + + Figure 8: Retry Pseudo-Packet + + The Retry Pseudo-Packet is not sent over the wire. It is computed by + taking the transmitted Retry packet, removing the Retry Integrity + Tag, and prepending the two following fields: + + ODCID Length: The ODCID Length field contains the length in bytes of + the Original Destination Connection ID field that follows it, + encoded as an 8-bit unsigned integer. + + Original Destination Connection ID: The Original Destination + Connection ID contains the value of the Destination Connection ID + from the Initial packet that this Retry is in response to. The + length of this field is given in ODCID Length. The presence of + this field ensures that a valid Retry packet can only be sent by + an entity that observes the Initial packet. + +6. Key Update + + Once the handshake is confirmed (see Section 4.1.2), an endpoint MAY + initiate a key update. + + The Key Phase bit indicates which packet protection keys are used to + protect the packet. The Key Phase bit is initially set to 0 for the + first set of 1-RTT packets and toggled to signal each subsequent key + update. + + The Key Phase bit allows a recipient to detect a change in keying + material without needing to receive the first packet that triggered + the change. An endpoint that notices a changed Key Phase bit updates + keys and decrypts the packet that contains the changed value. + + Initiating a key update results in both endpoints updating keys. + This differs from TLS where endpoints can update keys independently. + + This mechanism replaces the key update mechanism of TLS, which relies + on KeyUpdate messages sent using 1-RTT encryption keys. Endpoints + MUST NOT send a TLS KeyUpdate message. Endpoints MUST treat the + receipt of a TLS KeyUpdate message as a connection error of type + 0x010a, equivalent to a fatal TLS alert of unexpected_message; see + Section 4.8. + + Figure 9 shows a key update process, where the initial set of keys + used (identified with @M) are replaced by updated keys (identified + with @N). The value of the Key Phase bit is indicated in brackets + []. + + Initiating Peer Responding Peer + + @M [0] QUIC Packets + + ... Update to @N + @N [1] QUIC Packets + --------> + Update to @N ... + QUIC Packets [1] @N + <-------- + QUIC Packets [1] @N + containing ACK + <-------- + ... Key Update Permitted + + @N [1] QUIC Packets + containing ACK for @N packets + --------> + Key Update Permitted ... + + Figure 9: Key Update + +6.1. Initiating a Key Update + + Endpoints maintain separate read and write secrets for packet + protection. An endpoint initiates a key update by updating its + packet protection write secret and using that to protect new packets. + The endpoint creates a new write secret from the existing write + secret as performed in Section 7.2 of [TLS13]. This uses the KDF + function provided by TLS with a label of "quic ku". The + corresponding key and IV are created from that secret as defined in + Section 5.1. The header protection key is not updated. + + For example, to update write keys with TLS 1.3, HKDF-Expand-Label is + used as: + + secret_ = HKDF-Expand-Label(secret_, "quic ku", + "", Hash.length) + + The endpoint toggles the value of the Key Phase bit and uses the + updated key and IV to protect all subsequent packets. + + An endpoint MUST NOT initiate a key update prior to having confirmed + the handshake (Section 4.1.2). An endpoint MUST NOT initiate a + subsequent key update unless it has received an acknowledgment for a + packet that was sent protected with keys from the current key phase. + This ensures that keys are available to both peers before another key + update can be initiated. This can be implemented by tracking the + lowest packet number sent with each key phase and the highest + acknowledged packet number in the 1-RTT space: once the latter is + higher than or equal to the former, another key update can be + initiated. + + | Note: Keys of packets other than the 1-RTT packets are never + | updated; their keys are derived solely from the TLS handshake + | state. + + The endpoint that initiates a key update also updates the keys that + it uses for receiving packets. These keys will be needed to process + packets the peer sends after updating. + + An endpoint MUST retain old keys until it has successfully + unprotected a packet sent using the new keys. An endpoint SHOULD + retain old keys for some time after unprotecting a packet sent using + the new keys. Discarding old keys too early can cause delayed + packets to be discarded. Discarding packets will be interpreted as + packet loss by the peer and could adversely affect performance. + +6.2. Responding to a Key Update + + A peer is permitted to initiate a key update after receiving an + acknowledgment of a packet in the current key phase. An endpoint + detects a key update when processing a packet with a key phase that + differs from the value used to protect the last packet it sent. To + process this packet, the endpoint uses the next packet protection key + and IV. See Section 6.3 for considerations about generating these + keys. + + If a packet is successfully processed using the next key and IV, then + the peer has initiated a key update. The endpoint MUST update its + send keys to the corresponding key phase in response, as described in + Section 6.1. Sending keys MUST be updated before sending an + acknowledgment for the packet that was received with updated keys. + By acknowledging the packet that triggered the key update in a packet + protected with the updated keys, the endpoint signals that the key + update is complete. + + An endpoint can defer sending the packet or acknowledgment according + to its normal packet sending behavior; it is not necessary to + immediately generate a packet in response to a key update. The next + packet sent by the endpoint will use the updated keys. The next + packet that contains an acknowledgment will cause the key update to + be completed. If an endpoint detects a second update before it has + sent any packets with updated keys containing an acknowledgment for + the packet that initiated the key update, it indicates that its peer + has updated keys twice without awaiting confirmation. An endpoint + MAY treat such consecutive key updates as a connection error of type + KEY_UPDATE_ERROR. + + An endpoint that receives an acknowledgment that is carried in a + packet protected with old keys where any acknowledged packet was + protected with newer keys MAY treat that as a connection error of + type KEY_UPDATE_ERROR. This indicates that a peer has received and + acknowledged a packet that initiates a key update, but has not + updated keys in response. + +6.3. Timing of Receive Key Generation + + Endpoints responding to an apparent key update MUST NOT generate a + timing side-channel signal that might indicate that the Key Phase bit + was invalid (see Section 9.5). Endpoints can use randomized packet + protection keys in place of discarded keys when key updates are not + yet permitted. Using randomized keys ensures that attempting to + remove packet protection does not result in timing variations, and + results in packets with an invalid Key Phase bit being rejected. + + The process of creating new packet protection keys for receiving + packets could reveal that a key update has occurred. An endpoint MAY + generate new keys as part of packet processing, but this creates a + timing signal that could be used by an attacker to learn when key + updates happen and thus leak the value of the Key Phase bit. + + Endpoints are generally expected to have current and next receive + packet protection keys available. For a short period after a key + update completes, up to the PTO, endpoints MAY defer generation of + the next set of receive packet protection keys. This allows + endpoints to retain only two sets of receive keys; see Section 6.5. + + Once generated, the next set of packet protection keys SHOULD be + retained, even if the packet that was received was subsequently + discarded. Packets containing apparent key updates are easy to + forge, and while the process of key update does not require + significant effort, triggering this process could be used by an + attacker for DoS. + + For this reason, endpoints MUST be able to retain two sets of packet + protection keys for receiving packets: the current and the next. + Retaining the previous keys in addition to these might improve + performance, but this is not essential. + +6.4. Sending with Updated Keys + + An endpoint never sends packets that are protected with old keys. + Only the current keys are used. Keys used for protecting packets can + be discarded immediately after switching to newer keys. + + Packets with higher packet numbers MUST be protected with either the + same or newer packet protection keys than packets with lower packet + numbers. An endpoint that successfully removes protection with old + keys when newer keys were used for packets with lower packet numbers + MUST treat this as a connection error of type KEY_UPDATE_ERROR. + +6.5. Receiving with Different Keys + + For receiving packets during a key update, packets protected with + older keys might arrive if they were delayed by the network. + Retaining old packet protection keys allows these packets to be + successfully processed. + + As packets protected with keys from the next key phase use the same + Key Phase value as those protected with keys from the previous key + phase, it is necessary to distinguish between the two if packets + protected with old keys are to be processed. This can be done using + packet numbers. A recovered packet number that is lower than any + packet number from the current key phase uses the previous packet + protection keys; a recovered packet number that is higher than any + packet number from the current key phase requires the use of the next + packet protection keys. + + Some care is necessary to ensure that any process for selecting + between previous, current, and next packet protection keys does not + expose a timing side channel that might reveal which keys were used + to remove packet protection. See Section 9.5 for more information. + + Alternatively, endpoints can retain only two sets of packet + protection keys, swapping previous for next after enough time has + passed to allow for reordering in the network. In this case, the Key + Phase bit alone can be used to select keys. + + An endpoint MAY allow a period of approximately the Probe Timeout + (PTO; see [QUIC-RECOVERY]) after promoting the next set of receive + keys to be current before it creates the subsequent set of packet + protection keys. These updated keys MAY replace the previous keys at + that time. With the caveat that PTO is a subjective measure -- that + is, a peer could have a different view of the RTT -- this time is + expected to be long enough that any reordered packets would be + declared lost by a peer even if they were acknowledged and short + enough to allow a peer to initiate further key updates. + + Endpoints need to allow for the possibility that a peer might not be + able to decrypt packets that initiate a key update during the period + when the peer retains old keys. Endpoints SHOULD wait three times + the PTO before initiating a key update after receiving an + acknowledgment that confirms that the previous key update was + received. Failing to allow sufficient time could lead to packets + being discarded. + + An endpoint SHOULD retain old read keys for no more than three times + the PTO after having received a packet protected using the new keys. + After this period, old read keys and their corresponding secrets + SHOULD be discarded. + +6.6. Limits on AEAD Usage + + This document sets usage limits for AEAD algorithms to ensure that + overuse does not give an adversary a disproportionate advantage in + attacking the confidentiality and integrity of communications when + using QUIC. + + The usage limits defined in TLS 1.3 exist for protection against + attacks on confidentiality and apply to successful applications of + AEAD protection. The integrity protections in authenticated + encryption also depend on limiting the number of attempts to forge + packets. TLS achieves this by closing connections after any record + fails an authentication check. In comparison, QUIC ignores any + packet that cannot be authenticated, allowing multiple forgery + attempts. + + QUIC accounts for AEAD confidentiality and integrity limits + separately. The confidentiality limit applies to the number of + packets encrypted with a given key. The integrity limit applies to + the number of packets decrypted within a given connection. Details + on enforcing these limits for each AEAD algorithm follow below. + + Endpoints MUST count the number of encrypted packets for each set of + keys. If the total number of encrypted packets with the same key + exceeds the confidentiality limit for the selected AEAD, the endpoint + MUST stop using those keys. Endpoints MUST initiate a key update + before sending more protected packets than the confidentiality limit + for the selected AEAD permits. If a key update is not possible or + integrity limits are reached, the endpoint MUST stop using the + connection and only send stateless resets in response to receiving + packets. It is RECOMMENDED that endpoints immediately close the + connection with a connection error of type AEAD_LIMIT_REACHED before + reaching a state where key updates are not possible. + + For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit + is 2^23 encrypted packets; see Appendix B.1. For + AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the + number of possible packets (2^62) and so can be disregarded. For + AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted + packets; see Appendix B.2. Applying a limit reduces the probability + that an attacker can distinguish the AEAD in use from a random + permutation; see [AEBounds], [ROBUST], and [GCM-MU]. + + In addition to counting packets sent, endpoints MUST count the number + of received packets that fail authentication during the lifetime of a + connection. If the total number of received packets that fail + authentication within the connection, across all keys, exceeds the + integrity limit for the selected AEAD, the endpoint MUST immediately + close the connection with a connection error of type + AEAD_LIMIT_REACHED and not process any more packets. + + For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is + 2^52 invalid packets; see Appendix B.1. For AEAD_CHACHA20_POLY1305, + the integrity limit is 2^36 invalid packets; see [AEBounds]. For + AEAD_AES_128_CCM, the integrity limit is 2^21.5 invalid packets; see + Appendix B.2. Applying this limit reduces the probability that an + attacker can successfully forge a packet; see [AEBounds], [ROBUST], + and [GCM-MU]. + + Endpoints that limit the size of packets MAY use higher + confidentiality and integrity limits; see Appendix B for details. + + Future analyses and specifications MAY relax confidentiality or + integrity limits for an AEAD. + + Any TLS cipher suite that is specified for use with QUIC MUST define + limits on the use of the associated AEAD function that preserves + margins for confidentiality and integrity. That is, limits MUST be + specified for the number of packets that can be authenticated and for + the number of packets that can fail authentication. Providing a + reference to any analysis upon which values are based -- and any + assumptions used in that analysis -- allows limits to be adapted to + varying usage conditions. + +6.7. Key Update Error Code + + The KEY_UPDATE_ERROR error code (0x0e) is used to signal errors + related to key updates. + +7. Security of Initial Messages + + Initial packets are not protected with a secret key, so they are + subject to potential tampering by an attacker. QUIC provides + protection against attackers that cannot read packets but does not + attempt to provide additional protection against attacks where the + attacker can observe and inject packets. Some forms of tampering -- + such as modifying the TLS messages themselves -- are detectable, but + some -- such as modifying ACKs -- are not. + + For example, an attacker could inject a packet containing an ACK + frame to make it appear that a packet had not been received or to + create a false impression of the state of the connection (e.g., by + modifying the ACK Delay). Note that such a packet could cause a + legitimate packet to be dropped as a duplicate. Implementations + SHOULD use caution in relying on any data that is contained in + Initial packets that is not otherwise authenticated. + + It is also possible for the attacker to tamper with data that is + carried in Handshake packets, but because that sort of tampering + requires modifying TLS handshake messages, any such tampering will + cause the TLS handshake to fail. + +8. QUIC-Specific Adjustments to the TLS Handshake + + Certain aspects of the TLS handshake are different when used with + QUIC. + + QUIC also requires additional features from TLS. In addition to + negotiation of cryptographic parameters, the TLS handshake carries + and authenticates values for QUIC transport parameters. + +8.1. Protocol Negotiation + + QUIC requires that the cryptographic handshake provide authenticated + protocol negotiation. TLS uses Application-Layer Protocol + Negotiation [ALPN] to select an application protocol. Unless another + mechanism is used for agreeing on an application protocol, endpoints + MUST use ALPN for this purpose. + + When using ALPN, endpoints MUST immediately close a connection (see + Section 10.2 of [QUIC-TRANSPORT]) with a no_application_protocol TLS + alert (QUIC error code 0x0178; see Section 4.8) if an application + protocol is not negotiated. While [ALPN] only specifies that servers + use this alert, QUIC clients MUST use error 0x0178 to terminate a + connection when ALPN negotiation fails. + + An application protocol MAY restrict the QUIC versions that it can + operate over. Servers MUST select an application protocol compatible + with the QUIC version that the client has selected. The server MUST + treat the inability to select a compatible application protocol as a + connection error of type 0x0178 (no_application_protocol). + Similarly, a client MUST treat the selection of an incompatible + application protocol by a server as a connection error of type + 0x0178. + +8.2. QUIC Transport Parameters Extension + + QUIC transport parameters are carried in a TLS extension. Different + versions of QUIC might define a different method for negotiating + transport configuration. + + Including transport parameters in the TLS handshake provides + integrity protection for these values. + + enum { + quic_transport_parameters(0x39), (65535) + } ExtensionType; + + The extension_data field of the quic_transport_parameters extension + contains a value that is defined by the version of QUIC that is in + use. + + The quic_transport_parameters extension is carried in the ClientHello + and the EncryptedExtensions messages during the handshake. Endpoints + MUST send the quic_transport_parameters extension; endpoints that + receive ClientHello or EncryptedExtensions messages without the + quic_transport_parameters extension MUST close the connection with an + error of type 0x016d (equivalent to a fatal TLS missing_extension + alert, see Section 4.8). + + Transport parameters become available prior to the completion of the + handshake. A server might use these values earlier than handshake + completion. However, the value of transport parameters is not + authenticated until the handshake completes, so any use of these + parameters cannot depend on their authenticity. Any tampering with + transport parameters will cause the handshake to fail. + + Endpoints MUST NOT send this extension in a TLS connection that does + not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A + fatal unsupported_extension alert MUST be sent by an implementation + that supports this extension if the extension is received when the + transport is not QUIC. + + Negotiating the quic_transport_parameters extension causes the + EndOfEarlyData to be removed; see Section 8.3. + +8.3. Removing the EndOfEarlyData Message + + The TLS EndOfEarlyData message is not used with QUIC. QUIC does not + rely on this message to mark the end of 0-RTT data or to signal the + change to Handshake keys. + + Clients MUST NOT send the EndOfEarlyData message. A server MUST + treat receipt of a CRYPTO frame in a 0-RTT packet as a connection + error of type PROTOCOL_VIOLATION. + + As a result, EndOfEarlyData does not appear in the TLS handshake + transcript. + +8.4. Prohibit TLS Middlebox Compatibility Mode + + Appendix D.4 of [TLS13] describes an alteration to the TLS 1.3 + handshake as a workaround for bugs in some middleboxes. The TLS 1.3 + middlebox compatibility mode involves setting the legacy_session_id + field to a 32-byte value in the ClientHello and ServerHello, then + sending a change_cipher_spec record. Both field and record carry no + semantic content and are ignored. + + This mode has no use in QUIC as it only applies to middleboxes that + interfere with TLS over TCP. QUIC also provides no means to carry a + change_cipher_spec record. A client MUST NOT request the use of the + TLS 1.3 compatibility mode. A server SHOULD treat the receipt of a + TLS ClientHello with a non-empty legacy_session_id field as a + connection error of type PROTOCOL_VIOLATION. + +9. Security Considerations + + All of the security considerations that apply to TLS also apply to + the use of TLS in QUIC. Reading all of [TLS13] and its appendices is + the best way to gain an understanding of the security properties of + QUIC. + + This section summarizes some of the more important security aspects + specific to the TLS integration, though there are many security- + relevant details in the remainder of the document. + +9.1. Session Linkability + + Use of TLS session tickets allows servers and possibly other entities + to correlate connections made by the same client; see Section 4.5 for + details. + +9.2. Replay Attacks with 0-RTT + + As described in Section 8 of [TLS13], use of TLS early data comes + with an exposure to replay attack. The use of 0-RTT in QUIC is + similarly vulnerable to replay attack. + + Endpoints MUST implement and use the replay protections described in + [TLS13], however it is recognized that these protections are + imperfect. Therefore, additional consideration of the risk of replay + is needed. + + QUIC is not vulnerable to replay attack, except via the application + protocol information it might carry. The management of QUIC protocol + state based on the frame types defined in [QUIC-TRANSPORT] is not + vulnerable to replay. Processing of QUIC frames is idempotent and + cannot result in invalid connection states if frames are replayed, + reordered, or lost. QUIC connections do not produce effects that + last beyond the lifetime of the connection, except for those produced + by the application protocol that QUIC serves. + + TLS session tickets and address validation tokens are used to carry + QUIC configuration information between connections, specifically, to + enable a server to efficiently recover state that is used in + connection establishment and address validation. These MUST NOT be + used to communicate application semantics between endpoints; clients + MUST treat them as opaque values. The potential for reuse of these + tokens means that they require stronger protections against replay. + + A server that accepts 0-RTT on a connection incurs a higher cost than + accepting a connection without 0-RTT. This includes higher + processing and computation costs. Servers need to consider the + probability of replay and all associated costs when accepting 0-RTT. + + Ultimately, the responsibility for managing the risks of replay + attacks with 0-RTT lies with an application protocol. An application + protocol that uses QUIC MUST describe how the protocol uses 0-RTT and + the measures that are employed to protect against replay attack. An + analysis of replay risk needs to consider all QUIC protocol features + that carry application semantics. + + Disabling 0-RTT entirely is the most effective defense against replay + attack. + + QUIC extensions MUST either describe how replay attacks affect their + operation or prohibit the use of the extension in 0-RTT. Application + protocols MUST either prohibit the use of extensions that carry + application semantics in 0-RTT or provide replay mitigation + strategies. + +9.3. Packet Reflection Attack Mitigation + + A small ClientHello that results in a large block of handshake + messages from a server can be used in packet reflection attacks to + amplify the traffic generated by an attacker. + + QUIC includes three defenses against this attack. First, the packet + containing a ClientHello MUST be padded to a minimum size. Second, + if responding to an unverified source address, the server is + forbidden to send more than three times as many bytes as the number + of bytes it has received (see Section 8.1 of [QUIC-TRANSPORT]). + Finally, because acknowledgments of Handshake packets are + authenticated, a blind attacker cannot forge them. Put together, + these defenses limit the level of amplification. + +9.4. Header Protection Analysis + + [NAN] analyzes authenticated encryption algorithms that provide nonce + privacy, referred to as "Hide Nonce" (HN) transforms. The general + header protection construction in this document is one of those + algorithms (HN1). Header protection is applied after the packet + protection AEAD, sampling a set of bytes ("sample") from the AEAD + output and encrypting the header field using a pseudorandom function + (PRF) as follows: + + protected_field = field XOR PRF(hp_key, sample) + + The header protection variants in this document use a pseudorandom + permutation (PRP) in place of a generic PRF. However, since all PRPs + are also PRFs [IMC], these variants do not deviate from the HN1 + construction. + + As "hp_key" is distinct from the packet protection key, it follows + that header protection achieves AE2 security as defined in [NAN] and + therefore guarantees privacy of "field", the protected packet header. + Future header protection variants based on this construction MUST use + a PRF to ensure equivalent security guarantees. + + Use of the same key and ciphertext sample more than once risks + compromising header protection. Protecting two different headers + with the same key and ciphertext sample reveals the exclusive OR of + the protected fields. Assuming that the AEAD acts as a PRF, if L + bits are sampled, the odds of two ciphertext samples being identical + approach 2^(-L/2), that is, the birthday bound. For the algorithms + described in this document, that probability is one in 2^64. + + To prevent an attacker from modifying packet headers, the header is + transitively authenticated using packet protection; the entire packet + header is part of the authenticated additional data. Protected + fields that are falsified or modified can only be detected once the + packet protection is removed. + +9.5. Header Protection Timing Side Channels + + An attacker could guess values for packet numbers or Key Phase and + have an endpoint confirm guesses through timing side channels. + Similarly, guesses for the packet number length can be tried and + exposed. If the recipient of a packet discards packets with + duplicate packet numbers without attempting to remove packet + protection, they could reveal through timing side channels that the + packet number matches a received packet. For authentication to be + free from side channels, the entire process of header protection + removal, packet number recovery, and packet protection removal MUST + be applied together without timing and other side channels. + + For the sending of packets, construction and protection of packet + payloads and packet numbers MUST be free from side channels that + would reveal the packet number or its encoded size. + + During a key update, the time taken to generate new keys could reveal + through timing side channels that a key update has occurred. + Alternatively, where an attacker injects packets, this side channel + could reveal the value of the Key Phase on injected packets. After + receiving a key update, an endpoint SHOULD generate and save the next + set of receive packet protection keys, as described in Section 6.3. + By generating new keys before a key update is received, receipt of + packets will not create timing signals that leak the value of the Key + Phase. + + This depends on not doing this key generation during packet + processing, and it can require that endpoints maintain three sets of + packet protection keys for receiving: for the previous key phase, for + the current key phase, and for the next key phase. Endpoints can + instead choose to defer generation of the next receive packet + protection keys until they discard old keys so that only two sets of + receive keys need to be retained at any point in time. + +9.6. Key Diversity + + In using TLS, the central key schedule of TLS is used. As a result + of the TLS handshake messages being integrated into the calculation + of secrets, the inclusion of the QUIC transport parameters extension + ensures that the handshake and 1-RTT keys are not the same as those + that might be produced by a server running TLS over TCP. To avoid + the possibility of cross-protocol key synchronization, additional + measures are provided to improve key separation. + + The QUIC packet protection keys and IVs are derived using a different + label than the equivalent keys in TLS. + + To preserve this separation, a new version of QUIC SHOULD define new + labels for key derivation for packet protection key and IV, plus the + header protection keys. This version of QUIC uses the string "quic". + Other versions can use a version-specific label in place of that + string. + + The initial secrets use a key that is specific to the negotiated QUIC + version. New QUIC versions SHOULD define a new salt value used in + calculating initial secrets. + +9.7. Randomness + + QUIC depends on endpoints being able to generate secure random + numbers, both directly for protocol values such as the connection ID, + and transitively via TLS. See [RFC4086] for guidance on secure + random number generation. + +10. IANA Considerations + + IANA has registered a codepoint of 57 (or 0x39) for the + quic_transport_parameters extension (defined in Section 8.2) in the + "TLS ExtensionType Values" registry [TLS-REGISTRIES]. + + The Recommended column for this extension is marked Yes. The TLS 1.3 + Column includes CH (ClientHello) and EE (EncryptedExtensions). + + +=======+===========================+=====+=============+===========+ + | Value | Extension Name | TLS | Recommended | Reference | + | | | 1.3 | | | + +=======+===========================+=====+=============+===========+ + | 57 | quic_transport_parameters | CH, | Y | This | + | | | EE | | document | + +-------+---------------------------+-----+-------------+-----------+ + + Table 2: TLS ExtensionType Values Registry Entry + +11. References + +11.1. Normative References + + [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated + Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, + . + + [AES] "Advanced encryption standard (AES)", National Institute + of Standards and Technology report, + DOI 10.6028/nist.fips.197, November 2001, + . + + [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, + "Transport Layer Security (TLS) Application-Layer Protocol + Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, + July 2014, . + + [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF + Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, + . + + [HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand + Key Derivation Function (HKDF)", RFC 5869, + DOI 10.17487/RFC5869, May 2010, + . + + [QUIC-RECOVERY] + Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection + and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, + May 2021, . + + [QUIC-TRANSPORT] + Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [SHA] Dang, Q., "Secure Hash Standard", National Institute of + Standards and Technology report, + DOI 10.6028/nist.fips.180-4, July 2015, + . + + [TLS-REGISTRIES] + Salowey, J. and S. Turner, "IANA Registry Updates for TLS + and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, + . + + [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + +11.2. Informative References + + [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated + Encryption Use in TLS", 28 August 2017, + . + + [ASCII] Cerf, V., "ASCII format for network interchange", STD 80, + RFC 20, DOI 10.17487/RFC0020, October 1969, + . + + [CCM-ANALYSIS] + Jonsson, J., "On the Security of CTR + CBC-MAC", Selected + Areas in Cryptography, SAC 2002, Lecture Notes in Computer + Science, vol 2595, pp. 76-93, DOI 10.1007/3-540-36492-7_7, + 2003, . + + [COMPRESS] Ghedini, A. and V. Vasiliev, "TLS Certificate + Compression", RFC 8879, DOI 10.17487/RFC8879, December + 2020, . + + [GCM-MU] Hoang, V., Tessaro, S., and A. Thiruvengadam, "The Multi- + user Security of GCM, Revisited: Tight Bounds for Nonce + Randomization", CCS '18: Proceedings of the 2018 ACM + SIGSAC Conference on Computer and Communications Security, + pp. 1429-1440, DOI 10.1145/3243734.3243816, 2018, + . + + [HTTP-REPLAY] + Thomson, M., Nottingham, M., and W. Tarreau, "Using Early + Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September + 2018, . + + [HTTP2-TLS13] + Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, + DOI 10.17487/RFC8740, February 2020, + . + + [IMC] Katz, J. and Y. Lindell, "Introduction to Modern + Cryptography, Second Edition", ISBN 978-1466570269, 6 + November 2014. + + [NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed: + AEAD Revisited", Advances in Cryptology - CRYPTO 2019, + Lecture Notes in Computer Science, vol 11692, pp. 235-265, + DOI 10.1007/978-3-030-26948-7_9, 2019, + . + + [QUIC-HTTP] + Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 + (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- + quic-http-34, 2 February 2021, + . + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust + Channels: Handling Unreliable Networks in the Record + Layers of QUIC and DTLS 1.3", 16 May 2020, + . + +Appendix A. Sample Packet Protection + + This section shows examples of packet protection so that + implementations can be verified incrementally. Samples of Initial + packets from both client and server plus a Retry packet are defined. + These packets use an 8-byte client-chosen Destination Connection ID + of 0x8394c8f03e515708. Some intermediate values are included. All + values are shown in hexadecimal. + +A.1. Keys + + The labels generated during the execution of the HKDF-Expand-Label + function (that is, HkdfLabel.label) and part of the value given to + the HKDF-Expand function in order to produce its output are: + + client in: 00200f746c73313320636c69656e7420696e00 + + server in: 00200f746c7331332073657276657220696e00 + + quic key: 00100e746c7331332071756963206b657900 + + quic iv: 000c0d746c733133207175696320697600 + + quic hp: 00100d746c733133207175696320687000 + + The initial secret is common: + + initial_secret = HKDF-Extract(initial_salt, cid) + = 7db5df06e7a69e432496adedb0085192 + 3595221596ae2ae9fb8115c1e9ed0a44 + + The secrets for protecting client packets are: + + client_initial_secret + = HKDF-Expand-Label(initial_secret, "client in", "", 32) + = c00cf151ca5be075ed0ebfb5c80323c4 + 2d6b7db67881289af4008f1f6c357aea + + key = HKDF-Expand-Label(client_initial_secret, "quic key", "", 16) + = 1f369613dd76d5467730efcbe3b1a22d + + iv = HKDF-Expand-Label(client_initial_secret, "quic iv", "", 12) + = fa044b2f42a3fd3b46fb255c + + hp = HKDF-Expand-Label(client_initial_secret, "quic hp", "", 16) + = 9f50449e04a0e810283a1e9933adedd2 + + The secrets for protecting server packets are: + + server_initial_secret + = HKDF-Expand-Label(initial_secret, "server in", "", 32) + = 3c199828fd139efd216c155ad844cc81 + fb82fa8d7446fa7d78be803acdda951b + + key = HKDF-Expand-Label(server_initial_secret, "quic key", "", 16) + = cf3a5331653c364c88f0f379b6067e37 + + iv = HKDF-Expand-Label(server_initial_secret, "quic iv", "", 12) + = 0ac1493ca1905853b0bba03e + + hp = HKDF-Expand-Label(server_initial_secret, "quic hp", "", 16) + = c206b8d9b9f0f37644430b490eeaa314 + +A.2. Client Initial + + The client sends an Initial packet. The unprotected payload of this + packet contains the following CRYPTO frame, plus enough PADDING + frames to make a 1162-byte payload: + + 060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868 + 04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578 + 616d706c652e636f6dff01000100000a 00080006001d00170018001000070005 + 04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba + baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400 + 0d0010000e0403050306030203080408 050806002d00020101001c0002400100 + 3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000 + 75300901100f088394c8f03e51570806 048000ffff + + The unprotected header indicates a length of 1182 bytes: the 4-byte + packet number, 1162 bytes of frames, and the 16-byte authentication + tag. The header includes the connection ID and a packet number of 2: + + c300000001088394c8f03e5157080000449e00000002 + + Protecting the payload produces output that is sampled for header + protection. Because the header uses a 4-byte packet number encoding, + the first 16 bytes of the protected payload is sampled and then + applied to the header as follows: + + sample = d1b1c98dd7689fb8ec11d242b123dc9b + + mask = AES-ECB(hp, sample)[0..4] + = 437b9aec36 + + header[0] ^= mask[0] & 0x0f + = c0 + header[18..21] ^= mask[1..4] + = 7b9aec34 + header = c000000001088394c8f03e5157080000449e7b9aec34 + + The resulting protected packet is: + + c000000001088394c8f03e5157080000 449e7b9aec34d1b1c98dd7689fb8ec11 + d242b123dc9bd8bab936b47d92ec356c 0bab7df5976d27cd449f63300099f399 + 1c260ec4c60d17b31f8429157bb35a12 82a643a8d2262cad67500cadb8e7378c + 8eb7539ec4d4905fed1bee1fc8aafba1 7c750e2c7ace01e6005f80fcb7df6212 + 30c83711b39343fa028cea7f7fb5ff89 eac2308249a02252155e2347b63d58c5 + 457afd84d05dfffdb20392844ae81215 4682e9cf012f9021a6f0be17ddd0c208 + 4dce25ff9b06cde535d0f920a2db1bf3 62c23e596d11a4f5a6cf3948838a3aec + 4e15daf8500a6ef69ec4e3feb6b1d98e 610ac8b7ec3faf6ad760b7bad1db4ba3 + 485e8a94dc250ae3fdb41ed15fb6a8e5 eba0fc3dd60bc8e30c5c4287e53805db + 059ae0648db2f64264ed5e39be2e20d8 2df566da8dd5998ccabdae053060ae6c + 7b4378e846d29f37ed7b4ea9ec5d82e7 961b7f25a9323851f681d582363aa5f8 + 9937f5a67258bf63ad6f1a0b1d96dbd4 faddfcefc5266ba6611722395c906556 + be52afe3f565636ad1b17d508b73d874 3eeb524be22b3dcbc2c7468d54119c74 + 68449a13d8e3b95811a198f3491de3e7 fe942b330407abf82a4ed7c1b311663a + c69890f4157015853d91e923037c227a 33cdd5ec281ca3f79c44546b9d90ca00 + f064c99e3dd97911d39fe9c5d0b23a22 9a234cb36186c4819e8b9c5927726632 + 291d6a418211cc2962e20fe47feb3edf 330f2c603a9d48c0fcb5699dbfe58964 + 25c5bac4aee82e57a85aaf4e2513e4f0 5796b07ba2ee47d80506f8d2c25e50fd + 14de71e6c418559302f939b0e1abd576 f279c4b2e0feb85c1f28ff18f58891ff + ef132eef2fa09346aee33c28eb130ff2 8f5b766953334113211996d20011a198 + e3fc433f9f2541010ae17c1bf202580f 6047472fb36857fe843b19f5984009dd + c324044e847a4f4a0ab34f719595de37 252d6235365e9b84392b061085349d73 + 203a4a13e96f5432ec0fd4a1ee65accd d5e3904df54c1da510b0ff20dcc0c77f + cb2c0e0eb605cb0504db87632cf3d8b4 dae6e705769d1de354270123cb11450e + fc60ac47683d7b8d0f811365565fd98c 4c8eb936bcab8d069fc33bd801b03ade + a2e1fbc5aa463d08ca19896d2bf59a07 1b851e6c239052172f296bfb5e724047 + 90a2181014f3b94a4e97d117b4381303 68cc39dbb2d198065ae3986547926cd2 + 162f40a29f0c3c8745c0f50fba3852e5 66d44575c29d39a03f0cda721984b6f4 + 40591f355e12d439ff150aab7613499d bd49adabc8676eef023b15b65bfc5ca0 + 6948109f23f350db82123535eb8a7433 bdabcb909271a6ecbcb58b936a88cd4e + 8f2e6ff5800175f113253d8fa9ca8885 c2f552e657dc603f252e1a8e308f76f0 + be79e2fb8f5d5fbbe2e30ecadd220723 c8c0aea8078cdfcb3868263ff8f09400 + 54da48781893a7e49ad5aff4af300cd8 04a6b6279ab3ff3afb64491c85194aab + 760d58a606654f9f4400e8b38591356f bf6425aca26dc85244259ff2b19c41b9 + f96f3ca9ec1dde434da7d2d392b905dd f3d1f9af93d1af5950bd493f5aa731b4 + 056df31bd267b6b90a079831aaf579be 0a39013137aac6d404f518cfd4684064 + 7e78bfe706ca4cf5e9c5453e9f7cfd2b 8b4c8d169a44e55c88d4a9a7f9474241 + e221af44860018ab0856972e194cd934 + +A.3. Server Initial + + The server sends the following payload in response, including an ACK + frame, a CRYPTO frame, and no PADDING frames: + + 02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739 + 88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94 + 0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00 + 020304 + + The header from the server includes a new connection ID and a 2-byte + packet number encoding for a packet number of 1: + + c1000000010008f067a5502a4262b50040750001 + + As a result, after protection, the header protection sample is taken + starting from the third protected byte: + + sample = 2cd0991cd25b0aac406a5816b6394100 + mask = 2ec0d8356a + header = cf000000010008f067a5502a4262b5004075c0d9 + + The final protected packet is then: + + cf000000010008f067a5502a4262b500 4075c0d95a482cd0991cd25b0aac406a + 5816b6394100f37a1c69797554780bb3 8cc5a99f5ede4cf73c3ec2493a1839b3 + dbcba3f6ea46c5b7684df3548e7ddeb9 c3bf9c73cc3f3bded74b562bfb19fb84 + 022f8ef4cdd93795d77d06edbb7aaf2f 58891850abbdca3d20398c276456cbc4 + 2158407dd074ee + +A.4. Retry + + This shows a Retry packet that might be sent in response to the + Initial packet in Appendix A.2. The integrity check includes the + client-chosen connection ID value of 0x8394c8f03e515708, but that + value is not included in the final Retry packet: + + ff000000010008f067a5502a4262b574 6f6b656e04a265ba2eff4d829058fb3f + 0f2496ba + +A.5. ChaCha20-Poly1305 Short Header Packet + + This example shows some of the steps required to protect a packet + with a short header. This example uses AEAD_CHACHA20_POLY1305. + + In this example, TLS produces an application write secret from which + a server uses HKDF-Expand-Label to produce four values: a key, an IV, + a header protection key, and the secret that will be used after keys + are updated (this last value is not used further in this example). + + secret + = 9ac312a7f877468ebe69422748ad00a1 + 5443f18203a07d6060f688f30f21632b + + key = HKDF-Expand-Label(secret, "quic key", "", 32) + = c6d98ff3441c3fe1b2182094f69caa2e + d4b716b65488960a7a984979fb23e1c8 + + iv = HKDF-Expand-Label(secret, "quic iv", "", 12) + = e0459b3474bdd0e44a41c144 + + hp = HKDF-Expand-Label(secret, "quic hp", "", 32) + = 25a282b9e82f06f21f488917a4fc8f1b + 73573685608597d0efcb076b0ab7a7a4 + + ku = HKDF-Expand-Label(secret, "quic ku", "", 32) + = 1223504755036d556342ee9361d25342 + 1a826c9ecdf3c7148684b36b714881f9 + + The following shows the steps involved in protecting a minimal packet + with an empty Destination Connection ID. This packet contains a + single PING frame (that is, a payload of just 0x01) and has a packet + number of 654360564. In this example, using a packet number of + length 3 (that is, 49140 is encoded) avoids having to pad the payload + of the packet; PADDING frames would be needed if the packet number is + encoded on fewer bytes. + + pn = 654360564 (decimal) + nonce = e0459b3474bdd0e46d417eb0 + unprotected header = 4200bff4 + payload plaintext = 01 + payload ciphertext = 655e5cd55c41f69080575d7999c25a5bfb + + The resulting ciphertext is the minimum size possible. One byte is + skipped to produce the sample for header protection. + + sample = 5e5cd55c41f69080575d7999c25a5bfb + mask = aefefe7d03 + header = 4cfe4189 + + The protected packet is the smallest possible packet size of 21 + bytes. + + packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb + +Appendix B. AEAD Algorithm Analysis + + This section documents analyses used in deriving AEAD algorithm + limits for AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. + The analyses that follow use symbols for multiplication (*), division + (/), and exponentiation (^), plus parentheses for establishing + precedence. The following symbols are also used: + + t: The size of the authentication tag in bits. For these ciphers, t + is 128. + + n: The size of the block function in bits. For these ciphers, n is + 128. + + k: The size of the key in bits. This is 128 for AEAD_AES_128_GCM + and AEAD_AES_128_CCM; 256 for AEAD_AES_256_GCM. + + l: The number of blocks in each packet (see below). + + q: The number of genuine packets created and protected by endpoints. + This value is the bound on the number of packets that can be + protected before updating keys. + + v: The number of forged packets that endpoints will accept. This + value is the bound on the number of forged packets that an + endpoint can reject before updating keys. + + o: The amount of offline ideal cipher queries made by an adversary. + + The analyses that follow rely on a count of the number of block + operations involved in producing each message. This analysis is + performed for packets of size up to 2^11 (l = 2^7) and 2^16 (l = + 2^12). A size of 2^11 is expected to be a limit that matches common + deployment patterns, whereas the 2^16 is the maximum possible size of + a QUIC packet. Only endpoints that strictly limit packet size can + use the larger confidentiality and integrity limits that are derived + using the smaller packet size. + + For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the message length (l) is + the length of the associated data in blocks plus the length of the + plaintext in blocks. + + For AEAD_AES_128_CCM, the total number of block cipher operations is + the sum of the following: the length of the associated data in + blocks, the length of the ciphertext in blocks, the length of the + plaintext in blocks, plus 1. In this analysis, this is simplified to + a value of twice the length of the packet in blocks (that is, "2l = + 2^8" for packets that are limited to 2^11 bytes, or "2l = 2^13" + otherwise). This simplification is based on the packet containing + all of the associated data and ciphertext. This results in a one to + three block overestimation of the number of operations per packet. + +B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits + + [GCM-MU] specifies concrete bounds for AEAD_AES_128_GCM and + AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents + this analysis using several simplifying assumptions: + + * The number of ciphertext blocks an attacker uses in forgery + attempts is bounded by v * l, which is the number of forgery + attempts multiplied by the size of each packet (in blocks). + + * The amount of offline work done by an attacker does not dominate + other factors in the analysis. + + The bounds in [GCM-MU] are tighter and more complete than those used + in [AEBounds], which allows for larger limits than those described in + [TLS13]. + +B.1.1. Confidentiality Limit + + For confidentiality, Theorem (4.3) in [GCM-MU] establishes that, for + a single user that does not repeat nonces, the dominant term in + determining the distinguishing advantage between a real and random + AEAD algorithm gained by an attacker is: + + 2 * (q * l)^2 / 2^n + + For a target advantage of 2^-57, this results in the relation: + + q <= 2^35 / l + + Thus, endpoints that do not send packets larger than 2^11 bytes + cannot protect more than 2^28 packets in a single connection without + causing an attacker to gain a more significant advantage than the + target of 2^-57. The limit for endpoints that allow for the packet + size to be as large as 2^16 is instead 2^23. + +B.1.2. Integrity Limit + + For integrity, Theorem (4.3) in [GCM-MU] establishes that an attacker + gains an advantage in successfully forging a packet of no more than + the following: + + (1 / 2^(8 * n)) + ((2 * v) / 2^(2 * n)) + + ((2 * o * v) / 2^(k + n)) + (n * (v + (v * l)) / 2^k) + + The goal is to limit this advantage to 2^-57. For AEAD_AES_128_GCM, + the fourth term in this inequality dominates the rest, so the others + can be removed without significant effect on the result. This + produces the following approximation: + + v <= 2^64 / l + + Endpoints that do not attempt to remove protection from packets + larger than 2^11 bytes can attempt to remove protection from at most + 2^57 packets. Endpoints that do not restrict the size of processed + packets can attempt to remove protection from at most 2^52 packets. + + For AEAD_AES_256_GCM, the same term dominates, but the larger value + of k produces the following approximation: + + v <= 2^192 / l + + This is substantially larger than the limit for AEAD_AES_128_GCM. + However, this document recommends that the same limit be applied to + both functions as either limit is acceptably large. + +B.2. Analysis of AEAD_AES_128_CCM Usage Limits + + TLS [TLS13] and [AEBounds] do not specify limits on usage for + AEAD_AES_128_CCM. However, any AEAD that is used with QUIC requires + limits on use that ensure that both confidentiality and integrity are + preserved. This section documents that analysis. + + [CCM-ANALYSIS] is used as the basis of this analysis. The results of + that analysis are used to derive usage limits that are based on those + chosen in [TLS13]. + + For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an + attacker gains a distinguishing advantage over an ideal pseudorandom + permutation (PRP) of no more than the following: + + (2l * q)^2 / 2^n + + The integrity limit in Theorem 1 in [CCM-ANALYSIS] provides an + attacker a strictly higher advantage for the same number of messages. + As the targets for the confidentiality advantage and the integrity + advantage are the same, only Theorem 1 needs to be considered. + + Theorem 1 establishes that an attacker gains an advantage over an + ideal PRP of no more than the following: + + v / 2^t + (2l * (v + q))^2 / 2^n + + As "t" and "n" are both 128, the first term is negligible relative to + the second, so that term can be removed without a significant effect + on the result. + + This produces a relation that combines both encryption and decryption + attempts with the same limit as that produced by the theorem for + confidentiality alone. For a target advantage of 2^-57, this results + in the following: + + v + q <= 2^34.5 / l + + By setting "q = v", values for both confidentiality and integrity + limits can be produced. Endpoints that limit packets to 2^11 bytes + therefore have both confidentiality and integrity limits of 2^26.5 + packets. Endpoints that do not restrict packet size have a limit of + 2^21.5. + +Contributors + + The IETF QUIC Working Group received an enormous amount of support + from many people. The following people provided substantive + contributions to this document: + + * Adam Langley + * Alessandro Ghedini + * Christian Huitema + * Christopher Wood + * David Schinazi + * Dragana Damjanovic + * Eric Rescorla + * Felix Günther + * Ian Swett + * Jana Iyengar + * 奥 一穂 (Kazuho Oku) + * Marten Seemann + * Martin Duke + * Mike Bishop + * Mikkel Fahnøe Jørgensen + * Nick Banks + * Nick Harper + * Roberto Peon + * Rui Paulo + * Ryan Hamilton + * Victor Vasiliev + +Authors' Addresses + + Martin Thomson (editor) + Mozilla + + Email: mt@lowentropy.net + + + Sean Turner (editor) + sn3rd + + Email: sean@sn3rd.com diff --git a/compliance/specs/www.rfc-editor.org/rfc/rfc9151.txt b/compliance/specs/www.rfc-editor.org/rfc/rfc9151.txt new file mode 100644 index 00000000000..7a4f88813a0 --- /dev/null +++ b/compliance/specs/www.rfc-editor.org/rfc/rfc9151.txt @@ -0,0 +1,711 @@ + + + + +Independent Submission D. Cooley +Request for Comments: 9151 NSA +Category: Informational April 2022 +ISSN: 2070-1721 + + +Commercial National Security Algorithm (CNSA) Suite Profile for TLS and + DTLS 1.2 and 1.3 + +Abstract + + This document defines a base profile for TLS protocol versions 1.2 + and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with + the US Commercial National Security Algorithm (CNSA) Suite. + + The profile applies to the capabilities, configuration, and operation + of all components of US National Security Systems that use TLS or + DTLS. It is also appropriate for all other US Government systems + that process high-value information. + + The profile is made publicly available here for use by developers and + operators of these and any other system deployments. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9151. + +Copyright Notice + + Copyright (c) 2022 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 2. CNSA + 3. Terminology + 4. CNSA Suites + 4.1. CNSA (D)TLS Key Establishment Algorithms + 4.2. CNSA TLS Authentication + 5. CNSA Compliance and Interoperability Requirements + 5.1. Acceptable Elliptic Curve Cryptography (ECC) Curves + 5.2. Acceptable RSA Schemes, Parameters, and Checks + 5.3. Acceptable Finite Field Groups + 5.4. Certificates + 6. (D)TLS 1.2 Requirements + 6.1. The "extended_master_secret" Extension + 6.2. The "signature_algorithms" Extension + 6.3. The "signature_algorithms_cert" Extension + 6.4. The CertificateRequest Message + 6.5. The CertificateVerify Message + 6.6. The Signature in the ServerKeyExchange Message + 6.7. Certificate Status + 7. (D)TLS 1.3 Requirements + 7.1. The "signature_algorithms" Extension + 7.2. The "signature_algorithms_cert" Extension + 7.3. The "early_data" Extension + 7.4. Resumption + 7.5. Certificate Status + 8. Security Considerations + 9. IANA Considerations + 10. References + 10.1. Normative References + 10.2. Informative References + Author's Address + +1. Introduction + + This document specifies a profile of TLS version 1.2 [RFC5246] and + TLS version 1.3 [RFC8446] as well as DTLS version 1.2 [RFC6347] and + DTLS version 1.3 [RFC9147] for use by applications that support the + National Security Agency's (NSA) Commercial National Security + Algorithm (CNSA) Suite [CNSA]. The profile applies to the + capabilities, configuration, and operation of all components of US + National Security Systems [SP80059]. It is also appropriate for all + other US Government systems that process high-value information. It + is made publicly available for use by developers and operators of + these and any other system deployments. + + This document does not define any new cipher suites; instead, it + defines a CNSA-compliant profile of TLS and DTLS, and the cipher + suites defined in [RFC5288], [RFC5289], and [RFC8446]. This profile + uses only algorithms in the CNSA Suite. + + The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as + well as the DTLS 1.2 and 1.3 protocol specifications: [RFC5246], + [RFC8446], [RFC6347], and [RFC9147], respectively. All MUST-level + requirements from the protocol documents apply throughout this + profile; they are generally not repeated. This profile contains + changes that elevate some SHOULD-level options to MUST-level; this + profile also contains changes that elevate some MAY-level options to + SHOULD-level or MUST-level. All options that are not mentioned in + this profile remain at their original requirement level. + +2. CNSA + + The National Security Agency (NSA) profiles commercial cryptographic + algorithms and protocols as part of its mission to support secure, + interoperable communications for US National Security Systems. To + this end, it publishes guidance both to assist with the US Government + transition to new algorithms and to provide vendors -- and the + Internet community in general -- with information concerning their + proper use and configuration. + + Recently, cryptographic transition plans have become overshadowed by + the prospect of the development of a cryptographically relevant + quantum computer. The NSA has established the CNSA Suite to provide + vendors and IT users near-term flexibility in meeting their + Information Assurance (IA) interoperability requirements. The + purpose behind this flexibility is to avoid having vendors and + customers make two major transitions in a relatively short timeframe, + as we anticipate a need to shift to quantum-resistant cryptography in + the near future. + + The NSA is authoring a set of RFCs, including this one, to provide + updated guidance concerning the use of certain commonly available + commercial algorithms in IETF protocols. These RFCs can be used in + conjunction with other RFCs and cryptographic guidance (e.g., NIST + Special Publications) to properly protect Internet traffic and data- + at-rest for US National Security Systems. + +3. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + "ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital + Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), + respectively. ECDSA and ECDH are used with the NIST P-384 curve + (which is based on a 384-bit prime modulus) and the SHA-384 hash + function. Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman + (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH + are used with a 3072-bit or 4096-bit modulus. When RSA is used for + digital signature, it is used with the SHA-384 hash function. + + Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS + versions 1.2 and 1.3 collectively as "(D)TLS". + +4. CNSA Suites + + [CNSA] approves the use of both Finite Field and elliptic curve + versions of the DH key agreement algorithm as well as RSA-based key + establishment. [CNSA] also approves certain versions of the RSA and + elliptic curve digital signature algorithms. The approved encryption + techniques include the Advanced Encryption Standard (AES) used with a + 256-bit key in an Authenticated Encryption with Associated Data + (AEAD) mode. + + In particular, CNSA includes the following: + + Encryption: + AES [AES] (with key size 256 bits), operating in Galois/Counter + Mode (GCM) [GCM] + + Digital Signature: + ECDSA [DSS] (using the NIST P-384 elliptic curve) + + RSA [DSS] (with a modulus of 3072 bits or 4096 bits) + + Key Establishment (includes key agreement and key transport): + ECDH [PWKE-A] (using the NIST P-384 elliptic curve) + + DH [PWKE-A] (with a prime modulus of 3072 or 4096 bits) + + RSA [PWKE-B] (with a modulus of 3072 or 4096 bits, but only in + (D)TLS 1.2) + + [CNSA] also approves the use of SHA-384 [SHS] as the hash algorithm + for mask generation, signature generation, Pseudorandom Function + (PRF) in TLS 1.2 and HMAC-based Key Derivation Function (HKDF) in TLS + 1.3. + +4.1. CNSA (D)TLS Key Establishment Algorithms + + The following combination of algorithms and key sizes are used in + CNSA (D)TLS: + + AES with 256-bit key, operating in GCM mode + + ECDH [PWKE-A] using the Ephemeral Unified Model Scheme with + cofactor set to 1 (see Section 6.1.2.2 in [PWKE-A]) + + TLS PRF/HKDF with SHA-384 [SHS] + + Or + + AES with 256-bit key, operating in GCM mode + + RSA key transport using 3072-bit or 4096-bit modulus + [PWKE-B][RFC8017] + + TLS PRF/HKDF with SHA-384 [SHS] + + Or + + AES with 256-bit key, operating in GCM mode + + DH using dhEphem with domain parameters specified below in + Section 5.3 (see Section 6.1.2.1 in [PWKE-A]) + + TLS PRF/HKDF with SHA-384 [SHS] + + The specific CNSA-compliant cipher suites are listed in Section 5. + +4.2. CNSA TLS Authentication + + For server and/or client authentication, CNSA (D)TLS MUST generate + and verify either ECDSA signatures or RSA signatures. + + In all cases, the client MUST authenticate the server. The server + MAY also authenticate the client, as needed by the specific + application. + + The public keys used to verify these signatures MUST be contained in + a certificate (see Section 5.4 for more information). + +5. CNSA Compliance and Interoperability Requirements + + CNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA- + compliant system. CNSA (D)TLS servers and clients MUST implement and + use either (D)TLS version 1.2 [RFC5246] [RFC6347] or (D)TLS version + 1.3 [RFC8446] [RFC9147]. + +5.1. Acceptable Elliptic Curve Cryptography (ECC) Curves + + The elliptic curves used in the CNSA Suite appear in the literature + under two different names [DSS] [SECG]. For the sake of clarity, + both names are listed below: + + +=======+===========+===========+ + | Curve | NIST name | SECG name | + +=======+===========+===========+ + | P-384 | nistp384 | secp384r1 | + +-------+-----------+-----------+ + + Table 1: Elliptic Curves in + CNSA Suite + + [RFC8422] defines a variety of elliptic curves. CNSA (D)TLS + connections MUST use secp384r1 (also called nistp384), and the + uncompressed form MUST be used, as required by [RFC8422] and + [RFC8446]. + + Key pairs MUST be generated following Section 5.6.1.2 of [PWKE-A]. + +5.2. Acceptable RSA Schemes, Parameters, and Checks + + [CNSA] specifies a minimum modulus size of 3072 bits; however, only + two modulus sizes (3072 bits and 4096 bits) are supported by this + profile. + + For (D)TLS 1.2: + For certificate signatures, RSASSA-PKCS1-v1_5 [RFC8017] MUST be + supported, and RSASSA-PSS [DSS] SHOULD be supported. + + For signatures in TLS handshake messages, RSASSA-PKCS1-v1_5 + [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be + supported. + + For key transport, RSAES-PKCS1-v1_5 [RFC8017] MUST be supported. + + For (D)TLS 1.3: + For certificate signatures, RSASSA-PKCS1-v1_5 [RFC8017] MUST be + supported, and RSASSA-PSS [DSS] SHOULD be supported. + + For signatures in TLS handshake messages, RSASSA-PSS [DSS] MUST be + supported. + + For key transport, TLS 1.3 does not support RSA key transport. + + For all versions of (D)TLS: + RSA exponent e MUST satisfy 2^16. + + [CNSA] Committee for National Security Systems, "Use of Public + Standards for Secure Information Sharing", CNSSP 15, + October 2016, + . + + [DSS] National Institute of Standards and Technology, "Digital + Signature Standard (DSS)", FIPS PUB 186-4, + DOI 10.6028/NIST.FIPS.186-4, July 2013, + . + + [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of + Operation: Galois/Counter Mode (GCM) and GMAC", NIST + Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, + November 2007, + . + + [PWKE-A] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. + Davis, "Recommendation for Pair-Wise Key Establishment + Schemes Using Discrete Logarithm Cryptography", NIST + Special Publication 800-56A Revision 3, + DOI 10.6028/NIST.SP.800-56Ar3, April 2018, + . + + [PWKE-B] Barker, E., Chen, L., Roginsky, A., Vassilev, A., Davis, + R., and S. Simon, "Recommendation for Pair-Wise Key + Establishment Schemes Using Integer Factorization + Cryptography", NIST Special Publication 800-56B Revision + 2, DOI 10.6028/NIST.SP.800-56Br2, March 2019, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois + Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, + DOI 10.17487/RFC5288, August 2008, + . + + [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- + 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, + DOI 10.17487/RFC5289, August 2008, + . + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, . + + [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., + Langley, A., and M. Ray, "Transport Layer Security (TLS) + Session Hash and Extended Master Secret Extension", + RFC 7627, DOI 10.17487/RFC7627, September 2015, + . + + [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman + Ephemeral Parameters for Transport Layer Security (TLS)", + RFC 7919, DOI 10.17487/RFC7919, August 2016, + . + + [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, + "PKCS #1: RSA Cryptography Specifications Version 2.2", + RFC 8017, DOI 10.17487/RFC8017, November 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic + Curve Cryptography (ECC) Cipher Suites for Transport Layer + Security (TLS) Versions 1.2 and Earlier", RFC 8422, + DOI 10.17487/RFC8422, August 2018, + . + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + + [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security + Algorithm (CNSA) Suite Certificate and Certificate + Revocation List (CRL) Profile", RFC 8603, + DOI 10.17487/RFC8603, May 2019, + . + + [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The + Datagram Transport Layer Security (DTLS) Protocol Version + 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, + . + + [SHS] National Institute of Standards and Technology (NIST), + "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, + FIPS PUB 180-4, August 2015, + . + +10.2. Informative References + + [SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain + Parameters", Version 2.0, February 2010, + . + + [SP80059] Barker, W., "Guideline for Identifying an Information + System as a National Security System", + DOI 10.6028/NIST.SP.800-59, NIST Special + Publication 800-59, August 2003, + . + +Author's Address + + Dorothy Cooley + National Security Agency + Email: decoole@nsa.gov