Draft: draft-ietf-core-object-security

Commentary: Add explanatory text into section 4 Fill in the previously empty section 10.3 Rename OSCOAP to OSCORE Fix various grammatical issues and typos Add normative reference for base64url encoding Signed - off - by :   
 I do not believe that OBSERVE is an option that is supported by HTTP . I could be completely wrong there . Would you expect the proxy to strip the idea of an observe and convert the GET to a POST ? ( Comment by on the above ): Why would not the proxy just remove the Observe , which is a legitimate CoAP proxy operation and turn the GET / FETCH Observe into a normal GET / FETCH ?
Paragraph (version A):
This document defines Object Security of CoAP (OSCOAP), a method for
application layer protection of the Constrained Application Protocol
(CoAP), using the CBOR Object Signing and Encryption (COSE).  OSCOAP
provides end-to-end encryption, integrity and replay protection to
CoAP payload, options, and header fields, as well as a secure message
binding.  OSCOAP is designed for constrained nodes and networks and
can be used across intermediaries and over any layer.  The use of
OSCOAP is signaled with the CoAP option Object-Security, also defined
in this document.
Paragraph (version A):
The Constrained Application Protocol (CoAP) is a web application
protocol, designed for constrained nodes and networks RFC7228.  CoAP
specifies the use of proxies for scalability and efficiency.  At the
same time CoAP RFC7252 references DTLS RFC6347 for security.  CoAP
proxies require DTLS to be terminated at the proxy.  The proxy
therefore not only has access to the data required for performing the
intended proxy functionality, but is also able to eavesdrop on, or
manipulate any part of the CoAP payload and metadata, in transit
between client and server.  The proxy can also inject, delete, or
reorder packages since they are no longer protected by DTLS.
Paragraph (version A):
This document defines the security protocol Object Security of CoAP
(OSCOAP), protecting CoAP requests and responses end-to-end across
intermediary nodes such as CoAP forward proxies and cross-protocols
translations including HTTP-to-CoAP proxies RFC8075.  In addition to
the core features defined in RFC7252, OSCOAP supports Observe RFC7641
and Blockwise RFC7959.  An analysis of end-to-end security for CoAP
messages through some types of intermediary nodes is performed in I-
D.hartke-core-e2e-security-reqs.  OSCOAP protects the CoAP Request/
Response layer only, and not the Messaging Layer (Section 2 of
RFC7252).  Therefore, all the messages mentioned in this document
refer to non-empty CON, NON, and ACK messages.  Additionally, since
the message formats for CoAP over unreliable transport RFC7252 and
for CoAP over reliable transport I-D.ietf-core-coap-tcp-tls differ
only in terms of Messaging Layer, OSCOAP can be applied to both
unreliable and reliable transport.
Paragraph (version A):
OSCOAP is designed for constrained nodes and networks and provides an
in-layer security protocol for CoAP which does not depend on
underlying layers.  OSCOAP can be used anywhere where CoAP can be
used, including non-IP transport I-D.bormann-6lo-coap-802-15-ie.  An
extension of OSCOAP may also be used to protect group communication
for CoAP I-D.tiloca-core-multicast-oscoap.  The use of OSCOAP does
not affect the URI scheme and OSCOAP can therefore be used with any
URI scheme defined for CoAP.  The application decides the conditions
for which OSCOAP is required.
Paragraph (version A):
OSCOAP builds on CBOR Object Signing and Encryption (COSE) RFC8152,
providing end-to-end encryption, integrity, replay protection, and
secure message binding.  A compressed version of COSE is used, see
compression.  The use of OSCOAP is signaled with the CoAP option
Object-Security, defined in option.  OSCOAP is designed to protect as
much information as possible, while still allowing proxy operations
(proxy-operations).  OSCOAP provides protection of CoAP payload, most
options, and non-message layer header fields.  The solution
transforms a CoAP message into an "OSCOAP message" before sending,
and vice versa after receiving.  The OSCOAP message is a CoAP message
related to the original CoAP message in the following way: the
original CoAP message payload (if present), options not processed by
a proxy, and the request/response method (CoAP Code) are protected in
a COSE object.  The message fields of the original messages that are
encrypted are not present in the OSCOAP message, and instead the
Object-Security option and the compressed COSE object are added, see
fig-sketch.
Paragraph (version A):
OSCOAP may be used in very constrained settings, thanks to its small
message size and the restricted code and memory requirements in
addition to what is required by CoAP.  OSCOAP can be combined with
transport layer security such as DTLS or TLS, thereby enabling end-
to-end security of e.g.  CoAP Payload, Options and Code, in
combination with hop-by-hop protection of the Messaging Layer, during
transport between end-point and intermediary node.  Examples of the
use of OSCOAP are given in examples.
Paragraph (version A):
An implementation supporting this specification MAY only implement
the client part, MAY only implement the server part, or MAY only
implement one of the proxy parts.  OSCOAP is designed to work with
legacy CoAP-to-CoAP forward proxies RFC7252, but an OSCOAP aware
proxy will be more efficient.  HTTP-to-CoAP proxies RFC8075 and CoAP-
to-HTTP proxies need to implement respective part of this
specification to work with OSCOAP (see proxy-operations).
Paragraph (version B):
This document defines Object Security for Constrained RESTful
Environments (OSCORE), a method for application-layer protection of
the Constrained Application Protocol (CoAP) and HTTP, using CBOR
Object Signing and Encryption (COSE).  OSCORE provides end-to-end
encryption, integrity and replay protection, as well as a secure
message binding.  OSCORE is designed for constrained nodes and
networks and can be used across intermediaries and over any layer.
Paragraph (version B):
The Constrained Application Protocol (CoAP) is a web application
protocol, designed for constrained nodes and networks RFC7228.  CoAP
specifies the use of proxies for scalability and efficiency, and a
mapping to HTTP is also specified RFC8075.  At the same time CoAP
RFC7252 references DTLS RFC6347 for security.  CoAP and HTTP proxies
require (D)TLS to be terminated at the proxy.  The proxy therefore
not only has access to the data required for performing the intended
proxy functionality, but is also able to eavesdrop on, or manipulate
any part of the message payload and metadata, in transit between the
endpoints.  The proxy can also inject, delete, or reorder packets
since they are no longer protected by (D)TLS.
Paragraph (version B):
This document defines the Object Security for Constrained RESTful
Environments (OSCORE) security protocol, protecting CoAP and CoAP-
mappable HTTP requests and responses end-to-end across intermediary
nodes such as CoAP forward proxies and cross-protocol translators
including HTTP-to-CoAP proxies RFC8075.  In addition to the core CoAP
features defined in RFC7252, OSCORE supports Observe RFC7641 and
Blockwise RFC7959.  An analysis of end-to-end security for CoAP
messages through some types of intermediary nodes is performed in I-
D.hartke-core-e2e-security-reqs.  OSCORE protects the Request/
Response layer only, and not the CoAP Messaging Layer (Section 2 of
RFC7252).  Therefore, all the CoAP messages mentioned in this
document refer to non-empty CON, NON, and ACK messages.
Additionally, since the message formats for CoAP over unreliable
transport RFC7252 and for CoAP over reliable transport I-D.ietf-core-
coap-tcp-tls differ only in terms of Messaging Layer, OSCORE can be
applied to both unreliable and reliable transports.
Paragraph (version B):
OSCORE is designed for constrained nodes and networks and provides an
in-layer security protocol that does not depend on underlying layers.
OSCORE can be used anywhere where CoAP or HTTP can be used, including
non-IP transports (e.g., I-D.bormann-6lo-coap-802-15-ie).  An
extension of OSCORE may also be used to protect group communication
for CoAP I-D.tiloca-core-multicast-oscoap.  The use of OSCORE does
not affect the URI scheme and OSCORE can therefore be used with any
URI scheme defined for CoAP or HTTP.  The application decides the
conditions for which OSCORE is required.
Paragraph (version B):
OSCORE builds on CBOR Object Signing and Encryption (COSE) RFC8152,
providing end-to-end encryption, integrity, replay protection, and
secure message binding.  A compressed version of COSE is used, as
discussed in compression.  The use of OSCORE is signaled with the
Object-Security CoAP option or HTTP header, defined in option.
OSCORE is designed to protect as much information as possible, while
still allowing proxy operations (proxy-operations).  OSCORE provides
protection of message payload, most options, and non-message layer
header fields.  The solution transforms a message into an "OSCORE
message" before sending, and vice versa after receiving.  The OSCORE
message is related to the original message in the following way: the
original message is translated to CoAP (if not already in CoAP) and
the resulting message payload (if present), options not processed by
a proxy, and the request/response method (CoAP Code) are protected in
a COSE object.  The message fields of the original messages that are
encrypted are not present in the OSCORE message, and instead the
Object-Security option/header and the compressed COSE object are
added, see fig-sketch.
Paragraph (version B):
OSCORE may be used in very constrained settings, thanks to its small
message size and the restricted code and memory requirements in
addition to what is required by CoAP.  OSCORE can be combined with
transport layer security such as DTLS or TLS, thereby enabling end-
to-end security of e.g.  CoAP Payload, Options and Code, in
combination with hop-by-hop protection of the Messaging Layer, during
transport between end-point and intermediary node.  Examples of the
use of OSCORE are given in examples.
Paragraph (version B):
An implementation supporting this specification MAY only implement
the client part, MAY only implement the server part, or MAY only
implement one of the proxy parts.  OSCORE is designed to work with
legacy CoAP-to-CoAP forward proxies RFC7252, but an OSCORE-aware
proxy will be more efficient.  HTTP-to-CoAP proxies RFC8075 and CoAP-
to-HTTP proxies need to implement respective parts of this
specification to work with OSCORE (see proxy-operations).
Paragraph (version A):
The Object-Security option (see fig-option) indicates that the CoAP
message is an OSCOAP message and that it contains a compressed COSE
object (see cose-object and compression).  The Object-Security option
is critical, safe to forward, part of the cache key, and not
repeatable.
Paragraph (version A):
The Object-Security option SHALL contain the OSCOAP flag byte and the
Sender ID (see compression) If the flag byte is all zero (0x00) the
Option value SHALL be empty (Option Length = 0).  An endpoint
receiving a CoAP message without payload, that also contains an
Object-Security option SHALL treat it as malformed and reject it.
Paragraph (version B):
The CoAP Object-Security option (see fig-option) indicates that the
CoAP message is an OSCORE message and that it contains a compressed
COSE object (see cose-object and compression).  The Object-Security
option is critical, safe to forward, part of the cache key, and not
repeatable.
Paragraph (version B):
The Object-Security option SHALL contain the OSCORE flag byte and the
Sender ID (see compression) If the flag byte is all zero (0x00) the
Option value SHALL be empty (Option Length = 0).  An endpoint
receiving a CoAP message without payload, that also contains an
Object-Security option SHALL treat it as malformed and reject it.
Paragraph (version A):
Since the payload and most options are encrypted protected-fields,
and the corresponding plain text message fields of the original are
not included in the OSCOAP message, the processing of these fields
does not expand the total message size.
Paragraph (version B):
Since the payload and most options are encrypted protected-fields,
and the corresponding plain text message fields of the original are
not included in the OSCORE message, the processing of these fields
does not expand the total message size.
Paragraph (version A):
OSCOAP requires that client and server establish a shared security
context used to process the COSE objects.  OSCOAP uses COSE with an
Authenticated Encryption with Additional Data (AEAD) algorithm for
protecting CoAP message data between a CoAP client and a CoAP server.
In this section, we define the security context and how it is derived
in client and server based on a common shared master secret and a key
derivation function (KDF).
Paragraph (version A):
The security context is the set of information elements necessary to
carry out the cryptographic operations in OSCOAP.  For each endpoint,
the security context is composed of a "Common Context", a "Sender
Context", and a "Recipient Context".
Paragraph (version B):
OSCORE requires that client and server establish a shared security
context used to process the COSE objects.  OSCORE uses COSE with an
Authenticated Encryption with Additional Data (AEAD) algorithm for
protecting message data between a client and a server.  In this
section, we define the security context and how it is derived in
client and server based on a common shared master secret and a key
derivation function (KDF).
Paragraph (version B):
The security context is the set of information elements necessary to
carry out the cryptographic operations in OSCORE.  For each endpoint,
the security context is composed of a "Common Context", a "Sender
Context", and a "Recipient Context".
Paragraph (version A):
The Sender Sequence Number is initialized to 0.  The supported types
of replay protection and replay window length is application specific
and depends on the lower layers.  Default is DTLS-type replay
protection with a window size of 32 initiated as described in
Section 4.1.2.6 of RFC6347.
Paragraph (version B):
The Sender Sequence Number is initialized to 0.  The supported types
of replay protection and replay window length is application specific
and depends on the lower layers.  The default is DTLS-type replay
protection with a window size of 32 initiated as described in
Section 4.1.2.6 of RFC6347.
Paragraph (version A):
As collisions may lead to the loss of both confidentiality and
integrity, Sender ID SHALL be unique in the set of all security
contexts using the same Master Secret and Master Salt.  When a
trusted third party assigns identifiers (e.g. using I-D.ietf-ace-
oauth-authz) or by using a protocol that allows the parties to
negotiate locally unique identifiers in each endpoint, the Sender IDs
can be very short.  The maximum Sender ID is 2^(nonce length in bits
- 48) - 1, For AES-CCM-16-64-128 the maximum Sender ID is 2^56 - 1.
If Sender ID uniqueness cannot be guaranteed, random Sender IDs MUST
be used.  Random Sender IDs MUST be long enough so that the
probability of collisions is negligible.
Paragraph (version B):
As collisions may lead to the loss of both confidentiality and
integrity, Sender ID SHALL be unique in the set of all security
contexts using the same Master Secret and Master Salt.  When a
trusted third party assigns identifiers (e.g., using I-D.ietf-ace-
oauth-authz) or by using a protocol that allows the parties to
negotiate locally unique identifiers in each endpoint, the Sender IDs
can be very short.  The maximum Sender ID is 2^(nonce length in bits
- 48) - 1, For AES-CCM-16-64-128 the maximum Sender ID is 2^56 - 1.
If Sender ID uniqueness cannot be guaranteed, random Sender IDs MUST
be used.  Random Sender IDs MUST be long enough so that the
probability of collisions is negligible.
Paragraph (version A):
OSCOAP transforms a CoAP message into an OSCOAP message, and vice
versa.  OSCOAP protects as much of the original CoAP message as
possible while still allowing certain proxy operations (see proxy-
operations).  This section defines how OSCOAP protects the CoAP
message fields and transfers them between CoAP client and CoAP server
(in any direction).
Paragraph (version B):
OSCORE transforms a CoAP message (which may have been generated from
an HTTP message) into an OSCORE message, and vice versa.  OSCORE
protects as much of the original message as possible while still
allowing certain proxy operations (see proxy-operations).  This
section defines how OSCORE protects the message fields and transfers
them end-to-end between the client and server (in any direction).
Paragraph (version B):
The remainder of this section and later sections discuss the behavior
in terms of CoAP messages.  If HTTP is used for a particular leg in
the end-to-end path, then this section applies to the conceptual CoAP
message that is mappable to/from the original HTTP message as
discussed in proxy-operations.  That is, an HTTP message is
conceptually transformed to a CoAP message and then to an OSCORE
message, and similarly in the reverse direction.  An actual
implementation might translate directly from HTTP to OSCORE without
the intervening CoAP representation.
Paragraph (version A):
The sending endpoint SHALL transfer Class E message fields in the
ciphertext of the COSE object in the OSCOAP message.  The sending
endpoint SHALL include Class I message fields in the Additional
Authenticated Data (AAD) of the AEAD algorithm, allowing the
receiving endpoint to detect if the value has changed in transfer.
Class U message fields SHALL NOT be protected in transfer.  Class I
and Class U message field values are transferred in the header or
options part of the OSCOAP message which is visible to proxies.
Paragraph (version A):
Message fields not visible to proxies, i.e. transported in the
ciphertext of the COSE object, are called "Inner".  Message fields
transferred in the header or options part of the OSCOAP message,
which is visible to proxies, are called "Outer".
Paragraph (version A):
CoAP message fields are either Inner or Outer: Inner if the value is
intended for the destination endpoint, Outer if the value is intended
for a proxy.  An OSCOAP message may contain both an Inner and an
Outer message field of certain CoAP message fields.  Inner and Outer
message fields are processed independently.
Paragraph (version A):
The CoAP Payload, if present in the original message, SHALL be
encrypted and integrity protected and is thus a Class E message
field.  The sending endpoint writes the payload of the original CoAP
message into the plaintext (plaintext) input to the COSE object.  The
receiving endpoint verifies and decrypts the COSE object, and
recreates the payload of the original CoAP message.
Paragraph (version B):
The sending endpoint SHALL transfer Class E message fields in the
ciphertext of the COSE object in the OSCORE message.  The sending
endpoint SHALL include Class I message fields in the Additional
Authenticated Data (AAD) of the AEAD algorithm, allowing the
receiving endpoint to detect if the value has changed in transfer.
Class U message fields SHALL NOT be protected in transfer.  Class I
and Class U message field values are transferred in the header or
options part of the OSCORE message which is visible to proxies.
Paragraph (version B):
Message fields not visible to proxies, i.e., transported in the
ciphertext of the COSE object, are called "Inner".  Message fields
transferred in the header or options part of the OSCORE message,
which is visible to proxies, are called "Outer".
Paragraph (version B):
CoAP message fields are either Inner or Outer: Inner if the value is
intended for the destination endpoint, Outer if the value is intended
for a proxy.  An OSCORE message may contain both an Inner and an
Outer message field of certain CoAP message fields.  Inner and Outer
message fields are processed independently.
Paragraph (version B):
The CoAP Payload, if present in the original CoAP message, SHALL be
encrypted and integrity protected and is thus a Class E message
field.  The sending endpoint writes the payload of the original CoAP
message into the plaintext (plaintext) input to the COSE object.  The
receiving endpoint verifies and decrypts the COSE object, and
recreates the payload of the original CoAP message.
Paragraph (version A):
Specifications of new CoAP options SHOULD define how they are
processed with OSCOAP.  A new COAP option SHOULD be of class E unless
it requires proxy processing.
Paragraph (version A):
When using OSCOAP, Inner options (marked with 'x' in column E of fig-
option-protection) are sent in a way analogous to communicating in a
protected manner directly with the other endpoint.
Paragraph (version A):
The sending endpoint SHALL write the class E options present in the
original CoAP message into the plaintext of the COSE object
plaintext, and then remove the class E options from the OSCOAP
message.
Paragraph (version B):
Specifications of new CoAP options SHOULD define how they are
processed with OSCORE.  A new COAP option SHOULD be of class E unless
it requires proxy processing.
Paragraph (version B):
When using OSCORE, Inner options (marked with 'x' in column E of fig-
option-protection) are sent in a way analogous to communicating in a
protected manner directly with the other endpoint.
Paragraph (version B):
The sending endpoint SHALL write the class E options present in the
original CoAP message into the plaintext of the COSE object
plaintext, and then remove the class E options from the OSCORE
message.
Paragraph (version A):
The sending endpoint SHALL include the class U and class I options
present in the original message to the options part of the OSCOAP
message.  Class I options (marked with 'x' in column I of fig-option-
protection) SHALL be integrity protected between the endpoints as
specified in AAD.  All Outer options, including the Object-Security
option, SHALL be encoded as described in Section 3.1 of RFC7252,
where the delta is the difference to the previously included outer
option value.
Paragraph (version B):
The sending endpoint SHALL include the class U and class I options
present in the original message to the options part of the OSCORE
message.  Class I options (marked with 'x' in column I of fig-option-
protection) SHALL be integrity protected between the endpoints as
specified in AAD.  All Outer options, including the Object-Security
option, SHALL be encoded as described in Section 3.1 of RFC7252,
where the delta is the difference to the previously included outer
option value.
Paragraph (version A):
The Inner Max-Age option is used to specify the freshness (as defined
in RFC7252) of the resource, end-to-end from the server to the
client, taking into account that the option is not accessible to
proxies.  The Inner Max-Age SHALL be processed by OSCOAP as specified
in inner-options.
Paragraph (version A):
The Outer Max-Age option is used to avoid unnecessary caching of
OSCOAP responses at OSCOAP unaware intermediary nodes.  A server MAY
set a Class U Max-Age option with value zero to Observe responses
(see Section 5.6.1 of RFC7252) and process it according to outer-
options.  The Outer Max-Age option value SHALL be discarded by the
OSCOAP client.
Paragraph (version B):
The Inner Max-Age option is used to specify the freshness (as defined
in RFC7252) of the resource, end-to-end from the server to the
client, taking into account that the option is not accessible to
proxies.  The Inner Max-Age SHALL be processed by OSCORE as specified
in inner-options.
Paragraph (version B):
The Outer Max-Age option is used to avoid unnecessary caching of
OSCORE responses at OSCORE unaware intermediary nodes.  A server MAY
set a Class U Max-Age option with value zero to Observe responses
(see Section 5.6.1 of RFC7252) and process it according to outer-
options.  The Outer Max-Age option value SHALL be discarded by the
OSCORE client.
Paragraph (version A):
The sending CoAP endpoint MAY fragment a CoAP message as defined in
RFC7959 before the message is processed by OSCOAP.  In this case the
Block options SHALL be processed by OSCOAP as Inner options (inner-
options).  The receiving CoAP endpoint SHALL process the OSCOAP
message according to inner-options before processing blockwise as
defined in RFC7959.
Paragraph (version B):
The sending CoAP endpoint MAY fragment a CoAP message as defined in
RFC7959 before the message is processed by OSCORE.  In this case the
Block options SHALL be processed by OSCORE as Inner options (inner-
options).  The receiving CoAP endpoint SHALL process the OSCORE
message according to inner-options before processing blockwise as
defined in RFC7959.
Paragraph (version A):
Proxies MAY fragment an OSCOAP message using RFC7959, which then
introduces Outer Block options not generated by the sending endpoint.
Note that the Outer Block options are neither encrypted nor integrity
protected.  As a consequence, a proxy can maliciously inject block
fragments indefinitely, since the receiving endpoint needs to receive
the last block (see RFC7959) to be able to compose the OSCOAP message
and verify its integrity.  Therefore, applications supporting OSCOAP
and RFC7959 MUST specify a security policy defining a maximum
unfragmented message size (MAX_UNFRAGMENTED_SIZE) considering the
maximum size of message which can be handled by the endpoints.
Messages exceeding this size SHOULD be fragmented by the sending
endpoint using Inner Block options (inner-block-options).
Paragraph (version A):
An endpoint receiving an OSCOAP message with an Outer Block option
SHALL first process this option according to RFC7959, until all
blocks of the OSCOAP message have been received, or the cumulated
message size of the blocks exceeds MAX_UNFRAGMENTED_SIZE.  In the
former case, the processing of the OSCOAP message continues as
defined in this document.  In the latter case the message SHALL be
discarded.
Paragraph (version B):
Proxies MAY fragment an OSCORE message using RFC7959, which then
introduces Outer Block options not generated by the sending endpoint.
Note that the Outer Block options are neither encrypted nor integrity
protected.  As a consequence, a proxy can maliciously inject block
fragments indefinitely, since the receiving endpoint needs to receive
the last block (see RFC7959) to be able to compose the OSCORE message
and verify its integrity.  Therefore, applications supporting OSCORE
and RFC7959 MUST specify a security policy defining a maximum
unfragmented message size (MAX_UNFRAGMENTED_SIZE) considering the
maximum size of message which can be handled by the endpoints.
Messages exceeding this size SHOULD be fragmented by the sending
endpoint using Inner Block options (inner-block-options).
Paragraph (version B):
An endpoint receiving an OSCORE message with an Outer Block option
SHALL first process this option according to RFC7959, until all
blocks of the OSCORE message have been received, or the cumulated
message size of the blocks exceeds MAX_UNFRAGMENTED_SIZE.  In the
former case, the processing of the OSCORE message continues as
defined in this document.  In the latter case the message SHALL be
discarded.
Paragraph (version A):
Proxy-Uri, when present, is split by OSCOAP into class U options and
class E options, which are processed accordingly.  When Proxy-Uri is
used in the original CoAP message, Uri-* are not present RFC7252.
Paragraph (version B):
Proxy-Uri, when present, is split by OSCORE into class U options and
class E options, which are processed accordingly.  When Proxy-Uri is
used in the original CoAP message, Uri-* are not present RFC7252.
Paragraph (version A):
The Proxy-Uri option of the OSCOAP message SHALL be set to the
composition of Proxy-Scheme, Uri-Host and Uri-Port options (if
present) as specified in section 6.5 of RFC7252, and processed as an
Outer option of Class U (outer-options).
Paragraph (version A):
Note that replacing the Proxy-Uri value with the Proxy-Scheme and
Uri-* options works by design for all CoAP URIs (see Section 6 of
RFC7252.  OSCOAP-aware HTTP servers should not use the userinfo
component of the HTTP URI (as defined in section 3.2.1. of RFC3986),
so that this type of replacement is possible in the presence of CoAP-
to-HTTP proxies.  In other documents specifying cross-protocol
proxying behavior using different URI structures, it is expected that
the authors will create Uri-* options that allow decomposing the
Proxy-Uri, and specify in which OSCOAP class they belong.
Paragraph (version B):
The Proxy-Uri option of the OSCORE message SHALL be set to the
composition of Proxy-Scheme, Uri-Host and Uri-Port options (if
present) as specified in section 6.5 of RFC7252, and processed as an
Outer option of Class U (outer-options).
Paragraph (version B):
Note that replacing the Proxy-Uri value with the Proxy-Scheme and
Uri-* options works by design for all CoAP URIs (see Section 6 of
RFC7252.  OSCORE-aware HTTP servers should not use the userinfo
component of the HTTP URI (as defined in section 3.2.1. of RFC3986),
so that this type of replacement is possible in the presence of CoAP-
to-HTTP proxies.  In other documents specifying cross-protocol
proxying behavior using different URI structures, it is expected that
the authors will create Uri-* options that allow decomposing the
Proxy-Uri, and specify in which OSCORE class they belong.
Paragraph (version B):
See Section 6.1 of RFC7252 for more information.
Paragraph (version A):
In order for an OSCOAP-unaware proxy to support forwarding of Observe
messages (RFC7641), there SHALL be an Outer Observe option, i.e.
present in the options part of the OSCOAP message.  The processing of
the CoAP Code for Observe messages is described in coap-header.
Paragraph (version B):
In order for an OSCORE-unaware proxy to support forwarding of Observe
messages (RFC7641), there SHALL be an Outer Observe option, i.e.,
present in the options part of the OSCORE message.  The processing of
the CoAP Code for Observe messages is described in coap-header.
Paragraph (version A):
Most CoAP header fields are required to be read and/or changed by
CoAP proxies and thus cannot in general be protected end-to-end
between the endpoints.  As mentioned in intro, OSCOAP protects the
CoAP Request/Response layer only, and not the Messaging Layer
(Section 2 of RFC7252), so fields such as Type and Message ID are not
protected with OSCOAP.
Paragraph (version A):
The CoAP header field Code is protected by OSCOAP.  Code SHALL be
encrypted and integrity protected (Class E) to prevent an
intermediary from eavesdropping or manipulating the Code (e.g.
changing from GET to DELETE).
Paragraph (version A):
The sending endpoint SHALL write the Code of the original CoAP
message into the plaintext of the COSE object plaintext.  After that,
the Outer Code of the OSCOAP message SHALL be set to 0.02 (POST) for
requests and to 2.04 (Changed) for responses, except for Observe
messages.  For Observe messages, the Outer Code of the OSCOAP message
SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for
responses.  The exception allows OSCOAP to be compliant with the
Observe processing in OSCOAP-unaware proxies.  The choice of POST and
FETCH allows all OSCOAP messages to have payload.
Paragraph (version A):
The receiving endpoint SHALL discard the Code in the OSCOAP message
and write the Code of the Plaintext in the COSE object (plaintext)
into the decrypted CoAP message.
Paragraph (version A):
The other CoAP header fields are Unprotected (Class U).  The sending
endpoint SHALL write all other header fields of the original message
into the header of the OSCOAP message.  The receiving endpoint SHALL
write the header fields from the received OSCOAP message into the
header of the decrypted CoAP message.
Paragraph (version A):
This section defines how to use COSE RFC8152 to wrap and protect data
in the original CoAP message.  OSCOAP uses the untagged COSE_Encrypt0
structure with an Authenticated Encryption with Additional Data
(AEAD) algorithm.  The key lengths, IV length, nonce length, and
maximum Sender Sequence Number are algorithm dependent.
Paragraph (version B):
Most CoAP header fields are required to be read and/or changed by
CoAP proxies and thus cannot in general be protected end-to-end
between the endpoints.  As mentioned in intro, OSCORE protects the
CoAP Request/Response layer only, and not the Messaging Layer
(Section 2 of RFC7252), so fields such as Type and Message ID are not
protected with OSCORE.
Paragraph (version B):
The CoAP header field Code is protected by OSCORE.  Code SHALL be
encrypted and integrity protected (Class E) to prevent an
intermediary from eavesdropping or manipulating the Code (e.g.,
changing from GET to DELETE).
Paragraph (version B):
The sending endpoint SHALL write the Code of the original CoAP
message into the plaintext of the COSE object plaintext.  After that,
the Outer Code of the OSCORE message SHALL be set to 0.02 (POST) for
requests and to 2.04 (Changed) for responses, except for Observe
messages.  For Observe messages, the Outer Code of the OSCORE message
SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for
responses.  The exception allows OSCORE to be compliant with the
Observe processing in OSCORE-unaware proxies.  The choice of POST and
FETCH allows all OSCORE messages to have payload.
Paragraph (version B):
The receiving endpoint SHALL discard the Code in the OSCORE message
and write the Code of the Plaintext in the COSE object (plaintext)
into the decrypted CoAP message.
Paragraph (version B):
The other CoAP header fields are Unprotected (Class U).  The sending
endpoint SHALL write all other header fields of the original message
into the header of the OSCORE message.  The receiving endpoint SHALL
write the header fields from the received OSCORE message into the
header of the decrypted CoAP message.
Paragraph (version B):
This section defines how to use COSE RFC8152 to wrap and protect data
in the original message.  OSCORE uses the untagged COSE_Encrypt0
structure with an Authenticated Encryption with Additional Data
(AEAD) algorithm.  The key lengths, IV length, nonce length, and
maximum Sender Sequence Number are algorithm dependent.
Paragraph (version A):
version: contains the OSCOAP version number.  Implementations of
this specification MUST set this field to 1.  Other values are
reserved for future versions.
Paragraph (version B):
version: contains the OSCORE version number.  Implementations of
this specification MUST set this field to 1.  Other values are
reserved for future versions.
Paragraph (version A):
In order to prevent response delay and mismatch attacks I-D.mattsson-
core-coap-actuators from on-path attackers and compromised proxies,
OSCOAP binds responses to the request by including the request's ID
(Sender ID or Recipient ID) and partial IV in the AAD of the
response.  The server therefore needs to store the request's ID
(Sender ID or Recipient ID) and partial IV until all responses have
been sent.
Paragraph (version B):
In order to prevent response delay and mismatch attacks I-D.mattsson-
core-coap-actuators from on-path attackers and compromised proxies,
OSCORE binds responses to the request by including the request's ID
(Sender ID or Recipient ID) and partial IV in the AAD of the
response.  The server therefore needs to store the request's ID
(Sender ID or Recipient ID) and partial IV until all responses have
been sent.
Paragraph (version A):
For requests, OSCOAP provides weak absolute freshness as the only
guarantee is that the request is not older than the security context.
For applications having stronger demands on request freshness (e.g.
control of actuators), OSCOAP needs to be augmented with mechanisms
providing freshness I-D.amsuess-core-repeat-request-tag.
Paragraph (version B):
For requests, OSCORE provides weak absolute freshness as the only
guarantee is that the request is not older than the security context.
For applications having stronger demands on request freshness (e.g.,
control of actuators), OSCORE needs to be augmented with mechanisms
providing freshness I-D.amsuess-core-repeat-request-tag.
Paragraph (version A):
For requests, and responses with Observe, OSCOAP also provides
relative freshness in the sense that the received Partial IV allows a
recipient to determine the relative order of responses.
Paragraph (version B):
For requests, and responses with Observe, OSCORE also provides
relative freshness in the sense that the received Partial IV allows a
recipient to determine the relative order of responses.
Paragraph (version A):
After boot, a node MAY reject to use existing security contexts from
before it booted and MAY establish a new security context with each
party it communicates.  However, establishing a fresh security
context may have a non-negligible cost in terms of e.g. power
consumption.
Paragraph (version B):
After boot, a node MAY reject to use existing security contexts from
before it booted and MAY establish a new security context with each
party it communicates.  However, establishing a fresh security
context may have a non-negligible cost in terms of, e.g., power
consumption.
Paragraph (version A):
For each stored security context, the first time after boot the
server receives an OSCOAP request, the server uses the Repeat
option I-D.amsuess-core-repeat-request-tag to get a request with
verifiable freshness and uses that to synchronize the replay
window.  If the server can verify the fresh request, the partial
IV in the fresh request is set as the lower limit of the replay
window.
Paragraph (version B):
For each stored security context, the first time after boot the
server receives an OSCORE request, the server uses the Repeat
option I-D.amsuess-core-repeat-request-tag to get a request with
verifiable freshness and uses that to synchronize the replay
window.  If the server can verify the fresh request, the partial
IV in the fresh request is set as the lower limit of the replay
window.
Paragraph (version A):
This section describes the OSCOAP message processing.
Paragraph (version B):
This section describes the OSCORE message processing.
Paragraph (version A):
Given a CoAP response, the server SHALL perform the following steps
to create an OSCOAP response.  Note that CoAP error responses derived
from CoAP processing (point 10. in ver-req) are protected, as well as
successful CoAP responses, while the OSCOAP errors (point 3., 4., 7.
in ver-req) do not follow the processing below, but are sent as
simple CoAP responses, without OSCOAP processing.
Paragraph (version B):
Given a CoAP response, the server SHALL perform the following steps
to create an OSCORE response.  Note that CoAP error responses derived
from CoAP processing (point 10. in ver-req) are protected, as well as
successful CoAP responses, while the OSCORE errors (point 3., 4., 7.
in ver-req) do not follow the processing below, but are sent as
simple CoAP responses, without OSCORE processing.
Paragraph (version A):
Process outer Block options according to RFC7959, until all blocks
of the OSCOAP message have been received, see block-options.
Paragraph (version B):
Process outer Block options according to RFC7959, until all blocks
of the OSCORE message have been received, see block-options.
Paragraph (version A):
The Concise Binary Object Representation (CBOR) RFC7049 combines very
small message sizes with extensibility.  The CBOR Object Signing and
Encryption (COSE) RFC8152 uses CBOR to create compact encoding of
signed and encrypted data.  COSE is however constructed to support a
large number of different stateless use cases, and is not fully
optimized for use as a stateful security protocol, leading to a
larger than necessary message expansion.  In this section, we define
a simple stateless compression mechanism for OSCOAP, which
significantly reduces the per-packet overhead.
Paragraph (version B):
The Concise Binary Object Representation (CBOR) RFC7049 combines very
small message sizes with extensibility.  The CBOR Object Signing and
Encryption (COSE) RFC8152 uses CBOR to create compact encoding of
signed and encrypted data.  COSE is however constructed to support a
large number of different stateless use cases, and is not fully
optimized for use as a stateful security protocol, leading to a
larger than necessary message expansion.  In this section, we define
a simple stateless compression mechanism for OSCORE, which
significantly reduces the per-packet overhead.
Paragraph (version A):
This section provides examples of COSE Objects before and after
OSCOAP compression.
Paragraph (version B):
This section provides examples of COSE Objects before and after
OSCORE compression.
Paragraph (version A):
The use of OSCOAP MAY be indicated by a target attribute "osc" in a
web link RFC5988 to a CoAP resource.  This attribute is a hint
indicating that the destination of that link is to be accessed using
OSCOAP.  Note that this is simply a hint, it does not include any
security context material or any other information required to run
OSCOAP.
Paragraph (version B):
The use of OSCORE MAY be indicated by a target attribute "osc" in a
web link RFC5988 to a resource.  This attribute is a hint indicating
that the destination of that link is to be accessed using OSCORE.
Note that this is simply a hint, it does not include any security
context material or any other information required to run OSCORE.
Paragraph (version A):
RFC7252 defines operations for a CoAP-to-CoAP proxy (see Section 5.7
of RFC7252) and for proxying between CoAP and HTTP (Section 10 of
RFC7252).  A more detailed description of the HTTP-to-CoAP mapping is
provided by RFC8075.  This section describes the operations of
OSCOAP-aware proxies.
Paragraph (version A):
OSCOAP is designed to work with legacy CoAP-to-CoAP forward proxies
RFC7252, but OSCOAP-aware proxies provide certain simplifications as
specified in this section.
Paragraph (version A):
The targeted proxy operations are specified in Section 2.2.1 of I-
D.hartke-core-e2e-security-reqs.  In particular caching is disabled
since the CoAP response is only applicable to the original client's
CoAP request.  A OSCOAP-aware proxy SHALL NOT cache a response to a
request with an Object-Security option.  As a consequence, the search
for cache hits and CoAP freshness/Max-Age processing can be omitted.
Paragraph (version B):
RFC 7252 defines operations for a CoAP-to-CoAP proxy (see Section 5.7
of RFC7252) and for proxying between CoAP and HTTP (Section 10 of
RFC7252).  A more detailed description of the HTTP-to-CoAP mapping is
provided by RFC8075.  This section describes the operations of
OSCORE-aware proxies.
Paragraph (version B):
OSCORE is designed to work with legacy CoAP-to-CoAP forward proxies
RFC7252, but OSCORE-aware proxies provide certain simplifications as
specified in this section.
Paragraph (version B):
The targeted proxy operations are specified in Section 2.2.1 of I-
D.hartke-core-e2e-security-reqs.  In particular caching is disabled
since the CoAP response is only applicable to the original client's
CoAP request.  A OSCORE-aware proxy SHALL NOT cache a response to a
request with an Object-Security option.  As a consequence, the search
for cache hits and CoAP freshness/Max-Age processing can be omitted.
Paragraph (version A):
Proxy processing of the (Outer) Observe option is as defined in
RFC7641.  OSCOAP-aware proxies MAY look at the Partial IV value
instead of the Outer Observe option.
Paragraph (version A):
As requested in Section 1 of RFC8075, this section describes the HTTP
mapping for the OSCOAP protocol extension of CoAP.
Paragraph (version A):
The presence of the Object-Security option, both in requests and
responses, is expressed in a HTTP header field named Object-Security
in the mapped request or response.  The value of the field is the
compressed COSE Object of the OSCOAP message in base64url encoding
without padding (see RFC7515 Appendix C for implementation notes for
this encoding).
Paragraph (version B):
Proxy processing of the (Outer) Observe option is as defined in
RFC7641.  OSCORE-aware proxies MAY look at the Partial IV value
instead of the Outer Observe option.
Paragraph (version B):
Section 10.2 of RFC7252 and RFC8075 specify the behavior of an HTTP-
to-CoAP proxy.  As requested in Section 1 of RFC8075, this section
describes the HTTP mapping for the OSCORE protocol extension of CoAP.
Paragraph (version B):
The presence of the Object-Security option, both in requests and
responses, is expressed in an HTTP header field named Object-Security
in the mapped request or response.  The value of the field is the
compressed COSE Object of the OSCORE message in base64url encoding
(Section 5 of RFC4648) without padding (see RFC7515 Appendix C for
implementation notes for this encoding).
Paragraph (version A):
In scenarios with intermediary nodes such as proxies or brokers,
transport layer security such as DTLS only protects data hop-by-hop.
As a consequence, the intermediary nodes can read and modify
information.  The trust model where all intermediate 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 brittle.
Paragraph (version B):
Section 10.1 of RFC7252 describes the behavior of a CoAP-to-HTTP
proxy.  RFC 8075 RFC8075 does not cover this direction in any more
detail and so an example instantiation of Section 10.1 of RFC7252 is
used below.
Paragraph (version B):
Note that the HTTP Code 2.04 (Changed) in the next-to-last message is
the mapping of HTTP Status Code 200, whereas the CoAP Code 2.05
(Content) in the last message is the value that was encrypted within
the compressed COSE object carried in the Body of the HTTP response.
Paragraph (version B):
In scenarios with intermediary nodes such as proxies or brokers,
transport layer security such as (D)TLS only protects data hop-by-
hop.  As a consequence, the intermediary nodes can read and modify
information.  The trust model where all intermediate 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 brittle.
Paragraph (version A):
DTLS protects hop-by-hop the entire CoAP message, including header,
options, and payload.  OSCOAP protects end-to-end the payload, and
all information in the options and header, that is not required for
proxy operations (see protected-fields).  DTLS and OSCOAP can be
combined, thereby enabling 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.  The CoAP
message layer, however, cannot be protected end-to-end through
intermediary devices since the parameters Type and Message ID, as
well as Token and Token Length may be changed by a proxy.
Paragraph (version A):
The use of COSE to protect CoAP messages as specified in this
document requires an established security context.  The method to
establish the security context described in context-derivation is
based on a common shared secret material in client and server, which
may be obtained e.g. by using the ACE framework I-D.ietf-ace-oauth-
authz.  An OSCOAP profile of ACE is described in I-D.seitz-ace-
oscoap-profile.
Paragraph (version B):
The use of COSE to protect messages as specified in this document
requires an established security context.  The method to establish
the security context described in context-derivation is based on a
common shared secret material in client and server, which may be
obtained, e.g., by using the ACE framework I-D.ietf-ace-oauth-authz.
An OSCORE profile of ACE is described in I-D.seitz-ace-oscoap-
profile.
Paragraph (version A):
The inner block options enable the sender to split large messages
into OSCOAP-protected blocks such that the receiving node can verify
blocks before having received the complete message.  The outer block
options allow for arbitrary proxy fragmentation operations that
cannot be verified by the endpoints, but can by policy be restricted
in size since the encrypted options allow for secure fragmentation of
very large messages.  A maximum message size (above which the sending
endpoint fragments the message and the receiving endpoint discards
the message, if complying to the policy) may be obtained as part of
normal resource discovery.
Paragraph (version B):
The inner block options enable the sender to split large messages
into OSCORE-protected blocks such that the receiving node can verify
blocks before having received the complete message.  The outer block
options allow for arbitrary proxy fragmentation operations that
cannot be verified by the endpoints, but can by policy be restricted
in size since the encrypted options allow for secure fragmentation of
very large messages.  A maximum message size (above which the sending
endpoint fragments the message and the receiving endpoint discards
the message, if complying to the policy) may be obtained as part of
normal resource discovery.
Paragraph (version A):
Privacy threats executed through intermediate nodes are considerably
reduced by means of OSCOAP.  End-to-end integrity protection and
encryption of CoAP payload and all options that are not used for
proxy operations, provide mitigation against attacks on sensor and
actuator communication, which may have a direct impact on the
personal sphere.
Paragraph (version B):
Privacy threats executed through intermediate nodes are considerably
reduced by means of OSCORE.  End-to-end integrity protection and
encryption of the message payload and all options that are not used
for proxy operations, provide mitigation against attacks on sensor
and actuator communication, which may have a direct impact on the
personal sphere.