| Internet-Draft | Validation Request Extension | June 2022 |
| Segers & Kopman | Expires 5 December 2022 | [Page] |
This document describes the Path Validation extension to the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.¶
The Path Validation Extension provides a new protocol for TLS/DTLS allowing inclusion of certificate path validation information in the TLS/DTLS handshake.¶
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 https://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 5 December 2022.¶
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document describes an extension to TLS 1.3 [RFC8446] and DTLS 1.3 [RFC9147] for the inclusion of certificate path validation information in the TLS/DTLS handshake. Specifically, this extension covers the use of the Server-based Certificate Validation Protocol (SCVP) [RFC5055] for path validation. However, the extension is designed to allow for expansion to other path validation protocols.¶
This extension is defined for TLS and DTLS protocols. For convenience, the protocol will be referred to as TLS for the rest of the document. DTLS will only be specifically mentioned in cases where the protocols differ.¶
The TLS standard specifies that certificates should always be verified to ensure proper signing by a trusted Certificate Authority (CA) in Part Appendix C.2 of TLS 1.3 [RFC8446]. The establishment of trust requires construction and validation of a trust path from the end-entity certificate to a trust anchor. This validation can be a complex process of chaining certificates, validating revocation information, and enforcing organizational policies. Therefore, constrained clients may wish to delegate certificate path construction and validation to a trusted server. Additionally, to ensure that policies are consistently enforced throughout an ecosystem, centralization of certificate validation may be needed. Protocols such as Server-based Certificate Validation Protocol (SCVP) allow simplification of client implementations and consistent application of validation policies by delegating validation to a server.¶
The extension described here allows a TLS client to request that the TLS server return the certificate path validation corresponding to its certificate. If the server supports this extension, it performs the appropriate certificate validation queries and returns it to the client. The server returns the path validation as an extension to the Certificate message. Since path building and validation has been performed, the server can return only the end-entity certificate to be used for authentication, and does not need to return any supporting certificates in the chain. This further reduces the bandwidth consumption. The server can use a previously cached validation response, but it will need to retrieve it periodically as described in Section 4.2. The client then examines the returned validation response and the response signature using a local trust anchor.¶
TLS clients and servers MAY use the extension described in this document. The extension is designed to be backwards compatible, meaning that TLS clients that support the extension can talk to TLS servers that do not support the extension, and vice versa.¶
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].¶
A new extension type (validation_request (60 TBD)) is added to the extensions used in the client hello and certificate handshake messages. The extension type is specified as follows.¶
enum {
validation_request(60 TBD), (65535)
} ExtensionType;
¶
To indicate their desire to receive certificate path validation information, TLS clients MAY include an extension of type validation_request in the (extended) client hello. The extension_data field of the validation_request extension MUST contain a PathValidationRequest. The PathValidationRequest MUST consist of a PathValidationType and Request as defined in Section 3.¶
Servers that receive a client hello containing the validation_request extension MAY return a suitable certificate path validation response to the client along with their certificate.¶
Servers return a certificate path validation response along with their certificate by adding the validation_request extension to the extension block of the TLS server certificate. The Certificate message containing the TLS server end-entity certificate SHOULD contain the extension with extension_type validation_request and extension_data of PathValidation. Severs that send the PathValidation extension data MUST have received a validation_request in the extended client hello.¶
Servers that send the PathValidation extension SHOULD only include the end-entity authentication certificate in the Certificate message. The server MAY include supporting certificates. The client MAY ignore supporting certificates if the PathValidation is found to be satisfactory.¶
Clients that receive a PathValidation extension without sending a validation_request extension MUST abort the connection.¶
Servers that do not support (or are not configured to enable the use of) this extension SHOULD NOT include the validation_request extension in the Certificate message.¶
A server MAY also choose not to send a PathValidation extension, even if has received a validation_request extension in the client hello message.¶
If the client sent a validation_request in the client hello extension but did not receive a validation_request extension in the server Certificate message MAY choose to use alternative means to validate the server certificate or MAY choose to abort the connection.¶
Clients requesting a certificate path validation and receiving validation_request Certificate extension MUST check the PathValidation message and abort the handshake if the response is not satisfactory with bad_certificate_validation_response (117 TBD) alert. This alert is always fatal.¶
The PathValidationRequest and PathValidation types are further defined in Section 3 and Section 4 of this document.¶
Deployment of Public Key Infrastructure (PKI) enabled applications can be simplified by delegating path validation processing to a server. Additionally, for organizations wishing to centralize administration of validation policies, delegation to a server ensures consistent policy validation across clients in an ecosystem.¶
Constrained clients wishing to delegate path validation also face challenges such as bandwidth and latency limitations. This extension allows for such information to be sent in the TLS handshake, saving roundtrips and resources.¶
To indicate their desire to receive certificate validation information, TLS clients MAY include an extension of type validation_request in the extended client hello. ClientHello handshake messages containing the validation_request extension SHALL contain a PathValidationRequest in the extension_data field of this extension. The PathValidationRequest is defined as follows:¶
struct {
PathValidationType path_validation_type;
select (path_validation_type) {
case scvp: SCVPValidationRequest;
} request;
} PathValidationRequest;
enum { scvp(1), (255) } PathValidationType;
¶
The PathValidationRequest is defined for type Server-based Certificate Validation Protocol (SCVP) however is designed to be extendable to other protocols.¶
SCVP provides a standards-based client-server protocol for delegated path validation defined in RFC 5055 [RFC5055]. Clients wishing to request the use of SCVP path validation MAY include the path_validation extension in the client hello handshake with the PathValidationType of scvp (1) in the PathValidationRequest. If the PathValidationType is set to scvp, the Request SHALL be an SCVPValidationRequest.¶
The SCVPValidationRequest consists of three optional lists: a list of SCVP responder URIs, a list of trust anchors, and a list of validation extensions.¶
struct {
ResponderURIs responder_uri_list<0..2^16-1>;
TrustAnchors trust_anchor_list<0..2^16-1>;
ValidationExtensions validation_extensions_list<0..2^16-1>;
} SCVPValidationRequest;
¶
The ResponderURIs provides a list of SCVP responders that the client trusts. A zero-length responder_uri_list sequence has special meaning that the responders are implicitly known to the server, e.g. by prior arrangement. The ResponderURIs list is in the client's preferred order. The TLS server SHOULD process the responder URI list in order and return a response from the first reachable URI with an acceptable response. What constitutes an acceptable response is discussed in Section 4.1.1. The ResponderURIs list is represented as a DER encoded SEQUENCE OF ASN.1 IA5String objects.¶
Zero or more trust anchors MAY be provided in the SCVPValidationRequest to specify the trust anchors at which the certification path must terminate if the path is to be considered valid. The TrustAnchors type is an ASN.1 SEQUENCE OF PKCReference. The SCVP Server usage is defined in Section 3.2.4.7 of RFC 5055 [RFC5055]. If a TLS server receives a SCVPValidationRequest which contains TrustAnchors it SHOULD include the TrustAnchors in the SCVP Request Validation Policy. A non-zero length TrustAnchors sequence combined with a zero length Responder URI sequence indicates that the TLS client wishes to use the TLS server's default SCVP Responder to construct a certification path which terminates at a specified certificate. If a non-zero length TrustAnchors is provided and the TLS Client includes the validation_policy validation extension as defined in Section 3.1.3, the ValidationPolicy TrustAnchors MUST be equivalent to the SCVPValidationRequest TrustAnchors.¶
As defined in RFC 5055, the trust anchor PKCReference MAY be either an SCVPCertID or a Certificate. To minimize the size of the SCVPValidationRequest, TrustAnchors SHOULD be included by SCVPCertID.¶
This document defines nine optional ValidationExtensionTypes. These validation extensions allow the client to specify values in the CV Request as described in Section 3.1.4. Inclusion of the validation extensions will increase the size of the request and response. Therefore, the extensions should be included only when necessary.¶
The validation_extension_data values are DER-encoded ASN.1 types that can be directly mapped to the SCVP CVRequest as defined by RFC 5055 [RFC5055].¶
struct {
ValidationExtensionType validation_extension_type;
select (validation_extension_type {
case want_back: WantBack;
case validation_policy: ValidationPolicy;
case cached_response: BOOLEAN;
case query_extensions: Extensions;
case request_nonce: OCTET STRING;
case request_extensions: Extensions;
case signature_algorithm: AlgorithmIdentifier;
case hash_algorithm: OBJECT IDENTIFIER;
case requestor_text: UTF8String (SIZE (1..256));
} validation_extension_data;
} ValidationExtension
¶
Servers that receive a client hello containing the validation_request extension MAY return a suitable path validation response to the client along with their certificate. If SCVP is requested, the TLS Server SHOULD use the information contained in the extension when selecting an SCVP responder and Trust Anchor. The TLS server SHOULD map the validation extension types to the SCVP request as follows.¶
want_back : CVRequest.query.wantBack validation_policy : CVRequest.query.validationPolicy cached_response : CVRequest.query.responseFlags.cachedResponse query_extensions : CVRequest.query.queryExtensions request_nonce : CVRequest.requestNonce request_extensions : CVRequest.requestExtensions signature_algorithm : CVRequest.signatureAlgorithm hash_algorithm : CVRequest.hashAlgorithm requestor_text : CVRequest.requestorText¶
Conforming TLS Servers MUST construct a CVRequest with a cvRequestVersion and query.¶
TLS Servers conforming to RFC 5055 [RFC5055] MUST set the value of the cvRequestVersion item to one (1).¶
The query item is defined in Section 3.2 of RFC 5055 [RFC5055]¶
TLS Servers conforming to RFC 5055 [RFC5055] SHALL include the query item. For processing the TLS Validation Request the TLS server SHALL include the queriedCerts, certChecks and validationPolicy fields, MAY include wantBack, responseFlags, intermediateCerts, revInfos, and queryExtension fields, SHOULD NOT include producedAt and serverContextInfo fields, and MUST NOT include the validationTime field.¶
The TLS Server MUST populate the CertReferences item. The CertReferences sequence MUST be of length one and specify the server's X.509v3 TLS Certificate. This certificate MUST correspond to the TLS Certificate sent by the TLS server to the TLS client in the Certificate handshake message.¶
The TLS server MUST populate the CertChecks item. The item MUST be set to id-stc-build-status-checked-pkc-path (id-stc 3).¶
The TLS Server SHOULD NOT include want back unless specified by the TLS Client in the validation extension want_back item. If the TLS Server receives a SCVPValidationRequest with a want_back validation extension, the TLS Server MAY set the wantBack item in the CVRequest to the value of the want_back. Want backs can significantly increase the size of the CVResponse and should be used only when specifically required.¶
The TLS Server MUST include the ValidationPolicy item in the CVRequest query item as follows:¶
If the TLS Client specified a validation_policy in the validation extensions:¶
If the TLS Client did not specify a validation_policy¶
The TLS Server MAY only include the ResponseFlags item in the CVRequest if requesting non-default values. If default values are used for all flags, the responseFlags item MUST NOT be included in the request. To enable to TLS client to trust the CVResponse, the TLS Server MUST use the default value for the protectResponse flag (TRUE). To minimize the size of the CVResponse, the TLS Server SHOULD use the default values for the response flags fullRequestInResponse (FALSE) and responseValidationPolicyByRef (TRUE). If the TLS Client included the cached_response validation extension with a value of FALSE, the TLS Server SHOULD NOT use its cache as described in Section 4.1.2 and MAY include the cachedResponse set to FALSE in the CVRequest responseFlags item. If the TLS Server sets the cachedResponse flag to FALSE the request_nonce MUST be set. If the TLS Server received the request_nonce validation extension, the requestNonce in the CVRequest MAY be set to the value of the request_nonce extension. Otherwise, the TLS Server MUST generate and set a requestNonce in the CVRequest.¶
The TLS Server SHOULD NOT include the serverContextInfo item in the CVRequest.¶
The TLS Server MUST NOT include the validationTime item in the CVRequest.¶
The TLS Server MAY include the intermediateCerts item in the CVRequst to help the SCVP server create a valid certification path as defined in Section 3.2.8 of RFC 5055 [RFC5055].¶
The TLS Server MAY include the revInfos item in the CV Request which MAY be used by the SCVP Server when validating certification paths as defined in Section 3.2.9 of RFC 5055 [RFC5055].¶
The TLS Server SHOULD NOT include the producedAt item in the CVRequest.¶
The TLS Server MAY include the queryExtensions item in the CVRequest to extend the query. If the TLS Server receives a SCVPValidationRequest with a query_extensions validation extension, the TLS Server MAY set the queryExtensions item in the CVRequest to the value of the query_extension.¶
The TLS Server SHOULD NOT set the requestorRef item in the CVRequest.¶
The TLS Server MAY include the requestNonce item in the CVRequest to indicate a preference for a non-cached response. If the TLS Server receives a SCVPValidationRequest with a request_nonce validation extension, the TLS Server MAY set the requestNonce item in the CVRequest to the value of the request_nonce validation extension. If the TLS Server sets the cachedResponse response flag to FALSE but did not receive the request_nonce validation extension the TLS Server MUST generate and set a requestNonce in the CVRequest.¶
The TLS Server SHOULD NOT include the requestorName item in the CVRequest.¶
The TLS Server SHOULD NOT include the responderName item in the CVRequest.¶
The TLS Server MAY include the requestExtensions item in the CVRequest to extend the request. If the TLS Server receives a SCVPValidationRequest with a request_extensions validation extension, the TLS Server MAY set the requestExtensions item in the CVRequest to the value of the request_extension.¶
The TLS Server SHOULD NOT include the signatureAlgorithm item in the CVRequest unless specified by the TLS Client in the signature_algorithm validation extension. If the TLS Server receives a SCVPValidationRequest with a signature_algorithm validation extension, the TLS server MAY set the signatureAlgorithm item in the CVRequest to the value of the signature_algorithm.¶
To keep the size of the request and response small, it is recommended that community define the signature algorithm rather than using the signature_algorithm extension.¶
The TLS Server SHOULD NOT include the hashAlgorithm item in the CVRequest unless specified by the TLS Client in the hash_algorithm validation extension. If the TLS Server receives a SCVPValidationRequest with a hash_algorithm validation extension, the TLS Server MAY set the hashAlgorithm item in the CVRequest to the value of the hash_algorithm.¶
To keep the size of the request and response small, it is recommended that community define the hash algorithm rather than using the hash_algorithm extension.¶
The TLS Server SHOULD NOT include the requestorText item in the CVRequest unless specified by the TLS Client in the requestor_text validation extension. If the TLS Server receives a SCVPValidationRequest with a requestor_text validation extension, the TLS Server MAY set the requestorText item in the CVRequest to the value of the requestor_text.¶
To keep the size of the request and response small, it is recommended that the requestor text be used only for debugging purposes.¶
Servers that receive a client hello containing the validation_request extension MAY return a suitable path validation response to the client along with their certificate by sending a PathValidation as an extension to the Certificate message. Like the PathValidationRequest, the ValidationResponse is defined for type Server-Based Certificate Validation Protocol (SCVP) however is designed to be extendable to other protocols.¶
The PathValidation response is defined as follows:¶
struct {
PathValidationType path_validation_type;
select (path_validation_type) {
case scvp: SCVPResponse;
} response;
} PathValidation;
enum { scvp(1), (255) } PathValidationType;
¶
TLS Servers send the PathValidation response to the client in the extension_data of the validation_request extension to the TLS server end-entity certificate in the Certificate message. The PathValidation data conveys whether the certificate path was successfully built and validated. Therefore, in most cases, it is unnecessary for the TLS server to include supporting certificates in the Certificates message.¶
If a TLS server returns a PathValidation message in response to a PathValidationRequest of type scvp, that PathValidation message MUST be of type scvp and contain a SCVPResponse as follows.¶
struct {
opaque signed_cv_response
ValidationExtensions validation_extensions_list<0..2^16-1>;
} SCVPResponse;
¶
A signed_cv_response contains a complete, DER-encoded CMS SignedData object as defined in RFC 5652 [RFC5652] with an EncapsulatedContent of type CVResponse as defined in RFC 5055 [RFC5055]. Only one SCVP response may be sent.¶
The TLS Server SHOULD include the list of validation extensions from the SCVPValidationRequest that were used in the CVRequest to indicate to the TLS Client which validation extensions were honored. If the TLS Server did not use a validation extension in the CVRequest, it MUST NOT be included in the SCVPResponse. The SCVPResponse MUST NOT include validation extensions that were not present in the SCVPValidationRequest.¶
Section 9 of RFC 5055 [RFC5055] asserts that clients MUST verify that the response matches their original request and outlines the steps necessary to perform this verification. For this extension, the client responsibility of divided between the TLS server and the TLS client. Certain values are only known by the TLS server whereas other values require verification at the final end-point, the TLS client. The following two sections specify the verification of the SCVP response at the TLS server Section 4.1.1 and at the TLS client Section 4.1.2.¶
The TLS Server MUST verify the response from the SCVP server. If the TLS Server finds the response unacceptable, it MAY query another SCVP server (from the ResponderURIs or a pre-configured list) or MAY send a bad_path_validation_response alert notifying to close the connection.¶
The TLS server MUST verify that the response is a protected response consisting of a CVResponse encapsulated in CMS SignedData.¶
The TLS server SHOULD verify that the SignedData Message Digest is a hash of the received CVResponse.¶
The TLS server MAY verify the certificate of the SCVP responder used for signing the response. In some environments, it may be left to the TLS client to validate.¶
As an SCVP client, the TLS server MUST process the CVResponse as defined by RFC 5055 [RFC5055].¶
The TLS server SHOULD verify the responseStatus code. If the code does not indicate okay(0), the TLS server MAY choose to query another SCVP server from the Responder URIs.¶
As stated in RFC 5055, the requestRef item allows the SCVP client to determine that the request was not maliciously altered. The TLS Server creates the CVRequest and is therefore the only place where the full CVRequst is known. The TLS Server SHOULD compare the returned requestRef to the CVRequest.¶
If the TLS server generated a requestNonce it SHOULD verify that the requestNonce in the response matches the value in the request.¶
On receipt of a SCVPResponse, the TLS client MUST verify that the response indicates a successful path validation and can be trusted.¶
The TLS Client MUST verify that the CVResponse is encapsulated in a CMS SignedData object and validate the digital signature on the response to ensure that the expected SCVP server generated the response. The TLS Client MUST verify that the SignedData Message Digest matches a hash of the received CVResponse.¶
The CVResponse CertReply item MUST contain a single certificate matching the TLS Server certificate sent in the TLS Certificate Handshake message. If the CertReply does not meet this requirement the TLS client MUST abort the connection with a bad_path_validation_response.¶
The TLS Client MUST verify that the CVResponse indicates success. A CVResponse is successful if: the responseStatus is CVStatusCode okay(0) and the CertReply item containing the TLS Server's certificate has a replyStatus of success (0). If these conditions are not met the TLS client MUST abort the connection with a bad_path_validation_response.¶
The TLS Client should check the SCVPResponse validation_extensions against the validation_extensions sent in the SCVPValidationRequest. If the SCVPResponse validation_extensions list does not match the list of sent validation_extensions, the TLS client MAY abort the connection.¶
If the client set validation extensions in the SCVPValidationRequest, the TLS client SHOULD verify that the CVResponse appropriately reflects those validation extensions. For example, if the request_nonce validation extension was set the client SHOULD verify that the CVResponse respNonce contains the same value.¶
To improve performance and survive path validation service outages the TLS server MAY cache PathValidation responses. On receipt of a client hello with a validation_request extension the TLS Server MAY check a local cache for a PathValidation response matching the TLS client's settings. If a matching response is found the server MAY use this response rather than generating a fresh response.¶
If the validation_request is of type scvp, the server should check if the client has set validation extensions before returning a cached response. If the cached_response validation extension is set to FALSE or the request_nonce validation extension is set. The TLS server SHOULD NOT return a cached response.¶
The TLS server SHOULD place a time limit on cached responses and generate a fresh PathValidation response after that time has elapsed. To improve performance, the TLS server MAY proactively refresh cached responses before the cache time limit has been reached. Path validation servers may also perform caching to optimize response times. Timestamps may be included in the path validation response that MAY be used by the TLS server to determine when a fresh response will be available from the path validation server. In the case of SCVP, this information can optionally be communicated in the nextUpdate wantBack value.¶
On receipt of a PathValidation response the TLS client MUST validate that the response indicates a successful path validation as described in Section 4. If the PathValidation response does not indicate that the server certificate was successfully validated the TLS client MUST abort the connection with a bad_path_validation_response as follows.¶
enum {
bad_path_validation_response(121 TBD),
(255)
} AlertDescription;
¶
IANA considerations for TLS extensions and the creation of a registry are covered in Section 11 of RFC 8446 [RFC8446].¶
The following values in the TLS Alert Registry have been updated to reference this document:¶
The following ExtensionType values have been updated to reference this document:¶
General security considerations for TLS extensions are covered in TLS 1.3 RFC 8446 [RFC8446].¶
For security considerations specific to the Cryptographic Message Syntax message formats, see RFC 5652 [RFC5652]. For security considerations specific to the process of PKI certification path validation, see RFC 5280 [RFC5280]. For security considerations specific to SCVP, see RFC 5055 [RFC5055].¶
This section summarizes some of the more important security aspects specific to the TLS validation_request extension, though there are many security-relevant details in the remainder of this document.¶
If a client requests a path validation response, it must consider that an attacker's server could (and probably would) pretend not to support the extension. In this case, a client that requires path validation of certificates SHOULD either contact the validation server directly or abort the handshake.¶
Use of the optional SCVP cached response flag and request nonce items by either the TLS client in the validation extensions or by the TLS server may improve security against attacks that attempt to replay SCVP responses. However, use of these properties must be balanced with the performance impact of requiring generation of a fresh SCVP response.¶
Values in the client hello validation_request extension and PathValidationRequest are passed between the TLS client to the TLS server unprotected. This makes the values vulnerable to modification. An attacker might try to influence the handshake exchange in multiple ways including to increase latency, cause parties to abort the connection or to create trust in an untrusted server.¶
The SCVP type of this extension is made further vulnerable by the inclusion of validation extensions in the SCVPValidationRequest. These validation extensions have been included to support flexibility. However, to mitigate the vulnerability to modification, domains should consider limiting use of validation extensions and instead use preconfigured domain specific values. TLS client and server verification of values returned in the signed CVResponse as described in Section 4.1 should also be used to protect against these attacks and detect attempts to modify these values¶
The received PathValidation response could contain information unrelated to the request. A path for an end-entity certificate other than the TLS server certificate could be returned. The first certificate in the certificate path could not match any of the client provided trust anchors. Or the SCVP responder signing the response could be unknown to the client. If any such unrelated PathValidation response is received, it MUST be discarded and the TLS client MAY choose to use alternative means to validate the server certificate or MAY choose to abort the connection.¶
The TLS client relies on a locally known trust anchor to verify the signed PathValidation response. The trust anchor may change or expire periodically. TLS clients using this specification MUST implement a secure mechanism to keep their trust anchors up to date.¶