Object Security of CoAP (OSCOAP)
draft-selander-ace-object-security-03
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 , Francesca Palombini , Ludwig Seitz | ||
| Last updated | 2015-10-19 | ||
| Replaced by | draft-ietf-core-object-security, draft-ietf-core-object-security, RFC 8613 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-03
ACE Working Group G. Selander
Internet-Draft J. Mattsson
Intended status: Standards Track F. Palombini
Expires: April 21, 2016 Ericsson
L. Seitz
SICS Swedish ICT
October 19, 2015
Object Security of CoAP (OSCOAP)
draft-selander-ace-object-security-03
Abstract
This memo defines Object Security of CoAP (OSCOAP), a method for
protection of request and response message exchanges of the
Constrained Application Protocol (CoAP) using data object security.
OSCOAP provides end-to-end encryption, integrity and replay
protection to CoAP payload, options and header fields, and a secure
binding between CoAP request and response messages. The use of
OSCOAP is signaled with the Object-Security option, also defined in
this memo.
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 April 21, 2016.
Copyright 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
Selander, et al. Expires April 21, 2016 [Page 1]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Object-Security Option . . . . . . . . . . . . . . . . . 6
4. Secure Message Format . . . . . . . . . . . . . . . . . . . . 7
4.1. Secure Message Header . . . . . . . . . . . . . . . . . . 7
4.2. Secure Message Body and Tag . . . . . . . . . . . . . . . 8
4.2.1. Integrity Protection Only . . . . . . . . . . . . . . 8
4.2.2. Encryption and Integrity Protection . . . . . . . . . 8
5. CoAP Message Protection . . . . . . . . . . . . . . . . . . . 9
5.1. Integrity Protection Only . . . . . . . . . . . . . . . . 9
5.1.1. Protected CoAP message formatting . . . . . . . . . . 9
5.1.2. Secure Message formatting . . . . . . . . . . . . . . 10
5.1.3. Integrity Protection and Verification . . . . . . . . 10
5.2. Encryption and Integrity Protection . . . . . . . . . . . 10
5.2.1. Protected CoAP message formatting . . . . . . . . . . 10
5.2.2. Secure Message formatting . . . . . . . . . . . . . . 11
6. Protected CoAP Message Fields . . . . . . . . . . . . . . . . 12
6.1. Protected CoAP Header Fields . . . . . . . . . . . . . . 12
6.2. Protected CoAP Options . . . . . . . . . . . . . . . . . 12
6.2.1. Integrity Protection . . . . . . . . . . . . . . . . 13
6.2.2. Encryption . . . . . . . . . . . . . . . . . . . . . 15
7. Replay Protection and Freshness . . . . . . . . . . . . . . . 15
7.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 15
7.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. COSE Profile of SM . . . . . . . . . . . . . . . . . 21
A.1. Integrity Protection Only . . . . . . . . . . . . . . . . 21
A.1.1. COSE_Sign . . . . . . . . . . . . . . . . . . . . . . 21
A.1.2. COSE_mac . . . . . . . . . . . . . . . . . . . . . . 22
A.2. Encryption and Integrity Protection: COSE_enveloped . . . 22
A.3. COSE Optimizations . . . . . . . . . . . . . . . . . . . 23
Appendix B. Comparison of message sizes . . . . . . . . . . . . 25
Selander, et al. Expires April 21, 2016 [Page 2]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
B.1. MAC Only . . . . . . . . . . . . . . . . . . . . . . . . 26
B.2. Signature Only . . . . . . . . . . . . . . . . . . . . . 27
B.3. Authenticated Encryption with Additional Data (AEAD) . . 29
B.4. Symmetric Encryption with Asymmetric Signature (SEAS) . . 30
Appendix C. Object Security of Content (OSCON) . . . . . . . . . 32
C.1. Security Considerations of OSCON . . . . . . . . . . . . 33
Appendix D. Examples . . . . . . . . . . . . . . . . . . . . . . 34
D.1. CoAP Message Protection . . . . . . . . . . . . . . . . . 34
D.1.1. Integrity Protection of CoAP Message Exchange . . . . 34
D.1.2. Additional Encryption of CoAP Message . . . . . . . . 36
D.2. Payload Protection . . . . . . . . . . . . . . . . . . . 37
D.2.1. Proxy Caching . . . . . . . . . . . . . . . . . . . . 37
D.2.2. Publish-Subscribe . . . . . . . . . . . . . . . . . . 38
D.2.3. Transporting Authorization Information . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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 prominent features
of CoAP, store-and-forward and publish-subscribe exchanges, 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. 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 defines Object Security of CoAP (OSCOAP) a data object
based communication security solution complementing DTLS and
supporting secure messaging end-to-end across intermediary nodes.
OSCOAP may be used in very constrained settings where DTLS cannot be
supported. OSCOAP can also 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 message during transport between
end-point and intermediary node.
OSCOAP provides end-to-end encryption, integrity and replay
protection to CoAP payload, options and header fields, and a secure
binding between CoAP request and response messages. Using this
method the unprotected CoAP message is transformed into a protected
Selander, et al. Expires April 21, 2016 [Page 3]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
CoAP message, which contains a secure data object protecting the
unprotected message, and which is sent instead of the unprotected
message. The use of OSCOAP is signaled with the Object-Security
option, also defined in this memo.
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 [RFC4949]. These terms include, but are not limited to,
"authentication", "authorization", "confidentiality", "(data)
integrity", "message authentication code", and "verify". For
"signature", see below.
RESTful terms, such as "resource" or "representation", are to be
understood as used in HTTP [RFC7231] and CoAP.
Terminology for constrained environments, such as "constrained
device", "constrained-node network", is defined in [RFC7228].
Terminology for authentication and authorization in constrained
environments, such as "Authorization Server", "Resource Server", etc,
is defined in [I-D.ietf-ace-actors].
The CoAP option Object-Security and the Secure Message (SM) format
are defined in this memo.
Two different scopes of object security are defined:
o OSCOAP = object security of CoAP, signaled with the Object-
Security option
o OSCON = object security of content, signaled with Content Format/
Media Type set to application/oscon.
OSCON is defined in Appendix C and included for comparison with
OSCOAP.
The COSE message format is defined in [I-D.ietf-cose-msg].
Selander, et al. Expires April 21, 2016 [Page 4]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
2. Background
The background for this work is provided by the use cases and
architecture in [I-D.ietf-ace-usecases] and [I-D.ietf-ace-actors].
The focus of this memo is on end-to-end security in constrained
environments in the presence of intermediary nodes.
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.
Based on these examples the following security requirements have been
identified:
1. The payload shall be integrity protected and should be encrypted
end-to-end from sender to receiver.
2. It shall be possible for an intended receiver to detect if it has
received this message previously, i.e. replay protection.
3. The CoAP options which are not intended to be changed by an
intermediary node shall be integrity protected between Client and
Server.
4. The CoAP options which are not intended to be read by an
intermediary node shall be encrypted between Client and Server.
5. The CoAP header fields "Code" and "Version" shall be integrity
protected between Client and Server.
6. A Client shall be able to verify that a message is the response
to a particular request the Client made.
In this list above, requirements 1-2 deals essentially with
protecting the CoAP payload only, whereas 3-6 deals with protecting
an entire CoAP request-response exchange, including also CoAP options
and header fields.
Object Security of CoAP (OSCOAP), which is the main focus of this
memo, addresses all requirements above by defining a method for
Selander, et al. Expires April 21, 2016 [Page 5]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
encryption, integrity protection and replay protection of CoAP
payload, options and header fields, and a secure binding between CoAP
request and response messages. OSCOAP consists of:
o the Object-Security option, indicating that OSCOAP is being used;
o a compact cryptographic message format called "Secure Message",
based on the COSE message format ([I-D.ietf-cose-msg]); and
o a scheme for transforming an unprotected CoAP message into a
protected CoAP message, which contains the Object-Security option
and a Secure Message protecting CoAP payload, options and header
fields.
The same method can be applied to payload only of individual
messages, targeting only requirements 1-2 above. We call this object
security of content (OSCON) and it is defined in Appendix C.
Examples of the use of OSCOAP and OSCON are given in Appendix D.
3. The Object-Security Option
In order to end-to-end protect CoAP message exchanges including
options and headers, a new CoAP option is introduced: the Object-
Security option. The Object-Security option indicates that OSCOAP is
used, i.e. that certain CoAP Header fields, Options and Payload (if
present) are integrity and replay protected and potentially
encrypted, using a cryptographic message format called the Secure
Message format Section 4.
This option is critical, safe to forward, it is not part of a cache
key, and it is not repeatable. Figure 1 illustrates the structure of
this option.
+-----+---+---+---+---+-----------------+--------+--------+
| No. | C | U | N | R | Name | Format | Length |
+-----+---+---+---+---+-----------------+--------+--------|
| TBD | x | | x | | Object-Security | opaque | 0, TBD |
+-----+---+---+---+---+-----------------+--------+--------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Figure 1: The Object-Security Option
The length of the option depends on the specific choice of the Secure
Message format. Length 0 indicates that the Secure Message is the
CoAP Payload of the message, and is used when the CoAP message type
used supports payload.
Selander, et al. Expires April 21, 2016 [Page 6]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
4. Secure Message Format
There exist already standardized and draft content formats for
encryption and integrity protection of data such as CMS [RFC5652],
JWS [RFC7515], JWE [RFC7516], and COSE [I-D.ietf-cose-msg].
Current CMS and JWx objects are undesirably large for very
constrained devices. Large messages has a negative impact on memory
and storage in constrained devices, packet fragmentation in
constrained-node networks due to limited frame sizes, and increased
energy consumption due to more data transmission and reception. The
candidate for use with object security of CoAP messages is the COSE
message format [I-D.ietf-cose-msg].
Pending an optimized and stable version of the COSE message format
this memo defines the SM format to refer to a content format for
encrypted and integrity protected data, and also includes a unique
transaction identifier for replay protection. Appendix A shows a
profile of the COSE message format which complies with the Secure
Message format.
A Secure Message (SM) SHALL consist of Header, Body and Tag.
4.1. Secure Message Header
The following parameters SHALL be included in the SM Header:
o Context Identifier (CID). This parameter identifies the sender
security context including the cipher suite, key(s) and additional
algorithm specific parameters used to protect the message. Each
client and server communicating using OSCOAP has two contexts, one
for sending and one for receiving.
o Sequence Number (SEQ). The Sequence Number parameter enumerates
the Secure Messages sent associated to a Context 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.
The granularity of "sender" - what is being identified with the
Context Identifier - is defined by the application. With OSCOAP the
Context Identifier typically identifies the sending party and
different resources may be identified by the Uri-Path in the request.
(Compare Appendix C.)
The ordered sequence (SEQ, CID) is called Transaction Identifier
(TID), and SHALL be unique for each SM.
Selander, et al. Expires April 21, 2016 [Page 7]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
4.2. Secure Message Body and Tag
The use cases require support for two message types, one for
Encryption and Integrity Protection, and another for integrity
protection only. The SM Body and the SM Tag are different depending
on message type.
For Integrity Protection Only we denote by Authenticated Data (AD)
the data which is integrity protected in the Secure Message. For
Encryption and Integrity Protection we denote by Plaintext and
Additional Authenticated Data (AAD), the data which is encrypted and
integrity protected, and integrity protected only, respectively, in
the Secure Message.
The message type SHALL be explicit to allow an intermediate node to
distinguish between the two types and read the SM Body of an
Integrity Protected Only message.
4.2.1. Integrity Protection Only
In the case of integrity protection only, the SM Body SHALL consist
of the payload of the CoAP message.
The SM Tag SHALL consist of the Signature / Message Authentication
Code (MAC) as defined by the cipher suite calculated over the
Authenticated Data (AD). The AD for OSCOAP is defined in
Section 5.1.2.
4.2.2. Encryption and Integrity Protection
The use cases require support for two kinds of cipher suites:
Authenticated Encryption with Additional Data (AEAD) as well as
Symmetric Encryption and Asymmetric Signature (SEAS).
In case of AEAD, the SM Body and SM Tag SHALL consist of the
Ciphertext as defined by the cipher suite calculated over the
Plaintext and the Additional Authenticated Data (AAD).
In case of SEAS, the SM Body SHALL be the Ciphertext as defined by
the symmetric encryption algorithm, given by the cipher suite,
calculated over the Plaintext. The SM Tag SHALL be the Signature
defined by the cipher suite calculated over Ciphertext and AAD.
The Plaintext and the AAD for OSCOAP are defined in Section 5.2.2.
Selander, et al. Expires April 21, 2016 [Page 8]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
5. CoAP Message Protection
This section presents how OSCOAP protects individual CoAP messages
including payload, options and header fields, as well as request-
response message exchanges, using the Object-Security option
(Section 3) and the Secure Message format (Section 4).
The basic idea is that the significant parts of an unprotected CoAP
message - including payload, certain header field and options - are
protected using the Secure Message format and sent in a CoAP message
with the Object-Security option, in what we then call a "protected"
CoAP message. As much a possible of the CoAP message should be
protected, but 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, see Section 6.1 and Section 6.2.
The use of OSCOAP is signaled with the Object-Security option.
Endpoints supporting the Object-Security option MUST verify the SM as
described in this section before accepting a message as valid. An
endpoint receiving a CoAP request with the Object-Security option
MUST respond with a CoAP message with the Object-Security option.
The differences between Encryption and Integrity Protection vs
Integrity Protection Only is described below. Encryption and
Integrity Protection SHALL be used by default.
5.1. Integrity Protection Only
5.1.1. Protected CoAP message formatting
The protected CoAP message is formatted as an ordinary CoAP message,
with the following Header, Options and Payload based on the
unprotected CoAP message:
o The CoAP header SHALL be the same as the unprotected CoAP message.
o The CoAP options SHALL consist of the same options as the
unprotected CoAP message, and the Object-Security option.
o If the unprotected CoAP message has no Payload then the Object-
Security option SHALL contain the SM. If the unprotected CoAP
message has Payload, then the Object-Security option SHALL be
empty and the Payload of the CoAP message SHALL be the SM.
Selander, et al. Expires April 21, 2016 [Page 9]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
5.1.2. Secure Message formatting
The SM Header, Body and Tag are specified in Section 4.1 and
Section 4.2.
The Authenticated Data SHALL consist of the following data, in this
order:
o the SM Header;
o the two first bytes of the CoAP header (including Version and
Code) with Type and Token Length bits set to 0;
o all CoAP options present which are marked as IP in Figure 2
(Section 6.2), in the order as given by the option number (each
Option with Option Header including delta to previous IP-marked
Option which is present);
o the CoAP Payload (if any); and
o the Transaction Identifier of the associated CoAP Request, if the
message is a CoAP Response (see Section 4.1).
5.1.3. Integrity Protection and Verification
A CoAP endpoint protecting a CoAP message with the Object-Security
option using a cipher suite for integrity protection only SHALL
generate a protected CoAP message and SM based on the unprotected
CoAP message as described in Section 5.1.1 and Section 5.1.2. In
addition, the sending endpoint SHALL process the Sequence Number as
described in Section 7.
A CoAP endpoint receiving a message containing the Object-Security
option SHALL first recreate the Authenticated Data as described in
Section 5.1.2, and then verify the SM Tag as defined by the cipher
suite associated to the Context Identifier. In addition, the
receiving endpoint SHALL process the Sequence Number as described in
Section 7.
5.2. Encryption and Integrity Protection
5.2.1. Protected CoAP message formatting
The protected CoAP message is formatted as an ordinary CoAP message,
with the following Header, Options and Payload based on the
unprotected CoAP message:
o The CoAP header SHALL be the same as the unprotected CoAP message.
Selander, et al. Expires April 21, 2016 [Page 10]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
o The CoAP options SHALL consist of the unencrypted options of the
unprotected CoAP message (those not marked as E in Figure 2
(Section 6.2)), and the Object-Security 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 Object-
Security option SHALL contain the SM. If the unprotected CoAP
message has Payload, then the Object-Security option SHALL be
empty and the Payload of the CoAP message SHALL be the SM.
5.2.2. Secure Message formatting
The SM Header, Body and Tag are specified in Section 4.1 and
Section 4.2.
The Additional Authenticated Data SHALL consist of the following
data, in this order:
o the SM Header;
o the two first bytes of the CoAP header (including Version and
Code) with Type and Token Length bits set to 0;
o all CoAP options present which are marked as IP but not marked as
E in Figure 2 (Section 6.2), 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 Transaction Identifier of the associated CoAP Request, if the
message is a CoAP Response (see Section 4.1).
The 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 Figure 2 (see
Section 6.2), 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).
5.2.2.1. Encryption and Decryption
A CoAP endpoint protecting a CoAP message with the Object-Security
option using a cipher suite for encryption and integrity protection
SHALL generate a protected CoAP message and SM based on the
Selander, et al. Expires April 21, 2016 [Page 11]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
unprotected CoAP message as described in Section 5.2.1 and
Section 5.2.2. In addition, the sending endpoint SHALL process the
Sequence Number as described in Section 7.
A CoAP endpoint receiving a message containing the Object-Security
option SHALL recreate the Additional Authenticated Data as described
in Section 5.1.2 and verify the integrity of, and decrypt the message
as defined by the cipher suite associated to the Context Identifier.
In addition, the receiving endpoint SHALL process the Sequence Number
as described in Section 7.
6. Protected CoAP Message Fields
The CoAP payload SHALL be integrity protected. The CoAP payload
SHOULD be encrypted by default.
How CoAP Options and Header Fields shall be protected is described in
the remainder of this section.
6.1. Protected CoAP Header Fields
This section describes which CoAP header fields are encrypted or
integrity protected end-to-end in OSCOAP.
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.
The Version and Code fields SHALL be integrity protected, see
security considerations.
6.2. Protected CoAP Options
This section describes which CoAP options are encrypted and integrity
protected, if present in the unprotected CoAP message.
All CoAP options SHALL be encrypted by default, unless intended to be
read by an intermediate node; and SHALL be 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 depending on whether encryption is
applied or not.
The details are presented in Section 6.2.1 and Section 6.2.2, and
summarized in Figure 2.
Selander, et al. Expires April 21, 2016 [Page 12]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
+-----+---+---+---+---+----------------+--------+--------+---+----+
| 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 | | |
| 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 |
| 23 | x | x | - | | Block2 | uint | 0-3 | | |
| 27 | x | x | - | | Block1 | uint | 0-3 | | |
| 28 | | | x | | Size2 | uint | 0-4 | x | x |
| 35 | x | x | - | | Proxy-Uri | string | 1-1034 | | i |
| 39 | x | x | - | | Proxy-Scheme | string | 1-255 | | i |
| 60 | | | x | | Size1 | uint | 0-4 | x | x |
+-----+---+---+---+---+----------------+--------+--------+---+----+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable,
E=Encrypt, IP=Integrity Protect.
Figure 2: Protected CoAP options in OSCOAP
CoAP options marked "i" indicate that they are used as invariants in
the authenticated data (AD/AAD) as described in Section 6.2.1.1 and
Section 6.2.1.2.
In case of Integrity Protection Only, options marked with "a" and "b"
are composed into a URI as described in Section 6.2.1.2 and included
as invariant in the Proxy-Uri option in the Authenticated Data.
In case of Encryption and Integrity Protection, options marked "a"
are composed into a URI as described in Section 6.2.2 and included as
the Proxy-Uri option in the Additional Authenticated Data. (Options
marked "b" are included in the Plaintext.)
6.2.1. Integrity Protection
CoAP options which are not intended to be changed by an intermediate
node MUST be integrity protected.
o CoAP options of the unprotected message which are Safe-to-Forward
SHALL be integrity protected. See Figure 2.
Selander, et al. Expires April 21, 2016 [Page 13]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
Note: The Object-Security option in itself is Safe-to-Forward but is
added to the protected message.
CoAP options which are intended to be modified by a proxy can be
divided into two categories, those that are intended to change in a
predictable way, and those which are not. The following options are
of the latter kind and SHALL NOT be integrity protected:
o Max-Age, Observe, Block1, Block2: These options may be modified by
a proxy in a way that is not predictable for client and server.
The remaining options may be modified by a proxy, but when they are,
the change is predictable. Therefore it is possible to define
"invariants" which can be integrity protected.
6.2.1.1. Proxy-Scheme
A Forward Proxy is intended to replace the URI scheme with the
content of the Proxy-Scheme option. The Proxy-Scheme option is
defined in this memo to be an invariant with respect to the following
processing
o If there is a Proxy-Scheme present in the unprotected message,
then the client SHALL integrity protect the Proxy-Scheme option.
o If there is no Proxy-Scheme option present the client SHALL
include the Proxy-Scheme option in the authenticated data (AD/AAD)
set to the URI scheme. (The sent message does not include the
Proxy-Scheme option.)
o The server SHALL insert the Proxy-Scheme option with the name of
the URI scheme the message was received in the authenticated data
(AD/AAD).
6.2.1.2. Uri-*
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.
The Proxy-Uri option is defined in this memo to be an invariant with
respect to the following processing (applied to Integrity Protection
only, for Encryption 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.
Selander, et al. Expires April 21, 2016 [Page 14]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
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 Authenticated Data
contains the following options, modified compared to what is sent:
o All Uri-* options removed
o A Proxy-Uri option with the full URI included
o 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, which is included
in the Authenticated Data.
6.2.2. Encryption
All CoAP options MUST be encrypted, except the options below which
MUST NOT be encrypted:
o Max-Age, Observe, Block1, Block2, Proxy-Uri, Proxy-Scheme: This
information is intended to be read by a proxy.
o Uri-Host, Uri-Port: This information can be inferred from
destination IP address and port.
o Object-Security: This is the security-providing option.
In the case of encryption, the Proxy-Uri of the Additional
Authenticated Data MUST only contain Uri-Host and Uri-Port and MUST
NOT contain Uri-Path and Uri-Query because the latter options are not
necessarily available to a Forward Proxy.
7. Replay Protection and Freshness
In order to protect from replay of messages and verify freshness of
responses, a CoAP endpoint using object security SHALL maintain
Sequence Numbers (SEQs) of sent and received Secure Messages (see
Section 4.1), associated to the respective security context
identified with the Context Identifier (CID).
7.1. Replay Protection
An endpoint SHALL maintain a SEQ for each security context it uses to
receive messages, and one SEQ for each security context for
protecting sent messages. Depending on use case, an endpoint MAY
maintain a sliding receive window for Sequence Numbers in received
messages associated to each CID, equivalent to the functionality
described in section 4.1.2.6 of [RFC6347].
Selander, et al. Expires April 21, 2016 [Page 15]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
Before composing a new message a sending endpoint SHALL step the SEQ
of the associated CID. However, if the Sequence Number counter
wraps, the endpoint must first acquire a new CID and associated
security context/key(s). The latter is out of scope of this memo.
A receiving endpoint SHALL verify that the Sequence Number received
in the SM Header is greater than the Sequence Number of the
associated CID (or within the sliding window and not previously
received) and update the SEQ (window) accordingly.
7.2. Freshness
OSCOAP is a challenge-response protocol, where the response is
verified to match a prior request by including the unique transaction
identifier TID (concatenation of SEQ and CID) of the request in the
integrity calculation of the response message.
If a CoAP server receives a request with the Object-Security option,
then the authenticated data (AD or AAD) of the response SHALL include
the TID of the request as described in Section 5.1.2 and
Section 5.2.2.
If the CoAP client receives a response with the Object-Security
option, then the client SHALL verify the integrity of the response
using the TID of its own associated request in the authenticated data
(AD or AAD) as described in Section 5.1.2 and Section 5.2.2.
8. Security Considerations
In scenarios with proxies, gateways, or caching, DTLS only protects
data hop-by-hop meaning that these 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 OSCOAP protects the payload and message fields
described in Section 6.1 and Section 6.2. The cost for DTLS
providing this protection is the overhead in e.g. additional
messages, processing, memory incurred by the DTLS Handshake protocol,
which can be omitted in use cases where key establishment can be
provided by other means.
Selander, et al. Expires April 21, 2016 [Page 16]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
CoAP specifies how messages should be acknowledged on message layer.
The CoAP message layer, however, cannot be protected by application
layer security end-to-end since the parameters Type and Message ID,
as well as Token and Token Length may be changed by a proxy.
Moreover, messages that are not possible to verify should for
security reasons not always be acknowledged but in some cases be
silently dropped. This would not comply with CoAP message layer, but
does not have an impact on the object security solution, since
message layer is excluded from that.
The CoAP Header field Code needs to be integrity protected end-to-
end. For example, if a malicous man-in-the-middle would replace the
client requested GET with a DELETE, this must be detected by the
server. The CoAP Header field Version needs also to be integrity
protected to prevent from potential cross-version attacks, such as
bidding-down.
Blockwise transfers as defined [I-D.ietf-core-block] cannot be
protected with application layer security end-to-end because the
Block1/Block2 options may be changed in an unpredictable way by an
intermediate node.
However, it is possible to define end-to-end block options analogous
to Block1 and Block2 which are safe-to-forward, integrity protected
and not supposed to be changed by intermediate devices. With such an
option each individual block can be securely verified by the
receiver, retransmission securely requested etc. Since the blocks
are enumerated sequentially and carry information about last block,
when all blocks have been securely received, this proves that the
entire message has been securely transferred.
The Observe option cannot be integrity protected since it is allowed
to change in an unpredictable way. But since message sequence
numbers are integrity protected a client
can verifies that a GET response has not been received before.
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.
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
Selander, et al. Expires April 21, 2016 [Page 17]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
client and server, such as the Authorization Server in
[I-D.ietf-ace-actors]. 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 use to derive the keys used in the Secure Message exchange.
Similarly, the Authorization Server may, on behalf of the server,
notify the client of server supported ciphers, in order to facilitate
the usage of OSCOAP in deployments with multiple supported
cryptographic algorithms.
The security contexts required are different for different cipher
suites. For an AEAD or SEAS it is required to have a unique
Initialization Vector for each message, for which the Sequence Number
is used. The Initialization Vector SHALL be the concatenation of a
Salt (4 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 in each message. For
example, the Salt may be established by the same means as keys are
established.
9. 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 CoAP options provides additional
protection as to the content and nature of the message exchange.
The headers sent in plaintext allow 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).
10. 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 | Object-Security | [[this document]] |
+--------+-----------------+-------------------+
Selander, et al. Expires April 21, 2016 [Page 18]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
This document registers the following value in the CoAP Content
Format registry established by [RFC7252].
Media Type: application/oscon
Encoding: -
Id: 70
Reference: [this document]
11. Acknowledgments
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. We are grateful to Malisa Vucinic for
providing helpful and timely reviews of new versions of the draft.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<http://www.rfc-editor.org/info/rfc7516>.
Selander, et al. Expires April 21, 2016 [Page 19]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
12.2. Informative References
[I-D.ietf-ace-actors]
Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
architecture for authorization in constrained
environments", draft-ietf-ace-actors-02 (work in
progress), September 2015.
[I-D.ietf-ace-usecases]
Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
Kumar, "ACE use cases", draft-ietf-ace-usecases-09 (work
in progress), October 2015.
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP",
draft-ietf-core-block-18 (work in progress), September
2015.
[I-D.ietf-cose-msg]
Schaad, J. and B. Campbell, "CBOR Encoded Message Syntax",
draft-ietf-cose-msg-05 (work in progress), September 2015.
[I-D.seitz-ace-core-authz]
Seitz, L., Selander, G., and M. Vucinic, "Authorization
for Constrained RESTful Environments", draft-seitz-ace-
core-authz-00 (work in progress), June 2015.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, DOI 10.17487/
RFC7228, 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, DOI
10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
Selander, et al. Expires April 21, 2016 [Page 20]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
Appendix A. COSE Profile of SM
This section defines a profile of the 05-version of COSE
[I-D.ietf-cose-msg] complying with the Secure Message format (see
Section 4) and supporting the two scopes of object security OSCOAP
and OSCON (Appendix C). In the last subsection we elaborate on
possible optimizations.
o The "COSE_MSG" top level object as defined in COSE corresponds to
the Secure Message object.
o The "msg_type" parameter corresponds to the Secure Message type,
as defined in Section 4.2. Depending on the use case, this field
can take the values msg_type_mac, msg_type_signed or
msg_type_encryptData.
o The "Header" field of the COSE object corresponds to the Header
field of the Secure Message.
* The "protected" field includes:
+ the new "seq" parameter corresponding to the parameter
Sequence Number of the Secure Message (see Section 4.1).
* The "unprotected" field is empty.
A.1. Integrity Protection Only
When Integrity Protection only needs to be provided, the Secure
Message object corresponds to a COSE_MSG with msg_type equal to
msg_type_signed (COSE_Sign) or msg_type_mac (COSE_mac).
The Externally Supplied Data ("external_aad" field), as defined in
Section 4.1 of [I-D.ietf-cose-msg] include the Authenticated Data as
defined in Section 5.1.2 with the exception of SM Header and CoAP
Payload.
A.1.1. COSE_Sign
A COSE_MSG of type COSE_Sign is a Secure Message if its fields are
defined as follows (see example in Appendix B.2).
The "Headers" field of COSE_Sign as defined in Appendix A.
The "payload" field contains the CoAP Payload (if any).
The "signatures" array contains one "COSE_signature" item. The
"Headers" field of the COSE_signature object is defined as follows:
Selander, et al. Expires April 21, 2016 [Page 21]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
o The "protected" field includes:
* the new "cid" parameter which corresponds to the parameter
Context Identifier of the Secure Message (see Section 4.1);
o The "unprotected" field is empty.
The "signature" field contains the computed signature value as
described in Section 4.2 of [I-D.ietf-cose-msg].
A Secure Message with digital signature and Detached Content
corresponds to COSE_sign with "Headers" and "signatures" fields; i.e.
no "payload" field.
A.1.2. COSE_mac
A COSE_MSG of type COSE_mac is a Secure Message if its fields are
defined as follows (see example in Appendix B.1).
The "Headers" field of COSE_mac as defined in Appendix A.
The "payload" field contains the CoAP Payload (if any).
The "tag" field contains the MAC value, computed as defined in
Section 6.1 of [I-D.ietf-cose-msg].
The "recipients" array contains one "COSE_recipient" item (section 5
of [I-D.ietf-cose-msg]). The "COSE_recipient" item contains one
"COSE_encrypt_fields" object. The "Headers" field of the
COSE_encrypt_fields object is defined as follows:
o The "protected" field includes:
* the new "cid" parameter which corresponds to the parameter
Context Identifier of the Secure Message (see Section 4.1);
o The "unprotected" field is empty.
A Secure Message with MAC and Detached Content corresponds to a
COSE_sign with "Headers", "recipients" and "tag" fields; i.e. no
"payload" field.
A.2. Encryption and Integrity Protection: COSE_enveloped
When Encryption and Integrity Protection need to be provided, the
Secure Message object corresponds to a COSE_MSG with msg_type equal
to msg_type_enveloped (COSE_enveloped).
Selander, et al. Expires April 21, 2016 [Page 22]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
The Additional Authenticated Data ("Enc_structure") as described is
Section 5.3 of [I-D.ietf-cose-msg] is defined in Section 5.2.2: * the
"protected" parameters includes the SM Header; * the "external_aad"
includes the other fields (CoAP Version, Code, Options to integrity
protect and TID).
The plain text, as mentioned in Sections 5.3 and 5.4 of
[I-D.ietf-cose-msg] is defined in Section 5.2.2 and contains CoAP
Options to encrypt and the CoAP Payload.
A COSE_MSG of type COSE_enveloped [I-D.ietf-cose-msg] is a Secure
Message if its fields are defined as follows (see example in
Appendix B.3).
The "Headers" field of COSE_encrypt_fields item as defined in
Appendix A.
The "ciphertext" field is encoded as a nil type, following the
specifications in Section 5.1 of [I-D.ietf-cose-msg].
The "recipients" array contains one "COSE_recipient" item
(Section 5.1 of [I-D.ietf-cose-msg]). The "COSE_recipient" item
contains one "COSE_encrypt_fields" object. The "Headers" field of
the COSE_encrypt_fields object is defined as follows:
o The "protected" field includes:
* the new "cid" parameter which corresponds to the parameter
Context Identifier of the Secure Message (see Section 4.1);
o The "unprotected" field is empty.
The "ciphertext" field of the COSE_encrypt_fields object contains the
encrypted plain text, as defined in section 5 of [I-D.ietf-cose-msg].
A.3. COSE Optimizations
For constrained environments it is important that the message
expansion due to security overhead is kept at a minimum.
This section lists potential optimizations of COSE
[I-D.ietf-cose-msg] for the purpose of reducing message size and
improving performance in constrained node networks. The message
sizes resulting from the first four optimizations are presented in
Appendix B (as "modified COSE").
1. The first improvement proposed is to flatten the structure of the
COSE_msg, following the Encrypted COSE structure defined in
Selander, et al. Expires April 21, 2016 [Page 23]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
Section 5.2 of [I-D.ietf-cose-msg]. In fact, there is little
need to support multiple signatures or recipients in the use
cases targeting the most constrained devices. Two different
structures inspired by the COSE_encryptData are defined: COSE_ip
and COSE_en. COSE_ip is used for the Integrity Protection Only
use case (Section 5.1), COSE_en is used for Encryption
(Section 5.2).
2. In general, the security context defines uniquely the cipher
suite, and hence the "alg" parameter of COSE_msg can be removed.
3. The "unprotected" field is not used since it is assumed that all
parameters should be protected when possible. Thus the "Headers"
structure can be flattened into a "protectedHeader" field,
containing the "cid" parameter and the "seq" parameter.
4. Analogous to other key values, one-byte keys/labels can be
assigned to the new parameters defined in this document and
cipher suites adapted to constrained device processing. For
example: "cid" = 11 and "seq" = 12.
5. Digitally signed messages have the largest absolute overhead due
to the size of the signature (see Appendix B.2 and Appendix B.4).
Whereas certain MACs can be securely truncated, signatures
cannot. Signature schemes with message recovery allow some
remedy since they allow part of the message to be recovered from
the signature itself and thus need not be sent. The effective
size of the signature could in this way be considerably reduced,
which would have a large impact on the message size (compare size
of signature and total overhead in Figure 5 and Figure 6). A
valuable optimization would thus be to support signature schemes
with message recovery.
Combining the first 4 points, the resulting structures and their
fields are defined as follows: COSE_ip top level object corresponds
to the Secure Message object.
o The "msg_type" parameter takes a new value,
msg_type_integrityprotection=5.
o The "protectedHeader" field, analogous to the "protected" field of
the "Headers", includes:
* the new "cid" parameter which corresponds to the parameter
Context Identifier of the Secure Message (see Section 4.1);
* the new "seq" parameter corresponding to the parameter Sequence
Number of the Secure Message (see Section 4.1).
Selander, et al. Expires April 21, 2016 [Page 24]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
o The "payload" field (as described in Appendix A.1.1 and
Appendix A.1.2).
o The "tag" field (as described in Appendix A.1.1 and
Appendix A.1.2).
COSE_en top level object corresponds to the Secure Message object.
o The "msg_type" parameter takes a new value, msg_type_encryption=6.
o The "protectedHeader" field, analogous to the "protected" field of
the "Headers", includes:
* the new "cid" parameter which corresponds to the parameter
Context Identifier of the Secure Message (see Section 4.1);
* the new "seq" parameter corresponding to the parameter Sequence
Number of the Secure Message (see Section 4.1).
o The "ciphertext" field (as described in Appendix A.2).
o The "tag" field contains the tag value in case Integrity
Protection is also provided.
Appendix B. Comparison of message sizes
This section gives some examples of overhead incurred with the
current proposal for COSE at the time of writing [I-D.ietf-cose-msg].
Message sizes are also listed for a modified version of COSE
implementing some of the optimizations described in Appendix A.3 and
for a lower bound CBOR encoding of the Secure Message with structure
[seq, cid, body, tag].
Motivated by the use cases, there are four different kinds of
protected messages that need to be supported: message authentication
code, digital signature, authenticated encryption, and symmetric
encryption + digital signature. The latter is relevant e.g. for
proxy-caching and publish-subscribe with untrusted intermediary (see
Appendix D.2). The sizes estimated for selected algorithms are
detailed in the subsections.
The size of the header is shown separately from the size of the MAC/
signature. An 8-byte Context Identifier and a 3-byte Sequence Number
are used throughout all examples, with these value:
o cid: 0xa1534e3c5fdc09bd
o seq: 0x112233
Selander, et al. Expires April 21, 2016 [Page 25]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
For each scheme, we indicate the fixed length of these two parameters
("seq+cid" column) and of the tag ("MAC"/"SIG"/"TAG"). The "Total
Size" column shows the total Secure Message size, while the
"Overhead" column is calculated from the previous columns following
this equation:
Overhead = Total Size - (MAC + seq+cid)
This means that overhead incurring from CBOR encoding is also
included in the Overhead count.
To make it easier to read, COSE objects are represented using CBOR's
diagnostic notation rather than a binary dump.
B.1. MAC Only
This example is based on HMAC-SHA256, with truncation to 16 bytes.
The object in COSE encoding gives:
[
3, # msg_type
h'a201046373657143112233', # protected:
{1: 4,
"seq": h'112233'}
{}, # unprotected
h'', # payload
MAC, # truncated 16-byte MAC
[ # recipients
[ # recipient structure
h'', # protected
{1:-6, "cid":h'a1534e3c5fdc09bd'}, # unprotected
h'' # ciphertext
]
]
]
The COSE object encodes to a total size of 53 bytes.
In the modified version of COSE defined in Appendix A.3, the
equivalent COSE object would be:
Selander, et al. Expires April 21, 2016 [Page 26]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
[
5, # msg_type
h'a20b48a1534e3c5fdc09bd0c43112233', # protected:
{11:h'a1534e3c5fdc09bd',
12:h'112233'}
h'', # payload
MAC # truncated 16-byte MAC
]
This modified COSE object encodes to a total size of 37 bytes.
The low-bound CBOR encoding of this same object is encoded by:
[
h'112233', # seq
h'a1534e3c5fdc09bd', # cid
h'', # payload
MAC # truncated 16-byte MAC
]
This object encodes to a total size of 32 bytes.
Figure 3 summarizes these results.
+--------+---------+------+------------+----------+
| Scheme | seq+cid | MAC | Total Size | Overhead |
+--------+---------+------+------------+----------+
| COSE | 11 B | 16 B | 53 bytes | 26 bytes |
+--------+---------+------+------------+----------+
|mod-COSE| 11 B | 16 B | 37 bytes | 10 bytes |
+--------+---------+------+------------+----------+
| bound | 11 B | 16 B | 32 bytes | 5 bytes |
+--------+---------+------+------------+----------+
Figure 3: Comparison of COSE, modified COSE and CBOR lower bound for
HMAC-SHA256.
B.2. Signature Only
This example is based on ECDSA, with a signature of 64 bytes.
The object in COSE encoding gives:
Selander, et al. Expires April 21, 2016 [Page 27]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
[
1, # msg_type
h'a16373657143112233', # protected:
{"seq": h'112233'}
{}, # unprotected
h'', # payload
[ # signatures
[ # signature structure
h'a201266363696448a1534e3c5fdc09bd', # protected:
{1: -7,
"cid":h'a1534e3c5fdc09bd'}
{}, # unprotected
SIG # 64-byte signature
]
]
]
The COSE object encodes to a total size of 100 bytes.
In the modified version of COSE defined in Appendix A.3, the
equivalent COSE object would be:
[
5, # msg_type
h'a20b48a1534e3c5fdc09bd0c43112233', # protected:
{11:h'a1534e3c5fdc09bd',
12:h'112233'}
h'', # payload
SIG # 64-byte signature
]
The COSE object encodes to a total size of 86 bytes.
The low-bound CBOR encoding of this same object is encoded by:
[
h'112233', # seq
h'a1534e3c5fdc09bd', # cid
h'', # payload
SIG # 64-byte signature
]
This object encodes to a total size of 81 bytes.
Figure 4 summarizes these results.
Selander, et al. Expires April 21, 2016 [Page 28]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
+--------+---------+------+------------+----------+
| Scheme | seq+cid | SIG | Total Size | Overhead |
+--------+---------+------+------------+----------+
| COSE | 11 B | 64 B | 100 bytes | 25 bytes |
+--------+---------+------+------------+----------+
|mod-COSE| 11 B | 64 B | 86 bytes | 11 bytes |
+--------+---------+------+------------+----------+
| bound | 11 B | 64 B | 81 bytes | 6 bytes |
+--------+---------+------+------------+----------+
Figure 4: Comparison of COSE, modified COSE and CBOR lower bound for
64 byte ECDSA signature.
B.3. Authenticated Encryption with Additional Data (AEAD)
This example is based on AES-128-CCM-8.
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 whole IV in the message.
The object in COSE encoding gives:
[
2, # msg_type
h'a201046373657143112233', # protected:
{1: 4,
"seq": h'112233'}
{}, # unprotected
TAG, # 8byte authentication tag
[ # recipients
[ # recipient structure
h'', # protected
{1:-6, "cid":h'a1534e3c5fdc09bd'}, # unprotected
h'' # ciphertext
]
]
]
The COSE object encodes to a total size of 44 bytes.
In the modified version of COSE defined in Appendix A.3, the
equivalent COSE object would be:
Selander, et al. Expires April 21, 2016 [Page 29]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
[
6, # msg_type
h'a20b48a1534e3c5fdc09bd0c43112233', # protected:
{11:h'a1534e3c5fdc09bd',
12:h'112233'}
h'', # ciphertext
TAG # 8byte authentication tag
]
The modified COSE object encodes to a total size of 29 bytes.
The low-bound CBOR encoding of this same object is encoded by:
[
h'112233', # seq
h'a1534e3c5fdc09bd', # cid
h'', # ciphertext
TAG # 8byte authentication tag
]
This object encodes to a total size of 24 bytes.
Figure 5 summarizes these results.
+--------+---------+-----+------------+----------+
| Scheme | seq+cid | TAG | Total Size | Overhead |
+--------+---------+-----+------------+----------+
| COSE | 11 B | 8 B | 44 bytes | 25 bytes |
+--------+---------+-----+------------+----------+
|mod-COSE| 11 B | 8 B | 29 bytes | 10 bytes |
+--------+---------+-----+------------+----------+
| bound | 11 B | 8 B | 24 bytes | 5 bytes |
+--------+---------+-----+------------+----------+
Figure 5: Comparison of COSE, modified COSE and CBOR lower bound for
AES-CCM.
B.4. Symmetric Encryption with Asymmetric Signature (SEAS)
This example is based on AES-128-CTR and ECDSA with 64 bytes
signature. COSE requires this to be a nested encapsulation of one
object into another, here illustrated with a digitally signed AEAD
protected object.
The object in COSE encoding gives:
Selander, et al. Expires April 21, 2016 [Page 30]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
[
1, # msg_type
h'a16373657143112233', # protected:
{"seq": h'112233'}
{}, # unprotected
h'85024ba2010a6373657143112233a04081834
0a201256363696448a1534e3c5fdc09bd40', # payload:
[2,
h'a2010a6373657143112233',
{}, h', [[h'',
{1: -6,
"cid": h'a1534e3c5fdc09bd'
}, h'']]]
[ # signatures
[ # signature structure
h'a201266363696448a1534e3c5fdc09bd', # protected:
{1: -7,
"cid":h'a1534e3c5fdc09bd'}
{}, # unprotected
SIG # 64-byte signature
]
]
]
The COSE object encodes to a total size of 134 bytes.
In the modified version of COSE defined in Appendix A.3, the
equivalent COSE object would be:
[
6, # msg_type
h'a20b48a1534e3c5fdc09bd0c43112233', # protected:
{11:h'a1534e3c5fdc09bd',
12:h'112233'}
h'', # ciphertext
SIG # 64-byte signature
]
This modified COSE object encodes to a total size of 86 bytes.
The low-bound CBOR encoding of this same object is encoded by:
[
h'112233', # seq
h'a1534e3c5fdc09bd', # cid
h'', # ciphertext
SIG # 64-byte signature
]
Selander, et al. Expires April 21, 2016 [Page 31]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
This object encodes to a total size of 81 bytes.
Figure 6 summarizes these results.
+--------+---------+------+------------+----------+
| Scheme | seq+cid | SIG | Total Size | Overhead |
+--------+---------+------+------------+----------+
| COSE | 11 B | 64 B | 134 bytes | 59 bytes |
+--------+---------+------+------------+----------+
|mod-COSE| 11 B | 64 B | 86 bytes | 11 bytes |
+--------+---------+------+------------+----------+
| bound | 11 B | 64 B | 81 bytes | 6 bytes |
+--------+---------+------+------------+----------+
Figure 6: Comparison of nested AES-CCM within ECDSA (COSE) and
combined AES-ECDSA (modified COSE and CBOR lower bound).
Appendix C. Object Security of Content (OSCON)
In this section we define how to only protect the payload/content of
individual messages using the Secure Message format (Section 4) to
comply with the requirements 1 and 2 in Section 2. This is referred
to as Object Security of Content (OSCON).
Note that by only protecting the content of a message it may be
verified by multiple recipients. For example, in the case of a proxy
that supports caching, a recent response for a certain resource can
be cached and used to serve multiple clients. Or, in a publish-
subscribe setting, multiple subscribers can be served the same
publication. The use of content protection also decouples the
binding to the underlying transfer protocol, so the same protected
content object can be freely move between CoAP, HTTP, BlueTooth or
whatever application layer protocol.
The use of OSCON is signaled with the Content-Format/Media Type set
to application/oscon (Section 10). Since the actual format of the
content which is protected is lost, that information needs to be
added to the message header or known to the recipient.
The sending endpoint SHALL wrap the Payload, and the receiving
endpoint unwrap the Payload in the SM format as described in this
section. A CoAP client MAY request a response in the OSCON format by
setting the option Accept to application/oscon.
In case of cipher suite for integrity protection only, the
Authenticated Data SHALL be the concatenation of the SM Header and
the CoAP Payload. If case of cipher suite for both encryption and
integrity protection, then the AAD SHALL be the SM Header and the
Selander, et al. Expires April 21, 2016 [Page 32]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
Plaintext SHALL be the CoAP Payload. By default, cipher suites for
encryption and integrity protection SHALL be used.
The SM SHALL be protected (encrypted) and verified (decrypted) as
described in Section 5.1.3 (Section 5.2.2.1), including replay
protection as described in Section 7.1.
Whereas in OSCOAP, the Context Identifier of the SM Header
(Section 4.1) typically identifies the sending party, with OSCON
(Appendix C) the Context Identifier may well identify the sender and
resource.
C.1. Security Considerations of OSCON
OSCON (Appendix C) only protects payload and only gives replay
protection (not freshness of response), but allows additional use
cases such as point to multi-point interactions 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.
OSCON SHALL NOT be used in cases where CoAP header fields (such as
Code or Version) or CoAP options need to be integrity protected. The
request for a response in OSCON using the CoAP option Accept set to
"application/oscon" is not secured since OSCON does not integrity
protect any options. Hence the exchange of OSCON request-response
messages is vulnerable to a man-in-the-middle attack where response
is exchanged for another response, but since there is replay
protection only messages with higher sequence numbers will be
accepted.
Blockwise transfers in CoAP as defined in [I-D.ietf-core-block] can
be applied with OSCON, i.e. the entire payload is encapsulated in a
Secure Message which is partitioned into blocks which are sent with
unprotected CoAP. The receiver is able to verify the integrity of
the payload but only after the last block containing the signature/
MAC is received, and if the verification fails the entire message
needs to be resent. However, if the verification succeeds, then the
transmission in OSCON has less computational and packet overhead
since only one signature/MAC was generated and sent. As CoAP
blockwise transfer with OSCON is prone to Denial of Service attacks,
it should only be used for exchanges where this threat can be
mitigated, for example within a local area network where link-layer
security is activated.
Selander, et al. Expires April 21, 2016 [Page 33]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
Appendix D. Examples
This section gives examples of how to use the Object-Security option
and the message formats defined in this memo.
D.1. CoAP Message Protection
This section illustrates Object Security of CoAP (OSCOAP). 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 an OSCOAP object (Object-Security option is set) and
thus forwards the message as it cannot serve a cached response.
D.1.1. Integrity Protection of CoAP Message Exchange
Here is an example of a PUT request/response message exchange passing
an intermediate node protected with the Object-Security option. The
example illustrates a client closing a lock (PUT 1) and getting a
confirmation that the lock is closed. Code, Uri-Path and Payload of
the request and Code of the response are integrity protected (and
other message fields, see Section 6.1 and Section 6.2).
Selander, et al. Expires April 21, 2016 [Page 34]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
Client Proxy Server
| | |
| | |
| | |
+----->| | Code: 0.03 (PUT)
| PUT | | Token: 0x8c
| | | Uri-Path: lock
| | | Object-Security:
| | | Payload: ["seq":"142",
| | | "cid":"a1534e3c5fdc09bd", 1, <Tag>]
| | |
| +----->| Code: 0.03 (PUT)
| | PUT | Token: 0x7b
| | | Uri-Path: lock
| | | Object-Security:
| | | Payload: ["seq":"142",
| | | "cid":"a1534e3c5fdc09bd", 1, <Tag>]
| | |
| |<-----+ Code: 2.04 (Changed)
| | 2.04 | Token: 0x7b
| | | Object-Security: ["seq":"a6",
| | | "cid":"5fdc09bda1534e3c", , <Tag>]
| | |
|<-----+ | Code: 2.04 (Changed)
| 2.04 | | Token: 0x8c
| | | Object-Security: ["seq":"a6",
| | | "cid":"5fdc09bda1534e3c", , <Tag>]
| | |
Figure 7: CoAP PUT protected with OSCOAP
Since the request message (PUT) supports payload, the OSCOAP object
is carried in the CoAP payload. Since the response message (Changed)
does not supports payload the Object-Security option carries the
OSCOAP object.
The Header contains Sequence Number ("seq":"a6") and Context
Identifier ("cid":"5fdc09bda1534e3c"), the latter is an identifier
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. With OSCOAP, the client
additionally verifies the freshness of the response, i.e. that the
response message is generated as an answer to the received request
message (see Section 7).
Selander, et al. Expires April 21, 2016 [Page 35]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
This example deviates from encryption by default (see Section 8) just
to illustrate the case of Integrity Protection only. If there is no
compelling reason why the CoAP message should be in plaintext, then
it MUST be encrypted.
D.1.2. Additional 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 Section 6.1 and Section 6.2).
Client Proxy Server
| | |
| | |
| | |
+----->| | Code: 0.01 (GET)
| GET | | Token: 0x83
| | | Object-Security: ["seq":"15b7",
| | | "cid":"34e3c5fdca1509bd",
| | | {"glucose"}, <Tag>]
| | |
| +----->| Code: 0.01 (GET)
| | GET | Token: 0xbe
| | | Object-Security: ["seq":"15b7",
| | | "cid":"34e3c5fdca1509bd",
| | | {"glucose"}, <Tag>]
| | |
| | |
| |<-----+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe
| | | Object-Security:
| | | Payload: ["seq":"32c9",
| | | "cid":"c09bda155fd34e3c",
| | | {220}, <Tag>]
| | |
|<-----+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83
| | | Object-Security:
| | | Payload: ["seq":"32c9",
| | | "cid":"c09bda155fd34e3c",
| | | {220}, <Tag>]
| | |
Figure 8: CoAP GET protected with OSCOAP. The bracket { ... }
indicates encrypted data.
Selander, et al. Expires April 21, 2016 [Page 36]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
Since the request message (GET) does not support payload, the OSCOAP
object is carried in the Object-Security option. Since the response
message (Content) supports payload, the Object-Security option is
empty and the OSCOAP object is carried in the payload.
The Context 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 the client
additionally verifies the freshness of the response, i.e. that the
response message is generated as an answer to the received request
message (see Section 7).
D.2. Payload Protection
This section gives examples that illustrate Object Security of
Content (OSCON), see Appendix C). The assumption here is that only
the intended receiver(s) has the relevant security context related to
the resource. In case of a closed group of recipients of the same
object, e.g. in Information-Centric Networking or firmware update
distribution, it may be necessary to support symmetric key encryption
in combination with digital signature.
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 OSCON object, and
serve this response to another client request, such that both clients
can verify integrity and non-replay.
Selander, et al. Expires April 21, 2016 [Page 37]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
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: ["seq":"15b7",
| | | "cid":"c09bda155fd34e3c",
| | | "471 F", <Tag>]
| | |
|<-----+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83
| | | Payload: ["seq":"15b7",
| | | "cid":"c09bda155fd34e3c",
| | "471 F", <Tag>]
Client2 | |
| |
| | |
| | |
+----->| | Code: 0.01 (GET)
| GET | | Token: 0xa1
| | | Proxy-Uri: example.com/temp
| | |
|<-----+ | Code: 2.05 (Content)
| 2.05 | | Token: 0xa1
| | | Payload: ["seq":"15b7",
| | | "cid":"c09bda155fd34e3c",
| | | "471 F", <Tag>]
Figure 9: Proxy caching protected with Object Security of Content
(OSCON)
D.2.2. Publish-Subscribe
This example outlines a publish-subscribe setting where the payload
is encrypted, integrity and replay protected end-to-end between
Publisher and Subscriber. The example applies for example to closed
Selander, et al. Expires April 21, 2016 [Page 38]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
user groups of a single data source and illustrates a subscription
registration and a later 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 OSCOAP), but
cannot manipulate the Sequence Number without being possible to
detect.
Sub- PubSub- Pub-
scriber Broker lisher
| | |
+----->| | 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: ["seq":"15b7",
| | | "cid":"c09bda155fd34e3c",
| | | {"270"}, <Tag>]
| | |
| | |
| | |
| |<-----+ Code: 0.03 (PUT)
| | PUT | Token: 0x1f
| | | Uri-Path: ps
| | | Uri-Path: birch-pollen
| | | Payload: ["seq":"15b8",
| | | "cid":"c09bda155fd34e3c",
| | | {"300"}, <Tag>]
| | |
| +----->| Code: 2.04 (Changed)
| | 2.04 | Token: 0x1f
| | |
| | |
|<-----+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x72
| | | Observe: 2
| | | Payload: ["seq":"15b8",
| | | "cid":"c09bda155fd34e3c",
| | | {"300"}, <Tag>]
Figure 10: Publish-subscribe protected with OSCON. The bracket { ...
} indicates encrypted data.
Selander, et al. Expires April 21, 2016 [Page 39]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
This example deviates from encryption by default (see Section 8) just
to illustrate Integrity Protection only in the case of OSCON. If
there is no compelling reason why the payload should be in plaintext,
then encryption 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 e.g.
[I-D.ietf-ace-actors] or [I-D.seitz-ace-core-authz]. Here, C is
clearly not trusted with modifying the information, but may need to
be involved in 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 ("access tokens")
is the natural candidate.
This example considers the authorization information to be
encapsulated in a OSCON object, generated by AS. How C accesses the
OSCON object 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 OSCON object by doing POST to /authz-info. 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 11.
Selander, et al. Expires April 21, 2016 [Page 40]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
Authz Resource
Server Client Server
| | |
| | | Client accesses Access Token:
+- - ->| | ["seq":"142",
| | | "cid":"c09bda1534e3c5fdc09bd",
| | | <AuthzInfo>, <Tag>]
| | |
| +----->| Code: 0.02 (POST)
| | POST | Token: 0xac
| | | Uri-Path: authz-info
| | | Payload: ["seq":"142",
| | | "cid":"c09bda1534e3c5fdc09bd",
| | | <AuthzInfo>, <Tag>]
a)
| | |
| |<-----+ Code: 2.04 (Changed)
| | 2.04 | Token: 0xac
| | |
b)
| | |
| |<-----+ Code: 4.01 (Unauthorized)
| | 4.01 | Token: 0xac
| | |
Figure 11: Protected Transfer of Access Token using OSCON
Authors' Addresses
Goeran Selander
Ericsson
Farogatan 6
Kista 16480
Sweden
Email: goran.selander@ericsson.com
John Mattsson
Ericsson
Farogatan 6
Kista 16480
Sweden
Email: john.mattsson@ericsson.com
Selander, et al. Expires April 21, 2016 [Page 41]
Internet-Draft Object Security of CoAP (OSCOAP) October 2015
Francesca Palombini
Ericsson
Farogatan 6
Kista 16480
Sweden
Email: francesca.palombini@ericsson.com
Ludwig Seitz
SICS Swedish ICT
Scheelevagen 17
Lund 22370
Sweden
Email: ludwig@sics.se
Selander, et al. Expires April 21, 2016 [Page 42]