Using ECCSI Public Keys in Transport Layer Security (TLS)

DISCLAIMER: This is a personal draft and has not yet seen significant security analysis. Traditionally, TLS client and server exchange public keys based on [PKIX] certificates. It is considered complicated and may cause security weakness [Defeating-SSL]. To simplify the public key exchange, a light weight public key exchange protocol for TLS, using RAW public key in TLS/DTLS, has been standardized in [RFC7250]. However, using RAW public key requires out of band mechanisms to bind the public key to the entity presenting the key. This may require additional mechanism to resolve the binding relationship for each raw public key. 3GPP SA3 has adopted the EAP for 5G authentication framework and EAP-TLS is considered as authentication method for IOT devices. For use cases such as authentication between IOT devices and networks, identity of an entity provide the public key is necessary. To simplify the binding between the public key and entity presenting the key, this document proposes to use ECCSI public key for authentication. Different from the X.509 certificate and raw public key, the ECCSI public key takes the identity itself as a public key, which simplify the binding between public key and entity presenting the public key. ECCSI public key can be used by IOT devices to perform mutual authentication. Comparing to the PKIX based certificate, the ECCSI public key is shorter and requires less computation, and CA signing required by PKIX certificate is unnecessary for identity-based public key. Comparing to the RAW public key, ECCSI public key inherently provides entity authentication, which is required in many IOT network since IOT devices and networks need mutual authentication; the client/server does not need to have an out of band mechanism to bind the public key with the entity presenting the public key as required by raw public key. Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) public key in [RFC6507] specifies an identity-based signature scheme. The scheme is defined over Elliptic Curves. According to the RFC6507, to use the ECCSI public key, a Key Management System (KMS) is required to generate private keys and then distribute the generatedkeys to clients thereafter. The functionality of the KMS is similar to a Certificate Authority (CA). A KMS owns a KMS Secret Authentication Key (KSAK), which is the root trust for all other keys. A KMS Public Authentication Key (KPAK) derived from this KSAK is globally public, and can be used to verify signatures. To get an ECCSI-based private key for generating signatures, an entity need to provide its identity to the KMS, and then the KMS generates a Signer Secret Key (SSK) and a Public Validation Token (PVT), with the received Identity, the KSAK, the KPAK, and the pre-configured Elliptic curve as input. KMS delivers the SSK and PVT to the requestor who sends in the identity. For each identity, the generated SSK and PVT are specific to it. The identity and the PVT are used together with the KPAK to verify the signatures generated with the corresponding SSK. The signature generation and verification algorithms have been specified in [RFC6507]. To support ECCSI public key over TLS protocol, this document further extends the Certificate structure defined in [RFC7250] by including a type for ECCSI public key. The SubjectPublicKeyInfo structure defined in [PKIX] is extended since additional information for ECCSI public keys is required. The client_certificate_type and server_certificate_type defined in the RFC7250 are reused for ECCSI public key negotiation. Section 3 defines structure for ECCSI public key; Section 4 defines key exchange algorithm over TLS with the ECCSI public key. Section 5 specifies TLS client and server handshake behaviour; Section 6 give examples.

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.

This section defines the structures for using ECCSIpublic keys over TLS protocols. To carry the Identity-based public key within the TLS handshake messages, the Certificate payload is used as a container, as shown in Figure 1. The shown Certificate structure is an adaptation of its original form [RFC7250].

; struct { select(certificate_type){ // certificate type defined in this document. case IdentityBasedPublicKey: opaque ASN.1_subjectIdentityBasedPublicKeyInfo<1..2^24-1>; // certificate type defined in RFC 7250. case RawPublicKey: opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; // X.509 certificate defined in RFC 5246 case X.509: ASN.1Cert certificate_list<0..2^24-1>; // Additional certificate type based on // "TLS Certificate Types" subregistry }; } Certificate; ]]> The structure SubjectIdentityBasedPublicKeyInfo is defined in this document. It contains AlgorithmIdentifier, identity and parameters. The structure of Algorithm identifer is defined in RFC 5280 [PKIX]. Identity is a string provided by client or server. Parameters are specific to the chosen identity-based public key algorithm. In this document, structure for ECCSI-based public key is specified. It contains an PVT field.

The algorithm identifiers are Object identifiers (OIDs). It is defined in the following table. Key Type Document OID Elliptic Curve-Based Signatureless For Identitiy-based Encryption (ECCSI) This document 1.3.xxx.xxx.x.x (need to apply) PVT is an ECPoint. The encoding of the PVT has the following syntax: PVT ::= OCTET STRING The PVT (a value of type ECPoint that is an OCTET STRING) is mapped to a subjectPublicKey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. [From RFC 5480] The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 and the compressed form is indicated by either 0x02 or 0x03 (see 2.3.3 in [SEC1]). The public key MUST be rejected if any other value is included in the first octet. Similar to the certificate negotiation specified for raw public key, the 'extension_data' field in the client and server hello fields are used to carry the ClientCertTypeExtension and ServerCertTypeExtension structures, which are defined in [RFC7250] for raw public key negotiation. According to RFC7250, the CertificateType structure is an enum with values taken from the 'TLS Certificate Types' subregistry of the 'Transport Layer Security (TLS) Extensions' registry [TLS-Ext-Registry].

; case server: CertificateType client_certificate_type; } } ClientCertTypeExtension; struct { select(ClientOrServerExtension) { case client: CertificateType server_certificate_types<1..2^8-1>; case server: CertificateType server_certificate_type; } } ServerCertTypeExtension; ]]>

