<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-amsuess-lwig-oscore-00" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.43.0 -->
  <front>
    <title>OSCORE Implementation Guidance</title>
    <seriesInfo name="Internet-Draft" value="draft-amsuess-lwig-oscore-00"/>
    <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
      <organization/>
      <address>
        <email>christian@amsuess.com</email>
      </address>
    </author>
    <date year="2020" month="April" day="29"/>
    <area>Internet</area>
    <workgroup>LWIG</workgroup>
    <abstract>
      <t>Object Security for Constrained RESTful Environments (OSCORE)
is a means of end-to-end protection of short request/response exchanges for tiny devices,
typically transported using the Constrained Application Protocol (CoAP).
This document aims to assist implementers in
leveraging the optimizations catered for by the combination of CoAP and OSCORE,
and by generally providing experience from earlier implementations.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
  LWIG Working Group mailing list (lwig@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/lwig/">https://mailarchive.ietf.org/arch/browse/lwig/</eref>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://gitlab.com/chrysn/lwig-oscore/">https://gitlab.com/chrysn/lwig-oscore/</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>[ See abstract for now ]</t>
    </section>
    <section anchor="context-ace-lake-oscore" numbered="true" toc="default">
      <name>Context: ACE, LAKE, OSCORE</name>
      <t>[ Is this LWIG material? In W3C terminology, this would go into a "primer" document. ]</t>
      <t>When OSCORE was specified,
other parts of the ecosystem in which it is commonly used were already planned,
but not to the extent to be fully referernced.
This section gives a bigger picture of how surrounding technologies can be combined,
with the caveat that some of them are still in development:</t>
      <ul spacing="normal">
        <li>
          <t>OSCORE (<xref target="RFC8613" format="default"/>):  </t>
          <ul spacing="normal">
            <li>needs a pre-provisioned key, key identifiers and some other details on two communication parties</li>
            <li>needs to keep sequence numbers on both parties (therfore, the same setup can only be rolled out once, ever)</li>
            <li>provides a secure communication channel between those parties</li>
            <li>does not provide any form of Perfect-Forward Secrecy (PFS)</li>
            <li>has optional provisions for using a secret more than once, with randomness from both parties (Appendix B.2)</li>
          </ul>
        </li>
        <li>
          <t>ACE (<xref target="I-D.ietf-ace-oauth-authz" format="default"/>):  </t>
          <ul spacing="normal">
            <li>needs pre-existing secure channels and pre-established trust between communication parties and an Authorization Server (AS)</li>
            <li>provides tokens that encode some authorization on a Resource Serve (RS) to Clients (C)</li>
            <li>can be started by unprotected resource access (which fails, indicating the AS to get a token from) or from pre-established audiences and scopes</li>
          </ul>
        </li>
        <li>
          <t>OSCORE profile for ACE (<xref target="I-D.ietf-ace-oscore-profile" format="default"/>):  </t>
          <ul spacing="normal">
            <li>needs an ACE token (obtained by the Client at an AS, valid for a particular Resource Server)</li>
            <li>takes randomness from both C and RS</li>
            <li>provides all the data to start OSCORE between C and RS</li>
            <li>ensures to C that RS is the RS it asked a token for from AS</li>
            <li>ensures to RS that C was authorized by the AS for whatever the scope of the token is</li>
          </ul>
        </li>
        <li>
          <t>a LAKE (Lightweight Key Exchange), for example EDHOC (Ephemeral Diffie-Hellman Over COSE, <xref target="I-D.selander-lake-edhoc" format="default"/>):  </t>
          <ul spacing="normal">
            <li>needs any combination of credentials between two parties, not necessarily pre-shared (can be certificates, raw public keys, or pre-shared keys)</li>
            <li>provides a shared set of keys and other details sufficient to start OSCORE between the parties</li>
            <li>provides Perfect-Forward Secrecy (PFS)</li>
            <li>ensures to both parties that the other party has provided the indicated credentials</li>
          </ul>
        </li>
        <li>
          <t>BRSKI  </t>
          <ul spacing="normal">
            <li>[ TBD ]</li>
          </ul>
        </li>
      </ul>
      <t>[ same could be done for Group OSCORE ]</t>
      <section anchor="example-compositiions" numbered="true" toc="default">
        <name>Example compositiions</name>
        <t>[ While I'm reasonably sure what I'm writing in this document is correct,
the following is wild speculation in the hope that ACE and LAKE authors tell me better ]</t>
        <section anchor="plain-ace-oscore" numbered="true" toc="default">
          <name>Plain ACE-OSCORE</name>
          <t>A client tries to access a resource over unprotected CoAP,
but the server requires credentials (and thus a secure connection).</t>
          <t>On the initial unprotected request, the server responds 4.01 Unauthorized,
and sends the client off to the AS with information from the payload.</t>
          <t>The client, which needs to have a pre-established association with the AS
(or establishes one using yet unspecified mechanisms on the fly),
obtains a token from it,
posts it over the original unprotected CoAP transport to the server,
and from then on has an OSCORE context with the server,
over which it can request the resource successfully.</t>
          <t>This is illustrated well in <xref target="I-D.ietf-ace-oscore-profile" format="default"/> Figure 1.</t>
          <t>This combination has the advantage of not requiring any asymmetric cryptography,
but has the original request data unprotected,
and the AS can decrypt communication between C and RS
if it intercepts their first exchanged messages.</t>
        </section>
        <section anchor="ace-with-opportunistic-lake" numbered="true" toc="default">
          <name>ACE with opportunistic LAKE</name>
          <t>A client that tries to access a resource
but does not want to reveal the request details to passive eavesdroppers
can run an EDHOC with the origin server.
Nothing else being preconfigured,
it runs it on a raw public key,
and accepts any credentials from the server.
(If a set of root certificates of a public key infrastructure (PKI) is set,
it could require a certificate chain to the root certificates).</t>
          <t>Inside that opportunistically encrypted channel,
the client sends a first request to the resource.
If the server, as in the ACE-OSCORE example, requires authorization,
it can still reject the request and send the client off to the AS
with the same response.</t>
          <t>The client obtains a token from the AS as before,
but does not need to generate a new OSCORE context from it (and thus does not use the OSCORE profile for ACE).
Instead, it can post the token to the server in the existing EDHOC-created OSCORE context,
and thus upgrades the authorization set of that context.</t>
          <t>This combination has the advantage of not sending any actual request unprotected,
but does not ensure to the client that the server has any association with the AS.</t>
          <t>Alternatively, it can use ACE-OSCORE when obtaining the token
and when posting it to the RS over the EDHOC-created OSCORE context
to obtain a new OSCORE context.</t>
          <t>This combination has similar properties to the plain ACE-OSCORE,
at the cost of an asymmetric cryptography step,
but protecting the original request from passive eavesdroppers.</t>
        </section>
      </section>
    </section>
    <section anchor="protocol-implementation" numbered="true" toc="default">
      <name>Protocol Implementation</name>
      <section anchor="replay-freshness-and-safety" numbered="true" toc="default">
        <name>Replay, freshness and safety</name>
        <section anchor="background" numbered="true" toc="default">
          <name>Background</name>
          <t><xref target="RFC8613" format="default"/> Section 7.4 says that the server "SHALL stop processing the message" if that fails,
[ and I'm in quite a pickle here because I'd like to tell implementers that they can partially ignore that ].</t>
          <t>In OSCORE, replay protection serves two distinct purposes:</t>
          <ul spacing="normal">
            <li>To ensure that only one response is sent with no Partial IV present to any given request Partial IV on a context
- i.e., to curb nonce reuse.</li>
            <li>To ensure that any action authorized by OSCORE protection on the request is only executed once.</li>
          </ul>
          <t>For the first purpose, that mandate is absolute:
processing any request a second time and responding with an absent Partial IV is a severe security violation.
It does not apply, however, if the server chooses to encode an own Partial IV in the response in step 3 of RFC8613 Section 8.3.</t>
          <t>The relevance of the second purpose depends on the request and the implememtation of the resource backing it.
If the request is safe (in the sense of <xref target="RFC7231" format="default"/> Section 4.2.1, i.e. it is a GET or FETCH),
or at least idempotent (i.e. PUT, DELETE or iPATCH),
processing a replay of it has no side effect on the server,
and the only thing an attacking replaying party could learn from another response is the current content's length.</t>
          <t>[ TBD: Talk about how this interacts with freshness. ]</t>
        </section>
        <section anchor="optimization" numbered="true" toc="default">
          <name>Optimization</name>
          <t>Combined, these open some space for legitimate processing of replays.
Opening up to such processing is beneficial to the server,
as it allows a common optimization to happen even on OSCORE messages:
<xref target="RFC7252" format="default"/> Section 4.5 allows relaxation on message deduplication for idempotent requests,
to the point where some implementations of CoAP do not perform message deduplication at all
and demand of their applications to only implement idempotent behavior.</t>
          <t>On platforms that perform selective optimizations,
these optimizations can free up memory otherwised used for deduplication and retransmission,
provided the operation's idempotency is communicated to the OSCORE and CoAP implementation
(which would, in general, not be allowed to enact that optimization for the POST requests OSCORE requests appear as).</t>
          <t>On platforms that do not perform deduplication at all,
this enables the implementation of OSCORE in the first place.
(Otherwise, any lost response message results in an otherwise unactionable 4.01 Unauthorized error).</t>
          <t>Intermediaries (proxies) have no justification for treating the POST requests they see most OSCORE request as as idempotent;
however [ and this can not really be called "moving on the fringe of the specification" because it's clearly exceeding it ],
clients of a very constrained proxy (which might not even be able to forward non-idempotent requests at all)
might still appreciate a presumed-idempotent forwarding of OSCORE messages over a 5.05 Proxying Not Supported.</t>
        </section>
        <section anchor="implementation" numbered="true" toc="default">
          <name>Implementation</name>
          <t>Ensuring that only one response without a Partial IV is ever sent to a given request
is of utmost importance when implementing this optimization.</t>
          <t>One way of doing this is to annotate the received nonce or partial IV with
a marker that indicates the usability as an elided response Partial IV.
That marker is originally unset when the Partial IV is extracted from the request,
and only ever gets set the very time that sequence number gets removed from the replay window.
The marker is removed from the data structure when it is used in the encryption of a message.
Care must be taken when a nonce / Partial IV is copied to only let the marker stay with one copy,
and to unset it on the other one.</t>
          <t>Note that this aligns well with the typical other cases when responses use an own Partial IV:</t>
          <ul spacing="normal">
            <li>In observations, the first response can be sent without a Partial IV.
Later notifications are built with AAD linked to the original request's Partial IV,
but that was copied over from the original request's Partial IV
and thus does not carry a marker any more.</li>
            <li>In responses that serve to recover the replay window as in <xref target="RFC8613" format="default"/> Appendix B.1.2,
the replay window is invalid when the first response is generated,
thus there is no marker to respond without Partial IV.</li>
          </ul>
        </section>
        <section anchor="consequences-for-replay-window-recovery-using-echo" numbered="true" toc="default">
          <name>Consequences for replay window recovery using Echo</name>
          <t>[ This is maybe more corr-clar or even my own wishful thinking than actual implementation guidance. ]</t>
          <t>For the first response to the replay window recovery of <xref target="RFC8613" format="default"/> Appendix B.1.2,
applying the above considerations means that the server may not need to recover its replay window right away.</t>
          <t>If the initial request that triggers the recovery process is idempotent
(for example, the typical initial GET to /.well-known/core),
the server can accept the request as possible duplicate,
and send a successful response righ away.</t>
          <t>The response should still contain an Echo value (and the client should send the same Echo with the next request)
for the benefit of future non-idempotent operations
and to eventually allow the server to send shorter responses (without a Partial IV).</t>
          <t>Only when a resource with freshness requirements is accessed,
the client needs to have included the Echo value in at latest that very response.
A 4.01 response (which incurs the additional round-trip) thus only needs to happen
if the first request that triggers recovery is not idempotent.</t>
        </section>
      </section>
    </section>
    <section anchor="key-ids" numbered="true" toc="default">
      <name>Key IDs</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
The naming of Keys is a difficult matter,
it's not just one of your entropy games;
You may think at first I'm as mad as a hatter
When I tell you, a context needs space for its names.
]]></artwork>
      <t>[</t>
      <t>TBD. Topics:</t>
      <ul spacing="normal">
        <li>KID contexts are not strictly hierarchically above KIDs, that is up to the KID: A device may have some KIDs that are KID-context namespaced and will (at least initially) need a KID context, and some that are B.2 and the KID context is more of a detail under the KID than a namespace above.</li>
        <li>
          <t>When ACE'ing with different ASs, or combining ACE with EDHOC, or any of that with preconfigured keys, consider namespacing (eg. dealing out a prefix-based group of KIDs to an AS)  </t>
          <ul spacing="normal">
            <li>Generally recommend treating KIDs like URI paths - it's always up to the server?</li>
          </ul>
        </li>
        <li>Eventually avoid ever having to try different contexts, show it can be done</li>
      </ul>
      <t>]</t>
    </section>
    <section anchor="hkdfs" numbered="true" toc="default">
      <name>HKDFs</name>
      <t>[ This is more of a corr-clar topic than a LWIG - still fits here? ]</t>
      <t>[ TBD: Does it need to be HKDF? HMAC-based HKDF? What about other direct+HKDFs in COSE (<xref target="I-D.ietf-core-oscore-groupcomm" format="default"/> may do some updates here)? ]</t>
      <t>[ Why and how do direct+ KDFs of COSE apply at all? My current impression is: ]</t>
      <t>When KDFs are referred to by identifier, they are usually identified with the <tt>direct+HKDF-...</tt> COSE Algorithms.
