Internet Engineering Task Force H. Wang, Ed.
Internet-Draft Y. Yang
Intended status: Standards Track X. Kang
Expires: September 2, 2018 Huawei Technology Pte. Ltd.
March 1, 2018
Using Identity as Raw Public Key in Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)
draft-wang-tls-raw-public-key-with-ibc-00
Abstract
This document specifies the use of identity as a raw public key in
Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS). The protocol procedures are kept unchanged, but cipher
suites are extended to support Identity-based signature (IBS). The
example OID tables in the RFC 7250 [RFC7250] are expanded with OIDs
specific to the IBC-based signature algorithms.
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 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 September 2, 2018.
Copyright Notice
Copyright (c) 2018 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
Wang, et al. Expires September 2, 2018 [Page 1]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
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. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extension of RAW Public Key to IBC-based Identity . . . . . . 4
4. Parameters for Signature Verification . . . . . . . . . . . . 5
5. New Key Exchange Algorithms and Cipher Suites . . . . . . . . 6
6. TLS Client and Server Handshake Behavior . . . . . . . . . . 6
6.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Client Authentication . . . . . . . . . . . . . . . . . . 8
6.4. Server Authentication . . . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. TLS Client and Server Use ECCSI . . . . . . . . . . . . . 9
7.2. Combined Usage of Raw Public Keys and X.509 Certificates 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
DISCLAIMER: This is a personal draft and has not yet seen significant
security analysis.
Traditionally, TLS/DTLS client and server exchange public keys
endorsed by PKIX [PKIX] certificates. It is considered complicate
and may cause security weaknesses with the use of PKIX certificates
[Defeating-SSL]. To simplify certificates exchange, using RAW public
key in TLS/DTLS has been specified in RFC 7250. That is, instead of
transmitting a full certificate in the TLS messages, only public keys
are exchanged between client and server. However, an out-of-band
mechanism for public key and identity binding is assumed.
Recently, 3GPP has adopted the EAP authentication framework for 5G
and EAP-TLS is considered as one of candidate authentication methods
for private networks, especially for networks with a large number of
IOT devices. For IOT networks, TLS/DTLS with RAW public key is
particularly attractive, but binding identities with public keys
might be challenging. The cost to maintain a large table for
Wang, et al. Expires September 2, 2018 [Page 2]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
identity and public key mapping at server side incurrs additional
maintenance cost. e.g. devices have to pre-register to the server.
To simplify the binding between the public key and the entity
presenting the public key, a better way could be using Identity-Based
Cryptography(IBC), such as ECCSI public key specified in RFC 6507,
for authentication. Different from X.509 certificates and raw public
keys, a public key in IBC takes the form of the entity's identity.
This helps eliminate the necessity of binding between a public key
and the entity presenting the public key.
The concept of IBC was first proposed by Adi Shamir in 1984. As a
special class of public key cryptography, IBC uses a user's identity
as public key, avoiding the hassle of public key certification in
public key cryptosystems. IBC broadly includes IBE (Identity-based
Encryption) and IBS (Identity-based Signature). For an IBC system to
work, there exists a trusted third party, PKG (private key generator)
responsible for issuing private keys to the users. In particular,
the PKG has in possession a pair of Master Public Key and Master
Secret Key; a private key is generated based on the user's identity
by using the Master Secret key, while the Master Public key is used
together with the user's identities for encryption (in case of IBE)
and signature verification ( in case of IBS).
A number of IBE and IBS algorithms have been standardized by
different standardization bodies, such as IETF, IEEE, and ISO/IEC.
For example, IETF has specified several RFCs such as RFC 5091
[RFC5091], RFC 6507 [RFC6507] and RFC6508 [RFC6508] for both IBE and
IBS algorithms. ISO/JTC and IEEE also have a few standards on IBC
algorithms.
RFC 7250 has specified the use of raw public key with TLS/DTLS
protocol. Example OIDs for RSA, DSA, ECDSA algorithms have been
given. However, supporting of IBS algorithms has not been included
therein. Since IBC algorithms are efficient in public key
transmission and also eliminate the binding between public keys and
identities, in this document, an amendment to RFC 7250 is added for
supporting IBS algorithms.
The document is orgranized as follows: Section 3 explains the use of
identity as raw public key when IBS algorithms are chosen as the
underlying digital signature mechanism, and example OIDs for IBS
algorithms are given. Section 4 discusses provision of the global
parameters used with the IBS algorithms. Section 5 discusses the
security considerations.
Wang, et al. Expires September 2, 2018 [Page 3]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
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. Extension of RAW Public Key to IBC-based Identity
In RFC 7250, a new Certificate structure is defined with two types,
X.509 and RawPublicKey. When raw public key is used in TLS,
RawPublicKey type is selected and a data strucutre
subjectPublicKeyInfo is used to specify the raw public key and its
cryptographic algorithm. Within the subjectPublicKeyInfo structure,
two fields, algorithm and parameters, are defined. The algorithm
specifies the cryptographic algorithm used with raw public key, which
is represented by an object Identifiers (OID); and the parameters
field provides necessary parameters associated with the algorithm.
subjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
Figure 1: SubjectECCSIPublicKeyInfo ASN.1 Structure
When using an IBS algorithm, an identity is used as raw public key,
which can be coverted to an OCTET string. Therefore, the Certificate
and subjectPublicKey structure can be reused without changes. No OID
for an IBS algorithm has been given as examples in [RFC 7250]. It is
known that there are a few standardized IBS algorithms, therefore, in
what follows several exmaples of OIDs for IBS algorithms are given.
The OIDs for some IBC-based Signature algorithmsare listed in the
following table.
Wang, et al. Expires September 2, 2018 [Page 4]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
+----------------------+--------------------+-----------------------+
| Key Type | Document | OID |
+----------------------+--------------------+-----------------------+
| ISO/IEC 14888-3 | ISO/IEC 14888-3: | 1.0.14888.3.0.7 |
| ibs-1 | IBS-1 mechansim | |
| | (Identity-Based | |
| | Signature) | |
+----------------------+--------------------+-----------------------+
| ISO/IEC 14888-3 | ISO/IEC 14888-3: | 1.0.14888.3.0.8 |
| ibs-2 | IBS-2 mechansim | |
| | (Identity-Based | |
| | Signature) | |
+----------------------+--------------------+-----------------------+
| SM9-1 Digital | SM9-1 Digital | 1.2.156.10197.1.302.1 |
| Signature Algorithm | Signature | |
| | Algorithm | |
+----------------------+--------------------+-----------------------+
| Elliptic Curve-Based | Section 5.2 in RFC | 1.3.6.1.5.x (need to |
| Signatureless For | 6507 | apply) |
| Identitiy-based | | |
| Encryption (ECCSI) | | |
+----------------------+--------------------+-----------------------+
Table 1: Algorithm Object Identifiers
In particular, ISO/IEC 14888-3 specifies two IBS algorithms, IBS-1
and IBS-2. The ECCSI is an IBS algorithm that is specified in IETF
[RFC 6507]. SM9-1 is a Chinese standard for an IBS algorithm.
Recently it has been accepted by ISO/IEC 14888-3
How are the paramters of AlgorithmIdentifier specified?
4. Parameters for Signature Verification
Using IBS algorithm in TLS/DTLS for raw public key exempts client and
server from public key certification and identity binding. This is
achieved by checking an entity's signatures and its identity against
the master public key of its PKG. With IBS algorithm, a PKG
generates private keys for entities based on their identities.
Global parameters such as PKG's Master Public Key (MPK) need be
provisioned to both client and server side. These parameters are not
user specific, but PKG specific.
For a client, PKG specific parameters can be provioned, at the time
PKG provisons the private key to the client. For the server, how to
get the PKG specific parameters provisioned is out of the scope of
this document, and it is depolyment dependent.
Wang, et al. Expires September 2, 2018 [Page 5]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
5. New Key Exchange Algorithms and Cipher Suites
To support identity as raw public key, new key exchange algorithms
corresponding to the IBS algorithms need to be defined. The signing
capability of the IBS algorithms is to be exploited, thus existing
key exchange algorithms making use of ephemeral DH are extended to
accomodate the support of the IBS algorithms. Considering the
performance and the compatibility with the use of ECDSA in TLS (see
RFC 4492), this specification proposes to support the IBS algorithm,
ECCSI, defined in RFC 6507 [RFC6507]. As a reult, the table below
summarizes the new key exchange algorithm, which mimics ECDHE_ECDSA
(see RFC 4492).
+-------------------------+---------------------------------------+
| Key Exchange Algorithm | Description |
+-------------------------+---------------------------------------+
| ECDHE_ECCSI | Ephemeral ECDH with ECCSI signatures |
+-------------------------+---------------------------------------+
Table 2: Algorithm Object Identifiers
Note: The specification of ECDHE_ECCSI can follow ECHDE_ECDSA by
substituting ECDSA with ECCSI. The detailed specification will be
provided in the future
Note: Other key exchange algorithm with other IBS algorithm may be
added in the future.
Accordingly, below defines the new cipher suites that use the above
new key exchange algorithms.
CipherSuite TLS_ECDHE_ECCSI_WITH_AES_128_CBC_SHA256 = { 0xC0, 0x80 }
CipherSuite TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256 = { 0xC0, 0x8A }
6. TLS Client and Server Handshake Behavior
The handshake between the TLS client and server follows that defined
in RFC 7250 [RFC7250], but with the support of the new key exchange
algorithm and cipher suites due to the introducton of ECCSI. The
high-level message exchange in the below figure shows TLS handshake
using raw public keys, where the client_certificate_type and
server_certificate_type extensions added to the client and server
hello messages (see Section 4 of RFC 7250).
Wang, et al. Expires September 2, 2018 [Page 6]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
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 2: Basic Raw Public Key TLS Exchange
6.1. Client Hello
If the TLS client wants to use ECCSI, then the
client_certificate_type is set to be RawPublicKey. If the TLS client
prefers accepting the server to use ECCSI, then the the
server_certificate_type is set to be RawPublicKey, and the
CipherSuite element of the client hello message is set to be the
cipher suite(s) supporting ECCSI.
6.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 [RFC 7250]:
1. The server does not support the extension defined in this
document. In this case, the server returns the server hello without
the extensions defined in this document.
2. The server supports the extension defined in this document, 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".
Wang, et al. Expires September 2, 2018 [Page 7]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
3. The server supports the extensions defined in this document and
has at least one certificate type in common with the client. In this
case, the processing rules described below are followed.
The client_certificate_type extension in the client hello indicates
the certificate types the client is able to provide to the server,
when requested using a certificate_request message. If the TLS
server wants to request a certificate from the client (via the
certificate_request message), it MUST include the
client_certificate_type extension in the server hello. This
client_certificate_type extension in the server hello then indicates
the type of certificates the client is requested to provide in a
subsequent certificate payload. The value conveyed in the
client_certificate_type extension MUST be selected from one of the
values provided in the client_certificate_type extension sent in the
client hello. The server MUST also include a certificate_request
payload in the server hello message.
If the server does not send a certificate_request payload or none of
the certificates supported by the client match the server-supported
certificate types, then the client_certificate_type payload in the
server hello MUST be omitted.
If the server_certificate_type extension in the client hello is set
be RawPublicKey and the CipherSuite element of the client hello
message is set to be the cipher suite(s) supporting ECCSI, and the
server chooses to use ECCSI, then the TLS server MUST place the
SubjectPublicKeyInfo structure containing the ECCSI key into the
Certificate payload. With the server_certificate_type extension in
the server hello, the TLS server indicates the certificate type
carried in the Certificate payload.
6.3. Client Authentication
When the TLS server has specified RawPublicKey as the
client_certificate_type, and the TLS client sends the
SubjectPublicKeyInfo structure containing an ECCSI key in the client
certificate, authentication of the TLS client to the TLS server is
achieved.
6.4. Server Authentication
When the TLS server has specified RawPublicKey as the
server_certificate_type, and sends the SubjectPublicKeyInfo structure
containing an ECCSI key in the server certificate, authentication of
the TLS server to the TLS client is achieved.
Wang, et al. Expires September 2, 2018 [Page 8]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
7. Examples
In the following, examples of handshake exchages using ECCSI under
RawPublicKey are illustrated.
7.1. TLS Client and Server Use ECCSI
In this example, both the TLS client and the TLS server use ECCSI,
and they are restricted in that they can only process ECCSI keys. As
a result, the TLS client sets the server_certificate_type extension
to be raw public key while omits the client_certificate_type
extension; in addition, the TLS client sets the ciphersuites in the
client hellow messag to be TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA256,
as shown in (1).
When the TLS server receives the client hello, it processes the
message. Since it has an ECCSI key, it indicates in (2) that it
agreed to use ECCSI and provided an ECCSI key by placing the
SubjectPublicKeyInfo structure into the Certificate payload back to
the client (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 a raw public key. The TLS client, which has an ECCSI key,
returns its ECCSI key in the Certificate payload (6) to the server.
Wang, et al. Expires September 2, 2018 [Page 9]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
client_hello,
cipher_suites=(TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256) // (1)
client_certificate_type=(RawPublicKey) // (1)
server_certificate_type=(RawPublicKey) // (1)
->
<- server_hello,
server_certificate_type=RawPublicKey // (2)
certificate, // (3)
client_certificate_type=RawPublicKey // (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 3: Basic Raw Public Key TLS Exchange
7.2. Combined Usage of Raw Public Keys and X.509 Certificates
This example combines the uses of an ECCSI key and an X.509
certificate. The TLS client uses an ECCSI key for client
authentication, and the TLS server provides an X.509 certificate.
This exchange starts with the client indicating its ability to
process a raw public key, or an X.509 certificate, if provided by the
server. It prefers a raw public key, since the RawPublicKey value
precedes the other value in the server_certificate_type vector.
Furthermore, the client indicates that it has a raw public key for
client-side authentication (see (1)). The server chooses to provide
its X.509 certificate in (3) and indicates that choice in (2). For
client authentication, the server indicates in (4) that it has
selected the raw public key format and requests a certificate from
the client in (5). The TLS client provides an ECSSI key in (6) after
receiving and processing the TLS server hello message.
Wang, et al. Expires September 2, 2018 [Page 10]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
client_hello,
cipher_suites=(TLS_ECDHE_ECSSI_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA256) // (1)
server_certificate_type=(RawPublicKey, X.509) // (1)
client_certificate_type=(RawPublicKey) // (1)
->
<- server_hello,
server_certificate_type=X.509 // (2)
certificate, // (3)
client_certificate_type=RawPublicKey // (4)
certificate_request, // (5)
server_key_exchange,
server_hello_done
certificate, // (6)
client_key_exchange,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 4: Basic Raw Public Key TLS Exchange
8. Security Considerations
Using IBS-enabled raw public key in TLS/DTLS will not change the
handshake flows of TLS, so the security of the resulting protocol
rests on the security of the used IBS algorithms. The example IBS
algorithms mentioned above are all standardized and open, and thus
the security of these algorithms is supposed to have gone through
wide scrutinization.
9. IANA Considerations
This document describes new OIDs for IBS algorithms (Section 4), new
key exchange algorithm (Section 5) and the corresponding new cipher
suites (Section 5).
10. Acknowledgements
11. References
11.1. Normative References
Wang, et al. Expires September 2, 2018 [Page 11]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
[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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography
Standard (IBCS) #1: Supersingular Curve Implementations of
the BF and BB1 Cryptosystems", RFC 5091,
DOI 10.17487/RFC5091, December 2007,
<https://www.rfc-editor.org/info/rfc5091>.
[RFC6507] Groves, M., "Elliptic Curve-Based Certificateless
Signatures for Identity-Based Encryption (ECCSI)",
RFC 6507, DOI 10.17487/RFC6507, February 2012,
<https://www.rfc-editor.org/info/rfc6507>.
[RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)",
RFC 6508, DOI 10.17487/RFC6508, February 2012,
<https://www.rfc-editor.org/info/rfc6508>.
[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, <https://www.rfc-editor.org/info/rfc7250>.
11.2. Informative References
[Defeating-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
Wang, et al. Expires September 2, 2018 [Page 12]
Internet-Draft TLS-RAW-Public-Key-IBC March 2018
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
Xin Kang
Huawei Technology Pte. Ltd.
20 Secience Park Road, #3-30/31
Singapore 117687
SG
Phone: +65 6825 4200
Email: xin.kang@huawei.com
Wang, et al. Expires September 2, 2018 [Page 13]