Re: [core] OSCOAP: roll-out, recipient seqno, option number, sequence numbers

[Göran Selander <[e-mail]>]

Hi Christian,

Thanks for very good comments, apologies for slow response. Jim has
already provided some answers, here are some more.

On 2017-01-06 03:56, "Jim Schaad" <[e-mail]> wrote:

>Christian,
>
>While not an author on the drafts, I will take a stab at giving
>clarification to your points.
>
>See response below,
>
>Jim
>
>
>> -----Original Message-----
>> From: core [mailto:[e-mail]] On Behalf Of Christian Amsüss
>> Sent: Wednesday, January 04, 2017 1:12 AM
>> To: [e-mail]; [e-mail]
>> Subject: [core] OSCOAP: roll-out, recipient seqno, option number,
>>sequence
>> numbers
>> 
>> Hello OSCOAP authors,
>> 
>> getting familiar enough with OSCOAP to start an implementation, there
>>are
>> some areas which are not fully clear to me from reading the draft:
>> 
>> * At least master secret and CID are preconfigured (that's assuming
>>   default algorithm, sender/receiver ID). It's out of scope for this
>>   spec, but are there any other drafts on how those should be rolled out
>>   / rolled over?
>
>There are indeed a couple of drafts that are looking a this:
>
>Draft-ietf-ace-oath-authz provides an overview of how authentication and
>authorization is going to work.  It uses draft-ietf-ace-cbor-web-token as
>a
>message format to carry the keys from the auth server back to the client
>and
>resource server.  It can run over either DTLS with
>draft-gerdes-ace-dtls-authorize or OACAOP with
>draft-selander-ace-coap-profile.

I think Jim meant this draft:
https://tools.ietf.org/html/draft-seitz-ace-oscoap-profile

>
>Additionally, draft-selnder-ace-cose-ecdhe provides for a way to get these
>secrets based on pre-configured asymmetric keys or symmetric secrets.

Certificate based authentication is also supported in
                   
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe
                   

>
>> 
>>   * btw, why is algorithm a "SHALL" be pre-established (3.2) and the
>>     role IDs a "MAY" be predefined, if (as I understand) absence of
>>     pre-definition in both cases means fallback to defaults?
>
>SHALL == MUST so there is no fallback on the algorithm.  I think that the
>default on AEAD should be an MTI statement.  Yes the role IDs would
>default
>to the default values as would the KDF function.   Given that there is no
>negotiation on the replay window size, I don't think that there is really
>a
>default here as an application can probably choose any size they want, it
>will just effect the ability to cleanly pickup messages outside of the
>replay window.

The defaults should be MTI as Jim pointed out. See
https://github.com/core-wg/oscoap/issues/42


>
>> 
>> * speaking of "role IDs" to subsume sender and recipient ID, it
>>   strikes me as odd that sender and recipient contexts are qualitatively
>>   different (the former has a sequence number, the latter a replay
>>   window in 3.1), but the roles of Sender and Recipient in terms of used
>>   IDs stay the same when roles flip mid-conversation. Does that mean
>>   that once my server starts "asking back", it grows a recipient
>>   sequence number, and the former client grows a sender replay window?
>
>In some sense, what you have stated above is correct.  The sequence number
>is used for a nonce and thus needs to be unique for every message that I
>send.  In another sense, what you have stated above is wrong in that for
>most cases a device will be both a sender and a recipient and thus it will
>have a sender context for all the messages it sends and a recipient
>context
>for all of the messages that it can receive.  The same thing is true for
>DTLS where there is a sending stream and a receiving stream and they are
>handled differently.


There may be some confusion here indicating that further clarification is
needed in the draft: Both nodes have all parts of the context;  common,
sender and recipient. Thus when a node sends it always uses the sender
part and when it receives the recipient part, regardless of its initial
role. Sender and recipient parts are mirrored between the two nodes,
oversimplifying: Node 1: SenderCtx=A RecipientCtx=B; Node 2: SenderCtx=B
RecipientCtx=A

See https://github.com/core-wg/oscoap/issues/43

>
>Part of the confusion that you might be having at this point is the fact
>that there is another draft running around
>draft-tiloca-core-multicast-oscoap where you end up with a single sender
>context, but potentially one recipient context for each of the multicast
>receivers which can reply.  Since they did not want to make a clean
>separation between these documents about how the context structures are
>setup, I find that the section is a bit sloppy.

As Jim points out, the multicast case is covered in a separate draft. We
wanted to separate the security solutions for the different use cases
(unicast request-response, group communication/multicast with unicast
response, caching, pub-sub etc.) since otherwise the draft would be
unwieldy. The focus of OSCOAP is unicast request-response, but since group
communication/multicast can be supported with essentially the same
construct, we also wanted to prepare for that use case. Therefore this
draft defines recipient ID which is redundant in unicast but necessary
when there may be different unicast responses to one request. I think this
one thing Jim finds sloppy. The alternative would be to make different
message protection processing for unicast OSCOAP and multicast OSCOAP.

>
>> 
>> * The option numbers are "to be done". Is there one that's already in
>>   use in first implementations? Could we pick one now and hope that all
>>   concurrent drafts become aware of its use so it stays stable, and if
>>   not just change it when going from draft to RFC? Or agree on one to
>>   use from the experimenal range until RFC release?
>
>I am using a dummy with mine, however I would not want to make it
>generally
>known.  I would be willing to do one-on-one exchanges.  My assumption is
>that a pre-assignment should be made something mid-month based on the F2F
>conversation in Seoul.

I think it would be useful if some authoritative person would propose a
tentative option number in the 0..255 range to use for this purpose, which
could later be confirmed or replaced.

>
>> 
>> * Replay protection: The sequence numbers follow DTLS' anti-replay
>>   mechanisms, where DTLS sessions are (to my limited knowledge) more or
>>   less ephemeral.
>> 
>>   When a device with a precommissioned context encounters a factory
>>   reset condition, or any kind of mis-match happens between
>> 
>>   * the static context memory area of the keys,
>>   * the frequently modified window position possibly kept in log flash
>>     area, and
>>   * the bitfield inside the window (which I'd very much prefer not to
>>     commit to flash memory in embedded devices),
>> 
>>   is there any way to recover from such a situation, eg roughly by the
>>   recipient saying "I've heard all that, start at N or I can't trust you
>>   at all"?
>> 
>>   It might well be a bad idea to allow such a thing (at very least, that
>>   information needs to be authenticated), so right now this is primarily
>>   a question about whether there is a mechanism I missed, and whether
>>   there should be guidance considering the embedded use cases.
>
>The reset of the nonce is going to be a problem under all circumstances if
>you go back to a clean factory state and you cannot store the appropriate
>nonce in non-volatile memory.  Under these circumstances, the expectation
>that I have is that the key you are using is also going to be lost so you
>no
>longer have a key that can be used to encrypt messages and you will need
>to
>go through a key establishment protocol (see the above drafts) to create a
>new session encryption key.  This is going to be the same as with DTLS
>either with a shared secret or an asymmetric key pair where a new session
>is
>established.

As Jim said, the security context should not be reused when a device is
reset. I agree that we should at least have some considerations in the
case of PSK in embedded devices and perhaps make some recommendations.

See https://github.com/core-wg/oscoap/issues/48

Göran


>
>> 
>> Could you help clarify these issues?
>> 
>> Thanks
>> Christian
>> 
>> --
>> To use raw power is to make yourself infinitely vulnerable to greater
>powers.
>>   -- Bene Gesserit axiom
>