Draft: draft-ietf-core-object-security

Commentary: This Partly addresses 
 Clarify that maximum sequence number is algorithm dependant and define a formula for it . 
 May be simpler to just have a single structure for the externalaad . externalaad = [ ver : uint , code : uint , alg : int , i d : bstr , seq : bstr , ? tag - previous - block : bstr ] 
 the " context " parameter , which has value " Encrypted " This should be " Encrypt0 " , but even better OSCOAP should just point to draft - ietf - cose - msg that already specifies this . 
 -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
Paragraph (version A):
This section defines how to use the COSE format I-D.ietf-cose-msg to
wrap and protect data in the unprotected CoAP message.  OSCOAP uses
the COSE_Encrypt0 structure with an Authenticated Encryption with
Additional Data (AEAD) algorithm.
Paragraph (version A):
The AEAD algorithm AES-CCM-64-64-128 defined in Section 10.2 of I-
D.ietf-cose-msg is mandatory to implement.  For AES-CCM-64-64-128 the
length of Sender Key and Recipient Key SHALL be 128 bits, the length
of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the
maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as
described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the
Partial IV (Sequence Number in network byte order) with zeroes and
XORing it with the context IV (Sender IV or Recipient IV).
Paragraph (version A):
Since OSCOAP only makes use of a single COSE structure, there is no
need to explicitly specify the structure, and OSCOAP uses the
untagged version of the COSE_Encrypt0 structure (Section 2. of I-
D.ietf-cose-msg).  If the COSE object has a different structure, the
recipient MUST reject the message, treating it as malformed.
Paragraph (version A):
We denote by Plaintext the data that is encrypted and integrity
protected, and by Additional Authenticated Data (AAD) the data that
is integrity protected only, in the COSE object.
Paragraph (version A):
The fields of COSE_Encrypt0 structure are defined as follows (see
example in sem-auth-enc).
Paragraph (version A):
The "Partial IV" parameter.  The value is set to the Sender
Sequence Number.  The Partial IV is a byte string (type:
bstr), and SHOULD be of minimum length needed to encode the
sequence number.
Paragraph (version A):
The "kid" parameter.  The value is set to the Sender ID (see
sec-context-section).
Paragraph (version A):
The "unprotected" field, which SHALL be empty.
Paragraph (version A):
The "ciphertext" field is computed from the Plaintext (see
plaintext) and the Additional Authenticated Data (AAD) (see AAD)
and encoded as a byte string (type: bstr), following Section 5.2
of I-D.ietf-cose-msg.
Paragraph (version A):
the CoAP Payload, if present, and in that case prefixed by the
one-byte Payload Marker (0xFF).
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 A):
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 B):
This section defines how to use COSE I-D.ietf-cose-msg to wrap and
protect data in the unprotected CoAP message.  OSCOAP uses the
untagged COSE_Encrypt0 structure with an Authenticated Encryption
with Additional Data (AEAD) algorithm.  The key lengths, IV lengths,
and maximum sequence number are algorithm dependent.  The maximum
sequence number SHALL be 2^(nonce length in bits - 1) - 1.
Paragraph (version B):
The AEAD algorithm AES-CCM-64-64-128 defined in Section 10.2 of I-
D.ietf-cose-msg is mandatory to implement.  For AES-CCM-64-64-128 the
length of Sender Key and Recipient Key is 128 bits, the length of
nonce, Sender IV, and Recipient IV is 7 bytes, and the maximum
Sequence Number is 2^55 - 1.
Paragraph (version B):
The nonce is constructed as described in Section 3.1 of I-D.ietf-
cose-msg, i.e. by padding the partial IV (Sequence Number in network
byte order) with zeroes and XORing it with the context IV (Sender IV
or Recipient IV).  The first bit in the Sender IV or Recipient IV
SHALL be flipped in responses.
Paragraph (version B):
We denote by Plaintext the data that is encrypted and integrity
protected, and by Additional Authenticated Data (AAD) the data that
is integrity protected only.
Paragraph (version B):
The "Partial IV" parameter.  The value is set to the Sender
Sequence Number.  The Partial IV SHALL be of minimum length
needed to encode the sequence number.  This parameter SHALL be
present in requests, and MAY be present in responses.
Paragraph (version B):
The "kid" parameter.  The value is set to the Sender ID (see
sec-context-section).  This parameter SHALL be present in
requests.
Paragraph (version B):
The "unprotected" field is empty.
Paragraph (version B):
The "ciphertext" field is computed from the Plaintext (see
plaintext) and the Additional Authenticated Data (AAD) (see AAD)
following Section 5.2 of I-D.ietf-cose-msg.
Paragraph (version B):
the Payload of unprotected CoAP message, if present, and in that
case prefixed by the one-byte Payload Marker (0xFF).
Paragraph (version B):
ver: uint, contains the CoAP version number, as defined in
Section 3 of RFC7252.
Paragraph (version B):
alg: int, contains the Algorithm from the security context used
for the exchange (see sec-context-def-section).
Paragraph (version B):
request_id : bstr, contains 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):
request_seq : bstr, contains the value of the "Partial IV" in the
COSE object of the request (see Section 5).