Draft: draft-ietf-core-object-security

Commentary: This addresses and ( Use of different identifiers . This aligns with EDHOC ) This addresses and ( Remove multicast ) This ( definition and use of sid ) This partly addresses ( Use of different identifiers remove the need to use random cids with EDHOC and significantly reduces per packet overhead ) . This partly addresses ( Use of different identifiers remove the need to use random cids with EDHOC and reduces memory overhead ) . 
 This issue has been addressed by adding text on how applications can decrease memory usage , e.g. deleting security context parameters . Also shrinked the default length of the replay window . 
 OSCOAP uses COSE as an object security format . COSE is however constructed to support a large number of different stateless use cases , and is not fully optimized for use in a statefull security protocol , leading to a larger than necessary message expansion . In 6TiSCH working group , we would like to avoid fragmentation at all costs which is not easy with 80 - 90 bytes of available payload with IEEE 802.15.4 radios . Thus , it would be great if OSCOAP could define a compression mechanism to remove the redundant bytes from the COSE / CBOR encoding in the specific use - case of OSCOAP . 
 I 'll look into this . We do have some other preliminary ideas for reducing per - packet overhead when OSCOAP is used with EDHOC , and when OSCOAP is used without Observe . 
 could you give rough ideas on where things start to fragment ? reading through draft - ietf-6tisch - minimal - security-01 appendix A , i arrive at a request size of about 60 bytes from JN to JA , and about 64 bytes in the response . are those the ones that are problematic ( or can become problematic under realistic conditions ) , or is it the edhoc parts , which already exceed the 80 - 90 bytes in their payloads in some of the examples ( esp . message 2 ) in draft - selander - ace - cose - ecdhe-04 ? 
 Hi  , can you quantify that ?  ,     , Here is a quick example to quantify my issue . OSCOAP uses COSE_Encrypt0 struct of COSE . What will be present in each request is 1 ) array , 2 ) one protected headers map , 3 ) one unprotected headers map and 4 ) ciphertext . The unprotected headers map will typically be empty in OSCOAP case . Within the protected headers map , OSCOAP transports ' kid ' parameter and ' Partial IV ' parameter , each encoded with an associated label . If we were to transport a single array with the value of kid , Partial IV and ciphertext directly , we would be saving around 4 - 5 bytes with each OSCOAP message . Would that make sense ? 
 yes , we would like to avoid fragmentation in the PSK case which is what the example in Appendix A refers to . Note , however , that we are in the process of updating minimal - security draft and the message sizes given in the example change with latest updates . Namely , one will have to add 1 ) additional authentication tag and freshness indicator for the proxy to verify state information , 2 ) lease time with the short address and 3 ) other 802.15.4 - specific key information , so the example sizes will increase even in the PSK case . 
 I have thought about this issue quite a lot during the week . My view is that is both easy and possible to shave these 4 - 5 bytes . I will add a new appendix later today or tomorrow reducing the per - packet overhead further . The last weeks we have made at least four other significant chances that has reduced the per - packet overhead : Different " context " identifiers for client and sender No sequence number overhead in non - observe responses . No encrypted      is now MAY . 
 How will different context identifiers for client and sender benefit 6TiSCH ? As I read the current draft , the proxies even rely on them being the same ( and to be roundtripped by the server , and oversize ) for statelessness . 
 In the latest version of 6tisch - minimal - security draft , we have moved the statelessness mechanism to a new CoAP option so the information is no longer needed to be present as part of the context identifier . 
 The following optimizations have been included in the latest updates : COSE compression Different " context " identifiers for client and sender No sequence number overhead in non - observe responses . No encrypted      is now MAY . 
 Section 5 - You have defined a ' sid ' and said that it could be placed in the unprotected field , however you have also said that the unprotected field must be empty . These statements are contradictory 
 As per Christian Amsüss ' message from 2017 - 01 - 05 there still seems to be confusing text in that section . 
 Answering both to and ( ) The point here is : when defining the ' sid ' as a new COSE Header parameter , there is no reason related to security that would make this a " MUST be placed in the protected bucket " , so instead it is a MAY . But when used in OSCOAP , the ' sid ' is used in a way that it MUST be in the protected part , so the unprotected SHALL be empty . The ' sid ' is analogous to ' kid ' from this point of view , it is defined as a COSE parameter that MAY be unprotected , but is used protected . 
 Multicast removed in branch v-02 
 -00 Section 3.2.3 - You are getting ahead of yourself . The only way that the identifiers would not be unique would be if the sender and recipient collided . I do not know that this would be a problem and therefore talking about it makes no sense . I am assuming that this is supposed to have something to do with the multicast work that I have not looked at . If so it does not belong here but there . 
 Agree . I 'll delete all text on group communication from the document . 
 Multicast removed in branch v-02 
 Section 3.1 - I would think that you might be better off having the Cid be potentially different between the sender and receiver . Currently the closest you get in EDHOC would be to use the nonces , which are too long to be used here . 
 I think this might be a good idea , especially when used with EDHOC . The SessionIdentifier branch of EDHOC contain a specific ( short ) session identifier that would be perfect . I will make a study how and if this works with different use cases of OSCOAP ( EDHOC , non - EDHOC , Group communication , Non - Group communication ) . 
 I think this is a great idea . I looked into this and I think it works very well for all modes and deployment options , it might even simplify things . The current solution in EDHOC to derive random Cids makes them very large , and I keep hearing from radio people is that every single byte counts . Your idea would keep them minimal . I will wrote down a suggested update to OSCOAP and EDHOC before Chicago . Thanks for this great idea  .
