Draft: draft-ietf-core-object-security

Commentary: This PR should ( hopefully ) conclude the main rewrite of Observe which was triggered by the security analysis and additional reviews of Observe . It should ( hopefully ) now be clear what part of the Observe related processing can be omitted in case Observe is not supported or in case intermediaries are not used . A new appendix E is covering the latter case .
Paragraph (version A):
Observe RFC7641 is an optional feature.  An implementation MAY
support RFC7252 and the OSCORE option without supporting RFC7641.
The Observe option as used here targets the requirements on
forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1).
Paragraph (version A):
To support proxy operations, OSCORE MUST set Outer Observe.  If
Observe was only sent encrypted end-to-end, an OSCORE-unaware proxy
would not expect several responses to a request and notifications
would not reach the endpoint.  Moreover, intermediaries are allowed
to cancel observations at any time; forbidding this behavior would
also result in notifications being dropped.
Paragraph (version A):
An intermediary that supports Observe MUST copy the OSCORE option in
the next hop request unchanged.  It is worth noting that although
intermediaries are allowed to re-send notifications to other clients,
when using OSCORE this does not happen, since requests from different
clients will have different cache keys.
Paragraph (version A):
In case of registrations or re-registrations, the CoAP client using
Observe with OSCORE MUST set both Inner and Outer Observe to the same
value (0).  This allows the server to verify that the observation was
requested by the client, thereby avoiding unnecessary overhead
(processing and transmission of notifications) on the server, since
such notifications would not benefit the client.
Paragraph (version A):
Note that, as defined in Section 3.1 of RFC7641, the target resource
for Observe registration is identified by all options in the request
that are part of the Cache-Key, including OSCORE.  This means that
several clients registering to the same protected resource via an
intermediary, when using OSCORE, will be effectively registering to
different target resources.  The intermediary may then register to
the protected resource (different target resources) once per each
client.
Paragraph (version A):
The processing of the CoAP Code for Observe messages is described in
coap-header.
Paragraph (version A):
The Outer Observe option in the CoAP request may be legitimately
removed by a proxy or ignored by the server.  In these cases, the
server processes the request as a non-Observe request and produce a
non-Observe response.  If the OSCORE client receives a response to an
Observe request without an Outer Observe value, then it verifies the
response as a non-Observe response, as specified in ver-res.  If the
OSCORE client receives a response to a non-Observe request with an
Outer Observe value, it stops processing the message, as specified in
ver-res.
Paragraph (version B):
Observe RFC7641 is an optional feature.  An implementation MAY
support RFC7252 and the OSCORE option without supporting RFC7641, in
which case the Observe related processing specified in this section,
sequence-numbers and processing can be omitted.
Paragraph (version B):
The Observe option as used here targets the requirements on
forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1).
This section specifies Observe processing associated to the Partial
IV (observe-partial-iv) and Observe processing in the presence of
RFC7641-compliant intermediaries (observe-option-processing).
Paragraph (version B):
In contrast to e.g. block-wise, the Inner and Outer Observe option
are not processed independently.  Outer Observe is required to
support Observe operations in intermediaries, but the additional use
of Inner Observe is needed to protect Observe registrations end-to-
end (see observe-option-processing). observe-without-intermed
specifies a simplified Observe processing which is applicable in the
absence of intermediaries.
Paragraph (version B):
Note that OSCORE is compliant with the requirement that a client must
not register more than once for the same target resource (see
Section 3.1 of RFC7641) since the target resource for Observe
registration is identified by all options in the request that are
part of the Cache-Key, including OSCORE.
Paragraph (version B):
To support proxy operations, the CoAP client using Observe with
OSCORE MUST set Outer Observe.  If Observe was only sent encrypted
end-to-end, an OSCORE-unaware proxy would not expect several
responses to a non-Observe request and notifications would not reach
the client.  Moreover, intermediaries are allowed to cancel
observations and inform the server; forbidding this may result in
processing and transmission of notifications on the server side which
do not reach the client.
Paragraph (version B):
In case of registrations or re-registrations, the CoAP client using
Observe with OSCORE MUST set both Inner and Outer Observe to the same
value (0).  This allows the server to verify that the observation was
requested by the client, thereby avoiding unnecessary processing and
transmission of notifications, since such notifications would not
benefit the client.
Paragraph (version B):
An intermediary that supports Observe MUST copy the OSCORE option in
the next hop request unchanged.  Although intermediaries are allowed
to re-send notifications to other clients, when using OSCORE this
does not happen, since requests from different clients will have
different cache keys.
Paragraph (version B):
The Outer Observe option in the CoAP request may be legitimately
removed by a proxy or ignored by a server.  In these cases, the
server processes the request as a non-Observe request and produce a
non-Observe response.  If the OSCORE client receives a response to an
Observe request without an Outer Observe value, then it verifies the
response as a non-Observe response, as specified in ver-res.  If the
OSCORE client receives a response to a non-Observe request with an
Outer Observe value, it stops processing the message, as specified in
ver-res.
Paragraph (version B):
In order to support Observe processing in OSCORE-unaware
intermediaries, for messages with the Observe option the Outer Code
SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for
responses.
Paragraph (version A):
protection.  The client MAY ignore the Observe option value.
Paragraph (version A):
Clients can re-register observations to ensure that the observation
is still active and establish freshness again (RFC7641
Section 3.3.1).  When an OSCORE observation is refreshed, not only
the ETags, but also the partial IV (and thus the payload and OSCORE
option) change.  The server uses the new request's Partial IV as the
'request_piv' of new responses.
Paragraph (version B):
protection.
Paragraph (version B):
Clients can re-register observations to ensure that the observation
is still active and establish freshness again (RFC7641
Section 3.3.1).  When an OSCORE protected observation is refreshed,
not only the ETags, but also the partial IV (and thus the payload and
OSCORE option) change.  The server uses the new request's Partial IV
as the 'request_piv' of new responses.
Paragraph (version A):
The sending endpoint SHALL write the Code of the original CoAP
message into the plaintext of the COSE object (see plaintext).  After
that, the sending endpoint writes an Outer Code to the OSCORE
message.  The Outer Code SHALL be set to 0.02 (POST) or 0.05 (FETCH)
for requests.  For non-Observe requests the client SHALL set the
Outer Code to 0.02 (POST).  For responses, the sending endpoint SHALL
respond with Outer Code 2.04 (Changed) to 0.02 (POST) requests, and
with Outer Code 2.05 (Content) to 0.05 (FETCH) requests.  Using FETCH
with Observe allows OSCORE to be compliant with the Observe
processing in OSCORE-unaware intermediaries.  The choice of POST and
FETCH RFC8132 allows all OSCORE messages to have payload.
Paragraph (version A):
The receiving endpoint SHALL discard the Outer Code in the OSCORE
message and write the Code of the COSE object plaintext (plaintext)
into the decrypted CoAP message.
Paragraph (version B):
The sending endpoint SHALL write the Code of the original CoAP
message into the plaintext of the COSE object (see plaintext).  After
that, the sending endpoint writes an Outer Code to the OSCORE
message.  With one exeception (see observe-option-processing) the
Outer Code SHALL by default be set to 0.02 (POST) for requests and to
the Outer Code in the OSCORE message and write the Code of the COSE
object plaintext (plaintext) into the decrypted CoAP message.
Paragraph (version A):
Observe allows re-registration of observations (see 3.3.1 of
RFC7641).  A server receiving an Observe registration identical to a
previously stored one (including Partial IV and Token) SHALL treat it
as valid and reply with the last notification sent.
Paragraph (version A):
A client receiving a notification SHALL compare the Partial IV of a
received notification with the Notification Number associated to that
Observe registration.  Observe reordering MUST be linked to OSCORE's
ordering of notifications.  The client MAY do so by copying the least
significant bytes of the Partial IV into the Observe option, before
passing it to CoAP processing.  If the verification of the response
succeeds, and the received Partial IV was greater than the
Notification Number, then the client SHALL update the corresponding
Notification Number with the received Partial IV.  The client MUST
stop processing notifications with a Partial IV which has been
previously received.  An application MAY require the client to
discard notifications which have Partial IV less than the
Notification Number.
Paragraph (version B):
A client receiving a notification SHALL compare the Partial IV of a
received notification with the Notification Number associated to that
Observe registration.  The ordering of notifications after OSCORE
processing MUST be aligned with the Partial IV.  The client MAY do so
by copying the least significant bytes of the Partial IV into the
Observe option, before passing it to CoAP processing.  The client MAY
ignore an Outer Observe option value.  If the verification of the
response succeeds, and the received Partial IV was greater than the
Notification Number, then the client SHALL update the corresponding
Notification Number with the received Partial IV.  The client MUST
stop processing notifications with a Partial IV which has been
previously received.  An application MAY require the client to
discard notifications which have Partial IV less than the
Notification Number.
Paragraph (version B):
In order to allow intermediaries to re-register their interest in a
resource (see 3.3.1 of RFC7641), a server receiving an Observe
registration with Token, Kid and Partial IV identical to a previously
received registration, and which decrypts without error SHALL not
treat it as a replay and SHALL respond with a notification.  The
notification may be a cached copy of the latest sent notification
(with the same Token, Kid and Partial IV) or it may be a newly
generated notification with a fresh Partial IV.
Paragraph (version A):
Otherwise, discard both the Outer and Inner (if present)
Observe options.
Paragraph (version A):
If the value of Observe in the Outer message is not 0, discard
decrypted Observe option if present.
Paragraph (version A):
C.  If the message is an Observe registration, store it in memory for
later comparison with re-registrations (see replay-protection).
Paragraph (version A):
D.  If the message is an Observe cancellation, delete from memory the
previously stored registration related to that observation (see
replay-protection).
Paragraph (version B):
B.  If Observe is present in the received message, and has value 0,
check if the Token, Kid and Partial IV are identical to a previously
received Observe registration.  In this case, replay verification is
postponed until step C.  Otherwise verify the 'Partial IV' parameter
using the Replay Window, as described in replay-protection.
Paragraph (version B):
Otherwise, discard both the Outer and Inner (if present)
Observe options and verify the 'Partial IV' parameter using the
Replay Window, as described in replay-protection.
Paragraph (version B):
If the value of Observe in the Outer message is not 0, discard the
decrypted Observe option if present.
Paragraph (version A):
B.  If the message is an Observe notification, store it in memory for
use with re-registrations (see replay-protection), and delete from
memory any older one previously stored.