Internet DRAFT - draft-wang-tls-eccsi
draft-wang-tls-eccsi
Internet Engineering Task Force H. Wang, Ed.
Internet-Draft Y. Yang
Intended status: Standards Track Huawei Technology Pte. Ltd.
Expires: January 4, 2018 July 3, 2017
Using ECCSI Public Keys in Transport Layer Security (TLS)
draft-wang-tls-eccsi-00
Abstract
This document specifies a new certificate type and a TLS extension
for authentication with ECCSI public keys in Transport Layer Security
(TLS). The new certificate type allows ECCSI public keys to be used
for mutual authentication over TLS protocol.
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 January 4, 2018.
Copyright Notice
Copyright (c) 2017 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.
Wang & Yang Expires January 4, 2018 [Page 1]
Internet-Draft TLS-ECCSI-Public-Key July 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Structure of the ECCSI Public Key Extension . . . . . . . . . 4
4. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 6
5. TLS Client and Server Handshake Behaviour . . . . . . . . . . 7
5.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Client Authentication . . . . . . . . . . . . . . . . . . 8
5.4. Server Authentication . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. TLS Client and Server Use ECCSI Public Keys . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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
Wang & Yang Expires January 4, 2018 [Page 2]
Internet-Draft TLS-ECCSI-Public-Key July 2017
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.
Wang & Yang Expires January 4, 2018 [Page 3]
Internet-Draft TLS-ECCSI-Public-Key July 2017
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.
2. Terms
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].
3. Structure of the ECCSI Public Key Extension
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].
opaque ASN.1Cert<1..2^24-1>;
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;
Figure 1: Certificate Payload as a Container for the Raw Public Key.
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
Wang & Yang Expires January 4, 2018 [Page 4]
Internet-Draft TLS-ECCSI-Public-Key July 2017
document, structure for ECCSI-based public key is specified. It
contains an PVT field.
subjectECCSIPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
identity BIT STRING,
PVT BIT STRING,
parameters ANY DEFINED BY algorithm OPTIONAL }
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
Figure 2: SubjectECCSIPublicKeyInfo ASN.1 Structure
The algorithm identifiers are Object identifiers (OIDs). It is
defined in the following table.
+-------------------------------------+----------+------------------+
| Key Type | Document | OID |
+-------------------------------------+----------+------------------+
| Elliptic Curve-Based Signatureless | This | 1.3.xxx.xxx.x.x |
| For Identitiy-based Encryption | document | (need to apply) |
| (ECCSI) | | |
+-------------------------------------+----------+------------------+
Table 1: Algorithm Object Identifiers
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
Wang & Yang Expires January 4, 2018 [Page 5]
Internet-Draft TLS-ECCSI-Public-Key July 2017
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].
struct {
select(ClientOrServerExtension) {
case client:
CertificateType client_certificate_types<1..2^8-1>;
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;
Figure 3: CertTypeExtension Structure
4. Key Exchange Algorithm
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 |
+------------------------+--------------------------------------+
Table 2: ECC Key Exchange Algorithms
Wang & Yang Expires January 4, 2018 [Page 6]
Internet-Draft TLS-ECCSI-Public-Key July 2017
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:
a. CipherSuite TLS_ECDHE_ECCSI_WITH_AES_128_CBC_SHA = {0xXX, 0xXX}
b. CipherSuite TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA = {0xXX, 0xXX}
5. TLS Client and Server Handshake Behaviour
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.
client_hello,
client_certificate_type,
server_certificate_type ->
<- 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
Figure 4: Basic ECCSI Public Key TLS Exchange
5.1. Client Hello
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
Wang & Yang Expires January 4, 2018 [Page 7]
Internet-Draft TLS-ECCSI-Public-Key July 2017
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.
5.2. Server Hello
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:
a. The server does not support the extension. In this case, the
server returns the server hello without the extensions defined in
this document.
b. 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".
c. 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.
5.3. Client Authentication
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.
5.4. Server Authentication
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.
6. Examples
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.
Wang & Yang Expires January 4, 2018 [Page 8]
Internet-Draft TLS-ECCSI-Public-Key July 2017
6.1. TLS Client and Server Use ECCSI Public Keys
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.
client_hello,
client_certificate_type=(ECCSIPublicKey) // (1)
server_certificate_type=(ECCSIPublicKey) // (1)
->
<- 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
Figure 5: Example with ECCSI Public Key provided by the TLS Server
and the Client
Wang & Yang Expires January 4, 2018 [Page 9]
Internet-Draft TLS-ECCSI-Public-Key July 2017
7. Security Considerations
8. IANA Considerations
9. Acknowledgements
10. References
10.1. Normative References
10.2. Informative References
11. References
11.1. Normative References
[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", June 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<http://www.rfc-editor.org/info/rfc5480>.
[RFC6507] Groves, M., "Elliptic Curve-Based Certificateless
Signatures for Identity-Based Encryption (ECCSI)",
RFC 6507, DOI 10.17487/RFC6507, February 2012,
<http://www.rfc-editor.org/info/rfc6507>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>.
11.2. Informative References
Wang & Yang Expires January 4, 2018 [Page 10]
Internet-Draft TLS-ECCSI-Public-Key July 2017
[Defeatting-SSL]
Marlinspike, M.,, "New Tricks for Defeating SSL in
Practice", Feb 2009,
<http://www.blackhat.com/presentations/bh-dc-
09/Marlinspike/
BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>.
Appendix A. Examples
Authors' Addresses
Haiguang Wang (editor)
Huawei Technology Pte. Ltd.
20 Secience Park Road, #3-30/31
Singapore 117687
SG
Phone: +65 6825 4200
Email: wang.haiguang1@huawei.com
Yanjiang Yang
Huawei Technology Pte. Ltd.
20 Secience Park Road, #3-30/31
Singapore 117687
SG
Phone: +65 6825 4200
Email: yang.yanjiang@huawei.com
Wang & Yang Expires January 4, 2018 [Page 11]