In addition to [RFC4492], this document introduces one new ECC-based key exchange algorithm for TLS. It uses ephemeral ECDH keys to compute the TLS premaster secret, while the ECCSI scheme is used to authenticate them. The derivation of the TLS master secret from the premaster secret and the subsequent generation of bulk encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the use of the ECCSI scheme. Below shows the new key exchange algorithm: Key Exchange Algorithm Description ECDHE_ECCSI Ephemeral ECDH with ECCSI signatures The ECDHE_ECCSI key exchange mechanism requires the verifier to acquire the KPAK. To support the ECDHE_ECCSI key exchange mechanism, the following new Cipher suites are specified: CipherSuite TLS_ECDHE_ECCSI_WITH_AES_128_CBC_SHA = {0xXX, 0xXX} CipherSuite TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA = {0xXX, 0xXX}

The exchange of the TLS hello message with Identity-based public key is the same as the procedure specified in RFC 7250[RFC7250], but with an appropriate Cipher suite being chosen if the ECCSI public key is used. New Cipher suites specific to ECCSI public key are required.

<- server_hello, client_certificate_type, server_certificate_type, certificate, server_key_exchange, certificate_request, server_hello_done certificate, client_key_exchange, certificate_verify, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data ]]>

To indicate the support of ECCSI public keys, clients include the client_certificate_type and/or the server_certificate_type extensions in an extended client hello message. The usage of client_certificate_type and server_certificate_type are specified in the RFC7250. At the meantime, an appropriate cipher_suites needs to be specified too if it is to support ECCSI public keys.

If the server receives a client hello that contains the client_certificate_type extension and/or the server_certificate_type extension, then three outcomes are possible: The server does not support the extension. In this case, the server returns the server hello without the extensions defined in this document. The server supports the extension, but it does not have any certificate type in common with the client. Then, the server terminates the session with a fatal alert of type "unsupported_certificate". The server supports the extensions and has at least one certificate type in common with the client. In this case, the processing rules described below are followed. The details for the server in processing the client_certificate_type and server_certificate_type are specified in section 4.2 of RFC7250. Meanwhile, an appropriate cipher_suites needs to be specified too if it is to support ECCSI public keys.

When the TLS server has specified an ECCSI public key type, e.g. as the client_certificate_type, authentication of the TLS client to the TLS server is supported through authentication of the received client subjectECCSIPublicKeyInfo and signature.

When the TLS server has specified ECCSIPublicKey as the server_certificate_type, authentication of the TLS server to the TLS client is supported only through authentication of the received client SubjectPublicKeyInfo via an out-of-band method.

Figures 6 illustrates example exchanges. Note that TLS ciphersuites using a Diffie-Hellman exchange offering forward secrecy can be used with ECCSI public key, although this document does not show the information exchange at that level with the subsequent message flows.

This section shows an example where the TLS client as well as the TLS server use ECCSI public keys. This is one of the use cases envisioned for IOT devices authenticate with networks. The TLS client in this case is an IOT device that is configured with a ECCSI public/private keys for use with TLS and is also able to process ECCSI public key sent by the server. Therefore, it indicates these capabilities in (1). The server fulfills the client's request, indicates this via the ECCSIPublicKey value in the server_certificate_type payload (2), and provides an ECCSI public key with the ECCSIPublicKeyInfo structure in the Certificate payload back to the client (see (3)). The TLS server demands client authentication, and therefore includes a certificate_request (4). The client_certificate_type payload in (5) indicates that the TLS server accepts an ECCSI public key. The TLS client, which has an ECCSI public key pre-provisioned, returns it in the Certificate payload (6) to the server in the form of ECCSIPublicKeyInfo structure.

<- server_hello, server_certificate_type=ECCSIPublicKey // (2) certificate, // (3) client_certificate_type=ECCSIPublicKey // (5) certificate_request, // (4) server_key_exchange, server_hello_done certificate, // (6) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data ]]>