Draft: draft-ietf-core-object-security

Commentary: Back to one processing description Observe is now primarily inner  processing Explicit cancellation by intermediary not supported
Paragraph (version A):
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 A):
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 A):
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 A):
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 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 processing and
transmission of notifications, since such notifications would not
benefit the client.
Paragraph (version A):
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 A):
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 A):
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 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 can be omitted.
Paragraph (version B):
OSCORE supports a reduced set of RFC7641 operations performed in
intermediary nodes as specified in this section.  The use of Observe
targets the requirements on forwarding of Section 2.2.1 of I-
D.hartke-core-e2e-security-reqs, i.e. that observations go through
any intermediate node, as illustrated in Figure 8 of RFC7641).
Paragraph (version B):
Inner Observe is used by default to protect the value of the Observe
option between the endpoints.  Outer Observe is additionally used to
support a selected set of intermediate node operations that are
useful while maintaining end-to-end security.  Intermediary nodes
MUST copy the OSCORE option in the next hop request unchanged.
Paragraph (version B):
In order to support Observe processing in OSCORE-unaware
intermediaries, for messages with the Observe option the Outer Code
MUST be set to 0.05 (FETCH) for requests and to 2.05 (Content) for
responses.
Paragraph (version B):
The client MUST set both Inner and Outer Observe to the same value in
the request.  In order to support the case of an intermediary node
ignoring a registration request (Observe 0) and instead processing a
non-Observe request (Section 2 of RFC7641), the server MUST only
consider the received message a registration request if both Inner
and Outer Observe are set to 0.
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 Partial IV of the new
request as the 'request_piv' of new responses.
Paragraph (version B):
Since intermediaries are not assumed to have a security context with
the server, cancellation or re-registration of an observation
initiated by an intermediary node is not supported.
Paragraph (version B):
Cancellation of observation by an intermediary using the Reset
message as response to a notification can still be applied.
Paragraph (version B):
An intermediary node may forward a re-registration message, but if
a proxy re-sends an old registration message from a client this
will trigger the replay protection mechanism in the server which,
depending on action, may result in a termination of the
observation in proxy or client.  An OSCORE aware intermediary
SHALL NOT initiate re-registrations of observations.  A server MAY
respond to a replayed registration request with a cached
notification.  The server SHALL NOT respond to a replayed
registration request with a message encrypted using the Partial IV
of the request.
Paragraph (version A):
If the server accepts an Observe registration, a Partial IV MUST be
included in all notifications (both successful and error).  To secure
the order of notifications, the client SHALL maintain a Notification
Number for each Observation it registers.  The Notification Number is
a non-negative integer containing the largest Partial IV of the
received notifications for the associated Observe registration (see
replay-protection).  The Notification Number is initialized to the
Partial IV of the first successfully received notification response
to the registration request.  In contrast to RFC7641, the received
Partial IV MUST always be compared with the Notification Number,
which thus MUST NOT be forgotten after 128 seconds.  Further details
of replay protection of notifications are specified in replay-
protection.
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 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 B):
If the server accepts an Observe registration, a Partial IV MUST be
included in all notifications (both successful and error).  To secure
the order of notifications, the client SHALL maintain a Notification
Number for each Observation it registers.  The Notification Number is
a non-negative integer containing the largest Partial IV of the
received notifications for the associated Observe registration.
Further details of replay protection of notifications are specified
in replay-notifications.
Paragraph (version B):
The Inner Observe in a response MUST either have the value of Observe
in the original CoAP message or be empty.  The former is used to
allow the server to set the Observe values to be received by the
client.  In the latter case the overhead of the Observe value is
saved and instead the least significant bytes of the Partial IV is
used as Observe value, see replay-notifications.  The Outer Observe
in the response may be needed for intermediary nodes to support
multiple responses to one request.  The client MAY ignore the Outer
Observe value.
Paragraph (version B):
If the client receives a response to an Observe request without an
Observe value, then it verifies the response as a non-Observe
response, as specified in ver-res.  If the client receives a response
to a non-Observe request with an Observe value, then it stops
processing the message but keeps the observation alive, as specified
in ver-res.
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.  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 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) the Outer Code SHALL by
default be set to 0.02 (POST) for requests and to 2.04 (Changed) for
responses.  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 A):
Additionally to the previous section, the following applies when
Observe is supported.
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.  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 A):
If messages are processed concurrently, the Partial IV needs to be
validated a second time after decryption and before updating the
replay protection data.  The operation of validating the Partial IV
and updating the replay protection data MUST be atomic.
Paragraph (version A):
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 B):
The following applies additionally when Observe is supported.
Paragraph (version B):
The Notification Number is initialized to the Partial IV of the first
successfully received notification response to the registration
request.  A client receiving a notification SHALL compare the Partial
IV of a verified notification with the Notification Number associated
to that Observe registration.  In contrast to RFC7641, the received
Partial IV MUST always be compared with the Notification Number,
which thus MUST NOT be forgotten after 128 seconds.
Paragraph (version B):
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 operation of validating the Partial IV and updating
the replay protection data MUST be atomic.  If the Inner Observe
option is empty, then the client SHALL copy the least significant
bytes of the Partial IV into the Observe option, before passing it to
CoAP processing.
Paragraph (version B):
If the Partial IV is less than or equal to the Notification Number,
then the client SHALL stop processing the response but not cancel the
observation.
Paragraph (version A):
The client rejects notifications bound to the earlier
registration, removes all Notification Numbers and re-registers
using Observe.
Paragraph (version B):
The client forgets about earlier registrations, removes all
Notification Numbers and re-registers using Observe.
Paragraph (version A):
A.  Discard Code and all options marked in fig-option-protection with
'x' in column E, except for Observe, present in the received message.
For example, an If-Match Outer option is discarded, Uri-Host Outer
option is not discarded, Observe is not discarded.
Paragraph (version A):
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 A):
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 A):
If the value of Observe in the Outer message is not 0, discard the
decrypted Observe option if present.
Paragraph (version B):
A.  Check if the Outer Observe option is present and has value zero.
Paragraph (version B):
B.  If Inner Observe is present and has value zero, and Outer option
is either not present or has not value 0, then remove the Observe
option.
Paragraph (version A):
A.  Discard Code and all options marked in fig-option-protection with
'x' in column E, except for Observe, present in the received message.
For example, ETag Outer option is discarded, as well as Max-Age Outer
option, Observe is not discarded.
Paragraph (version A):
B.  If the Observe option is present in the response, but the request
was not an Observe registration, then go to 9.
Paragraph (version A):
C.  If an Observe option is included or the Notification number for
the observation has already been initiated, but the Partial IV is not
present in the response, then go to 9.
Paragraph (version A):
D.  For Observe notifications, verify the received 'Partial IV'
parameter against the corresponding Notification Number as described
in replay-protection.
Paragraph (version A):
E.  If the response is a notification, initiate or update the
corresponding Notification Number, as described in sequence-numbers.
Otherwise, delete the attribute-value pair (Token, {Security Context,
PIV}).
Paragraph (version A):
F.  Add decrypted Code, options and payload to the decrypted request,
except for decrypted Observe if present.  The OSCORE option is
removed.
Paragraph (version A):
An error condition occurring while processing a response in an
observation does not cancel the observation.  A client MUST NOT react
to failure in step 5 by re-registering the observation immediately.
Paragraph (version B):
If the request was not an Observe registration, then go to 9.
Paragraph (version B):
If the Partial IV was not present in the response, then go to 9.
Paragraph (version B):
If the request was an Observe registration and the Partial IV was
present in the response, then verify the received 'Partial IV'
parameter against the corresponding Notification Number, and
follow the processing described in replay-notifications.
Otherwise, delete the attribute-value pair (Token, {Security
Context, PIV}).
Paragraph (version B):
B.  In case any of the previous erroneous conditions apply: the
client SHALL stop processing the response.  An error condition
occurring while processing a response in an observation does not
cancel the observation.  A client MUST NOT react to failure by re-
registering the observation immediately.
Paragraph (version B):
Note that the attribute-value attribute-value pair (Token, {Security
Context, PIV}) MUST be deleted whenever the Observation is cancelled
or "forgotten".