This document defines a new certificate type and a new extension to exchange Verifiable Credentials (VCs) in Transport Layer Security (TLS). The new certificate type allows VC to be used for authentication purpose.¶
+This document defines a new certificate type and extension for the exchange of Verifiable Credentials (VCs) in Transport Layer Security (TLS). The new certificate type is intended to add the VC as a new means of authentication. The validation process of the VC uses a distributed ledger as the Root of Trust (RoT) of the TLS node's public keys. The nodes can use different distributed ledger technologies to store their public key and to perform the TLS handshake.¶
This note is to be removed before publishing as an RFC.¶
- The latest revision of this draft can be found at https://Cybersecurity-LINKS.github.io/draft-vesco-perugini-tls-ssi/draft-vesco-perugini-tuveri-tls-ssi.html. + The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/.¶
-Source for this draft and an issue tracker can be found at - https://github.com/Cybersecurity-LINKS/draft-vesco-perugini-tls-ssi.¶
++ Discussion of this document takes place on the + WG Working Group mailing list (mailto:WG@example.com), + which is archived at https://example.com/WG.¶
+Source for this draft and an issue tracker can be found at + https://github.com/USER/REPO.¶
- This Internet-Draft will expire on 12 May 2024.¶
+ This Internet-Draft will expire on 24 May 2024.¶5. TLS Client and Server Handshake
6.3. TLS Client Uses a VC and Server Uses an X.509 Certificate
W3C defined VC and DID¶
-How to create identity in SSI and how to verify the VP (in HS sections describe how the hs covers the VP presentation).¶
+The Self-Sovereign Identity (SSI) is a decentralised identity model that gives a node control over the data it uses to generate and prove its identity. SSI model relies on three fundamental elements: a distributed ledger as the Root of Trust (RoT) for public keys, Decentralized IDentifier DID, and Verifiable Credential VC. An SSI aware node builds his identity starting from generating the identity key pair ($sk, pk$). Then the node stores $pk$ in the distributed ledger of choice for other nodes to authenticate it. +A node's DID is a pointer to the distributed ledger where other nodes can retrieve its $pk$. A DID is a Uniform Resource Identifier (URI) in the form did:did-method-name:method-specific-id where method-name is the name of the DID Method used to interact with the distributed ledger and method-specific-id is the pointer to the DID Document that contains $pk$, stored in the distributed ledger. +After that, the node can request a VC from one of the Issuers available in the system. The VC contains the metadata to describe properties of the credential, the DID and the claims about the identity of the node and the signature of the Issuer. +The combination of the key pair ($sk, pk$), the DID and at least one VC forms the identity compliant with the SSI model. +A node requests access to services by presenting a Verfiable Presentation VP. The VP is an envelop of the VC signed by the node holding the VC with its $sk$. The verifier authenticates the node checking the authenticity of the VP and the validity and authenticity of the inner VC before granting or denying access to the requesting node. + +The current implementations of the authentication process run at the Application layer. A client node estabhlishes a TLS channel authenticating the server node with the server's X.509 certificate. Then the server node authenticate the client node that sends its VP at application layer (i.e. over the TLS channel already established). The mutual authentication with VPs occours when also the server node exchange its VP with the client node again at application layer.¶
+SSI is emerging as an identity option for Internet of Thing and Edge nodes in computing continuum environments. In these scenarios, (mutual) authentication with VP can take place directly at the TLS protocol layer, enabling the the peer-to-peer interaction model envisaged by the SSI model. +This document describes the extensions to TLS protocol to support the use of VCs for authentication while preserving the interoperability with TLS endpoints that use X.509 certificates. +The extensions enable server-only and mutual authentication using VC, X.509, Raw Public Key or a combination of VC and X.509 certificates at the TLS endpoints. The ability to perform hybrid authenticated handshakes supports the gradual deployment of SSI in existing systems. Moreover, the extension allow TLS endpoints to use different distributed ledger technologies to store their public keys and during the TLS handshake for authentication purpose.¶
The TLS extensions "client_certificate_type" and "server_certificate_type" [RFC7250] are used to negotiate the type of Certificate messages used in TLS to authenticate the server and, optionally, the client. Using separate extensions allows for mixed deployments where the client and server can use certificates of different types. -~~~ - /* Managed by IANA */ - enum { - X509(0), - RawPublicKey(2), - VC(224), - (255) - } CertificateType;¶
-struct { - select(certificate_type){ - // The new certificate type defined in this document - case VC: - opaque cert_data<1..2^24-1>;¶
-The TLS extensions client_certificate_type and server_certificate_type defined in RFC7250 are used to negotiate the type of Certificate messages used in TLS to authenticate the server and, optionally, the client. This section defines a new certificate type, called VC, for the TLS 1.3 handshake. The updated CertificateType enumeration and corresponding addition to the CertificateEntry structure are shown below. In the current version of this document VC certificate type is set to 224, one of the values indicated by IANA for private use. CertificateType values are sent in the server_certificate_type and client_certificate_type extensions, and the CertificateEntry structures are included in the certificate chain sent in the Certificate message.¶
- // RawPublicKey certificate type defined in RFC 7250
- case RawPublicKey:
- opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
+/* Managed by IANA */
+enum {
+ X509(0),
+ RawPublicKey(2),
+ VC(224),
+ (255)
+} CertificateType;
- // X.509 certificate defined in RFC 5246
- case X509:
- opaque cert_data<1..2^24-1>;
+struct {
+ select(certificate_type){
+ // The new certificate type defined in this document
+ case VC:
+ opaque cert_data<1..2^24-1>;
- // Additional certificate type based on
- // "TLS Certificate Types" subregistry
- }; } Certificate; ~~~
-¶
+ // RawPublicKey certificate type defined in RFC 7250
+ case RawPublicKey:
+ opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
+
+ // X.509 certificate defined in RFC 5246
+ case X509:
+ opaque cert_data<1..2^24-1>;
+ };
+ Extension extensions<0..2^16-1>;
+} CertificateEntry;
+
+struct {
+ opaque certificate_request_context<0..2^8-1>;
+ CertificateEntry certificate_list<0..2^24-1>;
+} Certificate;
+¶
As per RFC7250, the client will send a list of certificate types in endpoint_certificate_type extension(s), the server processes the received extension(s) and selects one of the offered certificate types, returning the negotiated value in the EncryptedExtensions message. Note that there is no requirement for the negotiated value to be the same in client_certificate_type and server_certificate_type extensions sent in the same message. Client and server can use different means of authentication as long as the other endpoint is able to verify that specific type of certificate.¶
This section defines the did_methods extension, used as part of an extended TLS 1.3 handshake when VC certificate type is used. This extension contains a list of DID Methods an endpoint supports, i.e. a set of DLTs an endpoint can interact with to resolve the peer's DID. A client MUST send this extension in the extended ClientHello only when it indicates VC support in the server_certificate_type extension. The server MUST send this extension in a CertificateRequest message only if it specified VC as client_certificate_type. The extension format which uses the extension_data field, is used to carry the DIDMethodList structure. The structure of this new extension is shown below.¶
+
- /* Managed by IANA */
- enum {
- iota(0),
- ..
- (65535)
- } DIDMethod
+enum {
+ btcr(0),
+ ethr(1),
+ iota(2),
+ ..
+ (65535)
+} DIDMethod
- struct {
- DIDMethod did_methods<2..2^16-2>
- } DIDMethodList
-
- [did-registry](https://www.w3.org/TR/did-spec-registries/#did-methods)
-¶
+struct {
+ DIDMethod did_methods<2..2^16-2>
+} DIDMethodList
+¶
did_methods extension could be sent only in ClientHello and CertificateRequest messages.¶
+The list of existing DID Methods is currently maintained by the W3C in the did-registry. Each DID Method is expressed in the form of a string. This document proposes the DIDMethod enum to map these strings into integer values.¶
The Figure below shows the basic full TLS handshake:¶
+In order to express support for VC certificate type, a client MUST include an extension of type client_certificate_type or server_certificate_type in the extended ClientHello message as described in Section 4.1.2 of RFC8446. If the client sends the server_certificate_type extension indicating VC support, it MUST also send the did_methods extension.¶
When the server receives the ClientHello containing the server_certificate_type extension and/or the client_certificate_type extension, the following scenarios are possible:¶
+The server does not support the extensions, omits them in EncryptedExtensions and the handshake proceeds with X.509 authentication.¶
+The server does not support any of the proposed certificate types and terminates the session with a fatal alert of type "unsupported_certificate".¶
+Both client and server indicate support for the VC certificate type. The server selects VC certificate type, but the client did not send the did_methods extension in addition to the server_certificate_type extension. The server MUST terminate the session with a fatal alert of type "missing_extension".¶
+Both client and server indicate support for the VC certificate type. The server selects VC certificate type, but the server's DID is not compatible with any of the DID Methods supported by the client, listed in the did_methods extension in ClientHello message. {It terminates the session with a fatal alert of type "unsupported_did_methods"/ It sends a HelloRetryRequest message equipped with the did_methods extension containing the list of DLTs in which it has a DID.}¶
+Both client and server indicate support for the VC certificate type, the server MAY select the first (most preferred) certificate type from the client's list that is supported by both peers. It MAY include the client_certificate_type in EncryptedExtensions and then request a certificate from the client. In case the server selects VC certificate type, MUST also send the did_methods extension in the CertificateRequest message.¶
+The server sends this message to request client authentication. It MUST include the did_methods extension if it specified VC in the client_certificate_type extension. If the ClientHello contained the did_methods extension, the server MUST send a list of DID Methods client and server have in common. If the client did not send the did_methods extension the server MUST select a list of DID Methods it supports. A client that processes this message that does not have a DID compatible with the DID Methods selected by the server MUST send a Certificate message containing no certificates, i.e. with the certificate list field having length 0.¶
+When the selected certificate type is VC, the certificate_list in the Certificate message MUST contain no more than one CertificateEntry with the content of the endpoint's Verifiable Credential. The content of the Verifiable Credential SHOULD be CBOR encoded. After decoding, the endpoint MUST follow the procedure in VC to verify the Verifiable Credential.¶
As discussed in Section I (Section 1), a Holder wraps its own Verifiable Credential into a Verifiable Presentation and signs it before presenting it to a Verifier for authentication purposes in accordance with SSI model. When the selected certificate type is VC, the subsequent CertificateVerify message acts also as the Holder signature on the Verifiable Presentation. In fact, the signature is computed over the transcript hash that contains also the Verifiable Credential of the sender inside the Certificate message.¶
This section shows some message-exchanges examples.¶
+This is an example of a client willing to receive and validate a VC from the server. The client does not own an identity at the TLS level and so omits the client_cert_type extension. The server indicates in the EncryptedExtensions message that it selected a VC to insert in the Certificate message.¶
it happens when the server does not send ssi_paramters extension in certificate request or it does but the client does not have a DID in the list of supported DLT (i.e. DID Methods) by the server¶
+This section shows an example where the TLS client as well as the TLS server use VCs for authentication. In fact the server selects VC for both client_cert_types and server_cert_types extensions and in the CertificateRequest message sends the did_methods extension with a set of DID methods both endpoints have in common.¶
server ignores ssi_parameters extension in the clientHello¶
+This example combines the use of a raw public key and an X.509 certificate. The client uses a VC for client authentication, and the server provides an X.509 certificate. The client expresses its ability to process an X.509 certificate or a raw public key from the server. In addtion it is willing to use either a VC or an X.509 certificate for client-side authentication. The server then selects X.509 to authenticate with the client and VC for client authentication. The server then sends a list of DID methods of its choice.¶
HelloRetryRequest + foobar extension -server replies with the list of its DID Methods, this implies that the server has a DID stored in each of the DLT of the listed DID Methods.¶
+This example proposes a client authenticating with an X.509 certificate and a server with a VC. The client is capable to process and validate a VC from the server, in fact it also sends the did_methods extension. The server then decides to request an X.509 certificate from the client and to provide a VC to authenticate with the client.¶
server enforces SSI client authentication (no fall back bu enforce SSI to the client)¶
-HelloRetryRequest¶
+We include an image of the message flow in this section if we decide that the server sends an HRR when it does not have a DID compatible with the list of DID Methods sent by the client.¶
TODO Security¶
+All the security considerations presented in RFC8446 applies to this document as well. +Further considerations, though, about the DID resolution process are worth discussing. Assuming that a DID resolution is performed in clear, a man-in-the-middle could impersonate the DLT node, forge a DID document containing the authenticating endpoint's DID, associate it with a key pair that he owns, and then return it to the DID resolver. Thus, the attacker is able to compute a valid CertificateVerify message by possessing the long term private key. In practice, the man-in-the-middle attacker breaks in transit the immutability feature of the DLT (i.e. the RoT for identity public keys). +A reasonable solution to this attack could be to create a TLS channel towards the DLT node and authenticate only the latter to rely on the received data. The DLT node must be authenticated through an X.509 certificate. The number of DLT nodes within an IoT large scale systems is expected to be very low (i.e. one or a couple of nodes) with respect to the total number of IoT and edge nodes, so adopting X.509 certificates to authenticate those DLT nodes does not reduce the overall benefit in terms of lower complexity and cost associated to certificate management proper of SSI solution. +In order to reduce the overhead of establishing a TLS channel with the DLT node for DID resolution, there are two possible approaches (i) leverage session resumption and 0 round-trip time (0-RTT) features of TLS 1.3 or (ii) change the logic of DLT nodes and adopt a data protection solution (e.g. with HMAC to authenticate the data from DLT node).¶
This document has no IANA actions.¶
-[DID] W3C, Decentralized Identifiers (DIDs) v1.0. Core architecture, data model, and representations. W3C Recommendation, 2022. https://www.w3.org/TR/did-core/¶
-[VC] W3C, Verifiable Credentials Data Model v2.0. W3C Recommendation, 2023. https://www.w3.org/TR/vc-data-model-2.0/¶
-This document has no IANA actions.¶