[core] OSCORE Inner/Outer duplication

[Michael Richardson]

section 4.0 of draft-ietf-core-object-security ends with:

An OSCORE message may contain both an Inner and an Outer instance of
a certain CoAP message field. Inner message fields are intended for
the receiving endpoint, whereas Outer message fields are used to
enable proxy operations. Inner and Outer message fields are
processed independently.

In Outer instance of a CoAP message field will be integrity protected if it's
in the class I message area. Changes to it would cause the integrity check
to fail and the entire message to be rejected. Such a message field is
effectively read-only to proxies.

If the message field instance is in the class U bucket, then it could be
modified by proxies. If an instance also exists in the E or I buckets,
then a receiver could determine if the copy in U bucket had been modified,
assuming it is reasonable for the message fields to be the same!

I think that the above text in section 4.0 should indicate that the two
occurances of the fields (Inner and Outer) are semantically different, and
receivers SHOULD NOT attempt to make sure they are identical.

OSCORE uses this in 4.1.3.5. No-Response in different ways, for instance.

[Göran Selander]

Hi Michael,

Thanks for comments. The last sentence of the paragraph you referred to is
a remnant from an older version of the specification. The processing of
Inner and Outer are dependent on the message field in question, so in fact
neither this statement nor the the statement you suggested are valid in
general. We will try to make the description more clear on this point in
the next update.

Thanks
Göran


On 2018-04-28, 19:34, "core on behalf of Michael Richardson"

Post by Michael Richardson
An OSCORE message may contain both an Inner and an Outer instance of
a certain CoAP message field. Inner message fields are intended for
the receiving endpoint, whereas Outer message fields are used to
enable proxy operations. Inner and Outer message fields are
processed independently.
In Outer instance of a CoAP message field will be integrity protected if it's
in the class I message area. Changes to it would cause the integrity check
to fail and the entire message to be rejected. Such a message field is
effectively read-only to proxies.
If the message field instance is in the class U bucket, then it could be
modified by proxies. If an instance also exists in the E or I buckets,
then a receiver could determine if the copy in U bucket had been modified,
assuming it is reasonable for the message fields to be the same!
I think that the above text in section 4.0 should indicate that the two
occurances of the fields (Inner and Outer) are semantically different, and
receivers SHOULD NOT attempt to make sure they are identical.
OSCORE uses this in 4.1.3.5. No-Response in different ways, for instance.
--
-= IPv6 IoT consulting =-