Mailing list commentary: Hello OSCOAP authors , some more questions came up : 5.2 gives the context for the Encstructure as " Encrypted " , while cose - msg-24 would set a " Encrypt0 " . Why does that differ here ? 5 . states that the ' " unprotected " field [ ... ] SHALL be empty ' , but above states that sid ' can be placed in the unprotected headers bucket ' . How do those statements go together ? How are sequence numbers ( which are sorted integers ) mapped to partial IVs ? Which endianness is used ? ( The padding direction follows from cose - msg-24 3.1 ) . I 'd assume ( and implement ) that big - endian is used because it aligns naturally with COSE 's left - padding , but as I see it , that does not strictly follow from the draft . I concluded that the tag is always the last bytes of the ciphertext from example A.4 , but did not find text in the spec to support that ; what made me especially unsure about this is that the COSEEncrypt0 definition of cose - msg-24 5.2 only mentions the ciphertext there , which may be nil . Best regards Christian
Paragraph (version A):
The security context is the set of information elements necessary to
carry out the cryptographic operations in OSCOAP.  Each security
context is identified by a Context Identifier.  A Context Identifier
that is no longer in use can be reassigned to a new security context.
Paragraph (version A):
For each endpoint, the security context is composed by a "Common
Context", a "Sender Context" and a "Recipient Context".  The
endpoints protect messages to send using the Sender Context and
verify messages received using the Recipient Context, both contexts
being derived from the Common Context and other data.  Each endpoint
has a unique ID used to derive its Sender Context, this identifier is
called "Sender ID".  The Recipient Context is derived with the other
endpoint's ID, which is called "Recipient ID".  The Recipient ID is
thus the ID of the endpoint from which a CoAP message is received.
In communication between two endpoints, the Sender Context of one
endpoint matches the Recipient Context of the other endpoint, and
vice versa.  Thus the two security contexts identified by the same
Context Identifiers in the two endpoints are not the same, but they
are partly mirrored.  Retrieval and use of the security context are
shown in sec-context-ex.
Paragraph (version A):
Context Identifier (Cid).  Variable length byte string that
identifies the security context.  Its value is immutable once the
security context is established.
Paragraph (version B):
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 by a "Common Context", a "Sender
Context" and a "Recipient Context".  The endpoints protect messages
to send using the Sender Context and verify messages received using
the Recipient Context, both contexts being derived from the Common
Context and other data.  Each (Sender Context, Recipient Context)-
pair has a unique ID.  An endpoint uses its Sender ID (SID) to derive
its Sender Context, and the other endpoint uses the same ID, now
called Recipient ID (RID), to derive its Recipient Context.  In
communication between two endpoints, the Sender Context of one
endpoint matches the Recipient Context of the other endpoint, and
vice versa.  Thus the two security contexts identified by the same
IDs in the two endpoints are not the same, but they are partly
mirrored.  Retrieval and use of the security context are shown in
sec-context-ex.
Paragraph (version A):
The 3-tuple (Cid, Sender ID, Partial IV) is called Transaction
Identifier (Tid), and SHALL be unique for each Master Secret.  The
Tid is used as a unique challenge in the COSE object of the protected
CoAP request.  The Tid is part of the Additional Authenticated Data
(AAD, see sec-obj-cose) of the protected CoAP response message, which
is how responses are bound to requests.
Paragraph (version B):
The 3-tuple (Sender ID, Partial IV) is called Transaction Identifier
(Tid), and SHALL be unique for each Base Key. The Tid is used as a
unique challenge in the COSE object of the protected CoAP request.
The Tid is part of the Additional Authenticated Data (AAD, see sec-
obj-cose) of the protected CoAP response message, which is how
responses are bound to requests.
Paragraph (version A):
As mentioned, Cid is pre-established.  How this is done is
application specific, but it is RECOMMENDED that the application uses
64-bits long pseudo-random Cids, in order to have globally unique
Context Identifiers.  Cid SHOULD be unique in the sets of all
security contexts used by all the endpoints.  If it is not the case,
it is the role of the application to specify how to handle
collisions.
Paragraph (version A):
If the application has total control of both clients and servers,
shorter unique Cids MAY be used.  Note that Cids of different lengths
can be used by different clients and that e.g. a Cid with the value
0x00 is different from the Cid with the value 0x0000.
Paragraph (version A):
In the same phase during which the Cid is established in the
endpoint, the application informs the endpoint what resources can be
accessed using the corresponding security contexts.  Resources that
are accessed with OSCOAP are called "protected" resources.  The set
of resources that can be accessed using a certain security context is
decided by the application (resource, host, etc.).  The client SHALL
save the association resource-Cid, in order to be able to retrieve
the correct security context to access a protected resource.  The
server SHALL save the association resource-Cid, in order to determine
whether a particular resource may be accessed using a certain Cid.
Paragraph (version A):
The Sender ID and Recipient ID SHALL be unique in the set of all
endpoints using the same security context.  Collisions may lead to
the loss of both confidentiality and integrity.  If random IDs are
used, they MUST be long enough so that the probability of collisions
is negligible.
Paragraph (version B):
The Sender ID and Recipient ID are pre-established, and how this is
done is application specific.  As collisions may lead to the loss of
both confidentiality and integrity, the Sender ID SHALL be unique in
the set of all endpoints using the same Master Secret.  Normally
(e.g. when using EDHOC) Sender IDs can be very short.  Note that
Sender IDs of different lengths can be used with the same Master
Secret.  E.g. the SID with value 0x00 is different from the SID with
the value 0x0000.  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):
To enable retrieval of the right Recipient Context, the Recipient ID
SHOULD be unique in the sets of all Recipent Contexts used by an
endpoint.
Paragraph (version B):
In the same phase during which the Sender ID and Recipient ID are
established in the endpoint, the application informs the endpoint
what resources can be accessed using the corresponding security
contexts.  Resources that are accessed with OSCOAP are called
"protected" resources.  The set of resources that can be accessed
using a certain security context is decided by the application
(resource, host, etc.).  The client SHALL save the association
resource-SID, in order to be able to retrieve the correct security
context to access a protected resource.  The server SHALL save the
association resource-RID, in order to determine whether a particular
resource may be accessed using a certain context.
Paragraph (version A):
This parameter is used to identify the sender of the message.
Applications MUST NOT assume that 'sid' values are unique.  This
is not a security critical field.  For this reason, it can be
placed in the unprotected headers bucket.
Paragraph (version A):
The "kid" parameter.  The value is set to the Context
Identifier (see sec-context-section).  This parameter is
optional if the message is a CoAP response.
Paragraph (version A):
Optionally, the parameter called "sid", defined below.  The
value is set to the Sender ID (see sec-context-section).
Note that since this parameter is sent in clear, privacy
issues SHOULD be considered by the application defining the
Sender ID.
Paragraph (version B):
The "kid" parameter.  The value is set to the Sender ID (see
sec-context-section).
Paragraph (version A):
cid : bstr, contains the cid for the request (which is same as the
cid for the response).
Paragraph (version A):
id : bstr, is the identifier for the endpoint sending the request
and verifying the response; which means that for the endpoint
sending the response, the id has value Recipient ID, while for the
endpoint receiving the response, id has the value Sender ID.
Paragraph (version A):
seq : bstr, is the value of the "Partial IV" in the COSE object of
the request (see Section 5).
Paragraph (version B):
id : bstr, is the identifier for the endpoint sending the
request and verifying the response; which means that for the
endpoint sending the response, the id has value Recipient ID,
while for the endpoint receiving the response, id has the value
Sender ID.
Paragraph (version B):
seq : bstr, is the value of the "Partial IV" in the COSE object
of the request (see Section 5).
Paragraph (version B):
tag-previous-block: bstr, contains the AEAD Tag of the message
containing the previous block in the sequence, as enumerated by
Block1 in the case of a request and Block2 in the case of a
response, if the message is fragmented using a block option
RFC7959.
Paragraph (version A):
A receiving endpoint SHALL verify that the Sequence Number (Partial
IV) received in the COSE object has not been received before in the
security context identified by the Cid. The size of the Replay Window
depends on the use case and lower protocol layers.  In case of
reliable and ordered transport, the recipient MAY just store the last
received sequence number and require that newly received Sequence
Numbers equals the last received Recipient Sequence Number + 1.
Paragraph (version B):
A receiving endpoint SHALL verify that the Sequence Number (Partial
IV) received in the COSE object has not been received before in the
Recipient Context identified by the kid.  The size of the Replay
Window depends on the use case and lower protocol layers.  In case of
reliable and ordered transport, the recipient MAY just store the last
received sequence number and require that newly received Sequence
Numbers equals the last received Recipient Sequence Number + 1.
Paragraph (version A):
Given an unprotected CoAP request, including header, options and
payload, the client SHALL perform the following steps to create a
protected CoAP request using a security context associated with the
target resource (see cid-est).
Paragraph (version B):
Given an unprotected CoAP request, including header, options and
payload, the client SHALL perform the following steps to create a
protected CoAP request using a security context associated with the
target resource (see id-est).
Paragraph (version A):
Store the association Token - Cid. The Client SHALL be able to
find the correct security context used to protect the request and
verify the response with use of the Token of the message exchange.
Paragraph (version B):
Store the association Token - Security Context.  The Client SHALL
be able to find the correct security context used to protect the
request and verify the response with use of the Token of the
message exchange.
Paragraph (version A):
A CoAP server receiving an unprotected CoAP request to access a
protected resource (as defined cid-est) SHALL reject the message with
error code 4.01 (Unauthorized).
Paragraph (version B):
A CoAP server receiving an unprotected CoAP request to access a
protected resource (as defined id-est) SHALL reject the message with
error code 4.01 (Unauthorized).