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

[Jim Schaad <[e-mail]>]

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.

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

> 
>   * 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.

> 
> * 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.

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.

> 
> * 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.  

> 
> * 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.

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