Internet DRAFT - draft-mehrtens-core-ace-concert
draft-mehrtens-core-ace-concert
CoRE Working Group H. Mehrtens
Internet-Draft Universitaet Bremen TZI
Intended status: Informational February 14, 2014
Expires: August 18, 2014
Constrained Certificates for the Constrained Application Protocol (CoAP)
draft-mehrtens-core-ace-concert-00
Abstract
The present document defines a new kind of certificate suited for
constrained environments. This new kind of certificate is intended
to be used in Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS) in combination with Constrained Application
Protocol (CoAP).
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 August 18, 2014.
Copyright Notice
Copyright (c) 2014 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.
Mehrtens Expires August 18, 2014 [Page 1]
Internet-Draft concert February 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases and Problem Statement . . . . . . . . . . . . . . . 4
3. Design Requirements . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of the approach . . . . . . . . . . . . . . . . . . . 6
5. Structure of the certificate . . . . . . . . . . . . . . . . . 7
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Mehrtens Expires August 18, 2014 [Page 2]
Internet-Draft concert February 2014
1. Introduction
The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] uses
DTLS [RFC6347] to establish a secure connection between distinct
nodes in a sensor network. Like TLS, DTLS provides various ways to
authenticate peers. For a certificate based authentication X.509
certificates or Raw Public Keys can be used [RFC5246],
[I-D.ietf-tls-oob-pubkey].
X.509 certificates [RFC5280] were invented to fulfill the needs of
the Public-Key infrastructure. This certificate format is very
flexible and has lots of extensions, but that makes it also difficult
to handle in constrained environments. In addition X.509
certificates are encoded using ASN.1 DER encoding, which needs
complex parsers, compared to other formats.
An alternative for X.509 certificates is the use of raw public keys.
They consist only of the public key and thus offer a very light-
weight solution. But they provide no means for binding the public
key to an entity. Moreover, many of the other features provided by
X.509 are missing.
The intention of this draft is to define a new format for
representing a certificate. This new kind of certificate aims to be
a alternative to X.509 for constrained environments, while still
being usable in the TLS and DTLS handshake like a X.509 certificate.
1.1. Terminology
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].
Mehrtens Expires August 18, 2014 [Page 3]
Internet-Draft concert February 2014
2. Use Cases and Problem Statement
When implementing DTLS with public key authentication on a Class 1
constrained node [I-D.ietf-lwig-terminology] using X.509 certificates
tends to consume too much memory. The analysis done in
[I-D.ietf-lwig-tls-minimal] on a constrained TLS implementation using
X.509 certificates showed that the X.509 related code needed 2,776
Bytes and the ASN.1 parser needed an addition of 5,512 bytes.
Using raw public keys in DTLS already showed problems regarding the
parsing and creation of ASN.1 structures needed for the ECDSA
signature in the handshake. In a raw public key 27 bytes are used to
describe the ECDSA capable key and to form the ASN.1 structure
itself.
Mehrtens Expires August 18, 2014 [Page 4]
Internet-Draft concert February 2014
3. Design Requirements
The constrained certificates presented in this document are designed
for the usage in TLS and DTLS with the Constrained Application
Protocol (CoAP) and to replace X.509 in these environments.
The main approach is to create certificates better suited for the use
in constrained environments. This is done by removing the elements
from the basic structures of the X.509 format, which are not needed
in this use case. In addition other elements are modified to include
additions added by certificate extensions in X.509, which are needed
in many use cases by TLS and DTLS.
While defining a new certificate format we used Binary Object
Representation (CBOR) [RFC7049] to encode the data instead of ASN.1,
because CBOR is better suited for constrained environments. The new
format also makes use of the tagging mechanism of CBOR to describe
elements.
Mehrtens Expires August 18, 2014 [Page 5]
Internet-Draft concert February 2014
4. Overview of the approach
The main differences in the design of Concerts compared to X.509
certificates are:
o Instead of using Object Identifiers as in X.509, tags from CBOR
are used. Each of the object identifiers found in a small X.509
ECDSA certificate is between 3 and 9 Bytes long and is stored in
an additional element whose definition needs additional space.
o Concerts will have a list of entity names the certificate is bound
to and not just one subject distinguished name. There is no need
for something like the subject alternative names extension,
because all these names are defined in the list of subject names.
This make the certificate itself smaller and it also makes the
parsing of the certificate easier, because there is just one
structure to parsed instead of two for X.509 certificates to get
all subject distinguished names.
o One subject name in the list of subject names consists of only one
value, such as the DNS name or the IP address. Many X.509
certificates used in the web also contain additional data in the
subject distinguished name, describing the organization which
operates the website, these information are not needed for the TLS
or DTLS authentication.
o Instead of referencing the issuer certificate by its subject
distinguished name, the issuer is referenced by a named
information like defined in [RFC6920]. A SHA-256 hash over the
public key of the issuer is computed and the first 8 to 32 bytes
of that hash are stored in the certificate the issuer singed to
identify issuer. This is similar to the use of the authority key
identifier from from [RFC5280], Section 4.2.1.1. to identify the
issuer certificate. This way Raw public keys
[I-D.ietf-tls-oob-pubkey] can be used as certificate authorities.
Mehrtens Expires August 18, 2014 [Page 6]
Internet-Draft concert February 2014
5. Structure of the certificate
This new certificate type uses a similar ordering than X.509 does.
Certificate ::= Array {
tbsCertificate TBSCertificate,
signatureValue Array }
TBSCertificate ::= Array {
serialNumber byte string,
signature integer,
issuer byte string,
notBefore dateTime,
notAfter dateTime,
subjectList SubjectNameList,
subjectPublicKeyInfo SubjectPublicKeyInfo,
extension Map }
SubjectNameList ::= ARRAY OF SubjectName
SubjectName ::= CHOICE {
IPv4 byte string,
IPv6 byte string,
dns utf-8 string }
SubjectPublicKeyInfo ::= ARRAY {
curve integer,
pubkey byte string }
The Certificate element contains the complete certificate and will be
tagged, to indicate a specific version of the concert certificate
format.
The TBSCertificate element stores the data to be signed.
The serialNumber should be used by an issuer to store additional data
like a serial number to do certificate revocation or to add some
additional entropy to the certificate.
The signature element stores the signature algorithm this certificate
was sign with. It must be the same value as used to tag the
signatureValue element.
The issuer element must contain a named information defined in
[RFC6920], which is a SHA-256 hash over the issuer's public key or
part of it. It is used to identify the issuer certificate. The
element is tagged with the hash algorithm used to create the hash.
Mehrtens Expires August 18, 2014 [Page 7]
Internet-Draft concert February 2014
There are no secure hash algorithms needed, because a collision will
not weaken the security, it will just prevent the issuer from being
found.
The notBefore and notAfter element must meet the requirements for
dateTime types.
The subject element is an array with the subject names this
certificate is bound to. The subject names in the list must have a
tag. There is a tag needed for an IPv4 address, IPv6 address and a
DNS name. Using special representation for some identifiers makes it
easier to compress the data and there is no code needed to convert an
IP address from string into a binary representation.
The subjectPublicKeyInfo element contains an array with elements
specific to the public key and is tagged with the public key type.
In case of an ECDSA capable public keys a curve name and the public
key itself are stored in this array.
The signatureValue element stores the signature of the tbsCertificate
block made with the issuer private key. This element is tagged with
the signature algorithm. That tag must match the tag of the
signature element in the tbsCertificate element. The number of
elements in the array depends on the needs of the signature algorithm
used.
The ECDSA signature is not stored in an ASN.1 DER representation, but
also encoded with CBOR. Both values of the ECDSA signature are
stored in the array in binary representation with a fixed length
depending on the signature type.
Mehrtens Expires August 18, 2014 [Page 8]
Internet-Draft concert February 2014
6. Example
Here is an example for such a certificate.
VERSION[
[
h'', // no serialNumber
SIG_ALGO,
TRUNCATED_HASH(h'
01 23 45 67 89 AB CD EF 01 23 45 67 89 AB CD
EF'),
1(1394751600), // 14/02/2014
1(1402783200), // 15/05/2014
[
IPv4(h'C0000201'), // 192.0.2.1
IPv6(h'20010DB8000000000000000000000001'),
// 2001:db8::1
DNS("www.example.com")
],
PUB_KEY([
23, // secp256r1
h'04 CD 4E 80 9A DA BF 6B F7 BB 03 EF 9C 5C
E0 0B C0 92 EB 94 14 04 5E C5 42 F2 57 99
BD F8 42 88 96 24 1A 08 90 9A ED 2F C5 68
BB 3C BC 48 20 78 08 7B D8 28 5C C9 ED 36
65 A6 97 BA AB 62 D5 E7 95'
])
],
SIG_ALGO([
h'28 B1 51 1E 6F 03 10 12 8E 9A E0 3D 11 A2 F0
AF BF 3D 1F EC 58 30 C3 FA 3E C4 F4 8B 75 40
E8 17',
h'D6 E4 0A 56 00 48 D7 BB F4 23 5B FC CB 5F 87
52 0F 49 D8 F5 B2 85 8B EF B2 C1 27 17 2E F3
A0 88'
])
]
Mehrtens Expires August 18, 2014 [Page 9]
Internet-Draft concert February 2014
7. References
7.1. Normative References
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[I-D.ietf-lwig-terminology]
Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained Node Networks", draft-ietf-lwig-terminology-07
(work in progress), February 2014.
[I-D.ietf-tls-oob-pubkey]
Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
T. Kivinen, "Using Raw Public Keys in Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress),
January 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] 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", RFC 5280, May 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, April 2013.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, October 2013.
7.2. Informative References
[I-D.ietf-lwig-tls-minimal]
Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's
Guide to the (Datagram) Transport Layer Security Protocol
for Smart Objects and Constrained Node Networks",
Mehrtens Expires August 18, 2014 [Page 10]
Internet-Draft concert February 2014
draft-ietf-lwig-tls-minimal-00 (work in progress),
September 2013.
Mehrtens Expires August 18, 2014 [Page 11]
Internet-Draft concert February 2014
Author's Address
Hauke Mehrtens
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Email: hmehr@tzi.de
Mehrtens Expires August 18, 2014 [Page 12]
