March 9, 2015
draft-selander-ace-object-security-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Göran Selander , John Preuß Mattsson , Ludwig Seitz | ||
| Last updated | 2015-03-09 | ||
| Replaced by | draft-ietf-core-object-security, draft-ietf-core-object-security, RFC 8613 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-selander-ace-object-security-01
ACE Working Group G. Selander
Internet-Draft J. Mattsson
Intended Status: Standards Track Ericsson
Expires: September 10, 2015 L. Seitz
SICS Swedish ICT
March 9, 2015
Object Security for CoAP
draft-selander-ace-object-security-01
Abstract
This memo presents a scheme for data object security applicable to
protection of payload of generic message formats as well as request
and response messages of the Constrained Application Protocol (CoAP).
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2015 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
Selander, et al. Expires September 10, 2015 [Page 1]
INTERNET DRAFT Object Security for ACE March 9, 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. End-to-end Security in Presence of Intermediary Nodes . . . . . 6
4. Secure Message . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Secure Message format . . . . . . . . . . . . . . . . . . . 8
4.1.1 Secure Message Header . . . . . . . . . . . . . . . . . 8
4.1.2 Secure Message Body . . . . . . . . . . . . . . . . . . 9
4.1.2.1 Secure Signed Message Body . . . . . . . . . . . . . 9
4.1.2.2 Secure Encrypted Message Body . . . . . . . . . . . 9
4.1.3 Secure Message Tag . . . . . . . . . . . . . . . . . . . 9
5. Message Protection . . . . . . . . . . . . . . . . . . . . . . 9
5.1 CoAP Message Protection . . . . . . . . . . . . . . . . . . 10
5.1.1 The Sig Option . . . . . . . . . . . . . . . . . . . . . 10
5.1.1.1 Option Structure . . . . . . . . . . . . . . . . . . 10
5.1.1.2 Integrity Protection and Verification . . . . . . . 11
5.1.1.3 SSM Body . . . . . . . . . . . . . . . . . . . . . . 11
5.1.2 The Enc Option . . . . . . . . . . . . . . . . . . . . . 12
5.1.2.1 Option Structure . . . . . . . . . . . . . . . . . . 12
5.1.2.2 Encryption and Decryption . . . . . . . . . . . . . 12
5.1.2.3 SEM Body . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2.4 CoAP Message with Enc Option . . . . . . . . . . . . 13
5.1.3 SM Tag . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Application Layer Protection . . . . . . . . . . . . . . . . 14
5.3 Replay Protection and Freshness . . . . . . . . . . . . . . 15
5.3.1 Replay Protection . . . . . . . . . . . . . . . . . . . 15
5.3.2 Freshness . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1 Normative References . . . . . . . . . . . . . . . . . . . 19
10.2 Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Which CoAP Header Fields and Options to Protect . . . 20
A.1 CoAP Header Fields . . . . . . . . . . . . . . . . . . . . . 20
A.2 CoAP Options . . . . . . . . . . . . . . . . . . . . . . . . 20
A.2.1 Integrity Protection . . . . . . . . . . . . . . . . . . 21
Selander, et al. Expires September 10, 2015 [Page 2]
INTERNET DRAFT Object Security for ACE March 9, 2015
A.2.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . 22
A.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix B. JOSE Objects as Secure Messages . . . . . . . . . . . 23
B.1 JWS as Secure Signed Message . . . . . . . . . . . . . . . 23
B.2 JWE as Secure Encrypted Message . . . . . . . . . . . . . . 23
B.3 "seq" (Sequence Number) Header Parameter . . . . . . . . . . 24
B.4 "mod" (Mode) Header Parameter . . . . . . . . . . . . . . . 24
B.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix C. Compact Secure Message . . . . . . . . . . . . . . . 25
C.1 CSM Format . . . . . . . . . . . . . . . . . . . . . . . . . 25
C.2 Comparison of Secure Message sizes . . . . . . . . . . . . . 27
Appendix D. Examples . . . . . . . . . . . . . . . . . . . . . . 29
D.1 CoAP Message Protection . . . . . . . . . . . . . . . . . . 29
D.1.1 Integrity protection of CoAP Message . . . . . . . . . . 29
D.1.2 Encryption of CoAP Message . . . . . . . . . . . . . . . 30
D.2 Application Layer Protection . . . . . . . . . . . . . . . . 32
D.2.1 Proxy Caching . . . . . . . . . . . . . . . . . . . . . 32
D.2.2 Publish-Subscribe . . . . . . . . . . . . . . . . . . . 33
D.2.3 Transporting Authorization Information . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Selander, et al. Expires September 10, 2015 [Page 3]
INTERNET DRAFT Object Security for ACE March 9, 2015
1. Introduction
The Constrained Application Protocol CoAP [RFC7252] was designed with
a constrained RESTful environment in mind. CoAP references DTLS
[RFC6347] for securing the message exchanges. Two commonly used
features of CoAP are store-and-forward and publish-subscribe
exchanges, which are problematic to secure with DTLS and transport
layer security. As DTLS offers hop-by-hop security, in case of
store-and-forward exchanges it necessitates a trusted intermediary.
On the other hand, securing publish-subscribe CoAP exchanges with
DTLS requires the use of the keep-alive mechanism which incurs
additional overhead and actually takes away most of the benefits of
asynchronous communication.
The pervasive monitoring debate has illustrated the need to protect
data also from trustworthy intermediary nodes as they can be
compromised. The community has reacted strongly to the revelations,
and new solutions must consider this attack [RFC7258] and include
encryption by default.
This memo presents an object security approach for secure messaging
in constrained environments that may be used as a complement to DTLS
for store-and-forward and publish-subscribe CoAP exchanges. Note
that the solution sketched in this memo can be combined with DTLS
thus enabling, for example, end-to-end security of CoAP payload in
combination with hop-by-hop protection of the entire CoAP messages
during transport between end-point and intermediary node.
This version of the draft focuses on symmetric key based algorithms.
Public key based algorithms will be addressed in the next version.
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 [RFC2119]. These
words may also appear in this document in lowercase, absent their
normative meanings.
Certain security-related terms are to be understood in the sense
defined in RFC 4949 [RFC4949]. These terms include, but are not
limited to, "authentication", "authorization", "confidentiality",
"(data) integrity", "message authentication code", "signature", and
"verify".
RESTful terms, such as "resource" or "representation", are to be
understood as used in HTTP [RFC7231] and CoAP.
Selander, et al. Expires September 10, 2015 [Page 4]
INTERNET DRAFT Object Security for ACE March 9, 2015
Terminology for constrained environments, such as "constrained
device", "constrained-node network", is defined in [RFC7228].
Client, Resource Server, and Authorization Server are defined in [I-
D.seitz-ace-problem-description]. The terms "server" and "Resource
Server" are used interchangeably.
JSON Web Signature (JWS), JOSE Header, JWS Payload, and JWS Signature
are defined in [I-D.ietf-jose-json-web-signature].
JSON Web Encryption (JWE), JWE AAD, JWE Ciphertext, and JWE
Authentication Tag are defined in [I-D.ietf-jose-json-web-
encryption].
Secure Message (SM), Secure Signed Message (SSM), and Secure
Encrypted Message (SEM) are message formats defined in this memo.
The Compact Secure Message (CSM) format is defined in Appendix C.
The Sig and Enc options are CoAP options defined in this memo.
Excluded Authenticated Data (EAD) is defined in this memo (see
Sections 4.1.2). Transaction Identifier (TID) is defined in this
memo (see Section 4.1.1).
2. Background
The background for this work is provided by the use cases and problem
description in [I-D.ietf-ace-usecases] and [I-D.seitz-ace-problem-
description]. The overall objective is that (a) only authorized
requests are granted, and (b) messages between client and server are
protected (according to requirements of the particular use case).
The focus of this memo is on end-to-end security in constrained
environments in the presence of intermediary nodes, which corresponds
to point (b).
For constrained-node networks there may be several reasons for
messages to be cached or stored in one node and later forwarded. For
example, connectivity between the nodes may be intermittent, or some
node may be sleeping at the time when the message should have been
forwarded (see e.g. [I-D.ietf-ace-usecases] sections 2.1.1, and
2.5.1). Also, the architectural model or protocol applied may
require an intermediary node which breaks security on transport layer
(see e.g. [I-D.ietf-ace-usecases] sections 2.1.1, and 2.5.2).
Examples of intermediary nodes include forward proxies, reverse
proxies, pub-sub brokers, HTTP-CoAP cross-proxies, and SMS servers.
On a high level, end-to-end security in this setting encompasses:
1. Protection against eavesdropping and manipulation of resource
Selander, et al. Expires September 10, 2015 [Page 5]
INTERNET DRAFT Object Security for ACE March 9, 2015
representations in intermediary nodes;
2. Protection against message replay;
3. Protection of authorization information ("access tokens") in
transport from an Authorization Server to a Resource Server via
a Client, or other intermediary nodes which could gain from
changing the information;
4. Allowing a client to verify that a response comes from a
certain server and is the response to a particular request;
5. Protection of the RESTful method used by the client, or the
response code used by the server. For example if a malicious
proxy replaces the client requested GET with a DELETE this must
be detected by the server;
6. Protection against eavesdropping of meta-data of the request or
response, including CoAP options such as for example Uri-Path
and Uri-Query, which may reveal some information on what is
requested.
From the listed examples, there are two main categories of security
requirements and corresponding solutions. The first category deals
essentially with application layer protection, i.e. protecting the
payload of the RESTful protocol (1-3). The second category deals
with protecting an entire CoAP message, targeting also CoAP options
and header fields (4-6). The next section formulates security
requirements for the two categories, which are denoted Mode:APPL and
Mode:COAP, respectively.
3. End-to-end Security in Presence of Intermediary Nodes
For high-level security requirements related to resource access, see
section 4.6 of [I-D.seitz-ace-problem-description]. This section
defines the specific requirements that address the two categories of
examples identified in the previous section, taking into account
potential intermediary nodes.
In the case of application layer protection (Mode:APPL), the end-to-
end security requirements apply to the RESTful protocol payload data,
such as Resource Representations:
a. The payload shall be integrity protected and should be
encrypted end-to-end from sender to receiver.
b. It shall be possible for an intended receiver to detect if it
has received this message previously, i.e. replay protection.
Selander, et al. Expires September 10, 2015 [Page 6]
INTERNET DRAFT Object Security for ACE March 9, 2015
In this case there may be multiple receivers of a given message, for
example in the case of a proxy that is caching responses used to
serve multiple clients, or in a publish-subscribe setting with
multiple subscribers to a given publication.
In the case of protecting specific Client-Server CoAP message
exchanges (Mode:COAP), potentially passing via intermediary nodes,
there are additional end-to-end security requirements:
c. The CoAP options which are not intended to be changed by an
intermediary node shall be integrity protected between Client
and Server.
d. The CoAP options which are not intended to be read by an
intermediary node shall be encrypted between Client and Server.
e. The CoAP header field "Code" shall be integrity protected
between Client and Server.
f. A Client shall be able to verify that a message is the response
to a particular request the Client made.
The requirements listed above can be met by encryption, integrity
protection and replay protection. What differs is the actual data
that is protected, i.e. application layer data or CoAP message data.
This memo specifies a common "Secure Message" format that can be used
to wrap either payload only or also additional selected CoAP message
fields, and be sent as part of the message.
4. Secure Message
There exist already standardized and draft content formats for
cryptographically protected data such as CMS [RFC5652], JWS, JWE, and
COSE [I-D.bormann-jose-cose]. None of the listed formats provide
support for replay protection, but it is noted in section 10.10 of
[I-D.ietf-jose-json-web-signature]) that one way to thwart replay
attacks is to include a unique transaction identifier and have the
recipient verify that the message has not been previously received or
acted upon.
The term Secure Message (SM) format refers to a content format for
cryptographically protected data which includes a unique transaction
identifier and allows customization to support different variants of
format and message processing (Modes).
This memo uses JOSE content formats as a model to specify format and
processing of messages. The terms Secure Signed Message (SSM) format
Selander, et al. Expires September 10, 2015 [Page 7]
INTERNET DRAFT Object Security for ACE March 9, 2015
and Secure Encrypted Message (SEM) format to refer to Secure Message
formats supporting integrity protection only and additional
encryption, analogous to JWS and JWE, respectively. Appendix B shows
how JWS and JWE could be extended to become Secure Message formats.
It should be noted that the current JOSE objects are undesirably
large for very constrained devices. In their current size they can
lead to packet fragmentation in constrained-node networks due to
limited frame sizes, and to problems with limited storage capacity on
constrained devices due to limited RAM. COSE renders more compact
objects, and further optimizations are considered. See Appendix C
for a discussion of minimum message expansion and message format
overhead.
4.1 Secure Message format
A Secure Message (SM) SHALL consist of Header, Body and Tag.
4.1.1 Secure Message Header
The following parameters SHALL be included in the SM Header:
o Algorithm. This parameter allows the receiver to identify the
cryptographic algorithm(s) used to protect the Secure Message.
In case of SSM it has the same syntax as the JOSE Header
Parameter "alg" defined in Section 4.1.1 of [I-D.ietf-jose-json-
web-signature]. In case of SEM, it has the same syntax as the
JOSE Header Parameter "enc" defined in Section 4.1.2 of [I-
D.ietf-jose-json-web-encryption]. (Assuming direct key
agreement, corresponding to the JWE "alg" = "dir" setting.)
o Key Identifier. This parameter allows the receiver to uniquely
identify the sender and the security context/key(s) used with
the Algorithm. It has the same syntax as the JOSE Header
Parameter "kid" defined in Section 4.1.4 of [I-D.ietf-jose-json-
web-signature].
o Sequence Number. The Sequence Number parameter enumerates the
Secure Messages protected using the key(s) identified by the Key
Identifier, and is used for replay protection and uniqueness of
nonce. The start sequence number SHALL be 0. For a given key,
any Sequence Number MUST NOT be used more than once.
o Mode. The Mode parameter defines application specific message
format, content and processing. This parameter provides means
for customization of the Secure Message format, in particular to
distinguish between Secure Messages containing application layer
data only or CoAP message data.
Selander, et al. Expires September 10, 2015 [Page 8]
INTERNET DRAFT Object Security for ACE March 9, 2015
The ordered sequence (Sequence Number, Key Identifier) is called
Transaction Identifier (TID), and SHALL be unique for each SM.
4.1.2 Secure Message Body
Analogously to JWS and JWE, the SM Body contains what is being
protected. The SM Body is different for SSM and SEM.
In order to obtain a compact representation, certain data is
integrity protected but excluded from the Secure Message. Such data
is referred to as Excluded Authenticated Data (EAD). To further
reduce message size, the unencrypted part of the SM Body may be
"detached" from the Secure Message, see sections 4.1.2.1 and 4.1.2.2.
The assumption behind excluding integrity protected data from the SM,
or detaching integrity protected but not encrypted parts of the SM
during transport, is that the data in question is known to the
receiver, e.g. because it is exchanged beforehand or because it is
transported as part of the CoAP message carrying the Secure Message.
4.1.2.1 Secure Signed Message Body
For SSM, the Body consists of the payload data which is integrity
protected, analogously to the JWS Payload. Detached Content is
defined to mean that the Body is removed from the Secure Message,
analogously to Appendix F of [I-D.ietf-jose-json-web-signature].
Hence a SSM with Detached Content consists of Header and Tag.
4.1.2.2 Secure Encrypted Message Body
Analogously to JWE, the terms Plaintext, Ciphertext and Additional
Authenticated Data (AAD) are used for the SEM. The Body of a SEM
consists of Ciphertext and Additional Authenticated Data (AAD). For
SEM Detached Content is defined to mean that the AAD is removed from
the Secure Message. Hence a SEM with Detached Content consists of
the Header, Ciphertext and Tag.
4.1.3 Secure Message Tag
The SM Tag consists of the Signature / Authentication Tag value as
defined by the Algorithm, calculated over the SM Header, SM Body and
EAD (if present). The content of EAD depends on the Mode, see 5.1.3
and 5.2
5. Message Protection
Selander, et al. Expires September 10, 2015 [Page 9]
INTERNET DRAFT Object Security for ACE March 9, 2015
This section describes what is protected in a Secure Message and how
it depends on the defined Modes ("CoAP Message Protection" and
"Application Layer Protection"). Both formats SSM and SEM defined in
the previous section are applicable to both Modes. For examples, see
Appendix D.
For any Secure Message Mode, the SEM format SHALL be used by default.
The SM Header is defined in 4.1.1, indicates the Mode, but is in all
other respects handled similarly in both Modes. This section also
describes the differences in SM Body and SM Tag.
5.1 CoAP Message Protection
Referring to examples 4-6 in Section 2 and requirements a-f in
Section 3, this section presents how to protect individual CoAP
messages including options and header fields, as well as request-
response message exchanges, using the Secure Message format. This is
called Secure Message Mode:COAP. An endpoint receiving a CoAP
request containing a Secure Message with Mode:COAP MUST respond with
a CoAP message containing a Secure Message with Mode:COAP.
Since slightly different message formats are used for integrity
protection only (SSM), and additional encryption (SEM), these cases
are treated separately. Two new CoAP security options are
introduced: the Enc option and the Sig option. A CoAP message SHALL
NOT include both Enc and Sig options.
5.1.1 The Sig Option
In order to integrity protect CoAP message exchanges, a new CoAP
option is introduced: the Sig option, containing a SSM Mode:COAP
object. Endpoints supporting this scheme MUST check for the
presence of a Sig option, and verify the SSM as described in Section
5.1.1.2 before accepting a message as valid.
5.1.1.1 Option Structure
The Sig option indicates that certain CoAP Header Fields, Options,
and Payload (if present) are integrity and replay protected using a
Secure Signed Message (SSM). The Sig option SHALL contain a SSM with
Detached Content (see Section 4.1.2.1).
This option is critical, safe to forward, it is not part of a cache
key, and it is not repeatable. Table 1 illustrates the structure of
this option.
Selander, et al. Expires September 10, 2015 [Page 10]
INTERNET DRAFT Object Security for ACE March 9, 2015
+-----+---+---+---+---+---------+--------+-----------+
| No. | C | U | N | R | Name | Format | Length *) |
+-----+---+---+---+---+---------+--------+-----------+
| TBD | x | | x | | Sig | opaque | 12-TBD |
+-----+---+---+---+---+---------+--------+-----------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Table 1: The Sig Option
*) Length is essentially Length(SSM Header) + Length(SSM Tag). The
minimum length is estimated in Appendix C. The maximum length
depends on actual message format selected and is TBD.
5.1.1.2 Integrity Protection and Verification
A CoAP endpoint composing a message with the Sig option SHALL process
the SSM and produce the SSM Tag, as defined in 5.1.1.3 and 5.1.3,
analogously to the specification for producing a JWS object as
described in Section 5.1 of [I-D.ietf-jose-json-web-signature] (cf.
Appendix B). In addition, the sending endpoint SHALL process the
Sequence Number as described in Section 5.3.
A CoAP endpoint receiving a message containing the Sig option SHALL
first recreate the SSM Body as described in Section 5.1.1.3, and then
verify the SSM Tag as described in Section 5.1.3, analogously to the
specification for verifying a JWS object as described in Section 5.2
of [I-D.ietf-jose-json-web-signature] (cf. Appendix B). In addition,
the receiving endpoint SHALL process the Sequence Number as described
in Section 5.3.
NOTE: The explicit steps of the protection and verification procedure
will be included in a future version of this draft.
5.1.1.3 SSM Body
The SSM Body SHALL consist of the following data, in this order:
o the 8-bit CoAP header field Code;
o all CoAP options present which are marked as IP in Table 3
(Appendix A), in the order as given by the option number (each
Option with Option Header including delta to previous IP-marked
Option which is present); and
o the CoAP Payload (if any).
Selander, et al. Expires September 10, 2015 [Page 11]
INTERNET DRAFT Object Security for ACE March 9, 2015
5.1.2 The Enc Option
In order to encrypt and integrity protect CoAP messages, a new CoAP
option is introduced: the Enc option, indicating the presence of a
SEM Mode:COAP object in the CoAP message, containing the encrypted
part of the CoAP message. Endpoints supporting this scheme MUST
check for the presence of an Enc option, and verify the SEM as
described in 5.1.2.2 before accepting a message as valid.
NOTE: This version of the draft is only considering AEAD algorithms.
5.1.2.1 Option Structure
The Enc option indicates that certain CoAP Options and Payload (if
present) are encrypted, integrity and replay protected using a Secure
Encrypted Message (SEM) with Detached Content (see Section 4.1.2.2).
The structure of a CoAP message with an Enc option is described in
Section 5.1.2.4.
This option is critical, safe to forward, it is not part of a cache
key, and it is not repeatable. Table 2 illustrates the structure of
this option.
+-----+---+---+---+---+---------+--------+-------------+
| No. | C | U | N | R | Name | Format | Length *) |
+-----+---+---+---+---+---------+--------+-------------+
| TBD | x | | x | | Enc | opaque | 0 or 12-TBD |
+-----+---+---+---+---+---------+--------+-------------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Table 2: The Enc Option
*) Length indicates in this case the additional length added to the
total length of all CoAP options. If the CoAP message has Payload,
then the Enc option is empty, otherwise it contains the SEM (see
Section 5.1.2.4). In the latter case, the SEM Ciphertext contains
the encrypted CoAP Options (see Section 5.1.2.3), which are thus
excluded from plaintext part of the message. Hence the additional
length is essentially Length(SEM Header) + Length(SEM Tag). The
minimum length is estimated in Appendix C. The maximum length
depends on actual message format selected and is TBD.
5.1.2.2 Encryption and Decryption
A CoAP endpoint composing a message with the Enc option SHALL process
Selander, et al. Expires September 10, 2015 [Page 12]
INTERNET DRAFT Object Security for ACE March 9, 2015
the SEM and produce the SEM Ciphertext and SEM Tag, as defined in
5.1.2.3 and 5.1.3, analogously to the specification for producing a
JWE object as described in Section 5.1 of [I-D.ietf-jose-json-web-
encryption] (cf. Appendix B). In addition, the sending endpoint
SHALL process the Sequence Number as described in Section 5.3.
A CoAP endpoint receiving a message containing the Enc option SHALL
first recreate the SEM Body as described in Section 5.1.2.3, and then
decrypt and verify the SEM analogously to the specification for
verifying a JWE object as describe in Section 5.2 of [I-D.ietf-jose-
json-web-encryption] (cf. Appendix B). In addition, the receiving
endpoint SHALL process the Sequence Number as described in Section
5.3.
NOTE: The explicit steps of the protection and verification procedure
will be included in a future version of this draft.
5.1.2.3 SEM Body
The SEM Plaintext SHALL consist of the following data, formatted as a
CoAP message without Header consisting of:
o all CoAP Options present which are marked as E in Table 3 (see
Appendix A), in the order as given by the Option number (each
Option with Option Header including delta to previous E-marked
Option); and
o the CoAP Payload, if present, and in that case prefixed by the
one-byte Payload Marker (0xFF).
The SEM Additional Authenticated Data SHALL consist of the following
data, in this order:
o the 8-bit CoAP header field Code;
o all CoAP options present which are marked as IP and not marked
as E in Table 2 (see Appendix A), in the order as given by the
Option number (each Option with Option Header including delta to
previous such Option).
5.1.2.4 CoAP Message with Enc Option
An unprotected CoAP message is encrypted and integrity protected by
means of an Enc option and a SEM. The structure and format of the
protected CoAP message being sent instead of the unprotected CoAP
message is now described.
Selander, et al. Expires September 10, 2015 [Page 13]
INTERNET DRAFT Object Security for ACE March 9, 2015
The protected CoAP message is formatted as an ordinary CoAP message,
with the following Header, Options and Payload:
o The CoAP header SHALL be the same as the unprotected CoAP
message
o The CoAP options SHALL consist of the unencrypted options of the
unprotected CoAP message, and the Enc option. The options SHALL
be formatted as in a CoAP message (each Option with Options
Header including delta to previous unencrypted Option).
o If the unprotected CoAP message has no Payload then the Enc
option SHALL contain the SEM with Detached Content. If the
unprotected CoAP message has Payload, then the SEM option SHALL
be empty and the Payload of the CoAP message SHALL be the SEM
with Detached Content. The Payload is prefixed by the one-byte
Payload Marker (0xFF).
5.1.3 SM Tag
This section describes the SM Tag for Mode:COAP, which applies
both to SEM and SSM. The SM Tag is defined in 4.1.3. If the
message is a CoAP Request, then EAD SHALL be empty. If the
message is a CoAP Response, then EAD SHALL consist of the TID of
the associated CoAP Request.
5.2 Application Layer Protection
Referring to examples 1-3 in Section 2 and requirements a and b
in Section 3, the case of only protecting Payload sent in a
RESTful protocol using the Secure Message format is now
discussed. This is called Secure Message Mode:APPL.
The sending endpoint SHALL wrap the Payload, and the receiving
endpoint unwrap the Payload in the relevant SM format (SSM or
SEM) Mode:APPL. The SSM (SEM) SHALL be protected (encrypted)
and verified (decrypted) as described in 5.1.1.2 (5.1.2.2),
including replay protection as described in section 5.3.
NOTE: The explicit steps of the protection and verification
procedure will be included in a future version of this draft.
For Mode:APPL, the EAD SHALL be empty. Hence, the SM Tag is
calculated over the SM Header and SM Body.
A CoAP message where the Payload is wrapped as a Secure Message
Selander, et al. Expires September 10, 2015 [Page 14]
INTERNET DRAFT Object Security for ACE March 9, 2015
Mode:APPL object is indicated by setting the option Content-
Format to application/sm. A CoAP client may request a response
containing such a payload wrapping by setting the option Accept
to application/sm. (See Section 8.)
5.3 Replay Protection and Freshness
In order to protect from replay of messages and verify freshness
of responses, a CoAP endpoint SHALL maintain Transaction
Identifiers (TIDs) of sent and received Secure Messages (see
section 4.1.1).
5.3.1 Replay Protection
An endpoint supporting Secure Message SHALL maintain two TIDs
and associated security context/key(s) for each other endpoint
it communicates with, one TID for protecting sent messages, and
one TID for verifying the received messages. Depending on use
case, an endpoint MAY maintain a sliding receive window for
Sequence Numbers associated to TIDs in received messages,
equivalent to the functionality described in section 4.1.2.6 of
[RFC6347].
Before composing a new message a sending endpoint supporting
Secure Message SHALL step the Sequence Number of the associated
send TID and SHALL include it in the SM Header parameter
Sequence Number as defined in section 4.1.1. However, if the
Sequence Number counter wraps, the client must first acquire a
new TID and associated security context/key(s). The latter is
out of scope of this memo.
A receiving endpoint supporting Secure Message SHALL verify that
the Sequence Number received in the SM Header is greater than
the Sequence Number in the TID for received messages (or within
the sliding window and not previously received) and update the
TID (window) accordingly.
5.3.2 Freshness
If a CoAP server receives a valid Secure Message request in
Mode:COAP, then the response SHALL include the TID of the
request as EAD, as defined in section 5.1.3. If the CoAP client
receives a Secure Message response in Mode:COAP, then the client
SHALL verify the signature by reconstructing SM Body and using
the TID of its own associated request as EAD, as defined in
section 5.1.3.
Selander, et al. Expires September 10, 2015 [Page 15]
INTERNET DRAFT Object Security for ACE March 9, 2015
6. Security Considerations
In scenarios with proxies, gateways, or caching, DTLS only
protects data hop-by-hop meaning that all intermediary nodes can
read and modify information. The trust model where all
participating nodes are considered trustworthy is problematic
not only from a privacy perspective but also from a security
perspective as the intermediaries are free to delete resources
on sensors and falsify commands to actuators (such as "unlock
door", "start fire alarm", "raise bridge"). Even in the rare
cases where all the owners of the intermediary nodes are fully
trusted, attacks and data breaches make such an architecture
weak.
DTLS protects the entire CoAP message including Header, Options
and Payload, whereas this proposal only protects selected
message fields. DTLS, however, also incurs a large overhead
cost, e.g. due to the handshake procedure. While that cost can
be amortized in scenarios with long lived connections, in cases
where a device will have connections with varying clients, using
secured objects instead of session security can provide a
significant performance gain.
Secure Message Mode:COAP addresses point to point encryption,
integrity and replay protection, and freshness of response.
Payload as well as relevant options and header field Code are
protected. It is possible to define unique session keys to
enable perfect forward secrecy.
Secure Message Mode:APPL only protects payload and only gives
replay protection (not freshness), but this allows more use
cases such as point to multi-point including publish-subscribe,
reverse proxies and proxy caching of responses. In case of
symmetric keys the receiver does not get data origin
authentication, which requires a digital signature using a
private asymmetric key.
Using blockwise transfer [I-D.ietf-core-coap-block], the
integrity protection as provided by the method described here
only covers the individual blocks, not the entire request or
response. One way to handle this would to allow the Sig or Enc
option to be repeatable, and in one or several of the block
transfer carry a MAC or signature that covers the entire request
or response.
The Version header field is not integrity protected to allow
backwards compatibility with future versions of CoAP.
Considering this, it may in theory be possible to launch a
Selander, et al. Expires September 10, 2015 [Page 16]
INTERNET DRAFT Object Security for ACE March 9, 2015
cross-version attack, e.g. something analogously to a bidding
down attack. Future updates of CoAP would need to take this
into account.
The use of sequence numbers for replay protection introduces the
problem related to wrapping of the counter. The alternatives
also have issues: very constrained devices may not be able to
support accurate time or generate and store large numbers of
random nonces. The requirement to change key at counter wrap is
a complication, but it also forces the user of this
specification to think about implementing key renewal.
Independently of message format, and whether the target is
application layer protection or CoAP message protection, this
specification needs to be complemented with a procedure whereby
the client and the server establish the keys used for wrapping
and unwrapping the Secure Message. One way to address key
establishment is to assume that there is a trusted third party
which can support client and server, such as the Authorization
Server in [I-D.seitz-ace-problem-description]. The
Authorization Server may, for example, authenticate the client
on behalf of the server, or provide cryptographic keys or
credentials to the client and/or server which can be used in the
Secure Message exchange.
The security contexts required for SSM and SEM are different.
For a SSM, the security context is essentially Algorithm, Key
Identifier, Sequence Number and Key. For a SEM it is also
required to have a unique AEAD Initialization Vector for each
message. The AEAD Initialization Vector SHALL be the
concatenation of a Salt (8 bytes unsigned integer) and the
Sequence Number. The Salt SHOULD be established between sender
and receiver before the message is sent, to avoid the overhead
of sending it. For example, the Salt may be established by the
same means as the keys used to secure the protocol between the
sender and receiver. For a SEM, the security context is
essentially Algorithm, Key Identifier, Salt, Sequence Number and
Key.
NOTE: This last paragraph will be moved into the main document
in a future version of this draft.
7. Privacy Considerations
End-to-end integrity protection provides certain privacy
properties, e.g. protection of communication with sensor and
actuator from manipulation which may affect the personal sphere.
End-to-end encryption of payload and certain options provides
Selander, et al. Expires September 10, 2015 [Page 17]
INTERNET DRAFT Object Security for ACE March 9, 2015
additional protection as to the content and nature of the
message exchange.
The headers sent in plaintext allows for example matching of CON
and ACK (CoAP Message Identifier), matching of request and
response (Token). Plaintext options could also reveal
information, e.g. lifetime of measurement (Max-age), or that
this message contains one data point in a sequence (Observe).
8. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "[this
document]" with the RFC number of this specification.
The following entry is added to the CoAP Option Numbers
registry:
+--------+---------+-------------------+
| Number | Name | Reference |
+--------+---------+-------------------+
| TBD | Sig | [[this document]] |
+--------+---------+-------------------+
| TBD | Enc | [[this document]] |
+--------+---------+-------------------+
NOTE: IANA considerations for Mode is TBD
This document registers the following value in the CoAP Content
Format registry established by [RFC7252].
Media Type: application/sm
Encoding: -
Id: 70
Reference: [this document]
9. Acknowledgements
Klaus Hartke has independently been working on the same problem
and a similar solution: establishing end-to-end security across
proxies by adding a CoAP option. The authors would like to
Selander, et al. Expires September 10, 2015 [Page 18]
INTERNET DRAFT Object Security for ACE March 9, 2015
thank Francesca Palombini for contributing to the discussion and
giving helpful implementation input to the specification. We
are grateful to Malisa Vucinic for providing many helpful
comments.
10. References
10.1 Normative References
[I-D.ietf-jose-json-web-signature]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature
(JWS)", draft-ietf-jose-json-web-signature-41 (work in
progress), January 2015.
[I-D.ietf-jose-json-web-encryption]
Jones, M., and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption-40 (work in progress),
January 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012,
<http://www.rfc-editor.org/info/rfc6347>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
10.2 Informative References
[I-D.seitz-ace-problem-description]
Seitz, L., and G. Selander, "Problem Description for
Authorization in Constrained Environments", draft-seitz-
ace-problem-description-02 (work in progress), May 2015.
[I-D.ietf-ace-usecases]
Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
Kumar, "ACE use cases", draft-ietf-ace-usecases-02 (work
in progress), February 2015.
[I-D.bormann-jose-cose]
Bormann, C., "Constrained Object Signing and Encryption
Selander, et al. Expires September 10, 2015 [Page 19]
INTERNET DRAFT Object Security for ACE March 9, 2015
(COSE)", draft-bormann-jose-cose-00 (work in progress,
October 2014
[I-D.ietf-core-coap-block]
Bormann, C., and Z. Shelby, "Blockwise transfers in CoAP",
draft-ietf-core-block-17 (work in progress), March 2015.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, August 2007, <http://www.rfc-
editor.org/info/rfc4949>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009, <http://www.rfc-
editor.org/info/rfc5652>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content",
RFC 7231, June 2014, <http://www.rfc-
editor.org/info/rfc7231>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014, <http://www.rfc-
editor.org/info/rfc7258>.
Appendix A. Which CoAP Header Fields and Options to Protect
In the case of CoAP Message Protection (Mode:COAP) as much as
possible of the CoAP message is protected. However, not all CoAP
header fields or options can be encrypted and integrity protected,
because some are intended to be read or changed by an intermediary
node.
A.1 CoAP Header Fields
The CoAP Message Layer parameters, Type and Message ID, as well as
Token and Token Length may be changed by a proxy and thus SHALL
neither be integrity protected nor encrypted. Example 5 in Section 2
shows that the Code SHALL be integrity protected. The Version
parameter SHALL neither be integrity protected nor encrypted (see
Section 6).
A.2 CoAP Options
Selander, et al. Expires September 10, 2015 [Page 20]
INTERNET DRAFT Object Security for ACE March 9, 2015
This section describes what options need to be integrity protected
and encrypted. On a high level, all CoAP options must be encrypted
by default, unless intended to be read by an intermediate node; and
integrity protected, unless intended to be changed by an intermediate
node.
However, some special considerations are necessary because CoAP
defines certain legitimate proxy operations, because the security
information itself may be transported as an option, and because
different processing is performed for SSM and SEM.
A.2.1 Integrity Protection
As a general rule, CoAP options which are Safe-to-Forward SHALL be
integrity protected, with the only exception being Enc and Sig, which
are the security-providing options.
The Unsafe options are divided in two categories, those that are
intended to change in a way that can be reconstructed by the server,
and those which are not. The following options are of the latter
kind and SHALL NOT be integrity protected: Max-Age, Observe, Proxy-
Scheme. These options are intended to be changed by a proxy.
For options related to URI of resource (Uri-Host, Uri-Port, Uri-Path,
Uri-Query, Proxy-Uri) a Forward Proxy is intended to replace the Uri-
* options with the content of the Proxy-Uri option. These options
are Unsafe, but the Forward Proxy is intended to perform this precise
operation and we can use this predictability to integrity protect the
destination endpoint URI, even if the options where the information
elements of the URI is located is changed by the Proxy.
This memo makes the full URI located in option 35 (Proxy-Uri) into a
common denominator for the URI integrity, as described in the
following. The following processing applies to a SSM, for SEM see
next section:
o If there is a Proxy-Uri present, then the client MUST integrity
protect the Proxy-Uri option and the Uri-* options MUST NOT be
integrity protected.
o If there is no Proxy-Uri option present, then the client SHALL
compose the full URI from Uri-* options according to the method
described in section 6.5 of [RFC7252]. The SM Tag is calculated
on the following message, modified compared to what is sent:
o All Uri-* options removed
o A Proxy-Uri option with the full URI included
Selander, et al. Expires September 10, 2015 [Page 21]
INTERNET DRAFT Object Security for ACE March 9, 2015
The server SHALL compose the URI from the Uri-* options according to
the method described in section 6.5 of [RFC7252]. The so obtained
URI is placed into a Proxy-Uri option (no. 35), which is included in
the integrity verification.
A.2.2 Encryption
All CoAP options MUST be encrypted, except the options below which
MUST NOT be encrypted:
o Max-Age, Observe: This information is intended to be read by a
proxy.
o Enc, Sig: These are the security-providing options.
o Uri-Host, Uri-Port: This information can be inferred from
destination IP address and port.
o Proxy-Uri, Proxy-Scheme: This information is intended to be
read by a proxy.
In the case of a SEM, the Proxy-Uri MUST only contain Uri-Host and
Uri-Port and MUST NOT contain Uri-Path and Uri-Query because the
latter options are not intended to be revealed to a Forward Proxy.
A.2.3 Summary
Table 3 summarizes which options are encrypted and integrity
protected, if present.
In a SSM, options marked with "a" and "b" are composed into a URI as
described above and included as the Proxy-Uri option which is part of
the SSM Body. In a SEM, options marked "a" are composed into a URI
as described above and included as the Proxy-Uri option in the SEM
Additional Authenticated Data.
+-----+---+---+---+---+----------------+--------+--------+--------+
| No. | C | U | N | R | Name | Format | Length | E | IP |
+-----+---+---+---+---+----------------+--------+--------+--------+
| 1 | x | | | x | If-Match | opaque | 0-8 | x | x |
| 3 | x | x | - | | Uri-Host | string | 1-255 | | a |
| 4 | | | | x | ETag | opaque | 1-8 | x | x |
| 5 | x | | | | If-None-Match | empty | 0 | x | x |
| 6 | | x | - | | Observe | uint | 0-3 | | |
Selander, et al. Expires September 10, 2015 [Page 22]
INTERNET DRAFT Object Security for ACE March 9, 2015
| 7 | x | x | - | | Uri-Port | uint | 0-2 | | a |
| 8 | | | | x | Location-Path | string | 0-255 | x | x |
| 11 | x | x | - | x | Uri-Path | string | 0-255 | x | b |
| 12 | | | | | Content-Format | uint | 0-2 | x | x |
| 14 | | x | - | | Max-Age | uint | 0-4 | | |
| 15 | x | x | - | x | Uri-Query | string | 0-255 | x | b |
| 17 | x | | | | Accept | uint | 0-2 | x | x |
| 20 | | | | x | Location-Query | string | 0-255 | x | x |
| 35 | x | x | - | | Proxy-Uri | string | 1-1034 | | x |
| 39 | x | x | - | | Proxy-Scheme | string | 1-255 | | |
| 60 | | | x | | Size1 | uint | 0-4 | x | x |
+-----+---+---+---+---+----------------+--------+--------+--------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable,
E=Encrypt, IP=Integrity Protect.
Table 3: Protected CoAP options in Mode=COAP.
Appendix B. JOSE Objects as Secure Messages
This section shows how to extend JWS and JWE to Secure Message
formats (see Section 4.1). The use of compact serialization is
assumed.
B.1 JWS as Secure Signed Message
The JOSE Header of JWS contains the mandatory parameter "alg",
defined in Section 4.1.1 of [I-D.ietf-jose-json-web-signature], which
corresponds to the parameter Algorithm of the Secure Message.
A JWS is a Secure Message if the JOSE Header includes
o the Parameter "kid" defined in Section 4.1.4 of [I-D.ietf-jose-
json-web-signature];
o the new Parameter "seq" defined in B.3; and
o the new Parameter "mod" defined in B.4.
In case of JWS, a SSM with Detached Content consists of the JOSE
Header and JWS Signature; i.e. no JWS Payload.
B.2 JWE as Secure Encrypted Message
In case of JWE, the SM Header parameters of a JWE consists of the
JOSE Header Parameters and JWE Initialization Vector (IV).
Selander, et al. Expires September 10, 2015 [Page 23]
INTERNET DRAFT Object Security for ACE March 9, 2015
The JOSE Header of JWE contains the mandatory parameter "enc",
defined in Section 4.1.2 of [I-D.ietf-jose-json-web-encryption],
which corresponds to the parameter Algorithm of the Secure Message.
The JOSE Header also contains the mandatory parameter "alg", the key
encryption algorithm, which in the current version of the draft is
assumed to be equal to "dir" (constant). It is also assumed that
plaintext compression (zip) is not used.
A JWE is a Secure Message if the IV contains the SM Sequence Number,
and the JOSE Header includes
o the Parameter "kid" defined in Section 4.1.4 of [I-D.ietf-jose-
json-web-signature]; and
o the new Parameter "mod" defined in B.4.
The IV also contain a Salt (see Section 6). For JWE it is mandatory
to include the IV and hence the Salt is sent in each message.
In case of JWE, a SEM with Detached Content consists of JOSE Header,
JWE Initialization Vector, JWE Ciphertext and JWE Authentication Tag;
i.e. no JWE AAD.
B.3 "seq" (Sequence Number) Header Parameter
The Sequence Number SHALL be a 64-bit unsigned integer in hexadecimal
representation. Only the significant bytes are sent (initial bytes
with zeros are removed). The start sequence number SHALL be 0. For
a given key, any Sequence Number MUST NOT be used more than once.
The parameter "seq" SHALL be marked as critical using the "crit"
header parameter (see section 4.1.11 of [I-D.ietf-jose-json-web-
signature]), meaning that if a receiver does not understand this
parameter it must reject the message.
B.4 "mod" (Mode) Header Parameter
The Mode parameter SHALL be an 8-byte unsigned integer defining
application specific message format, content and processing. The
parameter "mod" SHALL be marked as critical. "mod":"0" indicates
Mode:APPL which is defined in Section 5.2. "mod":"1" indicates
Mode:COAP which is defined in Section 5.1.
B.4 The TID consists of the concatenation of SEQ and KID, in that order,
formatted as in the JOSE. For "seq" the initial bytes with zeros are
removed.
Selander, et al. Expires September 10, 2015 [Page 24]
INTERNET DRAFT Object Security for ACE March 9, 2015
Appendix C. Compact Secure Message
For constrained environments it is important that the message
expansion due to security overhead is kept at a minimum. As an
attempt to assess what this minimum expansion could be, an optimized
Secure Message format is defined, tailor-made for this setting. This
is intended as a benchmark for generic content formats, to allow an
informed decision about which Secure Message format to mandate in a
future version of this draft.
C.1 CSM Format
This section defines a compact Secure Message format (see Section
4.1) called the Compact Secure Message (CSM) format, see Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | ALG | KL | SL | KID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SEQ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Body ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Compact Secure Message format
The CSM Header (see Section 4.1.1.) consists of 2 bytes of fixed
length parameters and two variable length parameters, Key Identifier
(KID) and Sequence Number (SEQ). The Header parameters are (compare
Table 5):
o Mode (M). M=0 indicates Mode:APPL as defined in Section 5.2.
M=1 indicates Mode:COAP as defined in Section 5.1. M=2 and M=3
are reserved for future use.
o Algorithm (ALG). This parameter consists of an encoding of the
ciphersuite used in the Secure Message. The encoding is TBD.
o KID Length (KL). This parameter consist of a length indication
of the header parameter Key Identifier. The actual length of
KID is KL + 1 bytes.
o SEQ Length (SL). This parameter consist of a length indication
of the header parameter Sequence Number. The actual length of
Selander, et al. Expires September 10, 2015 [Page 25]
INTERNET DRAFT Object Security for ACE March 9, 2015
SEQ is SL + 1 bytes.
o Key Identifier (KID). This parameter identifies the key(s) used
to protect the Secure Message. Only the significant bytes are
sent (initial bytes with zeros are removed).
o Sequence Number (SEQ). This parameter consists of the sequence
number used by the sender of the Secure Message. Only the
significant bytes are sent (initial bytes with zeros are
removed).
+------+-------------------------+--------------------+
| Name | Parameter | Length |
+------+-------------------------+--------------------+
| M | Mode | 2 bits |
+------+-------------------------+--------------------+
| ALG | Algorithm | 6 bits |
+------+-------------------------+--------------------+
| KL | Key Identifier Length | 5 bits |
+------+-------------------------+--------------------+
| SL | Sequence Number Length | 3 bits |
+------+-------------------------+--------------------+
| KID | Key Identifier | KL + 1: 1-32 bytes |
+------+-------------------------+--------------------+
| SEQ | Sequence Number | SL + 1: 1-8 bytes |
+------+-------------------------+--------------------+
Table 5: CSM Header Parameters.
The minimum CSM Header is 4 bytes.
The TID consists of the concatenation of SEQ and KID, in that order,
formatted as in the CSM format (initial bytes with zeros are
removed).
The content of CSM Body depends on whether it is a SSM or a SEM (see
Section 4.1.2) which is determined by the Algorithm. This version of
the draft focuses on Secure Message with Detached Content. Hence,
the SSM Body is empty and the SEM Body consists of the Ciphertext.
In the former case, the length of the CSM Body is 0. In the latter
case, the length of the CSM Body equals the sum of the lengths of the
present CoAP options marked encrypted in Table 3 and the length of
the payload of the unprotected CoAP message.
The CSM Tag contains the MAC/Signature as determined from the
Algorithm. The length is determined by ALG.
Selander, et al. Expires September 10, 2015 [Page 26]
INTERNET DRAFT Object Security for ACE March 9, 2015
C.2 Comparison of Secure Message sizes
This section gives some examples of overhead incurred with JOSE, the
current proposal for COSE at the time of writing (00-draft), and CSM.
The goal is not to give exact measurements, but to help the reader
appreciate the rough order of magnitude of the overhead involved.
COSE seems to be the most promising approach and CSM should be viewed
as an attempt to define a lower bound for COSE.
The comparison is complicated further by the fact that algorithms
suitable for constrained environments are not supported by JOSE, and
thereby not by COSE. This comparison does not consider the
ciphertext or signed payload expansion due to Base64url encoding in
JWS/JWE. This would increase the overhead of JWS and JWE even more.
The size of the header is shown separately from the size of the
authentication tag, since JWS/JWE has no provisions for truncating
it, a feature that could easily be added to the JOSE specifications.
For CSM the encoding of certain additional algorithms is assumed and
this could also easily be added to COSE. An 8-byte kid is used
throughout all examples. Finally compact serialization for both JWS
and JWE is assumed.
SSM uses HMAC-SHA256, with truncation to 16 bytes.
For JWS the following header is used:
{"alg":"HS256", "kid":"a1534e3c5fdc09bd", "seq":"00000142",
"mod":"0"}
which encodes to a size of 90 bytes in Base64url, and the 32 bytes of
HS256 MAC encode to 43 bytes. The concatenation marks add 2 bytes to
that in the total overhead.
The same header in COSE, representing the "kid" as bytes (not as
string) and the "seq" as positive integer encodes to a size of 35
bytes, and the MAC would add to 32 bytes to that. Note that encoding
the header and the MAC together incurs an additional overhead of 3
bytes.
For CSM the same header is represented by 12 bytes. The MAC could in
this case safely be truncated to 16 bytes, and a corresponding
algorithm identifier would need to be defined in the list of
supported algorithms.
Table 6 summarizes these results.
Selander, et al. Expires September 10, 2015 [Page 27]
INTERNET DRAFT Object Security for ACE March 9, 2015
+--------+----------------+----------------+
| Scheme | Header | MAC | Total Overhead |
+--------+----------------+----------------+
| JWS | 90 B | 43 B | 135 bytes |
+--------+---------+------+----------------+
| COSE | 35 B | 32 B | 70 bytes |
+--------+---------------------------------+
| CSM | 12 B | 16 B | 28 bytes |
+--------+---------------------------------+
Table 6: Comparison of JWS, COSE, and CSM
For SEM the use of AES-128-CCM-8 would be ideal, but since this is
not supported by JOSE, AES-128-GCM is used there instead.
For JWE it is assumed that the IV is generated from the sequence
number and some previously agreed upon Salt. This means it is not
required to explicitly send the IV in the CSM format, but also that
the JWE and COSE formats can omit the sequence number.
The JWE header
{"alg":"dir", "kid":"a1534e3c5fdc09bd", "enc":"A128GCM", "mod":"0"}
encodes to a size of 86 bytes in Base64url, while the necessary 12
byte IV for GCM mode is expanded to 16 bytes by encoding. The 16
bytes of the authentication tag expand to 22 bytes. The
concatenation marks add 3 bytes to the total overhead.
In COSE the same header encodes to 40 bytes and the IV and
authentication tag could be represented as 12 and 16 bytes
respectively. Note that encoding the header, the IV and the
authentication tag together incurs an additional overhead of 2 bytes.
For CSM this tests uses CCM mode instead of GCM. CCM requires a 16
byte IV, but is better suited for constrained devices, and for CSM
there is no impact since the IV can be deduced from the sequence
number and a previously agreed upon Salt. The corresponding header
for AES-128-CCM-8, including the 8 byte sequence number, is
represented by 12 bytes.
Table 7 summarizes these results.
+--------+----------------+-------+----------------+
| Scheme | Header | IV | Tag | Total Overhead |
+--------+----------------+-------+----------------+
Selander, et al. Expires September 10, 2015 [Page 28]
INTERNET DRAFT Object Security for ACE March 9, 2015
| JWE | 86 B | 16 B | 22 B | 127 bytes |
+--------+---------+------+-------+----------------+
| COSE | 40 B | 12 B | 16 B | 70 bytes |
+--------+------------------------+----------------+
| CSM | 12 B | 0 B | 8 B | 20 bytes |
+--------+------------------------+----------------+
Table 7: Comparison of JWE, COSE, and CSM
Appendix D. Examples
This section gives examples of how to use the new options and message
formats defined in this memo.
D.1 CoAP Message Protection
This section illustrates the Secure Message Mode:COAP. The message
exchange assumes there is a security context established between
client and server. One key is used for each direction of the
message transfer. The intermediate node detects that the CoAP
message contains a SM Mode:COAP object (Sig or Enc option is set) and
thus forwards the message as it cannot serve a cached response.
D.1.1 Integrity protection of CoAP Message
Here is an example of a PUT request/response message exchange passing
an intermediate node protected with the Sig option. The example
illustrates a client opening a lock and getting a confirmation that
the lock is opened. Code, Uri-Path and Payload are integrity
protected (see Appendix A).
Client Proxy Server
| | |
| | |
| | |
+----->| | Code: 0.03 (PUT)
| PUT | | Token: 0x8c
| | | Uri-Path: lock
| | | Sig: SSM {"mod"="1","seq":"00000142",
| | | "kid":"a1534e3c5fdc09bd", ...}
| | | Payload: 1
| | |
| +----->| Code: 0.03 (PUT)
| | PUT | Token: 0x7b
| | | Uri-Path: lock
| | | Sig: SSM {"mod"="1","seq":"00000142",
Selander, et al. Expires September 10, 2015 [Page 29]
INTERNET DRAFT Object Security for ACE March 9, 2015
| | | "kid":"a1534e3c5fdc09bd", ...}
| | | Payload: 1
| | |
| | |
| |<-----+ Code: 2.04 (Changed)
| | 2.04 | Token: 0x7b
| | | Sig: SSM {"mod"="1","seq":"000000a6",
| | | "kid":"5fdc09bda1534e3c", ...}
| | |
|<-----+ | Code: 2.04 (Changed)
| 2.04 | | Token: 0x8c
| | | Sig: SSM {"mod"="1","seq":"000000a6",
| | | "kid":"5fdc09bda1534e3c", ...}
| | |
Figure 8: CoAP PUT protected with Sig/SSM (Mode:COAP)
The Key Identifier is a hint to the receiver indicating which
security context was used to integrity protect the message, and may
be used as an identifier for a secret key or a public key. (It may
e.g. be the hash of a public key.)
The server and client can verify that the Sequence Number has not
been received and used with this key before, and since Mode is COAP,
the client can additionally verify the freshness of the response,
i.e. that the response message is generated as an answer to the
received request message (see Section 5.3).
The SSM also contains the Tag as specified in the Algorithm (not
shown).
This example deviates from encryption (SEM) by default (see Section
6) just to illustrate the Sig option. If there is no compelling
reason why the CoAP message should be in plaintext, then the Enc
option must be used.
D.1.2 Encryption of CoAP Message
Here is an example of a GET request/response message exchange passing
an intermediate node protected with the Enc option. The example
illustrates a client requesting a blood sugar measurement resource
(GET /glucose) and receiving the value 220 mg/dl. Uri-Path and
Payload are encrypted and integrity protected. Code is integrity
protected only (see Appendix A).
Client Proxy Server
| | |
| | |
Selander, et al. Expires September 10, 2015 [Page 30]
INTERNET DRAFT Object Security for ACE March 9, 2015
| | |
+----->| | Code: 0.01 (GET)
| GET | | Token: 0x83
| | | Enc: SEM {"mod"="1","seq":"000015b7",
| | | "kid":"34e3c5fdca1509bd",
| | | ["glucose" ... ], ...}
| | |
| +----->| Code: 0.01 (GET)
| | GET | Token: 0xbe
| | | Enc: SEM {"mod"="1","seq":"000015b7",
| | | "kid":"34e3c5fdca1509bd",
| | | ["glucose" ... ], ...}
| | |
| | |
| |<-----+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe
| | | Enc:
| | | Payload: SEM {"mod"="1","seq":"000015b7",
| | | "kid":"c09bda155fd34e3c",
| | | [... 220], ...}
| | |
|<-----+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83
| | | Enc:
| | | Payload: SEM {"mod"="1","seq":"000015b7",
| | | "kid":"c09bda155fd34e3c",
| | | [... 220], ...}
| | |
Figure 9: CoAP GET protected with Enc/SEM (Mode:COAP).
The bracket [ ... ] indicates encrypted data.
Since the request message (GET) does not support payload, the SEM is
carried in the Enc option. Since the response message (Content)
supports payload, the Enc option is empty and the SEM is carried in
the payload.
The Key Identifier is a hint to the receiver indicating which
security context was used to encrypt and integrity protect the
message, and may be used as an identifier for the AEAD secret key.
One key is used for each direction of the message transfer.
The server and client can verify that the Sequence Number has not
been received and used with this key before, and since Mode:COAP the
client can additionally verify the freshness of the response, i.e.
that the response message is generated as an answer to the received
request message (see Section 5.3).
Selander, et al. Expires September 10, 2015 [Page 31]
INTERNET DRAFT Object Security for ACE March 9, 2015
The SEM also contains the Tag as specified by the Algorithm (not
shown).
D.2 Application Layer Protection
This section gives examples that illustrate Secure Message Mode:APPL.
This mode assumes that only the intended receiver(s) has the
relevant security context related to the resource.
D.2.1 Proxy Caching
This example outlines how a proxy forwarding request and response of
one client can cache a response whose payload is a SEM object, and
serve this response to another client request, such that both clients
can verify integrity and non-replay.
Client1 Proxy Server
| | |
| | |
+----->| | Code: 0.01 (GET)
| GET | | Token: 0x83
| | | Proxy-Uri: example.com/temp
| | |
| | |
| +----->| Code: 0.01 (GET)
| | GET | Token: 0xbe
| | | Uri-Host: example.com
| | | Uri-Path: temp
| | |
| | |
| |<-----+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe
| | | Payload: SEM {"mod"="0","seq":"000015b7",
| | | "kid":"c09bda155fd34e3c",
| | | ["471 F"], ...}
| | |
|<-----+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83
| | | Payload: SEM {"mod"="0","seq":"000015b7",
| | | "kid":"c09bda155fd34e3c",
| | ["471 F"], ...}
Client2 | |
| |
| | |
| | |
+----->| | Code: 0.01 (GET)
Selander, et al. Expires September 10, 2015 [Page 32]
INTERNET DRAFT Object Security for ACE March 9, 2015
| GET | | Token: 0xa1
| | | Proxy-Uri: example.com/temp
| | |
|<-----+ | Code: 2.05 (Content)
| 2.05 | | Token: 0xa1
| | | Payload: SEM {"mod"="0","seq":"000015b7",
| | | "kid":"c09bda155fd34e3c",
| | | ["471 F"], ...}
Figure 10: Proxy caching protected with SEM (Mode:APPL)
D.2.2 Publish-Subscribe
This example outlines a publish-subscribe setting where the payload
is integrity and replay protected end-to-end between Publisher and
Subscriber. The example illustrates a subscription registration and
a new publication of birch pollen count of 300 per cubic meters. The
PubSub Broker can define the Observe count arbitrarily (as could any
intermediary node, even in Mode:COAP), but cannot manipulate the
Sequence Number without being noticed.
Sub- PubSub- Publisher
scriber Broker
| | |
+----->| | Code: 0.01 (GET)
| GET | | Token: 0x72
| | | Uri-Path: ps
| | | Uri-Path: birch-pollen
| | | Observe: 0 (register)
| | |
| | |
|<-----+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x72
| | | Observe: 1
| | | Payload: SSM {"mod"="0","seq":"000015b7",
| | | "kid":"c09bda155fd34e3c",
| | | ["270"], ...}
| | |
| | |
| | |
| |<-----+ Code: 0.03 (PUT)
| | PUT | Token: 0x1f
| | | Uri-Path: ps
| | | Uri-Path: birch-pollen
| | | Payload: SSM {"mod"="0","seq":"000015b8",
Selander, et al. Expires September 10, 2015 [Page 33]
INTERNET DRAFT Object Security for ACE March 9, 2015
| | | "kid":"c09bda155fd34e3c",
| | | ["300"], ...}
| | |
| +----->| Code: 2.04 (Changed)
| | 2.04 | Token: 0x1f
| | |
| | |
|<-----+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x72
| | | Observe: 2
| | | Payload: SSM {"mod"="0","seq":"000015b8",
| | | "kid":"c09bda155fd34e3c",
| | | ["300"], ...}
Figure 11: Publish-subscribe protected with SSM (Mode:APPL)
This example deviates from encryption (SEM) by default (see Section
6) just to illustrate the SSM in Mode:APPL. If there is no
compelling reason why the payload should be in plaintext, then SEM
must be used.
D.2.3 Transporting Authorization Information
This example outlines the transportation of authorization information
from a node producing (Authorization Server, AS) to a node consuming
(Resource Server, RS) such information. Authorization information
may for example be an authorization decision with respect to a Client
(C) accessing a Resource to be enforced by RS. See Section 4.4-4.5
of [I-D.seitz-ace-problem-description].
Here, C is clearly not trusted with modifying the information, but
may need to be involved with mediating the authorization information
to the RS, for example, because AS and RS does not have direct
connectivity. So end-to-end security is required and object security
is a natural candidate (cf. "Access Tokens").
This example considers the authorization information to be
encapsulated in a SEM Mode:APPL object, generated by AS. How C
accesses the SSM is out of scope for this example, it may e.g. be
using CoAP. C then requests RS to configure the authorization
information in the SEM by doing PUT to /authorization. This
particular resource has a default access policy that only new
messages signed by AS are authorized. RS thus verifies the integrity
and sequence number by using the existing security context for the
AS, and responds accordingly, a) or b), see Figure 12.
Authz Resource
Server Client Server
Selander, et al. Expires September 10, 2015 [Page 34]
INTERNET DRAFT Object Security for ACE March 9, 2015
| | |
| | | Client access Access Token:
+- - ->| | SEM {"mod"="0","seq":"00000142",
| | | "kid":"c09bda1534e3c5fdc09bd", ...}
| | |
| | |
| +----->| Code: 0.03 (PUT)
| | PUT | Token: 0xac
| | | Uri-Path: authorization
| | | Payload: SEM {"mod"="0","seq":"00000142",
| | | "kid":"c09bda1534e3c5fdc09bd", ...}
a)
| | |
| |<-----+ Code: 2.04 (Changed)
| | 2.04 | Token: 0xac
| | |
b)
| | |
| |<-----+ Code: 4.01 (Unauthorized)
| | 4.01 | Token: 0xac
| | |
Figure 12: Protected Transfer of Access Token = SEM (Mode:APPL)
Authors' Addresses
Goeran Selander
Ericsson
Farogatan 6
16480 Kista
SWEDEN
EMail: goran.selander@ericsson.com
John Mattsson
Ericsson
Farogatan 6
16480 Kista
SWEDEN
EMail: john.mattsson@ericsson.com
Ludwig Seitz
SICS Swedish ICT AB
Scheelevagen 17
22370 Lund
SWEDEN
Selander, et al. Expires September 10, 2015 [Page 35]
INTERNET DRAFT Object Security for ACE March 9, 2015
EMail: ludwig@sics.se
Selander, et al. Expires September 10, 2015 [Page 36]