This makes sense as those algorithms specify a particular key derivation function, but also slightly misleading:
What is meant by that usage is not to actually apply the "Direct Key with KDF" algorthm of <xref target="RFC8152" format="default"/>
([ what goes in as info there? ])
but to apply the OSCORE key derivation process (with <tt>[id, id_context, aead_alg, type, L]</tt> as info).</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <section anchor="assessment-of-idempotency" numbered="true" toc="default">
        <name>Assessment of idempotency</name>
        <t>Getting all implications of processing an idempotent request without an indication of freshness is hard.
The topic has been discussed at length in the context of TLS and HTTP/2 zero-round-trip actions
[ but I couldn't be bothered to find precise references for that yet ].</t>
        <t>[ Applications probably also need guidance as to what are the temporal aspects or idempotency
(a request that has the same effect when processed twice in the same second, and different ones if processed a day later - is it still idempotent then?),
and on the re-ordering of requests permitted by idempotency
("Just because you received confirmation does not mean it can't be reordered with a request you send later ... unless you put in a memory barrier?")
]</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Informative References</name>
      <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252">
        <front>
          <title>The Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
          <seriesInfo name="RFC" value="7252"/>
          <author initials="Z." surname="Shelby" fullname="Z. Shelby">
            <organization/>
          </author>
          <author initials="K." surname="Hartke" fullname="K. Hartke">
            <organization/>
          </author>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
            <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8613">
        <front>
          <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
          <seriesInfo name="DOI" value="10.17487/RFC8613"/>
          <seriesInfo name="RFC" value="8613"/>
          <author initials="G." surname="Selander" fullname="G. Selander">
            <organization/>
          </author>
          <author initials="J." surname="Mattsson" fullname="J. Mattsson">
            <organization/>
          </author>
          <author initials="F." surname="Palombini" fullname="F. Palombini">
            <organization/>
          </author>
          <author initials="L." surname="Seitz" fullname="L. Seitz">
            <organization/>
          </author>
          <date year="2019" month="July"/>
          <abstract>
            <t>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).  OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t>
            <t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration.  Therefore, this document updates RFC 7252.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7231" target="https://www.rfc-editor.org/info/rfc7231">
        <front>
          <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
          <seriesInfo name="DOI" value="10.17487/RFC7231"/>
          <seriesInfo name="RFC" value="7231"/>
          <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
            <organization/>
          </author>
          <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
            <organization/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="I-D.ietf-ace-oauth-authz" target="http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-33.txt">
        <front>
          <title>Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ace-oauth-authz-33"/>
          <author initials="L" surname="Seitz" fullname="Ludwig Seitz">
            <organization/>
          </author>
          <author initials="G" surname="Selander" fullname="Goeran Selander">
            <organization/>
          </author>
          <author initials="E" surname="Wahlstroem" fullname="Erik Wahlstroem">
            <organization/>
          </author>
          <author initials="S" surname="Erdtman" fullname="Samuel Erdtman">
            <organization/>
          </author>
          <author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig">
            <organization/>
          </author>
          <date month="February" day="6" year="2020"/>
          <abstract>
            <t>This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth.  The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices.  Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="I-D.ietf-ace-oscore-profile" target="http://www.ietf.org/internet-drafts/draft-ietf-ace-oscore-profile-10.txt">
        <front>
          <title>OSCORE profile of the Authentication and Authorization for Constrained Environments Framework</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ace-oscore-profile-10"/>
          <author initials="F" surname="Palombini" fullname="Francesca Palombini">
            <organization/>
          </author>
          <author initials="L" surname="Seitz" fullname="Ludwig Seitz">
            <organization/>
          </author>
          <author initials="G" surname="Selander" fullname="Goeran Selander">
            <organization/>
          </author>
          <author initials="M" surname="Gunnarsson" fullname="Martin Gunnarsson">
            <organization/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework.  It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="I-D.selander-lake-edhoc" target="http://www.ietf.org/internet-drafts/draft-selander-lake-edhoc-01.txt">
        <front>
          <title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
          <seriesInfo name="Internet-Draft" value="draft-selander-lake-edhoc-01"/>
          <author initials="G" surname="Selander" fullname="Goeran Selander">
            <organization/>
          </author>
          <author initials="J" surname="Mattsson" fullname="John Mattsson">
            <organization/>
          </author>
          <author initials="F" surname="Palombini" fullname="Francesca Palombini">
            <organization/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact, and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys.  EDHOC provides mutual authentication, perfect forward secrecy, and identity protection.  EDHOC is intended for usage in constrained scenarios and a main use case is to establish an OSCORE security context.  By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code footprint can be kept very low.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="I-D.ietf-core-oscore-groupcomm" target="http://www.ietf.org/internet-drafts/draft-ietf-core-oscore-groupcomm-08.txt">
        <front>
          <title>Group OSCORE - Secure Group Communication for CoAP</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-oscore-groupcomm-08"/>
          <author initials="M" surname="Tiloca" fullname="Marco Tiloca">
            <organization/>
          </author>
          <author initials="G" surname="Selander" fullname="Goeran Selander">
            <organization/>
          </author>
          <author initials="F" surname="Palombini" fullname="Francesca Palombini">
            <organization/>
          </author>
          <author initials="J" surname="Park" fullname="Jiye Park">
            <organization/>
          </author>
          <date month="April" day="6" year="2020"/>
          <abstract>
            <t>This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g. using IP multicast.  In particular, the described approach defines how OSCORE should be used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and the corresponding CoAP responses.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8152">
        <front>
          <title>CBOR Object Signing and Encryption (COSE)</title>
          <seriesInfo name="DOI" value="10.17487/RFC8152"/>
          <seriesInfo name="RFC" value="8152"/>
          <author initials="J." surname="Schaad" fullname="J. Schaad">
            <organization/>
          </author>
          <date year="2017" month="July"/>
          <abstract>
            <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol.  This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization.  This specification additionally describes how to represent cryptographic keys using CBOR.</t>
          </abstract>
        </front>
      </reference>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>[ TBD put into text ]</t>
      <t>OSCORE authors in general: discussion leading up to most of this during OSCORE dev'mt
FP: HKDF input</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAFomqV4AA5Vb7XIcx3X9P0/RBf0Q4OyuSEqKHbhSDASCIkJaZBFwWClb
ZfXO9O62MTuzmZ7BYuWyKu+Q18m/vEmeJOfc2z0fC9CuuFTwAjvTfft+nHvu
vc35fJ61vi3duTl5f3P5/uOVud7uSrd1VWtbX1fm+84XtsrdSVbUeWW3eLJo
7Kqd223oXAjzcu/X8zrkdePmz55luW3dum4O58ZXqzrL/K45N23ThfbFs2f/
9OxFZhtnz8111bqmcm22r5u7dVN3u3Pz7tP191kWWlsVf7JlXWGrgwvZzp+b
P7R1PjOhbtrGrQI+HbbxQ9v4vJ2ZvN7ubN7+mGW2azd1c56ZeWbwP1+Fc3O5
MBfb8D//HYL8TY9xuWl8aL2tJt+5rfXlucnTl/8Sz7nADjgNztRsoZl7hx3M
x9eXv37x7Yv48Tf/+Pzr/q9fP+fH6/mrhXftam5zN68p2pw/fn78nSpw19Qr
X7r0dXAllOGaeWnv3NwVmzo/z7JsPp8bu8TRceIse7/8s8tbc+PyrvHtwUBC
c1lX/NpXrjAfr25uV11prqp739QVTRvMqVr7LPPBWLN1tgqmXhlXFfO2nuP/
DERpsS59AF8E6LQ1jfsP6KL9qnFhhx2ccQ/5xlZrF2TX1lcHU7h7n7swy9rD
zue2LA8wP5bfYQFI0wVfrU27cRMZL3a7Eg/Lbh+wcZ3XpTm9rC8+nC2y2w2E
hPd1FN1Yvw2mrY0NARYyPrmrawKMnZXu3jV2nTapd63f+p9l5WDonA22o7DL
gzwAsy59ZdM5uaWBzo3qZ5bxMx5duwrL8jDQy70vuL572LnGOwSHWTX11jjb
lN41g0i660INtvVFUbos+4K+39RFJ7rNsj/+AaZzvT1Ftqremz/+yGehpNY9
tOfm4vJqZt5dvMVPFU3evIYqqB2GjtnydN6WL7GD+fT1pcGvW1/VZb0+zPS5
fd2VhVnX0BRVaE52jd+65qRX70L2/bRxVdzG7G0wYedyv/KumGU1lNaYnW1a
cRiq0OV1OITWbbGq2W98vjEehgnU7bauoLMuQOl7qN7YEuFfQItw7IrrLbsW
x21pUVnroaWR8dsSWu2ocAQ63myg5iL6Qoh+uUYY0n2Xfr2mUECCDntArA0U
GLoGuFKJqeDJG1GEd/SCiqur5SnD3rcbdQZ77yx23+BHqLcunnBrAFqAGl+W
PCI83JX1jupCNP4qKer0L3+JIPDXv57hC2N+ZSrnCkq409i+9wFyQxd3DhbB
D+MLrELVwnvparqr6LhwLaAIWq5Mu69FmV2VgoQGwFlGm0Bld87toBzEKH2y
6rZLLounl1gxvWJOuTq8zM3kzAFgiJfabieKEXtBO01dlhC0hnlqrDYzjKsz
2U8jQDQfCDruSDZCQuVKrNLuHRwJeAyoGEtc1HibVo9L4eiCW1sq/AOkg4Hn
r+tmb5uCwNa4/GBOP7y+UQE2cEkGdl3Z0vRqVQxSfBHJGteaLc5Je1bxFGJq
wFFRbyugugbuVD3AIuCffzDfLV6c0b4IPRr3c1h+bG3a2j0we0CQpCBVidpY
HkCaW5Y+bKBjyY69tp60s7zHTCXJLeIZNNPAKJD45sgwbX3nqqB+DF+ooWFx
LDt5Hf9Z89GFumvgLrKYOf14c0ZXugSSSZ641KVjzEBqQXEgYlfFDIFfm7SI
zXNq9VRRYEX/nSFkCjlOhOSLG26whnGsCipGODMwnljjWD22KwRkY4Dk9Q5e
NIRdTJli/CctNcmsj0KzkpdUjtN62Wo+islBtWCgRT53MzP3tvSaPqyaJu9K
2xwpMYZJi5wdnva1SznKx5ujcAK8cNfCttSMKjsdM7nH5FUYGd4lsX+p1v54
Q+DlKvwEucMdVZgUnXR88eh9PC4LXArgJ0cZVAGr8e09niESKHTQFikL6A5e
TGMlU5nTd369gdj8ad4C7a4iXTibyWLuwTJVmqtXb95fmtOrHaCWWda88itA
4vyNK8stNP+eG16+v0HuU+M+wYseG/ZwnNsBCIK2FnHYYxOQNcbYTBCpcvRg
23hJ9W4eNpaM4TQlDdcQrkkk8EJj92bXwVFzgjn+gEONXuLfHkOmfgfEpUx8
RCw6xfzQQQG5j6nwSUegzseY2m/x9/FzZPYJ9IkDCGvqk/xBwDauXciXMZzx
20ihtPp3H2/eXqsNQE1uv3slXAIfJcXkQj2gwgIZUMz/PWl/OpbQnS/gIeoS
5PN18K0nsMsinzaM8usvt0AbGwD9S1iI5xCflC/24L9EGV8p2+k5o3CRBlpo
QUs33L0s6708Ck7kIRcZDkJZXMWrcjd0blEJEYI2EqfW0ICy4JwgzrQHeFaU
/wvzoQSC8I15omkXJlcYQamiSo8oaQfcrOnhY0QlD1VyJIGmQE/67Wm4sSef
UrJ2003SMZKNUCSw5+x9Fc3m+cIRbgufn003IbdHBH2zePbc/L4aoEDJcHD8
UtiSHqterRJ7A0hIgu3LpFrBPTrroawtOBxIXHp5FvliT2E2YGCRL01yQAh1
7nXBnq0BxE6JIv1z5DouMoAD4qureuIKSxF6fNgqoaITlIcz8FmB/DDJRQDO
WQb3Q/4DhNYJ7qAF1BVHKpSCoS9wkiJUl6qwpABJuIwm23PrXNn9cKT0nuzZ
U2liTzSVPNW7TejEk4Qni17hzvyvLDtWE62wbiWtfycrmtd+Tdd5npYZYyeF
5r62uLeoataC+QRLdUghXIBbi6p861iQw0EPu7ZeN3a3OagbpzV6JaYDSbYb
aVSVFr2JJy+crHZEjB7lQ7+SqoOFYO52rezmke58g01SnUo/ALqjYF1ouDK0
Rfv1jvbD+uBtuUT6OHIFGD8bvnLAntPuraJ2gzxpy2iweNYI7y2TDupX+LqD
w4eiwfbg6plYuqvoIpoUe89QvUUHWWQ/AKKlBi0DIYgfETPwp5XYEVqEMrCS
ejCJ3jRXqZZ5EqpKkuUIU/qYTdudXq8EXiRnNTVOOU6E/KMdLc74byw8sNOC
7PTD2+szI4VbK4JpLohwhldHi5EqE4A1jh5tRUC7rgJrBjHKxGxSn4Mq0l2Y
npR0K+RHSyp62egWfVDVk7haZNercTjCs1NSGIA9sZfZAMsTeq0HhSG1bmyc
dGnG3pDQ9LNgOhSmkkFT12WCoOZJAIvhY0l0pNSbuijhVkk4uxotTVC5/TEq
RSgcZZh+ART0ssfTHBxGgo1aFPqzBF9E0xFNnMBk0m1fNInrz+GQgmBTqRI8
QJpuB4CRcmdzXNpETxUXiS/+v4CNZulhDU48wqsJVE20qrQqnW0CHcNZNQEc
PpfRIOVFydao9BjLQ69AanzkfHvJJ2L6VFeJZkU78iU1Lgynd29Q/D6X/S0V
Z3hel37SLz6nyOC3nsUQ1LNzkVDqxrsjTgQbtrH5FsROON9nkgeix+1Uz6kh
mTp7x4lEi8enYJVYP7QVpw1uYZ0fHUSErlcIsY3UahKbduXag+aJ72wubeqq
yLJRn4fkWhTw68U3eP4QHtn75ObNxbt3OEa94wmYOdIJYio6MT56qtbLJLvc
nowWagO2SIDufH6HENuwi7Z0uaVDXH9ZmNLfqc9Joh93Q5MoB41AknxBSL+u
YlekBW0VQE3tTiiTmhg3f+UcQQqlQuITKLbrGriXC9L+uq17zxdEZgOJPKxv
EgvwV5HlVLX5oJKY639jzgqxyGFQsKE3UJ3Rc5LBknsaM58bv3CLGd8D411i
VXa8GtcJOj6SKYYxjzOtbAf86nvd1QSjfdADuQdQa4YKN8IWr2uNI80jUR8z
3Q0la0FQZWt9GeoS751nI9tTmj4HkLPXRDTP/kxVJP7NB0VhjI2lKGmkD69s
/57OEFLj/97XWsEAfkewZHc74sim3jtJZn6c25Aka1qSmoydIvbK9tVkt6ST
ZNBKwtJ8zdiNsdBHwm8WX8cE1bjS3XN2lFoE8ahRW2BDO8nGRypP9C/68rbt
C/gJ910iIhXf+nQ9Mhpj15xGwaG9IEJI5HI2M4rcbxYvFs9n4k+xbW3N91e3
LOVfX91evmGN0LAFVKLsbNmwRWUqTepTeefD729n5tXVu6vbK77jP1zoS2OD
p7CqhaMSLBEGQmLcirV6UsG4bBCMo+sp0aMbtG08sy4npE9qdOVTELCJ+d9W
WsKPY1AAt0MVXMWcWLVfBrxUrdvNQkpslOzn5taWd/A4Nn7ZRZdCWlg1Aiio
S/YwuejL3vejOUuWXabWOjel6mFo7UCGnc2VJ5RujYKUM4sxLpJeyuEA2u/x
Fv/W7aQJ0qEYGj3pyW0qxzYJWfZR3SW817LKD4IcHERMhkFabLLVy862xH0E
g1QhnGfRXb59MXGXb9O68G/70LdS42vw6qIbhlk86chloodyOhZTY+2JjILq
oqCj4VE/kypqbZhL6377md2snFncB3tKW2kV6yA7TNgk2MW1+s3GMi4dinBf
N9o6gC1a7hjTSdo/ILZzUpTphE24dng8dqNbOkdLIqDr5qAdpr0PMhGME7mj
swgWSmW99SEIo570ocgy5FF4cS9+fkiDJy0VleeOqCqXFYVOFZ3FlrUMyNiy
ThM/7QounRpdl3OVzdtUf4xcahWTwof3N7e9qdPG/e90OtAkG86e1PCRoZ8y
MLWMUzr2wCL9nZ6GZo/bRgiMeaq0zF6n75P2Z5KMylpqoQgVybXwh65spfJh
SkivgABrKuXmj5tExjVN3WiZxvmjK7yVwvkUxnvAhzPt8QAA/9yFWNf1yiMf
TfRoqkXhMQE+tKWwU52yzrEjJ2h/m8VsZyKXEn3RDbVrITSI3VwrQ66TLdyK
4BN1xY7GkLS0haRSnvTUyxM8c0KusIMcFVVk23/8cZblcXwihTHkIEQP025q
4pCGJFvpjkv9QByip1GxcLNVbOCC3MyfwJDoDGeZrqBlJpyrcawrYhctdLDA
+O24aMTaI8jT+sCabxfPviVhfpAc8wNku+l2OsCPfZNjEn1FtqWWe5IDMm8w
pdgjFiNG6inglADybgJk7FoxOTwcAgidkPqm93jd1YdJLEpo4UlNukXdP+S1
hVNB4VSS0obcYd8issi6SVyZMlLwzILTNXdSOtm2b4Br5HXBLn1J/qWtPVcK
QvUnH87L6bXQQ1mKAscShhPyiiWrHEx8f6qkB7ka4IZeYt+5FaxXhkpNrl0r
XRZ5RvxOeKUOtKeDYX22ARzfTxcWprLHIev9QnjcIPCjp6V5NzR61DBCogTV
U2GvLZkITDa52yK75Fx9q9NPmZdVuoSNpvjqSBF5vfMKwXLkMh40ChhaEZzN
vIq15S52ufC4qtf3REvZER6Dn8C9XaqVyP5K1EdB+6Z9YR7vssT3ckvGLJIm
M8uBH1NnKZCuWamTmcQcOQLk3kvSfDXVScexskDV8473O4gUPRwFuZiw7HwZ
q6uLi1coCKu7Ie0dl8lArWHVGVbVGYNtZe4XFSww0Bv5by6BFR63h3LbwPX6
qGGO4SB+EbUxKC06JifP0jHN+wbFxA9jA25ceI+m9M8XL3iQx28Jc9WRbR9Z
R3rHI6kJVuginYR1I18hSaXAr1Nh1ptnbBzBRF5oijGmdxGm0sTTHeKA4gqV
l7LuCEtbe1g6vbDAYdU8ZzOF8w1C4vYgnoUEvOFdLtYEdxFuq9ShOuIA63hz
T0n6tGDtz993Pp+UNJVMn9G5VJYpXaNkuJfRE+uaJrqnXiw77ongpJM2ZLK7
F0CaSCKpzQLGSShWk0HWMBHR5jzvAIUE6Cp/LBfEEfoUmJ2OZs+zSXinpVn/
Qa6vFkSB+V0F1X/FecmZ9pJT6SyqZwd9Wr8G9t6CZxZP3M0NszMW7v3YZjAE
T5oOejsutsNGijtN76zbrBIy+g/vI3QuNWiHJnd8JfWWpXssz/eAVrHBGyU+
yxJx1YJKWnKrThD9iHv0nDskZKV30vsAx8KQx3Zm1UYZ5PLgqBrlBZEnME75
MBaKOaAv9adFZ+q360VGIrZok/E70sF0ouirvOxS4TDSnBdKXTKZR0cSvxk6
7RfKcHtrRNKG9bom9Y4LH68iSX9wDlfcnSmQSJYaScL4yWL/5WgCMXHi3oG9
4ulgAWll8irF9auQZb/88os4S2W3kdC95X0C6WEUvEORg8HzXmDLolgoK5cj
8ZYciRcOUDESdNsgXZo1HCX8Nvv3upMYFZShglRWNiQtcaoQqoPzcF29LHit
/UesNhs6dfHoQ83PAOflWxT3FB3oB2f/7tXC3CLv5NpOfHv9Kr2v6U368XLN
F8rceDhgk2/isEdBB6+E2Hsj89glVMPfz81FvJEqJxJnkDqb78TmYCO/zXuh
KSBFLiSz7Rl3p0P/RyGiPJwpfNmxwLPhDl+/9HeLF31La/SoIH6ttxVtHAyC
phQx/fFJxfZBHj2tJFHR+cXl1Zd9m5DmdtLbubjRiyjan+cD/ZBTuv7yJVNy
GpDIV5PpYbzNksC8F4GLnbr1AvIiq9LjJITx7so/zJeWnE8uc4srioZrvTp1
pvdCvu+v0XK77VYQKhV98oK0s3//8RocvN0E6fTSbW25Z3d9sK1CzEsq42oE
Qfc1kr3TQYvUdHwcgTSoJ/nWjLC0T+OVeC8FLinXbt+8ffU6TLNzb6shObf0
2mQmuYILcRWoV3R10oiX6RKMNNdekSH5IfNhW2710rz53cVlVKD+4ZP4j7Th
4tUgz/sr/yCSEbd4H4qX3V72c32Z6MfBvliBGkbapuMXtbpltyukcqFoZ71s
nzYH8VEqpKjTVka2YgOKW0myjzXnS/O7Q99LBO1onDRooKfz4f6wvM0IkAu8
TTzw+MrrTKt6PtMFNWD/ZTHkqp9GR58vFoufVKCLcg1m2m62IV4L3sqFO232
ymCPTWbbPxUr+cP06h7H1XBxfx+7EF0lzY2Z8GJbBuitJAmBbFsfgAEsnc+z
TxFsSHBavSNnORZl4ySCttwUSH4pyuNhTl7JYQTD5YQ41IlKCSGVcb0k5XrO
tmN2CuvI/aa1eE6lTHhVK0elAc/0llA92iNW9UdHS2RIcq/56Q+efa7iTwN0
4Wx/giAz0iEQo3c//pR2O5O00/8Lg8sJyZMJ2gUScAhbHWGP23FZ9r1rJbxt
nE/1tQsenExFnmiUDrVQ1V8j1SpyoANQ98Y2hdaqGpIbGXzDBwsf8o7cQBv4
bHWnojThMNa6fXcj7v/m9vbDVy/Mz66p50Muj5OjwEChqq+13V59KVXrUqJT
nXvl9XZvzjaZXlvvawHxD15KkokblroYN2Shh6VcaBOPE3RI9F1cuVYnsI12
LFrqiRclLX2afaZmovNTOyUWac4tRDCOHHRIrPqn+HvmyDQw0TvhnNZoShvg
EyAZOEIa3kT2AsCUUpz+73/+l5Dt1I4aWZQ3oF6epYZFZMzzuqGHpsZ/bGzt
+O8W2njPeHKuk3/VZoH24MA2huaNZK906ayvRBmfEePVXo2TLRO+DIriYsJW
9STAGaTjkg7Gb3ZdK9GX+tdLVLhAsJcnZzFjXF/8cPEoMKb/ciXOfeTJ6FNw
Bf3XIZxmcZmLnNVG6Yq10NvsL+farXHFP5+s4Bzu5K8pm0SZZPT70Aruph53
vKI4dLHPUyRQORHEYjLdxhm83pjUJl5cB8Tpy22bvf5wLkkJ62HL7P8AXSz0
eDQ2AAA=

-->

</rfc>
