<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version (Ruby 3.1.2) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ace-key-groupcomm-18" number="9594" category="std" consensus="true" submissionType="IETF" updates="" obsoletes="" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.18.0 -->version="3" xml:lang="en"> <front> <!--[rfced] Please note that the title of the document has been updated as follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review. Original: Key Provisioning for Group Communication using ACE Current: Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE) --> <title abbrev="Key Provisioning for Group Communication">Key Provisioning for Group Communicationusing ACE</title>Using Authentication and Authorization for Constrained Environments (ACE)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-ace-key-groupcomm-18"/>name="RFC" value="9594"/> <author initials="F." surname="Palombini" fullname="Francesca Palombini"> <organization>Ericsson AB</organization> <address> <postal> <street>Torshamnsgatan 23</street><city>Kista</city> <code>16440 Stockholm</code><city>Kista, Stockholm</city> <code>16440</code> <country>Sweden</country> </postal> <email>francesca.palombini@ericsson.com</email> </address> </author> <author initials="M." surname="Tiloca" fullname="Marco Tiloca"> <organization>RISE AB</organization> <address> <postal> <street>Isafjordsgatan 22</street><city>Kista</city> <code>16440 Stockholm</code><city>Kista, Stockholm</city> <code>16440</code> <country>Sweden</country> </postal> <email>marco.tiloca@ri.se</email> </address> </author> <date year="2024"month="January" day="16"/> <workgroup>ACE Working Group</workgroup>month="July"/> <area>sec</area> <workgroup>ace</workgroup> <!--[rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t>This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group membersactingthat act as Clients and are authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as the Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of thisdocument,document as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified.</t> </abstract><note removeInRFC="true"> <name>Discussion Venues</name> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/ace-wg/ace-key-groupcomm"/>.</t> </note></front> <middle> <section anchor="intro"> <name>Introduction</name> <t>This document builds on the Authentication and Authorization for Constrained Environments (ACE) framework and defines how to request, distribute, and renew keying material and configuration parameters to protect message exchanges in a group communication environment.</t> <t>Candidate group membersactingthat act as ACE Clients and are authorized to join a group can interact with the Key Distribution Center (KDC) acting as the ACE Resource Serverandthat is responsible for thatgroup,group in order to obtain the necessary keying material and parameters to communicate with other group members.</t> <t>In particular, this document defines the operations and interface available at the KDC, as well as general message formats for the interactions between Clients and the KDC. At the same time, communications in the group can rely on different approaches, e.g., based on multicast <xref target="I-D.ietf-core-groupcomm-bis"/> oronpublish-subscribe (pub-sub) messaging <xref target="I-D.ietf-core-coap-pubsub"/>, and can be protected in different ways.</t> <t>Therefore, this document delegates details on the communication and security approaches used in a group to separate application profiles. These are specialized instances of thisdocument, targetingdocument that target a particular group communication approach anddefiningdefine how communications in the group are protected, as well as the specific keying material and configuration parameters provided to group members.</t> <t>In order to ensure consistency and aid the development of such application profiles, <xref target="req"/> of this document defines a number of related compliance requirements. In particular, <xref target="req-mandatory"/> compiles the requirements that application profiles areREQUIRED<bcp14>REQUIRED</bcp14> to fulfill; these are referred to by an identifier that starts with "REQ". Instead, <xref target="req-optional"/> compiles the requirements that application profilesMAY<bcp14>MAY</bcp14> fulfill; these are referred to by an identifier that starts with "OPT".</t> <t>New keying material is intended to be generated and distributed to the group upon membership changes (rekeying). If the application requires backward security (i.e., new group members must be prevented from accessing communications in the group prior to their joining), then a rekeying has to occur every time new members join the group. If the application requires forward security (i.e., former group members must be prevented from accessing communications in the group after their leaving), then a rekeying has to occur every time current members leave or are evicted from the group.</t> <t>A group rekeying scheme performs the actual distribution of the new keyingmaterial,material by rekeying the current group members when a new Client joins thegroup,group and rekeying the remaining group members when a Client leaves the group. This can rely on different approaches, including efficient group rekeying schemes such as those described in <xref target="RFC2093"/>, <xref target="RFC2094"/>, and <xref target="RFC2627"/>.</t> <t>Consistently with what is recommended in the ACE framework, this document usesCBORConcise Binary Object Representation (CBOR) <xref target="RFC8949"/> for data encoding. However, using JSON <xref target="RFC8259"/> instead of CBOR ispossible,possible by relying on the conversion method specified in Sections <xref target="RFC8949" section="6.1" sectionFormat="bare"/> and <xref target="RFC8949" section="6.2" sectionFormat="bare"/> of <xref target="RFC8949"/>.</t> <section anchor="terminology"> <name>Terminology</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <t>Readers are expected to be familiarwith:</t>with the following:</t> <ul spacing="normal"> <li>The terms and concepts described in the ACE framework <xref target="RFC9200"/> and in the Authorization Information Format (AIF) <xref target="RFC9237"/> to express authorization information. The terminology for entities in the considered architecture is defined in OAuth 2.0 <xref target="RFC6749"/>. In particular, this includes Client (C), Resource Server (RS), and Authorization Server (AS).</li> <li>The terms and concepts described inCoAPthe Constrained Application Protocol (CoAP) <xref target="RFC7252"/>. Unless otherwise indicated, the term "endpoint" is used here following its OAuth definition, aimed at denoting resources such as /token and /introspect at theAS,AS and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol".</li> <li>The terms and concepts described inCDDLConcise Data Definition Language (CDDL) <xref target="RFC8610"/>, CBOR <xref target="RFC8949"/>, andCOSECBOR Object Signing and Encryption (COSE) <xref target="RFC9052"/> <xref target="RFC9053"/> <xreftarget="RFC9052"/><xref target="RFC9053"/><xreftarget="RFC9338"/>.</li> </ul> <t>A node interestedto participatein participating in groupcommunicationcommunication, as well as one that is already participating as a groupmembermember, is interchangeably denoted as "Client".</t> <t>This document also uses the following terms.</t><ul<dl spacing="normal"><li> <t>Group: a<dt>Group:</dt><dd><t>A set of nodes that share common keying material and security parameters used to protect their communications with one another. That is, the term refers to a "securitygroup". </t>group".</t> <t> This term is not to be confused with an "application group", which has relevance at the application level and whose members share a common pool of resources or content. Examples of application groups are the set of all nodes deployed in a same physicalroom,room or the set of nodes registered to a pub-sub topic. </t> <t> This term is also not to be confused with a "multicast group", which has relevance at the network level and whose members all listen to a group network address for receiving messages sent to that group. An example of a multicast group is the set of nodes that are configured to receive messages that are sent to the group's associated IP multicast address. </t> <t> The same security group might be associated with multiple application groups. Also, the same application group can be associated with multiple security groups. Further details and considerations on the mapping between the three types ofgroupgroups are out of the scope of this document.</t></li> <li>Key</dd> <dt>Key Distribution Center(KDC): the(KDC):</dt> <dd>The entity responsible for managing one or multiple groups, with particular reference to the group membership and the keying material to use for protecting groupcommunications.</li> </ul>communications.</dd> </dl> <t>Furthermore, this document uses "names" or "identifiers" for groups and nodes. Their different meanings are summarized below.</t><ul<dl spacing="normal"><li>Group name: The<dt>Group name:</dt><dd>The identifier of agroup,group as a text string encoded as UTF-8 <xref target="RFC3629"/>. Once established, it is invariant. It is used in the interactions between the Client, AS, and RS to identify a group. A group name is always unique among the group names of the existing groups under the sameKDC.</li> <li>GROUPNAME: TheKDC.</dd> <dt>GROUPNAME:</dt><dd>The text string used in URIs to identify a group. Once established, it is invariant. GROUPNAME uniquely maps to the group name of a group, although they do not necessarilycoincide.</li> <li>Group identifier: thecoincide.</dd> <dt>Group identifier:</dt><dd>The identifier of the group keying material used in a group. Unlike group name and GROUPNAME, this identifier changes overtime,time when the group keying material isupdated.</li> <li>Node name: Theupdated.</dd> <dt>Node name:</dt><dd>The identifier of anode,node as a text string encoded as UTF-8 <xref target="RFC3629"/> and consistent with the semantics of URI path segments (see <xref section="3.3" sectionFormat="of" target="RFC3986"/>). Once established, it is invariant. It is used in the interactions between the Client and RS, as well as to identify a member of a group. A node name is always unique among the node names of the current nodes within agroup.</li> <li>NODENAME: Thegroup.</dd> <dt>NODENAME:</dt><dd>The text string used in URIs to identify a member of a group. Once established, it is invariant. Its value coincides with the node name of the associated groupmember.</li> </ul>member.</dd> </dl> <t>This document additionally uses the following terminology:</t><ul<dl spacing="normal"><li>Transport profile: a<dt>Transport profile:</dt><dd>A profile of an ACE as per <xref section="5.8.4.3" sectionFormat="of" target="RFC9200"/>. <!--[rfced] "etc." can be used after a list of two or more items. So, is there another item that can be added to "... if it supports proof-of-possession access tokens, etc."? Original: A transport profile specifies the communication protocol and communication security protocol between an ACE Client and Resource Server, as well as proof-of-possession methods, if it supports proof-of-possession access tokens, etc. --> A transport profile specifies the communication protocol and communication security protocol between an ACE Client and Resource Server, as well as proof-of-possession methods if it supports proof-of-possession access tokens, etc. Transport profiles of ACE include, for instance,<xref target="RFC9203"/>,those described in <xref target="RFC9202"/>, <xref target="RFC9203"/>, and <xreftarget="RFC9431"/>.</li> <li>Application profile: atarget="RFC9431"/>.</dd> <dt>Application profile:</dt><dd>A profile that defines how applications enforce and use supporting security services they require. These services may include, for instance, provisioning, revocation, and distribution of keying material. An application profile may define specific procedures and messageformats.</li> <li>Authentication credential: theformats.</dd> <dt>Authentication credential:</dt><dd>The set of information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CBOR Web Tokens(CWTs) and(CWTs), CWT Claims Sets (CCSs) <xref target="RFC8392"/>, X.509 certificates <xref target="RFC5280"/>, and C509 certificates <xreftarget="I-D.ietf-cose-cbor-encoded-cert"/>.</li> <li>Individualtarget="I-D.ietf-cose-cbor-encoded-cert"/>.</dd> <dt>Individual keyingmaterial: informationmaterial:</dt><dd>Information pertaining exclusively to a group member, as associated with its group membership and related to other keying material and parameters used in the group. For example, this can be an identifier that the secure communication protocol employs to uniquely identify a node as a group member (e.g., a cryptographic key identifier uniquely associated with the group member in question). The specific nature and format of individual keying material used in a group is defined in the application profiles of this specification. The individual keying material of a group member is not related to the secure association between that group member and theKDC.</li> </ul>KDC.</dd> </dl> <t>Examples throughout this document are expressed in CBOR diagnostic notation without the tag and value abbreviations.</t> </section> </section> <section anchor="overview"> <name>Overview</name> <t>At a high level, the key provisioning process is separated in two phases: the first one follows the ACE Framework between the Client, AS, andKDC;KDC and the second one is the actual key distribution between the Client and KDC. After the two phases are completed, the Client is able to participate in the groupcommunication,communication via a Dispatcher entity.</t> <!--[rfced] The SVG has the width and height specified, which makes the artwork not scale. We suggest that scaling be enabled. Scaling will allow the figure to be resized when it is viewed on a mobile device; however, there may be aesthetic trade-offs (e.g., image may appear too large on a desktop screen or different figures may scale differently based on their relative sizes). Please review Figures 1, 34, and 35 in the HTML and PDF files and let us know how you'd like to proceed. The current document (SVG does not scale): https://www.rfc-editor.org/authors/rfc9594.html https://www.rfc-editor.org/authors/rfc9594.pdf https://www.rfc-editor.org/authors/rfc9594.xml (source) vs. SVG without width and height: https://www.rfc-editor.org/authors/test9594.html https://www.rfc-editor.org/authors/test9594.pdf https://www.rfc-editor.org/authors/test9594.xml (source) --> <!--[rfced] As "Group members" are shown as participants in Figure 1, should they be included and defined in the list that follows the figure? --> <figure anchor="fig-roles"> <name>Key Distribution Participants</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="224" width="544" viewBox="0 0 544 224" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"> <path d="M 8,32 L 8,64" fill="none" stroke="black"/> <path d="M 8,128 L 8,176" fill="none" stroke="black"/> <path d="M 56,72 L 56,120" fill="none" stroke="black"/> <path d="M 112,32 L 112,64" fill="none" stroke="black"/> <path d="M 112,128 L 112,176" fill="none" stroke="black"/> <path d="M 184,48 L 184,144" fill="none" stroke="black"/> <path d="M 240,32 L 240,64" fill="none" stroke="black"/> <path d="M 240,144 L 240,176" fill="none" stroke="black"/> <path d="M 344,32 L 344,64" fill="none" stroke="black"/> <path d="M 344,144 L 344,176" fill="none" stroke="black"/> <path d="M 408,128 L 408,176" fill="none" stroke="black"/> <path d="M 424,144 L 424,192" fill="none" stroke="black"/> <path d="M 440,160 L 440,208" fill="none" stroke="black"/> <path d="M 504,128 L 504,144" fill="none" stroke="black"/> <path d="M 520,144 L 520,160" fill="none" stroke="black"/> <path d="M 536,160 L 536,208" fill="none" stroke="black"/> <path d="M 8,32 L 112,32" fill="none" stroke="black"/> <path d="M 240,32 L 344,32" fill="none" stroke="black"/> <path d="M 184,48 L 232,48" fill="none" stroke="black"/> <path d="M 8,64 L 112,64" fill="none" stroke="black"/> <path d="M 240,64 L 344,64" fill="none" stroke="black"/> <path d="M 8,128 L 112,128" fill="none" stroke="black"/> <path d="M 408,128 L 504,128" fill="none" stroke="black"/> <path d="M 120,144 L 184,144" fill="none" stroke="black"/> <path d="M 240,144 L 344,144" fill="none" stroke="black"/> <path d="M 424,144 L 520,144" fill="none" stroke="black"/> <path d="M 120,160 L 232,160" fill="none" stroke="black"/> <path d="M 352,160 L 400,160" fill="none" stroke="black"/> <path d="M 440,160 L 536,160" fill="none" stroke="black"/> <path d="M 8,176 L 112,176" fill="none" stroke="black"/> <path d="M 240,176 L 344,176" fill="none" stroke="black"/> <path d="M 408,176 L 424,176" fill="none" stroke="black"/> <path d="M 424,192 L 440,192" fill="none" stroke="black"/> <path d="M 440,208 L 536,208" fill="none" stroke="black"/> <polygon class="arrowhead" points="408,160 396,154.4 396,165.6" fill="black" transform="rotate(0,400,160)"/> <polygon class="arrowhead" points="360,160 348,154.4 348,165.6" fill="black" transform="rotate(180,352,160)"/> <polygon class="arrowhead" points="240,160 228,154.4 228,165.6" fill="black" transform="rotate(0,232,160)"/> <polygon class="arrowhead" points="240,48 228,42.4 228,53.6" fill="black" transform="rotate(0,232,48)"/> <polygon class="arrowhead" points="128,160 116,154.4 116,165.6" fill="black" transform="rotate(180,120,160)"/> <polygon class="arrowhead" points="128,144 116,138.4 116,149.6" fill="black" transform="rotate(180,120,144)"/> <polygon class="arrowhead" points="64,120 52,114.4 52,125.6" fill="black" transform="rotate(90,56,120)"/> <polygon class="arrowhead" points="64,72 52,66.4 52,77.6" fill="black" transform="rotate(270,56,72)"/> <g class="text"> <text x="60" y="52">AS</text> <text x="288" y="52">KDC</text> <text x="60" y="148">Client</text> <text x="292" y="164">Dispatcher</text> <text x="488" y="180">Group</text> <text x="488" y="196">members</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .------------. .------------. | AS | .----->| KDC | '------------' | '------------' ^ | | | v | .------------. | .-----------. | Client |<-------' .------------. | .---------+-. | |<------------->| Dispatcher |<----->| | .---------+-. '------------' '------------' '-+ | Group | '-+ members | '-----------' ]]></artwork> </artset> </figure> <t>The following participants (see <xref target="fig-roles"/>) take part in the authorization and key distribution.</t> <ul spacing="normal"> <li>Client (C): A node that wants to join a group and take part in group communication with other group members. Within the group, the Client can have different roles.</li> <li>Authorization Server (AS):asAs per the AS defined in the ACE Framework <xref target="RFC9200"/>, it enforces access policies that prescribe whether a node is allowed to join a given group or not and with what roles and rights (e.g., write and/or read).</li> <li>Key Distribution Center (KDC): An entity that maintains the keying material to protect groupcommunications,communications and provides it to Clients authorized to join a given group. During the first part of the exchange (<xref target="sec-auth"/>), the KDC takes the role of the RS in the ACE Framework. During the second part (<xref target="key-distr"/>), which is not based on the ACE Framework, the KDC distributes the keying material. In addition, the KDC provides the latest keying material to group members when requested or, if required by the application, when group membership changes.</li><li> <t>Dispatcher:<li><t>Dispatcher: An entity through which the Clients communicate with the group when sending a message intended for multiple group members. That is, the Dispatcher distributes such a one-to-many message to the group members as intended recipients. The Dispatcher does not have access to the group keying material. A single-recipient message intended for only one group member may be delivered by alternative means, i.e., with no assistance from the Dispatcher. </t> <t> Examples of a Dispatcher are: the Broker in a pub-sub setting; a relayer for group communication that delivers group messages as multiple unicast messages to all group members; and an implicit entity as in a multicast communication setting, where messages are transmitted to a multicast IP address and delivered on the transport channel. </t> <t> If it consists of an explicitentityentity, such as a pub-sub Broker or a message relayer, the Dispatcher is comparable to an untrusted on-pathintermediary, andintermediary; assuchsuch, it is able to see the messages sent by Clients in thegroup,group but not able to decrypt them and read their plain content.</t> </li> </ul> <t>This document specifies a mechanism for:</t> <ul spacing="normal"><li>Authorizing<li>authorizing a Client to join the group (<xreftarget="sec-auth"/>),target="sec-auth"/>) and providing it with the group keying material to communicate with the other group members (<xreftarget="key-distr"/>).</li> <li>Allowingtarget="key-distr"/>),</li> <li>allowing a group member to retrieve group keying material(<xref target="ssec-key-material-retrieval"/>(Sections <xref target="ssec-key-material-retrieval" format="counter"/> and <xreftarget="update-keys"/>).</li> <li>Allowingtarget="update-keys" format="counter"/>),</li> <li>allowing a group member to retrieve authentication credentials of other group members (<xref target="sec-key-retrieval"/>) and to provide an updated authentication credential (<xreftarget="update-pub-key"/>).</li> <li>Allowingtarget="update-pub-key"/>),</li> <li>allowing a group member to leave the group (<xreftarget="ssec-group-leaving"/>).</li> <li>Evictingtarget="ssec-group-leaving"/>),</li> <li>evicting a group member from the group (<xreftarget="sec-node-removal"/>).</li>target="sec-node-removal"/>), and</li> <li><t>Renewing<t>renewing andre-distributingredistributing the group keying material (rekeying), e.g., upon a membership change in the group (<xref target="sec-group-rekeying"/>). </t> <t> Rekeying the group may result in a temporary misalignment of the keying material stored by the different group members. Different situations where this can happen and how they can be handled are discussed in <xref target="sec-misalignment-keying-material"/>.</t> </li> </ul> <t><xref target="fig-flow"/> provides ahigh levelhigh-level overview of the message flow for a node joining a group. The message flow can be expanded as follows.</t> <ol spacing="normal" type="1"><li> <t>The joining node requests an access token from theAS,AS in order to access one or more group-membership resources at the KDC and hence join the associated groups. </t> <t> This exchange between the Client and ASMUST<bcp14>MUST</bcp14> be secured, as specified by the transport profile of ACE used between the Client and KDC. Based on the response from the AS, the joining node will establish or continue using a secure communication association with the KDC.</t> </li> <li> <t>The joining node transfers authentication and authorization information to theKDC,KDC by transferring the obtained access token. This is typically achieved by including the access token in a request sent to the /authz-info endpoint at the KDC. </t> <t> Once this exchange is completed, the joining nodeMUST<bcp14>MUST</bcp14> have a secure communication association established with theKDC,KDC before joining a group under that KDC. </t> <t> This exchange and the following secure communications between the Client and the KDCMUST<bcp14>MUST</bcp14> occur in accordance with the transport profile of ACE used between the Client and KDC, such as the DTLS transport profile <xref target="RFC9202"/> and OSCORE transport profile <xref target="RFC9203"/> of ACE.</t> </li> <li> <t>The joining node starts the joining process to become a member of thegroup,group by sending a request to the related group-membership resource at the KDC. Based on the application requirements and policies, the KDC may perform a grouprekeying,rekeying by generating new group keying material and distributing it to the current group members through the rekeying scheme used in the group. </t> <t> At the end of the joining process, the joining node has receivedfrom the KDCthe parameters and group keying material from the KDC to securely communicate with the other group members. Also, the KDC has stored the association between the authorization information from the access token and the secure session with the joining node.</t> </li> <li>The joining node and the KDC maintain the secureassociation,association to support possible future communications. These especially include key management operations, such as the retrieval of updated keying material or participationtoof a group rekeying process.</li> <li>The joining node can communicate securely with the other groupmembers,members by using the keying material provided in step 3.</li> </ol> <figure anchor="fig-flow"> <name>Message FlowUponupon a New Node's Joining</name> <artwork align="center"><![CDATA[ C AS KDC Group | | | Members / | | | | | |--- Authorization Request -->| | | | | | | | | |<-- Authorization Response --| | | (*) < | | | | | | | | | | |--- Token Transfer Request ---->| | | | | | | |<--- Token Transfer Response-----| | \ | | | | | | | | |--------- Join Request --------->| | | | | | | | | -- Group rekeying -->| | | | (optional) | |<-------- Join Response ---------| | | | | | | | | | | | | Dispatcher | | | | |<======= Secure group communication =========|=========>| | | | (*) Defined in the ACE framework ]]></artwork> </figure> </section> <section anchor="sec-auth"> <name>Authorization to Join a Group</name> <t>This section describes in detail the format of messages exchanged by the participants when a node requests access to a given group. This exchange is based on ACE <xref target="RFC9200"/>.</t> <t>As defined in <xref target="RFC9200"/>, the Client asks the AS for the authorization to join the group through the KDC (see <xref target="ssec-authorization-request"/>). If the request is approved and authorization is granted, the AS provides the Client with a proof-of-possession access token and parameters to securely communicate with the KDC (see <xref target="ssec-authorization-response"/>).</t> <t>Communications between the Client and the ASMUST<bcp14>MUST</bcp14> besecured,secured according to what is defined by the used transport profile of ACE. The Content-Format used in the message also depends on the used transport profile of ACE. <!--[rfced] In this document, media type names appear in single quotes and without quotes in running text. We recommend using single quotes around media type names within this document. (Exception: we plan to leave the double quotes as they are because they used in the context of Content-Format). Please let us know if you prefer otherwise. For example: Original: it can be application/ace+cbor for the first two message and application/cwt for the third message: Suggested: it can be 'application/ace+cbor' for the first two messages and 'application/cwt' for the third message: --> For example, it can be application/ace+cbor for the first two messages and application/cwt for the third message, which are defined in the ACE framework.</t> <t>The transport profile of ACE also defines a number ofdetailsdetails, such as the communication and security protocols used with the KDC (seeAppendix C of<xreftarget="RFC9200"/>).</t>target="RFC9200" sectionFormat="of" section="C"/>).</t> <t><xref target="fig-group-member-registration"/> gives an overview of the exchange described above.</t> <figure anchor="fig-group-member-registration"> <name>Message Flow of Join Authorization</name> <artwork align="center"><![CDATA[ Client AS KDC | | | |---- Authorization Request: POST /token ------->| | | | | |<--- Authorization Response: 2.01 (Created) ----| | | | | |---- Token Transfer Request: POST /authz-info ------->| | | | |<--- Token Transfer Response: 2.01 (Created) -------->| | | | ]]></artwork> </figure> <section anchor="ssec-authorization-request"> <name>Authorization Request</name> <t>The Authorization Request sent from the Client to the AS is defined in <xref section="5.8.1" sectionFormat="of" target="RFC9200"/> andMAY<bcp14>MAY</bcp14> contain the following parameters, which, if included,MUST<bcp14>MUST</bcp14> have the format and value as specified below.</t> <ul spacing="normal"> <li><t>'scope',<t>'scope': specifying the names of the groups that the Client requests toaccess,access and optionally the roles that the Client requests to have in those groups. </t> <t> This parameter is encoded as a CBOR byte string, which wraps a CBOR array of scope entries. All the scope entries are specified according toathe same format, i.e., either the AIF format or the textual format defined below. </t> <ul spacing="normal"> <li> <t>If the AIF format is used, each scope entry is encoded as per <xref target="RFC9237"/>, i.e., as a CBOR array [Toid, Tperm]. If a scope entry expresses a set of roles to take in a group as per this document, the object identifier "Toid" specifies the group name andMUST<bcp14>MUST</bcp14> be encoded as a CBOR text string, while the permission set "Tperm" specifies the roles that the Client wishes to take in the group. </t> <t> The AIF format is the default format for application profiles of thisspecification,specification and is preferable for those that aim for a compact encoding of scope. This isdesirableespecially desirable for application profiles defining several roles, with the Client possibly asking for multiple roles combined. </t> <t><xref target="cddl-ex-0"/> shows an example in CDDL notation <xref target="RFC8610"/> where scope uses the AIF format.</t> </li> <li> <t>If the textual format is used, each scope entry is a CBOR array formatted as follows. </t> <ul spacing="normal"> <li>As the first element, the group name, encoded as a CBOR text string.</li> <li>Optionally, as the second element, the role or CBOR array of roles that the Client wishes to take in the group. This element is optional since roles may have been pre-assigned to the Client, as associated with its verifiable identity credentials. Alternatively, the application may have defined a single, well-known role for the target resource(s) and audience(s).</li> </ul> <t> <xref target="cddl-ex"/> shows an example in CDDL notation where scope uses the textualformat,format with the group name and role identifiers encoded as CBOR text strings.</t> </li> </ul> <!--[rfced] For mentions of the REQs and OPTs that are listed in the appendix, would you like links to appear in the HTML and PDF files? As an example, in Section 3.1 see how "REQ1" links to REQ1 in Appendix A. If you would like links to be added throughout, please let us know. Otherwise, we will remove this one sample link. --> <t> It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles of this specification to specify the exact format and encoding of scope(REQ1).(<xref target="req1" format="none">REQ1</xref>). This includes defining the set of possible roles and their identifiers, as well as the corresponding encoding to use in the scope entries according to the used scope format. </t> <t> If the application profile uses the AIF format, it is alsoREQUIRED<bcp14>REQUIRED</bcp14> to register its specific instance of "Toid" and "Tperm", as well as the correspondingMedia Typemedia type and Content-Format, as per the guidelines in <xref target="RFC9237"/> (REQ2). </t> <t> If the application profile uses the textual format, itMAY<bcp14>MAY</bcp14> additionally specify CBOR values to use for abbreviating the role identifiers (OPT1).</t> </li><li>'audience',<li>'audience': with an identifier of the KDC.</li> </ul> <t>As defined in <xref target="RFC9200"/>, other additional parameters can be included if necessary.</t> <figure anchor="cddl-ex-0"> <name>Example of scopeusingUsing the AIFformat</name>Format</name> <!--[rfced] This line appears to be a comment in CDDL; if so, we suggest changing "rfc9237" to "RFC 9237", to match how RFC numbers appear in text. There are two instances. Original: ;# include rfc9237 Perhaps: ;# include RFC 9237 --> <sourcecode type="CDDL"><![CDATA[ ;# include rfc9237 gname = tstr permissions = uint .bits roles roles = &( Requester: 1, Responder: 2, Monitor: 3, Verifier: 4 ) scope_entries = AIF-Generic<gname, permissions> scope = bstr .cbor scope_entries ]]></sourcecode> </figure> <figure anchor="cddl-ex"> <name>Example of scopeusingUsing thetextual format,Textual Format, with therole identifiers encodedRole Identifiers Encoded astext strings</name>Text Strings</name> <sourcecode type="CDDL"><![CDATA[ gname = tstr role = tstr scope_entry = [ gname , ? ( role / [ 2*role ] ) ] scope_entries = [ * scope_entry ] scope = bstr .cbor scope_entries ]]></sourcecode> </figure> </section> <section anchor="ssec-authorization-response"> <name>Authorization Response</name> <t>The AS processes the Authorization Request as defined in <xref section="5.8.2" sectionFormat="of" target="RFC9200"/>, especially verifying that the Client is authorized to access the specified groups with the requestedroles,roles or possibly a subset of those.</t> <t>In case of successful verification, the Authorization Response sent from the AS to the Client is also defined in <xref section="5.8.2" sectionFormat="of" target="RFC9200"/>. Note that the parameter 'expires_in'MAY<bcp14>MAY</bcp14> be omitted if the application defines how the expiration time is communicated to the Client via othermeans,means or if it establishes a default value.</t> <t>Additionally, when included, the following parameterMUST<bcp14>MUST</bcp14> have the corresponding values:</t> <ul spacing="normal"> <li>'scope' has the same format and encoding of 'scope' in the Authorization Request, as defined in <xref target="ssec-authorization-request"/>. If this parameter is not present, the granted scope is equal to the one requested in <xref target="ssec-authorization-request"/>.</li> </ul><t>The<!--[rfced] We note that the following sentence contains the only instance of 'access_token' in the document. Should 'access_token' be updated to something else? Original: The proof-of-possession access token (in 'access_token' above) MUST contain the following parameters: --> <t>The proof-of-possession access token (in 'access_token' above) <bcp14>MUST</bcp14> contain the following parameters:</t> <ul spacing="normal"> <li>a confirmation claim(see, for example(for example, see 'cnf' defined in <xref section="3.1" sectionFormat="of" target="RFC8747"/> for CWT);</li> <li>an expiration time claim(see, for example(for example, see 'exp' defined in <xref section="3.1.4" sectionFormat="of" target="RFC8392"/> forCWT);</li>CWT); and</li> <li> <t>a scope claim(see, for example(for example, see 'scope' registered in <xref section="8.14" sectionFormat="of" target="RFC9200"/> for CWT). </t> <t> This claim specifies the same access control information as in the 'scope' parameter of the AuthorizationResponse,Response if the parameter is present in the message. <!--[rfced] It is unclear what "if present" and "if not present" refer to. How should this sentence be updated? Original: If the parameter is not present, the claim specifies the access control information as in the 'scope' parameter of the Authorization Request, if present, or the default scope that the AS is granting the Client, if not present. --> If the parameter is not present, the claim specifies the access control information as in the 'scope' parameter of the Authorization Request, if present, or the default scope that the AS is granting the Client, if not present. </t> <t> By default, this claim has the same encoding as the 'scope' parameter in the Authorization Request, as defined in <xref target="ssec-authorization-request"/>. </t> <t> Optionally, an alternative extended format of scope defined in <xref target="sec-extended-scope"/> can be used. This format explicitly signals the semantics used to express the actual access control information,and according towhichthishas to be parsed. This enables a Resource Server to correctly process a received access token, also in case: </t> <ul spacing="normal"><li>The<li>the Resource Server implements a KDC that supports multiple application profiles of thisspecification,specification using different scopesemantics;semantics and/or</li><li>The<li>the Resource Server implements further services beyond a KDC for groupcommunication,communication using different scope semantics.</li> </ul> <t> If the Authorization Server is aware that this applies to the Resource Server for which the access token is issued, the Authorization ServerSHOULD<bcp14>SHOULD</bcp14> use the extended format of scope defined in <xref target="sec-extended-scope"/>.</t> </li> </ul> <t>The access tokenMAY<bcp14>MAY</bcp14> additionally contain other claims that the transport profile of ACErequires,or other optionalparameters.</t>parameters require.</t> <t>When receiving an Authorization Request from a Client that was previouslyauthorized,authorized and for which the AS still stores a valid non-expired access token, the ASMAY<bcp14>MAY</bcp14> reply with that token. Note that it is up to application profiles of ACE to make sure thatre-postingreposting the same access token does not causere-usereuse of keying material between nodes (for example, that is accomplished with the use of random nonces in <xref target="RFC9203"/>).</t> </section> <section anchor="token-post"> <name>Token Transferring</name> <t>The Client sends a Token Transfer Request to the KDC, i.e., a CoAP POST request including the access token and targeting the authz-info endpoint (see <xref section="5.10.1" sectionFormat="of" target="RFC9200"/>).</t> <t>Note that this request deviates from the one defined in <xref target="RFC9200"/>, since it allows asking the KDC for additional information concerning the authentication credentials used in the group to ensure source authentication, as well as for possible additional group parameters.</t> <t>The joining nodeMAY<bcp14>MAY</bcp14> ask for this information from the KDC through the same Token Transfer Request. <!--[rfced] We note that the phrasing "have Content-Format set to application/ace..." and "have Content-Format application/ace..." are used inconsistently throughout the document. Should these phrases be consistent? (Note that below are some examples; there are more occurrences throughout the document.) Original: In this case, the message MUST have Content-Format set to application/ace+cbor defined in Section 8.16 of [RFC9200] ... The Token Transfer Response MUST have Content-Format "application/ ace+cbor" ... those messages MUST have Content-Format set to application/ace- groupcomm+cbor ... the KDC MUST reply with a 4.00 (Bad Request) error response, which MUST also have Content-Format application/ace-groupcomm+cbor. --> In this case, the message <bcp14>MUST</bcp14> have the Content-Format set to application/ace+cbor as defined in <xref section="8.16" sectionFormat="of" target="RFC9200"/>, and the message payloadMUST<bcp14>MUST</bcp14> be formatted as a CBOR map, whichMUST<bcp14>MUST</bcp14> include the access token. The CBOR mapMAY<bcp14>MAY</bcp14> additionally include the following parameter, which, if included,MUST<bcp14>MUST</bcp14> have the format and value as specified below.</t> <ul spacing="normal"><li>'sign_info'<li>'sign_info': defined in <xref target="sign-info"/>, specifying the CBOR simple value "null" (0xf6) to request information about the signature algorithm, the signature algorithm parameters, the signature key parameters, and the exact format of authentication credentials used in the groups that the Client has been authorized to join.</li> </ul> <t>Alternatively, such information may be pre-configured on the joiningnode,node or may be retrieved by alternative means. For example, the joining node may have performed an early group discovery process and obtained the link to the associated group-membership resource at the KDC,togetheralong with attributesdescriptive ofthat describe the group configuration(see, e.g.,(e.g., see <xref target="I-D.tiloca-core-oscore-discovery"/>).</t> <t>After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group. Hence, the KDC replies to the Client with a Token Transfer Response, i.e., a CoAP 2.01 (Created) response.</t> <t>The Token Transfer ResponseMUST<bcp14>MUST</bcp14> have Content-Format "application/ace+cbor", and its payload is a CBOR map. Note that this deviates from what is defined in the ACE framework, where the response from the authz-info endpoint is defined as conveying no payload (see <xref section="5.10.1" sectionFormat="of" target="RFC9200"/>).</t> <t>If a scope entry in the access token specifies a role that requires the Client to send its own authentication credential to the KDC when joining the related group, then the CBOR mapMUST<bcp14>MUST</bcp14> include the parameter 'kdcchallenge' defined in <xref target="kdcchallenge"/>, specifying a dedicated challenge N_S generated by the KDC.</t> <t>Later, when joining the group (see <xref target="ssec-key-distribution-exchange"/>), the Client uses the 'kdcchallenge' value and additional information to build a proof-of-possession (PoP) input.ThisIn turn, this isin turnused to computeaPoP evidence, which the Client also provides to the KDC in order to prove possession of its own private key (see the 'client_cred_verify' parameter in <xref target="gid-post"/>).</t> <t>While storing the access token, the KDCMUST<bcp14>MUST</bcp14> store the 'kdcchallenge' value associated with the Client at least until it receives a Join Request from the Client (see <xreftarget="ssec-key-distribution-exchange"/>),target="ssec-key-distribution-exchange"/>) to be able to verify the PoP evidence provided during the joinprocess,process and thus that the Client possesses its own private key. The KDC deletes the 'kdcchallenge' value associated with the Client upon deleting the access token (e.g., upon its expiration, see <xref section="5.10.3" sectionFormat="of" target="RFC9200"/>).</t> <t>The same 'kdcchallenge' valueMAY<bcp14>MAY</bcp14> be reused several times by theClient,Client to generateanew PoP evidence, e.g., in case the Client provides the KDC with a new authentication credential while being a group member (see <xreftarget="update-pub-key"/>),target="update-pub-key"/>) or joins a different group where it intends to use a different authentication credential. Therefore, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the KDC keeps storing the 'kdcchallenge' value after the first join is processed as well. If, upon receiving a Join Request from a Client, the KDC has already discarded the 'kdcchallenge' value, that will trigger an error response with a newly generated 'kdcchallenge' value that the Client can use to restart the join process, as specified in <xref target="ssec-key-distribution-exchange"/>.</t> <t>If 'sign_info' is included in the Token Transfer Request, the KDCSHOULD<bcp14>SHOULD</bcp14> include the 'sign_info' parameter in the Token Transfer Response, as per the format defined in <xref target="sign-info"/>. Note that the field 'id' of each 'sign_info_entry' specifies thename,name or array of groupnames,names to which that 'sign_info_entry' applies. As an exception, the KDCMAY<bcp14>MAY</bcp14> omit the 'sign_info' parameter in the Token Transfer Response even if 'sign_info' is included in the Token TransferRequest,Request in case none of the groups that the Client is authorized to joinusesuse signatures to achieve source authentication.</t> <t>Note that the CBOR map specified as payload of the 2.01 (Created) response may include further parameters, e.g., according to the used transport profile of ACE. Application profiles of this specificationMAY<bcp14>MAY</bcp14> define additional parameters to use within this exchange (OPT2).</t> <t>Application profiles of this specificationMAY<bcp14>MAY</bcp14> define alternative specific negotiations of parameter values for the signature algorithm and signaturekeys,keys if 'sign_info' is not used (OPT3).</t> <t>If allowed by the used transport profile of ACE, the Client may provide the Access Token to the KDC by other means than the Token Transfer Request. An example is the DTLS transport profile of ACE, where the Client can provide the access token to the KDC during the secure session establishment (see <xref section="3.3.2" sectionFormat="of" target="RFC9202"/>).</t> <section anchor="sign-info"> <name>'sign_info' Parameter</name> <t>The 'sign_info' parameter is anOPTIONAL<bcp14>OPTIONAL</bcp14> parameter of the request and response messages exchanged between the Client and the authz-info endpoint at the RS (see <xrefsection="5.10.1."section="5.10.1" sectionFormat="of" target="RFC9200"/>).</t> <t>This parameter allows the Client and the RS to exchange information about a signature algorithm and about authentication credentials to accordingly use for signature verification. Its exact semantics and content are application specific.</t> <t>In this specification and in application profiles building on it, this parameter is used to exchange information about the signature algorithm and about authentication credentials to be used withit,it in the groups indicated by the transferred access token as per its 'scope' claim (see <xref target="ssec-authorization-response"/>).</t> <t>When used in the Token Transfer Request sent to the KDC (see <xref target="token-post"/>), the 'sign_info' parameter specifies the CBOR simple value "null" (0xf6). This is done to ask for information about the signature algorithm and about the authentication credentials used in the groups that, as per the granted roles, the Client has been authorized to join or interact with (e.g., as an external signature verifier).</t> <t>When used in the following Token Transfer Response from the KDC (see <xref target="token-post"/>), the 'sign_info' parameter is a CBOR array of one or more elements. The number of elements is at most the number of groups that the Client has been authorized to join or interact with. Each element contains information about signing parameters and about authentication credentials for one or moregroups,groups and is formatted as follows.</t> <ul spacing="normal"> <li>The first element 'id' is a group name or a CBOR array of group names, which is associated with groups for which the next four elements apply. Each specified group name is a CBOR text string and is hereafter referred to as 'gname'.</li> <li>The second element 'sign_alg' is a CBOR integer or a textstring, indicatingstring that indicates the signature algorithm used in the groups identified by the 'gname' values. It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles to define specific values that this parameter can take (REQ3), which are selected from the set of signing algorithms of theCOSE Algorithms"COSE Algorithms" registry <xref target="COSE.Algorithms"/>.</li> <li>The third element 'sign_parameters' is a CBOR arrayindicatingthat indicates the parameters of the signature algorithm used in the groups identified by the 'gname' values. Its content depends on the value of 'sign_alg'. <!--[rfced] As "values" is plural, should "structure" also be plural? Original: It is REQUIRED of application profiles to define the possible values and structure for the elements of this parameter (REQ4). ... It is REQUIRED of application profiles to define the possible values and structure for the elements of this parameter (REQ5). --> It is <bcp14>REQUIRED</bcp14> for application profiles to define the possible values and structure for the elements of this parameter (REQ4).</li> <li>The fourth element 'sign_key_parameters' is a CBOR arrayindicatingthat indicates the parameters of the key used with the signaturealgorithm,algorithm in the groups identified by the 'gname' values. Its content depends on the value of 'sign_alg'. It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles to define the possible values and structure for the elements of this parameter (REQ5).</li> <li>The fifth element 'cred_fmt' is either a CBOR integer indicating the format of authentication credentials used in the groups identified by the 'gname'values,values or hasvaluethe CBOR simple value "null"(0xf6) indicating(0xf6), which indicates that the KDC does not act as a repository of authentication credentials for group members. Its acceptable integer values are taken from the'Label'"Label" column of the "COSE Header Parameters" registry <xref target="COSE.Header.Parameters"/>, with some of those values also indicating the type of container to use for exchanging the authentication credentials with the KDC (e.g., a chain or bag of certificates). It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles to define specific values to use for thisparameter,parameter consistently with the acceptable formats of authentication credentials (REQ6).</li> </ul> <t>The CDDL notation <xref target="RFC8610"/> of the 'sign_info' parameter is given below.</t> <sourcecode type="CDDL"><![CDATA[ sign_info = sign_info_req / sign_info_resp sign_info_req = null ; in the Token Transfer ; Request to the KDC sign_info_resp = [ + sign_info_entry ] ; in the Token Transfer ; Response from the KDC sign_info_entry = [ id : gname / [ + gname ], sign_alg : int / tstr, sign_parameters : [ any ], sign_key_parameters : [ + parameter : any ], cred_fmt : int / null ] gname = tstr ]]></sourcecode> <t>This format is consistent with every signature algorithm currently defined in <xref target="RFC9053"/>, i.e., with algorithms that have only the COSE key type as their COSE capability. <xref target="sec-future-cose-algs"/> describes how the format of each 'sign_info_entry' can be generalized for possible future registered algorithms having a different set of COSE capabilities.</t> </section> <section anchor="kdcchallenge"> <name>'kdcchallenge' Parameter</name> <t>The 'kdcchallenge' parameter is anOPTIONAL<bcp14>OPTIONAL</bcp14> parameter of the response message returned from the authz-info endpoint at the RS, as defined in <xref section="5.10.1" sectionFormat="of" target="RFC9200"/>. This parameter contains a challenge generated by the RS and provided to the Client.</t> <t>In this specification and in application profiles building on it, the Client can use this challenge to prove possession of its own private key in the Join Request (see the 'client_cred_verify' parameter in <xref target="gid-post"/>).</t> </section> </section> </section> <section anchor="key-distr"> <name>KDC Functionalities</name> <t>This section describes the functionalities provided by the KDC, as related to the provisioning of the keying material as well as to the group membership management.</t> <t>In particular, this section defines the interface available at theKDC;KDC, specifies the handlers of each resource provided by the KDCinterface;interface, and describes how Clients interact with those resources to join a group and to perform additional operations as group members.</t> <t>A key operation that the Client can perform after transferring the access token to the KDC is a Join Request-Response exchange with the KDC. In the Join Request, the Client specifies the group it requests to join (see <xref target="ssec-key-distribution-exchange"/>). The KDC will then verify the access token and that the Client is authorized to join the specified group. If so, the KDC provides the Client with the keying material to securely communicate with the other members of the group.</t> <t>Later on as a group member, the Client can also rely on the interface at the KDC to perform additionaloperations,operations consistent with the roles it has in the group.</t> <section anchor="kdc-if"> <name>Interface at the KDC</name> <t>The KDC provides its interface by hosting the following resources. Note that the root url-path "ace-group" used hereafter is a default name; implementations are not required to use thisname,name and can define their own instead.</t> <t>If request messages sent to the KDC as well as success response messages from the KDC include a payload and specify a Content-Format, those messagesMUST<bcp14>MUST</bcp14> have Content-Format set to application/ace-groupcomm+cbor, as defined in <xref target="content-type"/>. CBOR labels for the message parameters are defined in <xref target="params"/>.</t> <ul spacing="normal"><li> <t>/ace-group<li><t>/ace-group : the path of this root resource is invariant once the resource isestablished,established and indicates that this specification is used. If other applications run on a KDC implementing this specification and use this same path, those applications will collide, and a mechanism will be needed to differentiate the endpoints. </t> <t> A Client can access this resource in order to retrieve a set of group names, each corresponding to one of the specified group identifiers. This operation is described in <xref target="retrieval-gnames"/>. </t> <t> Clients may be authorized to access this resource even without being members of any group at theKDC,KDC and even if they are not authorized to become group members (e.g., when authorized to be external signature verifiers). </t> <t> The Interface Description (if=) Link Target Attribute value "ace.groups" is registered in <xref target="if-ace-group"/> and can be used to describe the interface provided by this root resource. </t> <t> The example below shows an exchange with a KDC with address 2001:db8::ab that hosts the resource /ace-group and returns a link to such a resource in link-format <xref target="RFC6690"/>. </t> <!-- [rfced] Please review each artwork element and let us know if any should be marked as sourcecode (or another element) instead. --> <artwork><![CDATA[ Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: ".well-known" Uri-Path: "core" Uri-Query: "if=ace.groups" Response: Header: Content (Code=2.05) Content-Format: 40 (application/link-format) Payload: <coap://[2001:db8::ab]/ace-group>;if="ace.groups" ]]></artwork> </li><li> <t>/ace-group/GROUPNAME<!--[rfced] In the second sentence, may "of which it contains" be updated to be more concise, as follows or otherwise? Original: * /ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with name GROUPNAME that the KDC manages. In particular, it is the group-membership resource associated with that group, of which it contains the symmetric group keying material. Perhaps: * /ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with name GROUPNAME that the KDC manages. In particular, it is the group-membership resource associated with that group; it contains the symmetric group keying material. --> <li><t>/ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with the name GROUPNAME that the KDC manages. In particular, it is the group-membership resource associated with that group, of which it contains the symmetric group keying material. </t> <t> A Client can access this resource in order to join the group with nameGROUPNAME,GROUPNAME or later as a group member to retrieve the current group keying material. These operations are described in Sections <xreftarget="ssec-key-distribution-exchange"/>target="ssec-key-distribution-exchange" format="counter"/> and <xreftarget="ssec-key-material-retrieval"/>,target="ssec-key-material-retrieval" format="counter"/>, respectively. </t> <t> The Interface Description (if=) Link Target Attribute value "ace.group" is registered in <xref target="if-ace-group"/> and can be used to describe the interface provided by a group-membership resource. </t> <t> The example below shows an exchange with a KDC with address 2001:db8::ab that hosts the group-membership resource /ace-group/gp1 and returns a link to such a resource in link-format <xref target="RFC6690"/>. </t> <artwork><![CDATA[ Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: ".well-known" Uri-Path: "core" Uri-Query: "if=ace.group" Response: Header: Content (Code=2.05) Content-Format: 40 (application/link-format) Payload: <coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group" ]]></artwork> <t> If it is not required that the value of the GROUPNAME URI path and the group name in the access token scope ('gname' in <xref target="ssec-authorization-response"/>) coincide, the KDCMUST<bcp14>MUST</bcp14> implement a mechanism to map the GROUPNAME value in the URI to the groupname,name in order to refer to the correct group (REQ7).</t> </li><li> <t>/ace-group/GROUPNAME/creds<li><t>/ace-group/GROUPNAME/creds : the path of this resource is invariant once the resource is established. This resource contains the authentication credentials of all the members of the group with the name GROUPNAME. </t> <t> This resource is created only in case the KDC acts as a repository of authentication credentials for group members. </t> <t> As a group member, a Client can access this resource in order to retrieve the authentication credentials of other group members. That is, the Client can retrieve the authentication credentials of all the current groupmembers,members or a subset of them by specifying filter criteria. These operations are described in Sections <xreftarget="sec-key-retrieval-all"/>target="sec-key-retrieval-all" format="counter"/> and <xreftarget="sec-key-retrieval"/>,target="sec-key-retrieval" format="counter"/>, respectively. </t> <t> Clients may be authorized to access this resource even without being group members, e.g., if authorized to be external signature verifiers for the group.</t> </li><li> <t>/ace-group/GROUPNAME/kdc-cred<li><t>/ace-group/GROUPNAME/kdc-cred : the path of this resource is invariant once the resource is established. This resource contains the authentication credential of the KDC for the group with the name GROUPNAME. </t> <t> This resource is created only in case the KDC has an associated authentication credential and this is required for the correct group operation. It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles to define whether the KDC has such an associated authentication credential (REQ8). </t> <t> As a group member, a Client can access this resource in order to retrieve the current authentication credential of the KDC. </t> <t> Clients may be authorized to access this resource even without being group members, e.g., if authorized to be external signature verifiers for the group.</t> </li><li> <t>/ace-group/GROUPNAME/policies<li><t>/ace-group/GROUPNAME/policies : the path of this resource is invariant once the resource is established. This resource contains the group policies of the group with the name GROUPNAME. </t> <t> A Client can access this resource as a group member in order to retrieve the group policies. This operation is described in <xref target="policies"/>.</t> </li><li> <t>/ace-group/GROUPNAME/num<li><t>/ace-group/GROUPNAME/num : the path of this resource is invariant once the resource is established. This resource contains the current version number for the symmetric group keying material of the group with the name GROUPNAME. </t> <t> A Client can access this resource as a group member in order to retrieve the version number of the keying material currently used in the group. This operation is described in <xref target="key-version"/>.</t> </li><li> <t>/ace-group/GROUPNAME/nodes/NODENAME<li><t>/ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource of /ace-group/GROUPNAME is hosted for each group member of the group with the name GROUPNAME. Each such resource is identified by the node name NODENAME of the associated groupmember,member and contains the group keying material and the individual keying material for that group member. </t> <t> A Client as a group member can access this resource in order to retrieve the current group keying material together with its individual keyingmaterial;material, request new individual keying material to use in thegroup;group, and leave the group. These operations are described in Sections <xreftarget="update-keys"/>,target="update-keys" format="counter"/>, <xreftarget="new-keys"/>,target="new-keys" format="counter"/>, and <xreftarget="ssec-group-leaving"/>,target="ssec-group-leaving" format="counter"/>, respectively.</t> </li><li> <t>/ace-group/GROUPNAME/nodes/NODENAME/cred<li><t>/ace-group/GROUPNAME/nodes/NODENAME/cred : the path of this resource is invariant once the resource is established. This resource contains the individual authentication credential for the node with the nameNODENAME,NODENAME as a group member of the group with the name GROUPNAME. </t> <t> A Client can access this resource in order to upload at the KDC a new authentication credential to use in the group. This operation is described in <xref target="update-pub-key"/>. </t> <t> This resource is not created if the group member does not have an authentication credential to use in thegroup,group or if the KDC does not store the authentication credentials of group members.</t> </li> </ul> <t>The KDC is expected to fully provide the interface defined above. It is otherwiseREQUIRED of<bcp14>REQUIRED</bcp14> for the application profiles of this specification to indicate which resources are not hosted, i.e., which parts of the interface defined in this section are not supported by the KDC (REQ9). Application profiles of this specificationMAY<bcp14>MAY</bcp14> extend the KDCinterface,interface by defining additional handlers, as well as defining additional resources and their handlers.</t> <t>It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles of this specification to register a Resource Type for the group-membership resource (REQ10), i.e., the group-membership resource at /ace-group/GROUPNAME. This Resource Type can be used to discover the correct URL for sending a Join Request to the KDC. This Resource Type can also be used to indicate which specific application profile of this specification is used by a specific group-membership resource at the KDC.</t> <t>It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles of this specification to define what specific actions (e.g., CoAP methods) are allowed on each resource provided by the KDC interface, depending on whether the Client is a current groupmember;member, the roles that a Client is authorized to take as per the obtained access token (see <xreftarget="ssec-authorization-request"/>);target="ssec-authorization-request"/>), and the roles that the Client has as current group member (REQ11).</t> <section anchor="client-operations"> <name>Operations Supported by Clients</name> <t>It is expected that a Client minimally supports the following set of primary operations and corresponding interactions with the KDC.</t> <ul spacing="normal"> <li>FETCH request to /ace-group/,in order to retrieve group names associated with group identifiers.</li> <li>POST and GET requests to /ace-group/GROUPNAME/,in order to join a group (POST) and later retrieve the current group key material as a group member (GET).</li> <li>GET and FETCH requests to /ace-group/GROUPNAME/creds,in order to retrieve the authentication credentials of all the other group members (GET) or only some of them by filtering (FETCH). While retrieving authentication credentials remains possible by using GET requests, retrieval by filtering allows Clients to greatly limit the size of exchanged messages.</li> <li>GET request to /ace-group/GROUPNAME/num,in order to retrieve the current version of the group key material as a group member.</li> <li>DELETE request to /ace-group/GROUPNAME/nodes/NODENAME,in order to leave the group.</li> </ul> <t>In addition, some Clients may rather not support the following set of secondary operations and corresponding interactions with the KDC. This can be specified, for instance, in compliance documents defining minimalistic Clients and their capabilities in specific deployments. In turn, these might also have to consider the used application profile of this specification.</t> <ul spacing="normal"> <li>GET request to /ace-group/GROUPNAME/kdc-cred,in order to retrieve the current authentication credential of the KDC. This is relevant only if the KDC has an associated authentication credential and this is required for the correct group operation.</li> <li>GET request to /ace-group/GROUPNAME/policies,in order to retrieve the current group policies as a group member.</li> <li>GET request to /ace-group/GROUPNAME/nodes/NODENAME,in order to retrieve the current group keying material and individual keying material. The former can also be retrieved through a GET request to /ace-group/GROUPNAME/ (see above).</li> <li>PUT request to /ace-group/GROUPNAME/nodes/NODENAME,in order to ask for new individual keying material. Alternatively, the Client could obtain new individual keying material byre-joiningrejoining the group through a POST request to /ace-group/GROUPNAME/ (see above). Furthermore, depending on its roles in the group or on the application profile of this specification, the Client might simply not be associated with any individual keying material.</li> <li>POST request to /ace-group/GROUPNAME/nodes/NODENAME/cred,in order to provide the KDC with a new authentication credential. Alternatively, the Client could provide a new authentication credential byre-joiningrejoining the group through a POST request to /ace-group/GROUPNAME/ (see above). Furthermore, depending on its roles in the group, the Client might simply not have an associated authentication credential to provide.</li> </ul> <t>It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles of this specification to categorize possible newly defined operations for Clients into primaryoperationsand secondaryoperations,operations and to provide accompanying considerations (REQ12).</t> </section> <section anchor="kdc-if-errors"> <name>Error Handling</name> <t>Upon receiving a request from a Client, the KDCMUST<bcp14>MUST</bcp14> check that it is storing a valid access token from that Client. If this is not the case, the KDCMUST<bcp14>MUST</bcp14> reply with a 4.01 (Unauthorized) error response.</t> <t>Unless the request targets the /ace-group resource, the KDCMUST<bcp14>MUST</bcp14> check that it is storing a valid access token from that Client such that:</t> <ul spacing="normal"><li>The<li>the scope specified in the access token includes a scope entry related to the group name GROUPNAME associated with the targetedresource;resource and</li><li>The<li>the set of roles specified in that scope entry allows the Client to perform the requested operation on the targeted resource (REQ11).</li> </ul> <t>In case the KDC stores a valid access token but the verifications above fail, the KDCMUST<bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. This responseMAY<bcp14>MAY</bcp14> be an AS Request Creation Hints, as defined in <xref section="5.3" sectionFormat="of" target="RFC9200"/>, in which case the Content-FormatMUST<bcp14>MUST</bcp14> be set to application/ace+cbor.</t> <t>If the request is not formatted correctly (e.g., required fields are not present or are not encoded as expected), the handlerMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response.</t><t>If<!--[rfced] May we update "non-expected" to "unexpected"? Original: If the request includes unknown or non-expected fields, the handler MUST silently ignore them and continue processing the request. Perhaps: If the request includes unknown or unexpected fields, the handler MUST silently ignore them and continue processing the request. --> <t>If the request includes unknown or non-expected fields, the handler <bcp14>MUST</bcp14> silently ignore them and continue processing the request. Application profiles of this specificationMAY<bcp14>MAY</bcp14> define optional or mandatory payload formats for specific error cases (OPT4).</t> <t>Some error responses from the KDC can convey error-specific information according to the problem-details format defined in <xref target="RFC9290"/>. Such error responsesMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor. The payload of these error responsesMUST<bcp14>MUST</bcp14> be a CBOR map specifying a Concise Problem Details data item (see <xref section="2" sectionFormat="of" target="RFC9290"/>). The CBOR map is formatted as follows.</t> <ul spacing="normal"> <li> <t>ItMUST<bcp14>MUST</bcp14> include the Custom Problem Detail entry'ace-groupcomm-error''ace-groupcomm-error', which is registered in <xref target="iana-custom-problem-details"/> of this document. </t> <t> This entry is formatted as a CBOR map including only one field, namely 'error-id'. The map key for 'error-id' is the CBOR unsigned integer with value 0. The value of 'error-id' is a CBOR integer specifying the error that occurred at the KDC. This value is taken from the'Value'"Value" column of the "ACE Groupcomm Errors" registry defined in <xref target="iana-ace-groupcomm-errors"/> of this document. </t> <t> The CDDL notation <xref target="RFC8610"/> of the 'ace-groupcomm-error' entry is given below.</t></li> </ul><sourcecode type="CDDL"><![CDATA[ ace-groupcomm-error = { &(error-id: 0) => int } ]]></sourcecode><ul spacing="normal"></li> <li> <t>ItMAY<bcp14>MAY</bcp14> include further Standard Problem Detail entries or Custom Problem Detail entries (see <xref target="RFC9290"/>). </t> <t> In particular, it can include the Standard Problem Detail entry 'detail' (map key -2), whose value is a CBOR text string that specifies a human-readable, diagnostic description of the error occurred at the KDC. The diagnostic text is intended for software engineers as well as for device and networkoperators,operators in order to aid debugging and provide context for possible intervention. The diagnostic messageSHOULD<bcp14>SHOULD</bcp14> be logged by the KDC. The 'detail' entry is unlikely relevant in an unattended setup where human intervention is not expected.</t> </li> </ul> <t>An example of an error response using the problem-details format is shown in <xref target="fig-exapmle-error-response"/>.</t> <figure anchor="fig-exapmle-error-response"> <name>Example of an Error Response with Problem Details</name> <artwork><![CDATA[ Response: Header: Service Unavailable (Code=5.03) Content-Format: application/concise-problem-details+cbor Payload: { / title / -1: "No available node identifiers", / detail / -2: "Things will change after a group rekeying; try later", / ace-groupcomm-error /TBD:0: { / error-id / 0: 4 / "No available node identifiers" /, } } ]]></artwork> </figure><t>Note to RFC Editor: In the figure above, please replace "TBD" with the unsigned integer assigned as key value to the Custom Problem Detail entry 'ace-groupcomm-error' (see <xref target="iana-custom-problem-details"/>). Then, please delete this paragraph.</t><t>The problem-details formatin general(in general) and the Custom Problem Detail entry 'ace-groupcomm-error'in particular(in particular) areOPTIONAL to<bcp14>OPTIONAL</bcp14> support for Clients. A Client supporting the entry 'ace-groupcomm-error' andable tothat can understand the specified error may use that information to determine what actions to take next.</t> <t><xref target="error-types"/> of this specification defines an initial set of erroridentifiers,identifiers as possible values for the 'error-id' field. Application profiles of this specification inherit this initial set of error identifiers andMAY<bcp14>MAY</bcp14> define additional values (OPT5).</t> </section> </section> <section anchor="ace-group"> <name>/ace-group</name> <t>This resource implements the FETCH handler.</t> <section anchor="ace-group-fetch"> <name>FETCH Handler</name> <t>The FETCH handler receives group identifiers and returns the corresponding group names and GROUPNAME URIs.</t> <t>The handler expects a request with the payload formatted as a CBOR map, whichMUST<bcp14>MUST</bcp14> contain the following fields:</t> <ul spacing="normal"><li>'gid',<li>'gid': whose value is encoded as a CBOR array, containing one or more group identifiers. The exact encoding of the group identifierMUST<bcp14>MUST</bcp14> be specified by the application profile (REQ13). The Client indicates that it wishes to receive the group names of all the groups having these identifiers.</li> </ul> <t>The handler identifies the groups where communications are secured by using the keying material identified by those group identifiers.</t> <t>If all verifications succeed, the handler replies with a 2.05 (Content) response, whose payload is formatted as a CBOR map thatMUST<bcp14>MUST</bcp14> contain the following fields:</t> <ul spacing="normal"><li>'gid',<li>'gid': whose value is encoded as a CBOR array, containing zero or more group identifiers. The handler indicates that those are the identifiers it is sending group names for. This CBOR array is a subset of the 'gid' array in the FETCH request.</li><li>'gname',<li>'gname': whose value is encoded as a CBOR array, containing zero or more group names. The elements of this array are encoded as text strings. Each element of index i in this CBOR array is associated with the element of index i in the 'gid' array.</li><li>'guri',<li>'guri': whose value is encoded as a CBOR array, containing zero or more URIs, each indicating a group-membership resource. The elements of this array are encoded as text strings. Each element of index i in this CBOR array is associated with the element of index i in the 'gid' array.</li> </ul> <t>If the KDC does not find any group associated with the specified group identifiers, the handler returns a response with the payload formatted as a CBOR byte string of zero length.</t> <t>Note that the KDC only verifies that the node is authorized by the AS to access this resource. Nodes that are not members of the group but are authorized to do signature verification on the group messages may be allowed to access thisresource,resource if the application needs it.</t> <section anchor="retrieval-gnames"> <name>Retrieve Group Names</name> <t>In case the joining node only knows the group identifier of the group it wishes to join or about which it wishes to get updated information from the KDC, the node can contact the KDC to request the corresponding group name and group-membership resource URI. The node can request several group identifiers at once. It does so by sending a CoAP FETCH request to the /ace-group endpoint at the KDC formatted as defined in <xref target="ace-group-fetch"/>.</t> <t><xref target="fig-ace-group-fetch"/> gives an overview of the exchanges described above, and <xref target="fig-ace-group-fetch-2"/> shows an example.</t> <figure anchor="fig-ace-group-fetch"> <name>Message Flow of Group Name and URI Retrieval Request-Response</name> <artwork align="center"><![CDATA[ Client KDC | | |------------ Group Name and URI Retrieval Request: -------->| | FETCH /ace-group | | | |<-- Group Name and URI Retrieval Response: 2.05 (Content) --| | | ]]></artwork> </figure> <figure anchor="fig-ace-group-fetch-2"> <name>Example of Group Name and URI Retrieval Request-Response</name> <artwork><![CDATA[ Request: Header: FETCH (Code=0.05) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation): { "gid": [1, 2] } Response: Header: Content (Code=2.05) Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation): { "gid": [1, 2], "gname": ["group1", "group2"], "guri": ["/ace-group/g1", "/ace-group/g2"] } ]]></artwork> </figure> </section> </section> </section> <section anchor="ace-groupgroupname"> <name>/ace-group/GROUPNAME</name> <t>This resource implements the POST and GET handlers.</t> <section anchor="gid-post"> <name>POST Handler</name> <t>The POST handler processes the Join Request sent by a Client to join agroup,group and returns a Join Response as a successful result of the joining process (see <xref target="ssec-key-distribution-exchange"/>). At a high level, the POST handler adds the Client to the list of current group members, adds the authentication credential of the Client to the list of the group members' authentication credentials, and returns the symmetric group keying material for the group identified by GROUPNAME.</t> <t>The handler expects a request with payload formatted as a CBOR map, whichMAY<bcp14>MAY</bcp14> contain the following fields, which, if included,MUST<bcp14>MUST</bcp14> have the format and value as specified below.</t> <ul spacing="normal"><li>'scope',<li>'scope': with the value the specific group that the Client is attempting to join, i.e., the group name, and the roles it wishes to have in the group. This value is a CBOR byte string wrapping one scope entry, as defined in <xref target="ssec-authorization-request"/>.</li> <li><t>'get_creds',<t>'get_creds': if the Client wishes to receive the authentication credentials of the current group members from the KDC. This parameter may be included in the Join Request if the KDC stores the authentication credentials of the group members, while it is not useful to include it if the Client obtains those authentication credentials through alternative means, e.g., from the AS. Note that including this parameter might result in a following Join Response of a large size, which can be inconvenient for resource-constrained devices. </t> <t> If the Client wishes to retrieve the authentication credentials of all the current group members, the 'get_creds' parameterMUST<bcp14>MUST</bcp14> encode the CBOR simple value "null" (0xf6). Otherwise, if the Client wishes to retrieve the authentication credentials of nodes with specific roles, the 'get_creds' parameterMUST<bcp14>MUST</bcp14> encode a non-empty CBORarray,array containing the three elements 'inclusion_flag', 'role_filter', and'id_filter''id_filter', as defined below. </t> <ul spacing="normal"> <li>The first element, namely 'inclusion_flag', encodes the CBOR simple value "true" (0xf5) if the Client wishes to receive the authentication credentials of the nodes having their node identifier specified in 'id_filter' (i.e., selection by inclusive filtering). Instead, this element encodes the CBOR simple value "false" (0xf4) if the Client wishes to receive the authentication credentials of the nodesnot havingthat don't have the node identifiers specified in the third element 'id_filter' (i.e., selection by exclusive filtering). In the Join Request, this parameter encodes the CBOR simple value "true" (0xf5).</li> <li> <t>The second element, namely 'role_filter', is a CBOR array. Each element of the array contains one role or a combination of roles for the group identified by GROUPNAME. This parameter indicates that the Client wishes to receive the authentication credentials of all the group members having any of the specified roles or combination of roles (i.e., having any of those singleroles,roles or at least all the roles indicated in any of those combinations of roles). </t> <t> For example, the array ["role1", "role2+role3"] indicates that the Client wishes to receive the authentication credentials of all group members that have at least "role1" or at least both "role2" and "role3". In the JoinRequestRequest, this parameter is a non-empty array.</t> </li> <li> <t>The third element, namely 'id_filter', is a CBOR array. Each element of the array contains a node identifier of a group member for the group identified by GROUPNAME. This parameter indicates that the Client wishes to receive the authentication credentials of the nodes that have or do not have the specified nodeidentifiers,identifiers based on the value of 'inclusion_flag' (i.e., as a selection by inclusive or exclusive filtering). In the Join Request, the Client does not filter authentication credentials based on node identifiers, so this parameter is an empty array. </t> <t> In fact, when first joining the group, the Client is not expected or capable to express a filter based on node identifiers of other group members. Instead, when already a group member and sending a Join Request tore-join,rejoin, the Client is not expected to include the 'get_creds' parameter in the Join Request altogether, since it can rather retrieve authentication credentials associated with specific group identifiers as defined in <xref target="sec-key-retrieval"/>.</t> </li> </ul> <!--[rfced] We are having some trouble parsing "using as example encoding". May we update it as follows? Original: The CDDL definition [RFC8610] of 'get_creds' is given in Figure 9, using as example encoding: node identifier encoded as a CBOR byte string; role identifier encoded as a CBOR text string, and combination of roles encoded as a CBOR array of roles. Perhaps: The CDDL definition [RFC8610] of 'get_creds' is given in Figure 9; as an example, it uses a node identifier encoded as a CBOR byte string, a role identifier encoded as a CBOR text string, and a combination of roles encoded as a CBOR array of roles. --> <t> The CDDL definition <xref target="RFC8610"/> of 'get_creds' is given in <xref target="cddl-ex-getpubkeys"/>, using as example encoding: node identifier encoded as a CBOR bytestring;string, role identifier encoded as a CBOR text string, and combination of roles encoded as a CBOR array of roles. </t> <t> Note that, for this handler, 'inclusion_flag' is always set totrue,true and the array of roles 'role_filter' is always non-empty, while the array of node identifiers 'id_filter' is always empty. However, this is not necessarily the case for other handlers using the 'get_creds' parameter.</t></li> </ul><figure anchor="cddl-ex-getpubkeys"> <name>CDDLdefinitionDefinition of 'get_creds',using as example node identifier encodedUsing an Example Node Identifier Encoded as bstr androleRole as tstr</name> <sourcecode type="CDDL"><![CDATA[ inclusion_flag = bool role = tstr comb_role = [ 2*role ] role_filter = [ *(role / comb_role) ] id = bstr id_filter = [ *id ] get_creds = null / [ inclusion_flag, role_filter, id_filter] ]]></sourcecode> </figure><ul spacing="normal"> <li>'client_cred',</li> <!--[rfced] As the slash (/) can mean "and", "or", or "and/or", would this instance be more clear as "and/or"? Original: This parameter MUST be present if the KDC is managing (collecting from/distributing to the Client) the authentication credentials of the group members and the Client's role in the group will require the Client to send messages to one or more group members. Perhaps: This parameter MUST be present if the KDC is managing (collecting from and/or distributing to the Client) the authentication credentials of the group members and the Client's role in the group will require the Client to send messages to one or more group members. --> <li>'client_cred': encoded as a CBOR byte string, whose value is the original binary representation of the Client's authentication credential. This parameterMUST<bcp14>MUST</bcp14> be present if the KDC is managing (collectingfrom/distributingfrom / distributing to the Client) the authentication credentials of the group members and the Client's role in the group will require the Client to send messages to one or more group members. It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles to define the specific formats that are acceptable to use for authentication credentials in the group (REQ6).</li><li>'cnonce',<li>'cnonce': encoded as a CBOR bytestring,string and including a dedicated nonce N_C generated by the Client. This parameterMUST<bcp14>MUST</bcp14> be present.</li> <li><t>'client_cred_verify',<t>'client_cred_verify': encoded as a CBOR byte string. This parameterMUST<bcp14>MUST</bcp14> be present if the 'client_cred' parameter is present and no authentication credential associated with the Client's token can be retrieved for that group. </t> <t> This parameter containsaproof-of-possession (PoP) evidence computed by the Client over the following PoP input: the scope (encoded as a CBOR bytestring),string) concatenated with N_S (encoded as a CBOR byte string) concatenated with N_C (encoded as a CBOR byte string), where: </t> <ul spacing="normal"> <li>scope is the CBOR byte string either specified in the 'scope' parameter above, if present, or encoding a default scope entry that the handler is expected to know, ifomitted.</li>omitted;</li> <li>N_S is the challenge received from the KDC in the 'kdcchallenge' parameter of the 2.01 (Created) response to the Token Transfer Request (see <xref target="token-post"/>), encoded as a CBOR bytestring.</li>string; and</li> <li>N_C is the nonce generated by the Client and specified in the 'cnonce' parameter above, encoded as a CBOR byte string.</li> </ul> <t> An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in <xref target="fig-client-cred-input"/>. </t> <t> A possible type of PoP evidence is a signature that the Client computes by using its own private key, whose corresponding public key is specified in the authentication credential carried in the 'client_cred' parameter. Application profiles of this specificationMUST<bcp14>MUST</bcp14> specify the exact approaches used to compute the PoP evidence to include in'client_cred_verify','client_cred_verify' andMUST<bcp14>MUST</bcp14> specify which of those approaches is used in which case (REQ14). </t> <t> If the token was not provided to the KDC through a Token Transfer Request (e.g., it is used directly to validate TLS instead), it isREQUIRED<bcp14>REQUIRED</bcp14> of the specific application profile to define how the challenge N_S is generated (REQ15).</t> </li><li>'creds_repo',<li>'creds_repo': which can be present if the format of the Client's authentication credential in the 'client_cred' parameter is a certificate. <!--[rfced] We are having trouble understanding "has as value the URI". May we update it for clarity? Original: In such a case, this parameter has as value the URI of the certificate. Perhaps: In such a case, this parameter has as its value the URI of the certificate. Or: In such a case, this parameter is set to the URI of the certificate. --> In such a case, this parameter has as value the URI of the certificate. This parameter is encoded as a CBOR text string. Alternative specific encodings of this parameterMAY<bcp14>MAY</bcp14> be defined in application profiles of this specification (OPT6).</li> <li><t>'control_uri',<t>'control_uri': whose value is a full URI, encoded as a CBOR text string. A default url-path is /ace-group/GROUPNAME/node, although implementations can use different ones instead. The URIMUST NOT<bcp14>MUST NOT</bcp14> have url-path /ace-group/GROUPNAME. </t> <t> If 'control_uri' is specified in the Join Request, the Client acts as a CoAP server and hosts a resource at this specific URI. The KDCMAY<bcp14>MAY</bcp14> use this URI to send CoAP requests to the Client (acting as a CoAP server in this exchange), forexampleexample, for one-to-one provisioning of new group keying material when performing a group rekeying (see <xreftarget="update-keys"/>),target="update-keys"/>) or to inform the Client of its removal from the group (see <xref target="sec-node-removal"/>). </t> <t> In particular, this resource is intended for communicationsconcerningexclusively concerning the group identified by GROUPNAME and whose group name is specified in the 'scope' parameter, if present. If the KDC does not implement mechanisms using this resource for that group, it can ignore this parameter. Other additional functionalities of this resourceMAY<bcp14>MAY</bcp14> be defined in application profiles of this specifications (OPT7).</t> </li> </ul> <figure anchor="fig-client-cred-input"> <name>Example of PoPinputInput tocomputeCompute 'client_cred_verify'usingUsing CBORencoding</name>Encoding</name> <artwork><![CDATA[ scope, N_S, and N_C expressed in CBOR diagnostic notation: scope = h'826667726f7570316673656e646572' N_S = h'018a278f7faab55a' N_C = h'25a8991cd700ac01' scope, N_S, and N_C as CBOR encoded byte strings: scope = 0x4f826667726f7570316673656e646572 N_S = 0x48018a278f7faab55a N_C = 0x4825a8991cd700ac01 PoP input: 0x4f 826667726f7570316673656e646572 48 018a278f7faab55a 48 25a8991cd700ac01 ]]></artwork> </figure> <t>If the request does not include a 'scope' field, the KDC is expected to understand what roles the Client is requesting to join the group with. For example, as per the access token, the Client might have been granted access to the group with only one role. If the KDC cannot determine which exact roles should be considered for the Client, itMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response.</t> <t>The handler considers the scope specified in the access token associated with theClient,Client and checks the scope entry related to the group identified by the GROUPNAME associated with the endpoint. In particular, the handler checks whether the set of roles specified in that scope entry includes all the roles that the Client wishes to have in the group as per the Join Request. If this is not the case, the KDCMUST<bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response.</t> <t>If the KDC manages the group members' authentication credentials, the handler checks if one is included in the 'client_cred' field. If so, the KDC retrieves the authentication credential and performs the following actions.</t> <ul spacing="normal"> <li>If the access token was provided through a Token Transfer Request (see <xref target="token-post"/>) but the KDC cannot retrieve the 'kdcchallenge' associated with this Client (see <xref target="token-post"/>), the KDCMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response, whichMUST<bcp14>MUST</bcp14> also have Content-Format application/ace-groupcomm+cbor. The payload of the error response is a CBOR map including a newly generated 'kdcchallenge' value, which is specified in the 'kdcchallenge' parameter. The KDCMUST<bcp14>MUST</bcp14> store the newly generated value as the 'kdcchallenge' value associated with this Client, replacing the currently stored value (if any).</li> <li> <t>The KDC checks the authentication credential to be valid for the group identified by GROUPNAME. That is, it checks that the authentication credential has the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group. </t> <t> If this verification fails, the handlerMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 2 ("Authentication credential incompatible with the group configuration").</t> </li> <li> <t>The KDC verifies the PoP evidence contained in the 'client_cred_verify' field. Application profiles of this specificationMUST<bcp14>MUST</bcp14> specify the exact approaches used to verify the PoPevidence,evidence andMUST<bcp14>MUST</bcp14> specify which of those approaches is used in which case (REQ14). </t> <t> If the PoP evidence does not pass verification, the handlerMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 3 ("Invalid Proof-of-Possession evidence").</t> </li> </ul> <t>If no authentication credential is included in the 'client_cred' field, the handler checks if an authentication credential is already associated with the received access token and to the group identified by GROUPNAME (see also <xref target="ssec-key-distribution-exchange"/>). Note that the same joining node may use different authentication credentials in different groups, and all those authentication credentials would be associated with the same access token.</t> <t>If an eligible authentication credential for the Client is neither present in the 'client_cred' field nor retrieved from the stored ones at the KDC, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the handler stops the processing and replies with a 4.00 (Bad Request) error response. Application profilesMAY<bcp14>MAY</bcp14> define alternatives (OPT8).</t> <t>If, regardless of the reason, the KDC replies with a 4.00 (Bad Request) error response, the payload of the responseMAY<bcp14>MAY</bcp14> be a CBOR map. For instance, the CBOR map can include a 'sign_info' parameter formatted as 'sign_info_res' defined in <xref target="sign-info"/>, with the 'cred_fmt' element set to the CBOR simple value "null" (0xf6) if the Client sent its own authentication credential and the KDC is not set to store authentication credentials of the group members. When the response payload is a CBOR map including such parameters, the error response has Content-Format set to application/ace-groupcomm+cbor.</t> <t>If all the verifications above succeed, the KDC proceeds as follows.</t> <t>First, only in case the Client is not already a group member, the handler performs the following actions:</t> <ul spacing="normal"> <li>The handler adds the Client to the list of current members of the group.</li> <li>The handler assigns a name NODENAME to theClient,Client and creates a sub-resource to /ace-group/GROUPNAME at the KDC, i.e., "/ace-group/GROUPNAME/nodes/NODENAME".</li> <li>The handler associates the node identifier NODENAME with the access token and the secure communication association for the Client.</li> </ul> <t>Then, the handler performs the following actions.</t> <ul spacing="normal"> <li> <t>If the KDC manages the group members' authentication credentials: </t> <ul spacing="normal"> <li>The handler associates the retrieved Client's authentication credential to the tuple composed of the node name NODENAME, the group name GROUPNAME, and the received access token.</li> <li>The handler adds the retrieved Client's authentication credential to the stored list of authentication credentials stored for the group identified by GROUPNAME. If such a list already includes an authentication credential for the Client, but a different authentication credential is specified in the 'client_cred' field, then the handlerMUST<bcp14>MUST</bcp14> replace the old authentication credential in the list with the one specified in the 'client_cred' field.</li> </ul> </li> <li>If backward security is prescribed by application policies installed at the KDC or by the used application profile of this specification, then the KDCMUST<bcp14>MUST</bcp14> generate new group keying material and securely distribute it to the current group members (see <xref target="sec-group-rekeying"/>).</li> <li>The handler returns a successful JoinResponseResponse, as defined below, containing the symmetric group keying material; the group policies; and the authentication credentials of the current members of thegroup,group if the KDC manages those and the Client requested them.</li> </ul> <t>The Join ResponseMUST<bcp14>MUST</bcp14> have response code 2.01 (Created) if the Client has been added to the list of group members in this join exchange (seeabove),above) or 2.04 (Changed) otherwise, i.e., if the Client isre-joiningrejoining the group without having left it.</t> <t>The Join Response messageMUST<bcp14>MUST</bcp14> include the Location-Path CoAP option, specifying the URI path to the sub-resource associated with the Client, i.e., "/ace-group/GROUPNAME/nodes/NODENAME".</t> <t>The Join Response messageMUST<bcp14>MUST</bcp14> have Content-Format application/ace-groupcomm+cbor. The payload of the response is formatted as a CBOR map, whichMUST<bcp14>MUST</bcp14> contain the following fields and values.</t> <ul spacing="normal"><li>'gkty',<li>'gkty': identifying the key type of the keying material specified in the 'key' parameter. This parameter is encoded as a CBOR integer or a CBOR text string. The set of values can be found in the "Key Type" column of the "ACE Groupcomm Key Types" registry. ImplementationsMUST<bcp14>MUST</bcp14> verify that the key type matches the application profile being used, if present, as registered in the "ACE Groupcomm Key Types" registry.</li><li>'key',<li>'key': containing the keying material for the groupcommunication,communication or information required to derive it.</li><li>'num',<li>'num': containing the version number of the keying material for the group communication, formatted as a CBOR integer. This is a strictly monotonic increasing field. The application profileMUST<bcp14>MUST</bcp14> define the initial version number (REQ16).</li> </ul> <t>The exact type of the keying material specified in the 'key' parameterMUST<bcp14>MUST</bcp14> be defined in application profiles of this specification (REQ17), together with values of 'gkty' accepted by the application (REQ18). Additionally, documents specifying a type of keying materialMUST<bcp14>MUST</bcp14> register an entry in the "ACE Groupcomm Key Types" registry defined in <xref target="iana-key"/>, including its name, the corresponding value for the 'gkty parameter', and the application profile to be used with.</t><figure<table anchor="fig-gkty"> <name>ACE Groupcomm Key Types</name><artwork align="center"><![CDATA[ +----------+----------------+---------+-------------+------------+ | Name | Key<thead> <tr> <th>Name</th> <th>Key TypeValue | Profile | Description | Reference | +----------+----------------+---------+-------------+------------+ | Reserved | 0 | | This value | [RFC-XXXX] | | | | | is reserved | | +----------+----------------+---------+-------------+------------+ ]]></artwork> </figure> <t>Note to RFC Editor: In <xref target="fig-gkty"/>, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.</t>Value</th> <th>Profile</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>Reserved</td> <td>0</td> <td></td> <td>This value is reserved</td> <td>RFC 9594</td> </tr> </tbody> </table> <t>The Join ResponseSHOULD<bcp14>SHOULD</bcp14> contain the following parameters:</t> <ul spacing="normal"><li>'exp',<li>'exp': with the value of the expiration time of the keying material for the group communication, encoded as a CBOR unsigned integer. This field contains a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what is specified for NumericDate in <xref section="2" sectionFormat="of" target="RFC7519"/>. Group membersMUST NOT<bcp14>MUST NOT</bcp14> use the keying material after the time indicated in this field, and they can retrieve the new group keying material from the KDC.</li><li>'exi',<li>'exi': with the value of the residual lifetime of the keying material for the group communication, encoded as a CBOR unsigned integer. If the 'exp' parameter is included, this parameterMUST<bcp14>MUST</bcp14> also be included. This field contains a numeric value representing the residual lifetime of the keying material in seconds, i.e., the number of seconds between the current time at the KDC and the time when the keying material expires (as specified in the 'exp' parameter, if present). A Client determines the expiration time of the keying material by adding the seconds specified in the 'exi' parameter to its current time upon receiving the response containing the 'exi' parameter. The ClientMUST NOT<bcp14>MUST NOT</bcp14> use the keying material after such an expiration time, and it can retrieve the new group keying material from the KDC.</li> </ul> <t>If a Client has a reliable way to synchronize its internal clock with UTC, and both the 'exp' and 'exi' parameters are present, then the ClientMUST<bcp14>MUST</bcp14> use the 'exp' parameter value as expiration time for the group keying material. Otherwise, the Client uses the 'exi' parameter value.</t> <t>When a Client relies on the 'exi' parameter, the expiration time that it computes is offset in the future with respect to the actual expiration time as intended by the KDC and specified in the 'exp' parameter (if present). Such an offset is the amount of time between when the KDC sends the response message including the 'exi' parameter and when the Client receives that message. That is, especially if the delivery of the response to the Client is delayed, the Client will believe the keying material to be valid for a longer time than the KDC actually means. However, before approaching the actual expiration time, the KDC is expected to rekey the group and distribute new keying material (see <xref target="sec-group-rekeying"/>).</t> <t>Optionally, the Join ResponseMAY<bcp14>MAY</bcp14> contain the following parameters, which, if included,MUST<bcp14>MUST</bcp14> have the format and value as specified below.</t> <ul spacing="normal"><li>'ace_groupcomm_profile',<li><t>'ace_groupcomm_profile': with the value of a CBOR integer thatMUST<bcp14>MUST</bcp14> be used to uniquely identify the application profile for group communication. Applications of this specificationMUST<bcp14>MUST</bcp14> register an application profile identifier and the related value for this parameter in the "ACE Groupcomm Profiles" registry(REQ19).</li> </ul> <figure(REQ19).</t> <table anchor="ace-groupcomm-profile-0"> <name>ACE Groupcomm Profiles</name><artwork align="center"><![CDATA[ +----------+------------------------+------------+------------+ | Name | Description | CBOR Value | Reference | +----------+------------------------+------------+------------+ | Reserved | This value is reserved | 0 | [RFC-XXXX] | +----------+------------------------+------------+------------+ ]]></artwork> </figure> <t>Note to RFC Editor: In <xref target="ace-groupcomm-profile-0"/>, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.</t> <ul spacing="normal"> <li>'creds',<thead> <tr> <th>Name</th> <th>Description</th> <th>CBOR Value</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>Reserved</td> <td>This value is reserved</td> <td>0</td> <td>[RFC-XXXX</td> </tr> </tbody> </table> </li> <li>'creds': whichMUST<bcp14>MUST</bcp14> be present if 'get_creds' was present in therequest, otherwiserequest; otherwise, itMUST NOT<bcp14>MUST NOT</bcp14> be present. This parameter is a CBOR array specifying the authentication credentials of the group members, i.e., of all of them or of the ones selected according to the 'get_creds' parameter in the request. In particular, each element of the array is a CBOR byte string, whose value is the original binary representation of a group member's authentication credential. It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles to define the specific formats of authentication credentials that are acceptable to use in the group (REQ6).</li> <li><t>'peer_roles',<t>'peer_roles': whichSHOULD<bcp14>SHOULD</bcp14> be present if 'creds' is alsopresent, otherwisepresent; otherwise, itMUST NOT<bcp14>MUST NOT</bcp14> be present. This parameter is a CBOR array of n elements, where n is the number of authentication credentials included in the 'creds' parameter (atmostmost, the number of members in the group). The i-th element of the array specifies the role(s) that the group member associated with the i-th authentication credential in 'creds' has in the group. In particular, each array element is encoded like the role element of a scope entry, which is consistent with the used format (see <xref target="ssec-authorization-request"/>). </t> <t> This parameterMAY<bcp14>MAY</bcp14> be omitted if the Client can rely on other means to unambiguously gain knowledge of the role of each group member whose associated authentication credential is specified in the 'creds' parameter. For example, all such group members may have the same role in the group joined by the Client, and such a role can be unambiguously assumed by the Client (e.g., based on what is defined in the used application profile of this specification). As another example, each of the authentication credentials specified in the 'creds' parameter can indicate the role(s) that the corresponding group member has in the group joined by the Client. </t> <t> When receiving the authentication credential of a Client in the 'client_cred' parameter of a Join Request (see <xref target="ssec-key-distribution-exchange"/>) or of an Authentication Credential Update Request (see <xref target="update-pub-key"/>), the KDC is not expected to check that the authentication credential indicates the role(s) that the Client can have or has in the group in question. When preparing a Join Response, the KDC can decide whether to include the 'peer_roles'parameterparameter, depending on the specific set of authentication credentials specified in the 'creds' parameter of that Join Response.</t> </li><li>'peer_identifiers',<li>'peer_identifiers': whichMUST<bcp14>MUST</bcp14> be present if 'creds' is alsopresent, otherwisepresent; otherwise, itMUST NOT<bcp14>MUST NOT</bcp14> be present. This parameter is a CBOR array of n elements, where n is the number of authentication credentials included in the 'creds' parameter (atmostmost, the number of members in the group). The i-th element of the array specifies the node identifier that the group member associated with the i-th authentication credential in 'creds' has in the group. In particular, the i-th array element is encoded as a CBOR byte string, whose value is the node identifier of the group member. The specific format of node identifiers of group members is specified by the application profile (REQ25).</li><li>'group_policies',<li><t>'group_policies': with the value of a CBOR map, whose entries specify how the group handles specific management aspects. These include, for instance, approaches to achieve synchronization of sequence numbers among group members. The elements of this field are registered in the "ACE Groupcomm Policies" registry. This specification defines the three elements "Sequence Number Synchronization Methods", "Key Update Check Interval", and "Expiration Delta", which are summarized in <xref target="fig-ACE-Groupcomm-Policies"/>. <!--[rfced] Should "content format" be updated to "Content-Format" to match usage throughout the rest of the document? Original: Application profiles that build on this document MUST specify the exact content format and default value of included map entries(REQ20).</li> </ul> <figure(REQ20). --> Application profiles that build on this document <bcp14>MUST</bcp14> specify the exact content format and default value of included map entries (REQ20).</t> <table anchor="fig-ACE-Groupcomm-Policies"> <name>ACE Groupcomm Policies</name><artwork align="center"><![CDATA[ +--------------+-------+----------+----------------------+------------+ | Name | CBOR | CBOR | Description | Reference | | | label | type | | | +--------------+-------+----------+----------------------+------------+ | Sequence | 0 | tstr/int |<thead> <tr> <th>Name</th> <th>CBOR Label</th> <th>CBOR Type</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>Sequence Number Synchronization Method</td> <td>0</td> <td>int or tstr</td> <td> Method for recipient| [RFC-XXXX] | | Number | | |group members to| | | Synchroniza- | | |synchronize with| | | tion Method | | |sequence numbers of| | | | | |sender group| | | | | |members. Its value| | | | | |is taken from the| | | | | | 'Value'"Value" column of| | | | | |theSequence"Sequence Number| | | | | |Synchronization| | | | | | Method registry | | +--------------+-------+----------+----------------------+------------+ | KeyMethod" registry.</td> <td>RFC 9594</td> </tr> <tr> <td>Key Update| 1 | int | PollingCheck Interval</td> <td>1</td> <td>int</td> <td>Polling interval in| [RFC-XXXX] | | Check | | | seconds,seconds for group| | | Interval | | |members to check at| | | | | |the KDC if the| | | | | |latest group keying| | | | | |material is the one| | | | | |that theystore | | +--------------+-------+----------+----------------------+------------+ | Expiration | 2 | uint | Numberstore.</td> <td>RFC 9594</td> </tr> <tr> <td>Expiration Delta</td> <td>2</td> <td>uint</td> <td>Number of seconds| [RFC-XXXX] | | Delta | | |from 'exp' until a| | | | | |UTC date/time, after| | | | | |which group members| | | | | |MUST stop using the| | | | | |group keying| | | | | |material that they| | | | | |store to decrypt| | | | | |incomingmessages | | +--------------+-------+----------|----------------------|------------+ ]]></artwork> </figure> <t>Note to RFC Editor: In <xref target="fig-ACE-Groupcomm-Policies"/>, please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.</t> <ul spacing="normal">messages.</td> <td>RFC 9594</td> </tr> </tbody> </table> </li> <li><t>'kdc_cred',<t>'kdc_cred': encoded as a CBOR byte string, whose value is the original binary representation of the KDC's authentication credential. This parameter is used if the KDC has an associated authentication credential and this is required for the correct group operation. It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles to define whether the KDC has an authentication credential or not and if this has to be provided through the 'kdc_cred' parameter (REQ8). </t> <t> In such a case, the KDC's authentication credentialMUST<bcp14>MUST</bcp14> have the same format used for the authentication credentials of the group members. It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles to define the specific formats that are acceptable to use for the authentication credentials in the group (REQ6).</t> </li><li>'kdc_nonce',<li>'kdc_nonce': encoded as a CBOR bytestring,string and including a dedicated nonce N_KDC generated by the KDC. This parameterMUST<bcp14>MUST</bcp14> be present if the 'kdc_cred' parameter is present.</li> <li><t>'kdc_cred_verify',<t>'kdc_cred_verify': encoded as a CBOR byte string. This parameterMUST<bcp14>MUST</bcp14> be present if the 'kdc_cred' parameter is present. </t> <t> This parameter containsaproof-of-possession (PoP) evidence computed by the KDC over the following PoP input: the nonce N_C (encoded as a CBOR byte string) concatenated with the nonce N_KDC (encoded as a CBOR byte string), where: </t> <ul spacing="normal"> <li>N_C is the nonce generated by the Client and specified in the 'cnonce' parameter of the Join Request, encoded as a CBOR byte string.</li> <li>N_KDC is the nonce generated by the KDC and specified in the 'kdc_nonce' parameter, encoded as a CBOR byte string.</li> </ul> <t> An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in <xref target="fig-kdc-cred-input"/>. </t> <t> A possible type of PoP evidence is a signature that the KDC computes by using its own private key, whose corresponding public key is specified in the authentication credential carried in the 'kdc_cred' parameter. Application profiles of this specificationMUST<bcp14>MUST</bcp14> specify the exact approaches used by the KDC to compute the PoP evidence to include in'kdc_cred_verify','kdc_cred_verify' andMUST<bcp14>MUST</bcp14> specify which of those approaches is used in which case (REQ21).</t> </li><li>'rekeying_scheme',<li><t>'rekeying_scheme': identifying the rekeying scheme that the KDC uses to provide new group keying material to the group members. This parameter is encoded as a CBOR integer, whose value is taken from the "Value" column of the "ACE Groupcomm Rekeying Schemes" registry defined in <xref target="iana-ace-groupcomm-rekeying-schemes"/> of thisspecification.</li> </ul> <figurespecification.</t> <table anchor="rekeying-scheme-0"> <name>ACE Groupcomm Rekeying Schemes</name><artwork align="center"><![CDATA[ +-------+----------------+-------------------------------+------------+ | Value | Name | Description | Reference | +-------+----------------+-------------------------------+------------+ | 0 | Point-to-Point | The<thead> <tr> <th>Value</th> <th>Name</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Point-to-Point</td> <td>The KDC individually targets| [RFC-XXXX] | | | |each node to rekey, using the| | | | |pairwise secure communication| | | | |association with thatnode | | +-------+----------------+-------------------------------+------------+ ]]></artwork> </figure>node</td> <td>RFC 9594</td> </tr> </tbody> </table> <t>Application profiles of this specificationMAY<bcp14>MAY</bcp14> define a default group rekeyingscheme,scheme to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response (OPT9).</t><t>Note to RFC Editor: In <xref target="rekeying-scheme-0"/>, please replace "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.</t> <ul spacing="normal"></li> <li><t>'mgt_key_material',<t>'mgt_key_material': encoded as a CBOR byte string and containing the specific administrative keying material that the joining node requires in order to participate in the group rekeying process performed by the KDC. This parameterMUST NOT<bcp14>MUST NOT</bcp14> be present if the 'rekeying_scheme' parameter is not present and the application profile does not specify a default group rekeying scheme to use in the group. Some simple rekeying schemes may not require specific administrative keying material to be provided, e.g., the basic "Point-to-Point" group rekeying scheme (see <xref target="point-to-point-rekeying"/>). </t> <t> In more advanced group rekeying schemes, the administrative keying material can be composed of multiple keys organized, for instance, into a logical tree hierarchy, whose root key is the only administrative key shared by all the group members. In such a case, each group member is exclusively associated with one leaf key in thehierarchy,hierarchy and stores only the administrative keys from the associated leaf key all the way up along the path to the root key. That is, different group members can be provided with a different subset of the overall administrative keying material. </t> <t> It is expected from separate documents to define how the advanced group rekeyingschemescheme, possibly indicated in the 'rekeying_scheme'parameterparameter, is used by an application profile of this specification. This includes defining the format of the administrative keying material to specify in'mgt_key_material','mgt_key_material' consistently with the group rekeying scheme and the application profile in question.</t> </li> <li><t>'control_group_uri',<t>'control_group_uri': with a full URI as the value, encoded as a CBOR text string. The URIMUST<bcp14>MUST</bcp14> specify addressing information intended to reach all the members in the group. For example, this can be a multicast IP address, optionally together with a port number that, if omitted, defaults to 5683, i.e., the default port number for the "coap" URI scheme (see <xref section="6.1" sectionFormat="of" target="RFC7252"/>). The URIMUST<bcp14>MUST</bcp14> include GROUPNAME in the url-path. A default url-path is /ace-group/GROUPNAME, although implementations can use different ones instead. The URIMUST NOT<bcp14>MUST NOT</bcp14> have url-path /ace-group/GROUPNAME/node. </t> <t> If 'control_group_uri' is included in the Join Response, the Clients supporting this parameter act as CoAP servers, host a resource at this specific URI, and listen to the specified addressing information. </t> <t> The KDCMAY<bcp14>MAY</bcp14> use this URI to send one-to-many CoAP requests to the Client group members (acting as CoAP servers in this exchange), forexampleexample, for one-to-many provisioning of new group keying material when performing a group rekeying (see <xreftarget="update-keys"/>),target="update-keys"/>) or to inform the Clients of their removal from the group (see <xref target="sec-node-removal"/>). </t> <t> In particular, this resource is intended for communicationsconcerningexclusively concerning the group identified by GROUPNAME and whose group name was specified in the 'scope' parameter of the Join Request, if present. If the KDC does not implement mechanisms using this resource for that group, it can ignore this parameter. Other additional functionalities of this resourceMAY<bcp14>MAY</bcp14> be defined in application profiles of this specifications (OPT10).</t> </li> </ul> <figure anchor="fig-kdc-cred-input"> <name>Example of PoPinputInput tocomputeCompute 'kdc_cred_verify'usingUsing CBORencoding</name>Encoding</name> <artwork><![CDATA[ N_C and N_KDC expressed in CBOR diagnostic notation: N_C = h'25a8991cd700ac01' N_KDC = h'cef04b2aa791bc6d' N_C and N_KDC as CBOR encoded byte strings: N_C = 0x4825a8991cd700ac01 N_KDC = 0x48cef04b2aa791bc6d PoP input: 0x48 25a8991cd700ac01 48 cef04b2aa791bc6d ]]></artwork> </figure> <t>After sending the Join Response, if the KDC has an associated authentication credential, the KDCMUST<bcp14>MUST</bcp14> store the N_C value specified in the 'cnonce' parameter of the JoinRequest,Request as a 'clientchallenge' value associated with the Client, replacing the currently stored value (if any). If, as a group member, the Client later sends a GET request to the /ace-group/GROUPNAME/kdc-cred resource for retrieving the latest KDC's authentication credential (see <xref target="kdc-pub-key-get"/>), then the KDC is able to use the stored 'clientchallenge' for computingaPoP evidence to include in the response sent to the Client, hence proving the possession of its own private key.</t> <t>If the Join Response includes the 'kdc_cred_verify' parameter, the Client verifies the conveyed PoP evidence and considers the group joining unsuccessful in case of failed verification. Application profiles of this specificationMUST<bcp14>MUST</bcp14> specify the exact approaches used by the Client to verify the PoP evidence in'kdc_cred_verify','kdc_cred_verify' andMUST<bcp14>MUST</bcp14> specify which of those approaches is used in which case (REQ21).</t> <t>Specific application profiles that build on this documentMUST<bcp14>MUST</bcp14> specify the communication protocol that members of the group use to communicate with each other (REQ22) and how exactly the keying material is used to protect the group communication (REQ23).</t> <section anchor="ssec-key-distribution-exchange"> <name>Join the Group</name> <t><xref target="fig-key-distr-join"/> gives an overview of the join exchange between the Client and theKDC,KDC when the Client first joins a group, while <xref target="fig-key-distr-join-2"/> shows an example.</t> <figure anchor="fig-key-distr-join"> <name>Message Flow of the Join Request-Response</name> <artwork align="center"><![CDATA[ Client KDC | | |-------- Join Request: POST /ace-group/GROUPNAME ------>| | | |<------------ Join Response: 2.01 (Created) ----------- | | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | ]]></artwork> </figure> <figure anchor="fig-key-distr-join-2"> <name>Example of the First Join Request-Response for Group Joining</name> <artwork align="center"><![CDATA[ Request: Header: POST (Code=0.02) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation, with AUTH_CRED and POP_EVIDENCE being CBOR byte strings): { "scope": << [ "group1", ["sender", "receiver"] ] >> , "get_creds": [true, ["sender"], []], "client_cred": AUTH_CRED, "cnonce": h'25a8991cd700ac01', "client_cred_verify": POP_EVIDENCE } Response: Header: Created (Code=2.01) Content-Format: "application/ace-groupcomm+cbor" Location-Path: "kdc.example.com" Location-Path: "g1" Location-Path: "nodes" Location-Path: "c101" Payload (in CBOR diagnostic notation, with KEY, AUTH_CRED_1, AUTH_CRED_2, ID_1, and ID_2 being CBOR byte strings): { "gkty": 13, "key": KEY, "num": 12, "exp": 1924992000, "exi": 2592000, "creds": [ AUTH_CRED_1, AUTH_CRED_2 ], "peer_roles": ["sender", ["sender", "receiver"]], "peer_identifiers": [ ID1, ID2 ] } ]]></artwork> </figure> <t>If not previously established, the Client and the KDCMUST<bcp14>MUST</bcp14> first establish apairwise securepairwise-secure communication association (REQ24). This can be achieved, for instance, by using a transport profile of ACE. The join exchangeMUST<bcp14>MUST</bcp14> occur over that secure communication association. The Client and the KDCMAY<bcp14>MAY</bcp14> use that same secure communication association to protect further pairwise communications that must be protected.</t> <t>It isREQUIRED<bcp14>REQUIRED</bcp14> that the secure communication association between the Client and the KDC is established by using the proof-of-possession key bound to the access token. As a result, theproof-of-possessionproof of possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access token for establishing secure communication between the Client and the KDC.</t> <t>To join the group, the Client sends a CoAP POST request to the /ace-group/GROUPNAME endpoint at the KDC, where the group to join is identified by GROUPNAME. The group name is specified in the scope entry conveyed by the 'scope' parameter of the request (if present), formatted as specified in <xref target="gid-post"/>. This group name is the same as in the scope entry corresponding to that group, specified in the 'scope' parameter of the Authorization Request/Response, or it can be retrieved from it. Note that, in case of successful joining, the Client will receive the URI to retrieve individual keying material and to leave the group in the Location-Path option of the response.</t> <t>If the node is joining a group for the first time and the KDC maintains the authentication credentials of the group members, the Client isREQUIRED<bcp14>REQUIRED</bcp14> to send its own authentication credential and proof-of-possession (PoP) evidence in the Join Request (see the 'client_cred' and 'client_cred_verify' parameters in <xref target="gid-post"/>). The request is accepted only if both the authentication credential is provided and the PoP evidence is successfully verified.</t> <t>If a nodere-joinsrejoins a group as authorized by the same access token and using the same authentication credential, it can omit the authentication credential and the PoP evidence, or just the PoP evidence, from the Join Request. Then, the KDC will be able to retrieve the node's authentication credential associated with the access token for that group. If the authentication credential has been discarded, the KDC replies with a 4.00 (Bad Request) error response, as specified in <xref target="gid-post"/>. If a nodere-joinsrejoins a group but wants to update its own authentication credential, it needs to include both its authentication credential and the PoP evidence in the Join Request like when it joined the group for the first time.</t> </section> </section> <section anchor="gid-get"> <name>GET Handler</name> <t>The GET handler returns the symmetric group keying material for the group identified by GROUPNAME.</t> <t>The handler expects a GET request.</t> <t>In addition to what is defined in <xref target="kdc-if-errors"/>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDCMUST<bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 0 ("Operation permitted only to group members").</t> <t>If all verifications succeed, the handler replies with a 2.05 (Content) response containing the symmetric group keying material. The payload of the response is formatted as a CBOR mapwhich MUSTthat <bcp14>MUST</bcp14> contain the parameters 'gkty', 'key', and'num''num', as specified in <xref target="gid-post"/>.</t> <t>Each of the following parameters specified in <xref target="gid-post"/>MUST<bcp14>MUST</bcp14> also be included in the payload of theresponse,response if they are included in the payload of the Join Responses sent for the group:'rekeying_scheme','rekeying_scheme' and 'mgt_key_material'.</t> <t>The payloadMAY<bcp14>MAY</bcp14> also include the parameters 'ace_groupcomm_profile', 'exp', and'exi''exi', as specified in <xref target="gid-post"/>. If the 'exp' parameter is included, the 'exi' parameterMUST<bcp14>MUST</bcp14> also be included. If the parameter 'exi' is included, its value specifies the residual lifetime of the group keying material from the current time at the KDC.</t> <section anchor="ssec-key-material-retrieval"> <name>Retrieve Group Keying Material</name> <t>A node in the group can contact the KDC to retrieve the current group keyingmaterial,material by sending a CoAP GET request to the /ace-group/GROUPNAME endpoint at the KDC, where the group is identified by GROUPNAME.</t> <t><xref target="fig-retrieve-key-material"/> gives an overview of the key distribution exchange between the Client and theKDC,KDC when the Client first joins a group, while <xref target="fig-retrieve-key-material-2"/> shows an example.</t> <figure anchor="fig-retrieve-key-material"> <name>Message Flow of Key Distribution Request-Response</name> <artwork align="center"><![CDATA[ Client KDC | | |------ Key Distribution Request: GET /ace-group/GROUPNAME ------>| | | |<----------- Key Distribution Response: 2.05 (Content) --------- | | | ]]></artwork> </figure> <figure anchor="fig-retrieve-key-material-2"> <name>Example of Key Distribution Request-Response</name> <artwork><![CDATA[ Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Payload: - Response: Header: Content (Code=2.05) Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation, with KEY being a CBOR byte strings): { "gkty": 13, "key": KEY, "num": 12 } ]]></artwork> </figure> </section> </section> </section> <section anchor="ace-groupgroupnamecreds"> <name>/ace-group/GROUPNAME/creds</name> <t>This resource implements the GET and FETCH handlers.</t> <section anchor="pubkey-fetch"> <name>FETCH Handler</name> <t>The FETCH handler receives identifiers of group members for the group identified by GROUPNAME and returns the authentication credentials of such group members.</t> <t>The handler expects a request with the payload formatted as a CBOR map, whichMUST<bcp14>MUST</bcp14> contain the following field.</t> <ul spacing="normal"> <li><t>'get_creds',<t>'get_creds': whose value is encoded as in <xref target="gid-post"/> with the following modifications. </t> <ul spacing="normal"> <li> <t>The arrays 'role_filter' and 'id_filter'MUST NOT<bcp14>MUST NOT</bcp14> both be empty, i.e., in CDDL notation: [ bool, [ ], [ ] ]. If the 'get_creds' parameter has such a format, the requestMUST<bcp14>MUST</bcp14> be considered malformed, and the KDCMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. </t> <t> Note that a group member can retrieve the authentication credentials of all the current group members by sending a GET request to the same KDC resource instead (see <xref target="sec-key-retrieval-all"/>).</t> </li> <li>The element 'inclusion_flag' encodes the CBOR simple value "true" (0xf5) or "false" (0xf4), as defined in <xref target="gid-post"/>.</li> <li>The array 'role_filter' can beempty,empty if the Client does not wish to filter the requested authentication credentials based on the roles of the group members.</li> <li>The array 'id_filter' contains zero or more node identifiers of groupmembers,members for the group identified by GROUPNAME, as defined in <xref target="gid-post"/>. The array may beempty,empty if the Client does not wish to filter the requested authentication credentials based on the node identifiers of the group members.</li> </ul> </li> </ul> <t>Note that, in case the 'role_filter' array and the 'id_filter' array are both non-empty:</t> <ul spacing="normal"> <li>If the 'inclusion_flag' encodes the CBOR simple value "true" (0xf5), the handler returns the authentication credentials of group members whose roles match with 'role_filter' and/orhavinghave their node identifier specified in 'id_filter'.</li> <li>If the 'inclusion_flag' encodes the CBOR simple value "false" (0xf4), the handler returns the authentication credentials of group members whose roles match with 'role_filter' and, at the same time, do nothavinghave their node identifier specified in 'id_filter'.</li> </ul> <t>The specific format of authentication credentials as well as the identifiers, roles, and combination of roles of group membersMUST<bcp14>MUST</bcp14> be specified by application profiles of this specification (REQ1, REQ6, REQ25).</t> <t>The handler identifies the authentication credentials of the current group members for which either of the following holds:</t> <ul spacing="normal"><li>the<li>The role identifier matches with one of those indicated in the request; note that the request can specify a combination of roles, in whichcasecase, the handler selects only the group members that have all the roles included in the combination.</li><li>the<li>The node identifier matches with one of those indicated in therequest,request or does not match with any of those, which is consistent with the value of the element 'inclusion_flag'.</li> </ul> <t>If all verifications succeed, the handler returns a 2.05 (Content) message response with the payload formatted as a CBOR map, containing only the following parameters from <xref target="gid-post"/>.</t> <ul spacing="normal"><li>'num',<li>'num': which encodes the version number of the current group keying material.</li><li>'creds',<li>'creds': which encodes the list of authentication credentials of the selected group members.</li> <li><t>'peer_roles',<t>'peer_roles': which encodes the role(s) that each of the selected group members has in the group. </t> <t> This parameterSHOULD<bcp14>SHOULD</bcp14> bepresentpresent, and itMAY<bcp14>MAY</bcp14> be omitted, according to the same criteria defined for the Join Response (see <xref target="gid-post"/>).</t> </li><li>'peer_identifiers',<li>'peer_identifiers': which encodes the node identifier that each of the selected group members has in the group.</li> </ul> <t>The specific format of authentication credentials as well as of node identifiers of group members is specified by the application profile (REQ6, REQ25).</t> <t>If the KDC does not store any authentication credential associated with the specified node identifiers, the handler returns a response with the payload formatted as a CBOR byte string of zero length.</t> <t>The handlerMAY<bcp14>MAY</bcp14> enforce one of the followingpolicies,policies in order to handle possible node identifiers that are included in the 'id_filter' element of the 'get_creds' parameter of the request but are not associated with any current group member. Such a policyMUST<bcp14>MUST</bcp14> be specified by the application profile (REQ26).</t> <ul spacing="normal"> <li>The KDC silently ignores those node identifiers.</li> <li> <t>The KDC retains authentication credentials of group members for a given amount of time after theirleaving,leaving before discarding them. As long as such authentication credentials are retained, the KDC provides them to a requesting Client. </t> <t> If the KDC adopts this policy, the application profileMUST<bcp14>MUST</bcp14> also specify the amount of time during which the KDC retains the authentication credential of a former group member after its leaving, possibly on a per-member basis.</t> </li> </ul> <t>Note that this resource handler only verifies that the node is authorized by the AS to access this resource. Nodes that are not members of the group but are authorized to do signature verifications on the group messages may be allowed to access thisresource,resource if the application needs it.</t> <section anchor="sec-key-retrieval"> <name>Retrieve a Subset of Authentication Credentials in the Group</name> <t>In case the KDC maintains the authentication credentials of group members, a node in the group can contact the KDC to request the authentication credentials, roles, and node identifiers of a specified subset of groupmembers,members by sending a CoAP FETCH request to the /ace-group/GROUPNAME/creds endpoint at the KDC, where the group is identified byGROUPNAME,GROUPNAME and formatted as defined in <xref target="pubkey-fetch"/>.</t> <t><xref target="fig-public-key-1"/> gives an overview of the exchange mentioned above, while <xref target="fig-public-key-2"/> shows an example of such an exchange.</t> <figure anchor="fig-public-key-1"> <name>Message Flow of Authentication Credential Request-Response to Obtain the Authentication Credentials of Specific Group Members</name> <artwork align="center"><![CDATA[ Client KDC | | | Authentication Credential Request: | |-------------------------------------------------------->| | FETCH /ace-group/GROUPNAME/creds | | | |<-- Authentication Credential Response: 2.05 (Created) --| | | ]]></artwork> </figure> <figure anchor="fig-public-key-2"> <name>Example of Authentication Credential Request-Response to Obtain the Authentication Credentials of Specific Group Members</name> <artwork><![CDATA[ Request: Header: FETCH (Code=0.05) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "creds" Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation): { "get_creds": [true, [], [ ID_2, ID_3 ]] } Response: Header: Content (Code=2.05) Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation, with AUTH_CRED_2, AUTH_CRED_3, ID_2, and ID_3 being CBOR byte strings): { "creds": [ AUTH_CRED_2, AUTH_CRED_3, ], "peer_roles": [ ["sender", "receiver"], "receiver" ], "peer_identifiers": [ ID_2, ID_3 ] } ]]></artwork> </figure> </section> </section> <section anchor="pubkey-get"> <name>GET Handler</name> <t>The handler expects a GET request.</t> <t>If all verifications succeed, the KDC replies with a 2.05 (Content) response as in the FETCH handler in <xreftarget="pubkey-fetch"/>,target="pubkey-fetch"/> butspecifying in the payloadspecifies the authentication credentials of all the group members, together with their roles and nodeidentifiers.</t>identifiers, in the payload.</t> <t>The parameter 'peer_roles'SHOULD<bcp14>SHOULD</bcp14> be present in the payload of theresponseresponse, and itMAY<bcp14>MAY</bcp14> be omitted, according to the same criteria defined for the Join Response (see <xref target="gid-post"/>).</t> <section anchor="sec-key-retrieval-all"> <name>Retrieve All Authentication Credentials in the Group</name> <t>In case the KDC maintains the authentication credentials of group members, a group or an external signature verifier can contact the KDC to request the authentication credentials, roles, and node identifiers of all the current groupmembers,members by sending a CoAP GET request to the /ace-group/GROUPNAME/creds endpoint at the KDC, where the group is identified by GROUPNAME.</t> <t><xref target="fig-public-key-3"/> gives an overview of the message exchange, while <xref target="fig-public-key-4"/> shows an example of such an exchange.</t> <figure anchor="fig-public-key-3"> <name>Message Flow of Authentication Credential Request-Response to Obtain the Authentication Credentials ofallAll the Group Members</name> <artwork align="center"><![CDATA[ Client KDC | | | Authentication Credential Request: | |-------------------------------------------------------->| | GET /ace-group/GROUPNAME/creds | | | |<-- Authentication Credential Response: 2.05 (Content) --| | | ]]></artwork> </figure> <figure anchor="fig-public-key-4"> <name>Example of Authentication Credential Request-Response to Obtain the Authentication Credentials ofallAll the Group Members</name> <artwork><![CDATA[ Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "creds" Payload: - Response: Header: Content (Code=2.05) Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation, with AUTH_CRED_1, AUTH_CRED_2, AUTH_CRED_3, ID_1, ID_2, and ID_3 being CBOR byte strings): { "num": 5, "creds": [ AUTH_CRED_1, AUTH_CRED_2, AUTH_CRED_3 ], "peer_roles": ["sender", ["sender", "receiver"], "receiver"], "peer_identifiers": [ ID_1, ID_2, ID_3 ] } ]]></artwork> </figure> </section> </section> </section> <section anchor="ace-groupgroupnamekdc-cred"> <name>/ace-group/GROUPNAME/kdc-cred</name> <t>This resource implements a GET handler.</t> <section anchor="kdc-pub-key-get"> <name>GET Handler</name> <t>The handler expects a GET request.</t> <t>If all verifications succeed, the handler returns a 2.05 (Content) message containing the KDC's authentication credential together withaproof-of-possession (PoP) evidence. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/ace-groupcomm+cbor. The payload of the response is a CBOR map, which includes the following fields.</t> <ul spacing="normal"><li>The 'kdc_cred' parameter,<li>'kdc_cred: specifying the KDC's authentication credential. This parameter is encoded like the 'kdc_cred' parameter in the Join Response (see <xref target="gid-post"/>).</li><li>The 'kdc_nonce' parameter,<li>'kdc_nonce': specifying a nonce generated by the KDC. This parameter is encoded like the 'kdc_nonce' parameter in the Join Response (see <xref target="gid-post"/>).</li> <li><t>The 'kdc_cred_verify' parameter,<t>'kdc_cred_verify': specifyingaPoP evidence computed by the KDC over the following PoP input: the nonce N_C (encoded as a CBOR byte string) concatenated with the nonce N_KDC (encoded as a CBOR byte string), where: </t> <ul spacing="normal"> <!--[rfced] This list item (ii) is unclear. How should it be clarified? Original: N_C is the nonce generated by the Client group member such that: i) the nonce was specified [...]; and ii) the KDC stored the nonce as 'clientchallenge' value associated with this Client as group member after sending the corresponding Join Response (see Section 4.3.1). Perhaps: N_C is the nonce generated by the Client group member such that: i) the nonce was specified [...]; and ii) the KDC stored the nonce as a 'clientchallenge' value associated with this group member Client after sending the corresponding Join Response (see Section 4.3.1). Or: N_C is the nonce generated by the Client group member such that: i) the nonce was specified [...]; and ii) the KDC stored the nonce as a 'clientchallenge' value and as a group member associated with this Client after sending the corresponding Join Response (see Section 4.3.1). --> <li>N_C is the nonce generated by the Client group member such that: i) the nonce was specified in the 'cnonce' parameter of the latest Join Request that the Client sent to the KDC in order to join the group identified byGROUPNAME;GROUPNAME and ii) the KDC stored the nonce as 'clientchallenge' value associated with this Client as group member after sending the corresponding Join Response (see <xref target="gid-post"/>). This nonce is encoded as a CBOR byte string.</li> <li>N_KDC is the nonce generated by the KDC and specified in the 'kdc_nonce' parameter, encoded as a CBOR byte string.</li> </ul> <t> An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in <xref target="fig-kdc-cred-input-2"/>. </t> <t> The PoP evidence is computed by means of the same method used for computing the PoP evidence that was included in the Join Response for this Client (see <xref target="gid-post"/>). </t> <t> Application profiles of this specificationMUST<bcp14>MUST</bcp14> specify the exact approaches used by the KDC to compute the PoP evidence to include in'kdc_cred_verify','kdc_cred_verify' andMUST<bcp14>MUST</bcp14> specify which of those approaches is used in which case (REQ21). </t> <t> If an application profile supports the presence of external signature verifiers that send GET requests to this resource, then the application profileMUST<bcp14>MUST</bcp14> specify how external signature verifiers provide the KDC with a self-generated nonce to use as N_C (REQ21).</t> </li> </ul> <figure anchor="fig-kdc-cred-input-2"> <name>Example of PoPinputInput tocomputeCompute 'kdc_cred_verify'usingUsing CBORencoding</name>Encoding</name> <artwork><![CDATA[ N_C and N_KDC expressed in CBOR diagnostic notation: N_C = h'25a8991cd700ac01' N_KDC = h'0b7db12aaff56da3' N_C and N_KDC as CBOR encoded byte strings: N_C = 0x4825a8991cd700ac01 N_KDC = 0x480b7db12aaff56da3 PoP input: 0x48 25a8991cd700ac01 48 0b7db12aaff56da3 ]]></artwork> </figure> <section anchor="kdc-pub-key"> <name>Retrieve the KDC's Authentication Credential</name> <t>In case the KDC has an associated authentication credential as required for the correct group operation, a group member or an external signature verifier can contact the KDC to request the KDC's authenticationcredential,credential by sending a CoAP GET request to the /ace-group/GROUPNAME/kdc-cred endpoint at the KDC, where GROUPNAME identifies the group.</t> <t>Upon receiving the 2.05 (Content) response, the Client retrieves the KDC's authentication credential from the 'kdc_cred'parameter,parameter andMUST<bcp14>MUST</bcp14> verify the proof-of-possession (PoP) evidence specified in the 'kdc_cred_verify' parameter. In case of successful verification of the PoP evidence, the ClientMUST<bcp14>MUST</bcp14> store the obtained KDC's authentication credential and replace the currently stored one.</t> <t>The PoP evidence is verified by means of the same method used when processing the Join Response (see <xref target="gid-post"/>). Application profiles of this specificationMUST<bcp14>MUST</bcp14> specify the exact approaches used by the Client to verify the PoP evidence in'kdc_cred_verify','kdc_cred_verify' andMUST<bcp14>MUST</bcp14> specify which of those approaches is used in which case (REQ21).</t> <t><xref target="fig-kdc-pub-key-req-resp"/> gives an overview of the exchange described above, while <xref target="fig-kdc-pub-key-req-resp-ex"/> shows an example.</t> <figure anchor="fig-kdc-pub-key-req-resp"> <name>Message Flow of KDC Authentication Credential Request-Response to Obtain the Authentication Credential of the KDC</name> <artwork align="center"><![CDATA[ Group Member KDC | | | KDC Authentication Credential Request | |------------------------------------------------------------>| | GET /ace-group/GROUPNAME/kdc-cred | | | |<-- KDC Authentication Credential Response: 2.05 (Content) --| | | ]]></artwork> </figure> <figure anchor="fig-kdc-pub-key-req-resp-ex"> <name>Example of KDC Authentication Credential Request-Response to Obtain the Authentication Credential of the KDC</name> <artwork><![CDATA[ Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "kdc-cred" Payload: - Response: Header: Content (Code=2.05) Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation, with AUTH_CRED_KDC and POP_EVIDENCE being CBOR byte strings): { "kdc_nonce": h'0b7db12aaff56da3', "kdc_cred": AUTH_CRED_KDC, "kdc_cred_verify": POP_EVIDENCE } ]]></artwork> </figure> </section> </section> </section> <section anchor="ace-groupgroupnamepolicies"> <name>/ace-group/GROUPNAME/policies</name> <t>This resource implements the GET handler.</t> <section anchor="policies-get"> <name>GET Handler</name> <t>The handler expects a GET request.</t> <t>In addition to what is defined in <xref target="kdc-if-errors"/>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDCMUST<bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 0 ("Operation permitted only to group members").</t> <t>If all verifications succeed, the handler replies with a 2.05 (Content) response containing the list of policies for the group identified by GROUPNAME. The payload of the response is formatted as a CBOR map including only the parameter 'group_policies' defined in <xref target="gid-post"/> and specifying the current policies in the group. If the KDC does not store any policy, the payload is formatted as a zero-length CBOR byte string.</t> <t>The specific format and meaning of group policiesMUST<bcp14>MUST</bcp14> be specified in the application profile (REQ20).</t> <section anchor="policies"> <name>Retrieve the Group Policies</name> <t>A node in the group can contact the KDC to retrieve the current grouppolicies,policies by sending a CoAP GET request to the /ace-group/GROUPNAME/policies endpoint at the KDC, where GROUPNAME identifies the group, and is formatted as defined in <xref target="policies-get"/></t> <t><xref target="fig-policies"/> gives an overview of the exchange described above, while <xref target="fig-policies-2"/> shows an example.</t> <figure anchor="fig-policies"> <name>Message Flow of Policies Request-Response</name> <artwork align="center"><![CDATA[ Client KDC | | |-- Policies Request: GET /ace-group/GROUPNAME/policies -->| | | |<----------- Policies Response: 2.05 (Content) -----------| | | ]]></artwork> </figure> <figure anchor="fig-policies-2"> <name>Example of Policies Request-Response</name> <artwork><![CDATA[ Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "policies" Payload: - Response: Header: Content (Code=2.05) Content-Format: "application/ace-groupcomm+cbor" Payload(in CBOR diagnostic notation): { "group_policies": {"exp-delta": 120} } ]]></artwork> </figure> </section> </section> </section> <section anchor="ace-groupgroupnamenum"> <name>/ace-group/GROUPNAME/num</name> <t>This resource implements the GET handler.</t> <section anchor="num-get"> <name>GET Handler</name> <t>The handler expects a GET request.</t> <t>In addition to what is defined in <xref target="kdc-if-errors"/>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDCMUST<bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 0 ("Operation permitted only to group members").</t> <t>If all verifications succeed, the handler returns a 2.05 (Content) message containing an integer that represents the version number of the symmetric group keying material. This number is incremented on the KDC every time the KDC updates the symmetric group keyingmaterial,material before the new keying material is distributed. This number is stored in persistent storage.</t> <t>The payload of the response is formatted as a CBOR integer.</t> <section anchor="key-version"> <name>Retrieve the Keying Material Version</name> <t>A node in the group can contact the KDC to request information about the version number of the symmetric group keyingmaterial,material by sending a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the KDC, where GROUPNAME identifies the group, and is formatted as defined in <xref target="num-get"/>. In particular, the version is incremented by the KDC every time the group keying material isrenewed,renewed before it is distributed to the group members.</t> <t><xref target="fig-version"/> gives an overview of the exchange described above, while <xref target="fig-version-2"/> shows an example.</t> <figure anchor="fig-version"> <name>Message Flow of Version Request-Response</name> <artwork align="center"><![CDATA[ Client KDC | | |---- Version Request: GET /ace-group/GROUPNAME/num ---->| | | |<---------- Version Response: 2.05 (Content) -----------| | | ]]></artwork> </figure> <figure anchor="fig-version-2"> <name>Example of Version Request-Response</name> <artwork><![CDATA[ Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "num" Payload: - Response: Header: Content (Code=2.05) Payload(in CBOR diagnostic notation): 13 ]]></artwork> </figure> </section> </section> </section> <section anchor="node-subresource"> <name>/ace-group/GROUPNAME/nodes/NODENAME</name> <t>This resource implements the GET, PUT, and DELETE handlers.</t> <t>In addition to what is defined in <xref target="kdc-if-errors"/>, each of the handlers performs the following two verifications.</t> <ul spacing="normal"> <li>The handler verifies that the Client is a current member of the group. If the verification fails, the KDCMUST<bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 0 ("Operation permitted only to group members").</li> <li>The handler verifies that the node name of the Client is equal to NODENAME used in the url-path. If the verification fails, the handler replies with a 4.03 (Forbidden) error response.</li> </ul> <section anchor="node-get"> <name>GET Handler</name> <t>The handler expects a GET request.</t> <t>If all verifications succeed, the handler replies with a 2.05 (Content) response containing both the group keying material and the individual keying material for theClient,Client or information enabling the Client to derive it.</t> <t>The payload of the response is formatted as a CBOR map, which includes the same fields of the response defined in <xref target="gid-get"/>. In particular, the format for the group keying material is the same as defined in the response of <xref target="gid-get"/>. If the 'exp' parameter is included, the 'exi' parameterMUST<bcp14>MUST</bcp14> also be included. If the parameter 'exi' is included, its value specifies the residual lifetime of the group keying material from the current time at the KDC.</t> <!--[rfced] These sentences are difficult to parse because of their use of commas. May we update them as follows for clarity? Additionally, does "it" refer to the "format"? Original: The specific format of individual keying material for group members, or of the information to derive it, and corresponding CBOR label, MUST be specified in the application profile (REQ27) and registered in Section 11.7. ... The specific format of newly-generated individual keying material for group members, or of the information to derive it, and corresponding CBOR label, MUST be specified in the application profile (REQ27) and registered in Section 11.7. Perhaps: The specific format of individual keying material for group members or of the information to derive the format and corresponding CBOR label MUST be specified in the application profile (REQ27) and registered in Section 11.7. ... The specific format of newly generated individual keying material for group members or of the information to derive the format and corresponding CBOR label MUST be specified in the application profile (REQ27) and registered in Section 11.7. --> <t>The CBOR map can include additional parameters that specify the individual keying material for the Client. The specific format of individual keying material for group members, or of the information to derive it, and corresponding CBOR label,MUST<bcp14>MUST</bcp14> be specified in the application profile (REQ27) and registered in <xref target="iana-reg"/>.</t> <t>Optionally, the KDC can make the sub-resource at /ace-group/GROUPNAME/nodes/NODENAME also Observable <xref target="RFC7641"/> for the associated node. In case the KDC removes that node from the group without having been explicitly asked for it, this allows the KDC to send an unsolicited 4.04 (Not Found) response to the node as a notification of eviction from the group (see <xref target="sec-node-removal"/>).</t> <t>Note that the node could have also been observing the resource at/ace-group/GROUPNAME,/ace-group/GROUPNAME in order to be informed of changes in the keying material. In such a case, this method would result in largely overlapping notifications received for the resource at /ace-group/GROUPNAME and the sub-resource at /ace-group/GROUPNAME/nodes/NODENAME.</t> <t>In order to mitigate this, a node that supports the No-Response option <xref target="RFC7967"/> can use it when starting the observation of the sub-resource at /ace-group/GROUPNAME/nodes/NODENAME. In particular, the GET observation request can also include the No-Response option, with value set to 2 (Not interested in 2.xx responses).</t> <section anchor="update-keys"> <name>Retrieve Group and Individual Keying Material</name> <t>When any of the following happens, a nodeMUST<bcp14>MUST</bcp14> stop using the stored group keying material to protect outgoingmessages,messages andSHOULD<bcp14>SHOULD</bcp14> stop using it to decrypt and verify incoming messages.</t> <ul spacing="normal"> <li>Upon expiration of the keying material, according to what is indicated by the KDC with the 'exp' and/or 'exi' parameter (e.g., in a JoinResponse),Response) or to a pre-configured value.</li> <li>Upon receiving a notification of revoked/renewed keying material from the KDC, possibly as part of an update of the keying material (rekeying) triggered by the KDC.</li> <li>Upon receiving messages from other group members without being able to retrieve the keying material to correctly decrypt them. This may be due to rekeying messages previously sent by theKDC,KDC that the Client was not able to receive or decrypt.</li> </ul> <t>In either case, if it wants to continue participating in the group communication, the Client has to request the latest keying material from the KDC. To this end, the Client sends a CoAP GET request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, formatted as specified in <xref target="node-get"/>. The Client can request the latest keying material from the KDC before the currently stored, old keying material reaches its expiration time.</t> <t>Note that policies can be setup,up so that the Client sends a Key Distribution Request to the KDC only after a given number of received messages could not be decrypted (because of failed decryption processing or the inability to retrieve the necessary keying material).</t> <t>It is application dependent andpertainingpertains to the particular message exchange (e.g., <xref target="I-D.ietf-core-oscore-groupcomm"/>) to set up these policies for instructing Clients to retain incoming messages and for how long (OPT11). This allows Clients to possibly decrypt such messages after getting updated keying material, rather than just consider them invalid messages to discard right away.</t> <t>After having failed to decrypt messages from another group member and having sent a Key Distribution Request to the KDC, the Client might end up retrieving the same, latest group keying material that it already stores. In such a case, multiple failed decryptions might be due to the message sender and/or the KDC that have changed their authentication credential. Hence, the Client can retrieve such latest authenticationcredentials,credentials by sending to the KDC an Authentication Credential Request (see Sections <xreftarget="sec-key-retrieval"/>target="sec-key-retrieval" format="counter"/> and <xreftarget="sec-key-retrieval-all"/>)target="sec-key-retrieval-all" format="counter"/>) and a KDC Authentication Credential Request (see <xref target="kdc-pub-key"/>), respectively.</t> <t>The Client can also send to the KDC a Key Distribution Request without having been triggered by a failed decryption of a message from another groupmember,member if the Client wants to be sure that it currently stores the latest group keying material. If that is the case, the Client will receive from the KDC the same group keying material it already stores.</t> <t><xref target="fig-key-redistr-req-resp"/> gives an overview of the exchange described above, while <xref target="fig-key-redistr-req-resp-2"/> shows an example.</t> <figure anchor="fig-key-redistr-req-resp"> <name>Message Flow of Key Distribution Request-Response</name> <artwork align="center"><![CDATA[ Client KDC | | |------------------ Key Distribution Request: --------------->| | GET /ace-group/GROUPNAME/nodes/NODENAME | | | |<-------- Key Distribution Response: 2.05 (Content) ---------| | | ]]></artwork> </figure> <figure anchor="fig-key-redistr-req-resp-2"> <name>Example of Key Distribution Request-Response</name> <artwork><![CDATA[ Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "nodes" Uri-Path: "c101" Payload: - Response: Header: Content (Code=2.05) Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation, with KEY and IND_KEY being CBOR byte strings, and "ind-key" being the profile-specified label for individual keying material): { "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY } ]]></artwork> </figure> </section> </section> <section anchor="node-put"> <name>PUT Handler</name> <t>The PUT handler processes requests from a Client that asks for new individual keying material, as required to process messages exchanged in the group.</t> <t>The handler expects a PUT request with an empty payload.</t> <t>In addition to what is defined in <xref target="kdc-if-errors"/> and at the beginning of <xref target="node-subresource"/>, the handler verifies that this operation is consistent with the set of roles that the Client has in the group (REQ11). If the verification fails, the KDCMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 1 ("Request inconsistent with the current roles").</t> <t>If the KDC is currently not able to serve this request, i.e., to generate new individual keying material for the requesting Client, the KDCMUST<bcp14>MUST</bcp14> reply with a 5.03 (ServiceUnavailable)unavailable) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 4 ("No available node identifiers").</t> <t>If all verifications succeed, the handler replies with a 2.05 (Content) response containing newlygenerated,generated individual keying material for the Client. The payload of the response is formatted as a CBOR map. The specific format ofnewly-generatednewly generated individual keying material for groupmembers,members or of the information to derive it, and corresponding CBOR label,MUST<bcp14>MUST</bcp14> be specified in the application profile (REQ27) and registered in <xref target="iana-reg"/>.</t> <t>The typical successful outcome consists in replying with newlygenerated,generated individual keying material for the Client, as defined above. However, application profiles of this specificationMAY<bcp14>MAY</bcp14> also extend this handler in order to achieve different akin outcomes (OPT12), for instance:</t> <ul spacing="normal"> <li>Not providing the Client with newlygenerated,generated individual keying material, but rather rekeying the whole group, i.e., providing all the current group members with newly generated group keying material.</li> <li>Both providing the Client with newlygenerated,generated individual keying material, as well as rekeying the whole group, i.e., providing all the current group members with newly generated group keying material.</li> </ul> <t>In either case, the handler may specify the new group keying material as part of the 2.05 (Content) response.</t> <t>Note that this handler is not intended to accommodate requests from a group member to trigger a group rekeying, whose scheduling and execution is an exclusive prerogative of the KDC(see also(also see related security considerations in <xref target="sec-cons-rekeying"/>).</t> <section anchor="new-keys"> <name>Request to Change Individual Keying Material</name> <t>A Client may ask the KDC fornew,new individual keying material. For instance, this can be due to the expiration of such individual keyingmaterial,material or to the exhaustion ofAEAD nonces,Authenticated Encryption with Associated Data (AEAD) nonces if an AEAD encryption algorithm is used for protecting communications in the group. An example of individual keying material can simply be an individual encryption key associated with the Client. Hence, the Client may ask for a new individual encryptionkey,key or for new input material to derive it.</t> <t>To this end, the Client performs a Key Renewal Request-Response exchange with the KDC, i.e., it sends a CoAP PUT request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME identifies the group and NODENAME is its node name, and is formatted as defined in <xref target="node-get"/>.</t> <t><xref target="fig-renewal-req-resp"/> gives an overview of the exchange described above, while <xref target="fig-renewal-req-resp-2"/> shows an example.</t> <figure anchor="fig-renewal-req-resp"> <name>Message Flow of Key Renewal Request-Response</name> <artwork align="center"><![CDATA[ Client KDC | | |---------------- Key Renewal Request: ---------------->| | PUT /ace-group/GROUPNAME/nodes/NODENAME | | | |<-------- Key Renewal Response: 2.05 (Content) --------| | | ]]></artwork> </figure> <figure anchor="fig-renewal-req-resp-2"> <name>Example of Key Renewal Request-Response</name> <artwork><![CDATA[ Request: Header: PUT (Code=0.03) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "nodes" Uri-Path: "c101" Payload: - Response: Header: Content (Code=2.05) Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation, with IND_KEY being a CBOR byte string, and "ind-key" being the profile-specified label for individual keying material): { "ind-key": IND_KEY } ]]></artwork> </figure> <t>Note that there is a difference between the Key Renewal Request in this section and the Key Distribution Request in <xref target="update-keys"/>. The former asks the KDC for new individual keying material, while the latter asks the KDC for the current group keying material together with the current individual keying material.</t> <t>As discussed in <xref target="node-put"/>, application profiles of this specification may define alternative outcomes for the Key Renewal Request-Response exchange (OPT12), where the provisioning of new individual keying material is replaced by or combined with the execution of a whole group rekeying.</t> </section> </section> <section anchor="node-delete"> <name>DELETE Handler</name> <t>The DELETE handler removes the node identified by NODENAME from the group identified by GROUPNAME.</t> <t>The handler expects a DELETE request with an empty payload.</t> <t>In addition to what is defined in <xref target="kdc-if-errors"/>, the handler verifies that the Client is a current member of the group. If the verification fails, the KDCMUST<bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 0 ("Operation permitted only to group members").</t> <t>If all verification succeeds, the handler performs the actions defined in <xref target="sec-node-removal"/> and replies with a 2.02 (Deleted) response with an empty payload.</t> <section anchor="ssec-group-leaving"> <name>Leave the Group</name> <t>A Client can actively request to leave the group. In this case, the Client sends a CoAP DELETE request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME identifies the group and NODENAME is its node name, formatted as defined in <xref target="node-delete"/></t> <t>Note that, after having left the group, the Client may wish to join it again. Then, as long as the Client is still authorized to join the group, i.e., the associated access token is still valid, the Client can request tore-joinrejoin the group directly to the KDC (see <xreftarget="ssec-key-distribution-exchange"/>),target="ssec-key-distribution-exchange"/>) without having to retrieve a new access token from the AS.</t> </section> </section> </section> <section anchor="ace-groupgroupnamenodesnodenamecred"> <name>/ace-group/GROUPNAME/nodes/NODENAME/cred</name> <t>This resource implements the POST handler.</t> <section anchor="node-pub-key-post"> <name>POST Handler</name> <t>The POST handler is used to replace the stored authentication credential of this Client (identified by NODENAME) with the one specified in the request at theKDC,KDC for the group identified by GROUPNAME.</t> <t>The handler expects a POST request withpayloadthe payload, as specified in <xref target="gid-post"/>, with the difference that it includes only the parameters 'client_cred', 'cnonce', and 'client_cred_verify'.</t> <t>The PoP evidence included in the 'client_cred_verify' parameter is computed in the same way considered in <xref target="gid-post"/> and defined by the specific application profile(REQ14),(REQ14) by using the following to build the PoP input: i) the same scope entry specified by the Client in the 'scope' parameter of the latest Join Request that the Client sent to the KDC in order to join the group identified by GROUPNAME; ii) the latest N_S value stored by the Client; and iii) a new N_C nonce generated by the Client and specified in the parameter 'cnonce' of this request.</t> <t>An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in <xref target="fig-client-cred-input-2"/>.</t> <t>It isREQUIRED of<bcp14>REQUIRED</bcp14> for application profiles to define the specific formats of authentication credentials that are acceptable to use in the group (REQ6).</t> <t>In addition to what is defined in <xref target="kdc-if-errors"/> and at the beginning of <xref target="node-subresource"/>, the handler verifies that this operation is consistent with the set of roles that the node has in the group. If the verification fails, the KDCMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 1 ("Request inconsistent with the current roles").</t> <t>If the KDC cannot retrieve the 'kdcchallenge' associated with this Client (see <xref target="token-post"/>), the KDCMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response, whichMUST<bcp14>MUST</bcp14> also have Content-Format application/ace-groupcomm+cbor. The payload of the error response is a CBOR map including a newly generated 'kdcchallenge' value. This is specified in the 'kdcchallenge' parameter. In such acasecase, the KDCMUST<bcp14>MUST</bcp14> store the newly generated value as the 'kdcchallenge' value associated with this Client, replacing the currently stored value (if any).</t> <t>Otherwise, the handler checks that the authentication credential specified in the 'client_cred' field is valid for the group identified by GROUPNAME. That is, the handler checks that the authentication credential is encoded according to the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group. If that cannot be successfully verified, the handlerMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 2 ("Authentication credential incompatible with the group configuration").</t> <t>Otherwise, the handler verifies the PoP evidence contained in the 'client_cred_verify' field of therequest,request by using the authentication credential specified in the 'client_cred' field, as well as the same way considered in <xref target="gid-post"/> and defined by the specific application profile (REQ14). If the PoP evidence does not pass verification, the handlerMUST<bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 3 ("Invalid Proof-of-Possession evidence").</t> <t>If all verifications succeed, the handler performs the following actions.</t> <ul spacing="normal"> <li>The handler associates the authentication credential from the 'client_cred' field of the request with the node identifier NODENAME, as well as with the access token associated with the node identified by NODENAME.</li> <li>In the stored list of group members' authentication credentials for the group identified by GROUPNAME, the handler replaces the authentication credential of the node identified by NODENAME with the authentication credential specified in the 'client_cred' field of the request.</li> </ul> <t>Then, the handler replies with a 2.04 (Changed) response, which does not include a payload.</t> <figure anchor="fig-client-cred-input-2"> <name>Example of PoPinputInput tocomputeCompute 'client_cred_verify'usingUsing CBORencoding</name>Encoding</name> <artwork><![CDATA[ scope, N_S, and N_C expressed in CBOR diagnostic notation: scope = h'826667726f7570316673656e646572' N_S = h'018a278f7faab55a' N_C = h'0446baefc56111bf' scope, N_S, and N_C as CBOR encoded byte strings: scope = 0x4f826667726F7570316673656E646572 N_S = 0x48018a278f7faab55a N_C = 0x480446baefc56111bf PoP input: 0x4f 826667726f7570316673656e646572 48 018a278f7faab55a 48 0446baefc56111bf ]]></artwork> </figure> <section anchor="update-pub-key"> <name>Uploading an Authentication Credential</name> <t>In case the KDC maintains the authentication credentials of group members, a node in the group can contact the KDC to upload a new authentication credential to use in thegroup,group and to replace the currently stored one.</t> <t>To this end, the Client performs an Authentication Credential Update Request-Response exchange with the KDC, i.e., it sends a CoAP POST request to the /ace-group/GROUPNAME/nodes/NODENAME/cred endpoint at the KDC, where GROUPNAME identifies the group and NODENAME is its node name.</t> <t>The request is formatted as specified in <xref target="node-pub-key-post"/>.</t> <t><xref target="fig-pub-key-update-req-resp"/> gives an overview of the exchange described above, while <xref target="fig-pub-key-update-req-resp-2"/> shows an example.</t> <figure anchor="fig-pub-key-update-req-resp"> <name>Message Flow of Authentication Credential Update Request-Response</name> <artwork align="center"><![CDATA[ Client KDC | | |----------- Authentication Credential Update Request: --------->| | POST /ace-group/GROUPNAME/nodes/NODENAME/cred | | | |<-- Authentication Credential Update Response: 2.04 (Changed) --| | | ]]></artwork> </figure> <figure anchor="fig-pub-key-update-req-resp-2"> <name>Example of Authentication Credential Update Request-Response</name> <artwork><![CDATA[ Request: Header: POST (Code=0.02) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "nodes" Uri-Path: "c101" Uri-Path: "cred" Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation, with AUTH_CRED and POP_EVIDENCE being CBOR byte strings): { "client_cred": AUTH_CRED, "cnonce": h'0446baefc56111bf', "client_cred_verify": POP_EVIDENCE } Response: Header: Changed (Code=2.04) Payload: - ]]></artwork> </figure> <t>Additionally, after updating its own authentication credential, a group memberMAY<bcp14>MAY</bcp14> send to the group a number ofrequestsrequests, including an identifier of the updated authentication credential, to notify other group members that they have to retrieve it. How this is done depends on the group communication protocolused,used and therefore is application profile specific (OPT13).</t> </section> </section> </section> </section> <section anchor="sec-node-removal"> <name>Removal of a Group Member</name> <t>A Client identified by NODENAME may be removed from a group identified by GROUPNAME where it is a member, forexampleexample, due to the following reasons.</t> <ol spacing="normal"type="1"><li>Thetype="1"> <li>The Client explicitly asks to leave the group, as defined in <xref target="ssec-group-leaving"/>.</li> <li>The node has been found compromised or is suspected so. The KDC is expected to determine that a group member has to be evicted either through its ownmeans,means or based on information that it obtains from a trusted source (e.g., an Intrusion DetectionSystem,System or an issuer of authentication credentials). Additional mechanics, protocols, and interfaces at the KDC that can support this are out of the scope of this document.</li> <li>The Client's authorization to be a group member with the current roles is not valid anymore, i.e., the access token has expired or has been revoked. If the AS provides token introspection (see <xref section="5.9" sectionFormat="of" target="RFC9200"/>), the KDC can optionally use it and check whether the Client is still authorized.</li> </ol> <t>Ineither case,all cases, the KDC performs the following actions.</t> <ul spacing="normal"> <li>The KDC removes the Client from the list of current members of the group. When doing so, the KDC deletes the currently stored value of 'clientchallenge' for that Client, which was specified in the latest Join Request that the Client sent to the KDC in order to join the group (see <xref target="gid-post"/>).</li> <li>In case of forced eviction, i.e., for cases 2 and 3 above, the KDC deletes the authentication credential of the removedClient,Client if it acts as a repository of authentication credentials for group members.</li> <li>If the removed Client is registered as an observer of the group-membership resource at /ace-group/GROUPNAME, the KDC removes the Client from the list of observers of that resource.</li> <li> <t>If the sub-resource nodes/NODENAME was created for the removed Client, the KDC deletes that sub-resource. </t> <t> In case of forced eviction, i.e., for cases 2 and 3 above, the KDCMAY<bcp14>MAY</bcp14> explicitly inform the removedClient,Client by means of the following methods. </t> <ul spacing="normal"> <li>If the evicted Client implements the 'control_uri' resource specified in <xref target="gid-post"/>, the KDC sends a DELETE request, targeting the URI specified in the 'control_uri' parameter of the Join Request (see <xref target="gid-post"/>).</li> <li> <t>If the evicted Client is observing its associated sub-resource at /ace-group/GROUPNAME/nodes/NODENAME (see <xref target="node-get"/>), the KDC sends an unsolicited 4.04 (Not Found) error response, which does not include the ObserveoptionOption and indicates that the observed resource has been deleted (see <xref section="3.2" sectionFormat="of" target="RFC7641"/>). </t> <t> The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 5 ("Group membership terminated").</t> </li> </ul> </li> <li>If forward security is prescribed by application policies installed at the KDC or by the used application profile of this specification, then the KDCMUST<bcp14>MUST</bcp14> generate new group keying material and securely distribute it to all the current group members except the leaving node (see <xref target="sec-group-rekeying"/>).</li> </ul> </section> <section anchor="sec-group-rekeying"> <name>Group Rekeying Process</name> <t>A group rekeying is started and driven by the KDC. The KDC is not intended to accommodate explicit requests from group members to trigger a group rekeying. That is, the scheduling and execution of a group rekeying is an exclusive prerogative of the KDC. <!--[rfced] Are the three reasons listed the only things that can trigger a group rekeying, or are they just examples? If there are other reasons, should the sentence be updated as follows? Original: Reasons that can trigger a group rekeying are a change in the group membership, the current group keying material approaching its expiration time, or a regularly scheduled update of the group keying material. Perhaps: Some reasons that can trigger a group rekeying include a change in the group membership, the current group keying material approaching its expiration time, or a regularly scheduled update of the group keying material. --> Reasons that can trigger a group rekeying are a change in the group membership, the current group keying material approaching its expiration time, or a regularly scheduled update of the group keying material.</t> <t>The KDC can perform a group rekeying before the current group keying material expires, unless it is acceptable or there are reasons to temporarily pause secure communications in the group, following the expiration of the current keying material. For example, a pause in the group communication might have been scheduled to start anyway when the group keying material expires, e.g., to allow maintenance operations on the group members. As another example, the KDC might be carrying out a verification that some group members are seemingly compromised and to be evicted, and thisrequiresneeds to be completed in order to appropriately define and schedule the exact rekeying process to perform. As a result, the KDC could delay the execution of the group rekeying.</t> <t>The KDCMUST<bcp14>MUST</bcp14> increment the version number NUM of the current keyingmaterial,material before distributing the newly generated keying material with version number NUM+1 to the group. Once the group rekeying is completed, the KDCMUST<bcp14>MUST</bcp14> delete the old keying material andSHOULD<bcp14>SHOULD</bcp14> store the newly distributed keying material in persistent storage.</t> <t>Distributing the new group keying material requires the KDC to send multiple rekeying messages to the group members. Depending on the rekeying scheme used in the group and the reason that has triggered the rekeying process, each rekeying message can be intended for one or multiple group members, hereafter referred to as target group members. The KDCMUST<bcp14>MUST</bcp14> support at least the "Point-to-Point" group rekeying scheme described in <xref target="point-to-point-rekeying"/> andMAY<bcp14>MAY</bcp14> support additional ones.</t> <t>Each rekeying messageMUST<bcp14>MUST</bcp14> have Content-Format set to application/ace-groupcomm+cbor and its payload formatted as a CBOR map, whichMUST<bcp14>MUST</bcp14> include at least the information specified in the Key Distribution Response message (see <xref target="gid-get"/>), i.e., the parameters 'gkty', 'key', and 'num' defined in <xref target="gid-post"/>. The CBOR mapSHOULD<bcp14>SHOULD</bcp14> also include the parameters 'exp' and 'exi'. If the 'exp' parameter is included, the 'exi' parameterMUST<bcp14>MUST</bcp14> also be included. The CBOR mapMAY<bcp14>MAY</bcp14> include the parameter 'mgt_key_material'specifyingto specify new administrative keying material for the target groupmembers,members if it is relevant for the used rekeying scheme.</t> <t>A rekeying message may include additional information, depending on the rekeying scheme used in the group, the reason that has triggered the rekeying process, and the specific target group members. In particular, if the group rekeying is performed due to one or multiple Clients that have joined the group and the KDC acts as a repository of authentication credentials of the group members, then a rekeying messageMAY<bcp14>MAY</bcp14> also include the authentication credentials that those Clients use in the group, together with the roles and node identifier that the corresponding Client has in the group. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to specify this information by means of the parameters 'creds', 'peer_roles', and 'peer_identifiers', like it is done in the Join Response message (see <xref target="gid-post"/>).</t> <t>The complete format of a rekeying message, including the encoding and content of the 'mgt_key_material' parameter, has to be defined in separate specifications aimed at profiling the used rekeying scheme in the context of the used application profile of this specification. As a particular case, an application profile of this specificationMAY<bcp14>MAY</bcp14> define additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme in <xref target="point-to-point-rekeying"/> (OPT14).</t> <t>Consistently with the used group rekeying scheme, the actual delivery of rekeying messages can occur through different approaches, as discussed inthe followingSections <xreftarget="point-to-point-rekeying"/>target="point-to-point-rekeying" format="counter"/> and <xreftarget="one-to-many-rekeying"/>.</t>target="one-to-many-rekeying" format="counter"/>.</t> <t>The possible, temporary misalignment of the keying material stored by the different group members due to a group rekeying is discussed in <xref target="sec-misalignment-keying-material"/>. Further security considerations related to the group rekeying process are compiled in <xref target="sec-cons-rekeying"/>.</t> <section anchor="point-to-point-rekeying"> <name>Point-to-Point Group Rekeying</name> <t>A point-to-point group rekeying consists in the KDC sending one individual rekeying message to each target group member. In particular, the rekeying message is protected by means of the security association between the KDC and the target group member in question, as per the used application profile of this specification and the used transport profile of ACE.</t> <t>This is the approach taken by the basic "Point-to-Point" group rekeying scheme,thatwhich the KDC can explicitly signal in the Join Response (see <xref target="gid-post"/>), through the 'rekeying_scheme' parameter specifying the value 0.</t> <t>When taking this approach in the group identified by GROUPNAME, the KDC can practically deliver the rekeying messages to the target group members in different,co-existingcoexisting ways.</t> <ul spacing="normal"> <li> <t>The KDCSHOULD<bcp14>SHOULD</bcp14> make the /ace-group/GROUPNAME resource Observable <xref target="RFC7641"/>. Thus, upon performing a group rekeying, the KDC can distribute the new group keying material through individual notification responses sent to the target group members that are also observing that resource. </t> <t> In case the KDC deletes the group (and thus deletes the /ace-group/GROUPNAME resource), relying on CoAP Observe as discussed above also allows the KDC to send an unsolicited 4.04 (Not Found) response to each observer groupmember,member as a notification of group termination. The responseMUST<bcp14>MUST</bcp14> have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fieldMUST<bcp14>MUST</bcp14> be set to 6 ("Group deleted").</t> </li> <li> <t>If a target group member specified a URI in the 'control_uri' parameter of the Join Request upon joining the group (see <xref target="gid-post"/>), the KDC can provide that group member with the new group keying material by sending a unicast POST request to that URI. </t> <t> A Client that does not plan to observe the /ace-group/GROUPNAME resource at the KDCSHOULD<bcp14>SHOULD</bcp14> provide a URI in the 'control_uri' parameter of the Join Request upon joining the group.</t> </li> </ul> <t>If the KDC has to send a rekeying message to a target group member, but this did not include the 'control_uri' parameter in the Join Request and is not a registered observer for the /ace-group/GROUPNAME resource, then that target group member would not be able to participate in the group rekeying. Later on, after having repeatedly failed to successfully exchange secure messages in the group, that group member can retrieve the current group keying material from theKDC,KDC by sending a GET request to /ace-group/GROUPNAME or /ace-group/GROUPNAME/nodes/NODENAME (see Sections <xreftarget="gid-get"/>target="gid-get" format="counter"/> and <xreftarget="node-get"/>,target="node-get" format="counter"/>, respectively).</t> <t><xref target="fig-rekeying-example-1"/> provides an example of point-to-point group rekeying. In particular, the example makes the followingassumptions.</t>assumptions:</t> <ul spacing="normal"> <li>The group currently consists of four group members, namely C1, C2, C3, and C4.</li> <li>Each group member, when joining the group, provided the KDC with a URI in the 'control_uri'parameter,parameter with url-path "grp-rek".</li> <li>Before the group rekeying is performed, the keying material used in the group has version number num=5.</li> <li>The KDC performs the group rekeying in such a way to evict the group member C3, which has been found to be compromised.</li> </ul> <t>In the example, the KDC individually rekeys the group members intended to remain in the group (i.e., C1, C2, andC4),C4) by means of one rekeying message each.</t> <figure anchor="fig-rekeying-example-1"> <name>Example of Message Exchanges for a Point-to-Point Group Rekeying</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="384" width="560" viewBox="0 0 560 384" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"> <path d="M 32,32 L 32,64" fill="none" stroke="black"/> <path d="M 40,256 L 40,288" fill="none" stroke="black"/> <path d="M 80,72 L 80,208" fill="none" stroke="black"/> <path d="M 112,256 L 112,288" fill="none" stroke="black"/> <path d="M 184,256 L 184,288" fill="none" stroke="black"/> <path d="M 224,72 L 224,208" fill="none" stroke="black"/> <path d="M 256,256 L 256,288" fill="none" stroke="black"/> <path d="M 328,256 L 328,288" fill="none" stroke="black"/> <path d="M 400,256 L 400,288" fill="none" stroke="black"/> <path d="M 480,256 L 480,288" fill="none" stroke="black"/> <path d="M 520,72 L 520,208" fill="none" stroke="black"/> <path d="M 552,32 L 552,64" fill="none" stroke="black"/> <path d="M 552,256 L 552,288" fill="none" stroke="black"/> <path d="M 32,32 L 552,32" fill="none" stroke="black"/> <path d="M 32,64 L 552,64" fill="none" stroke="black"/> <path d="M 40,256 L 112,256" fill="none" stroke="black"/> <path d="M 184,256 L 256,256" fill="none" stroke="black"/> <path d="M 328,256 L 400,256" fill="none" stroke="black"/> <path d="M 480,256 L 552,256" fill="none" stroke="black"/> <path d="M 40,288 L 112,288" fill="none" stroke="black"/> <path d="M 184,288 L 256,288" fill="none" stroke="black"/> <path d="M 328,288 L 400,288" fill="none" stroke="black"/> <path d="M 480,288 L 552,288" fill="none" stroke="black"/> <path d="M 44,344 L 140,344" fill="none" stroke="black"/> <path d="M 444,344 L 548,344" fill="none" stroke="black"/> <polygon class="arrowhead" points="528,208 516,202.4 516,213.6" fill="black" transform="rotate(90,520,208)"/> <polygon class="arrowhead" points="232,208 220,202.4 220,213.6" fill="black" transform="rotate(90,224,208)"/> <polygon class="arrowhead" points="88,208 76,202.4 76,213.6" fill="black" transform="rotate(90,80,208)"/> <g class="text"> <text x="288" y="52">KDC</text> <text x="24" y="100">Group</text> <text x="168" y="100">Group</text> <text x="464" y="100">Group</text> <text x="28" y="116">keying</text> <text x="172" y="116">keying</text> <text x="468" y="116">keying</text> <text x="36" y="132">material</text> <text x="180" y="132">material</text> <text x="476" y="132">material</text> <text x="32" y="148">(num=6)</text> <text x="176" y="148">(num=6)</text> <text x="472" y="148">(num=6)</text> <text x="76" y="244">/grp-rek</text> <text x="220" y="244">/grp-rek</text> <text x="364" y="244">/grp-rek</text> <text x="516" y="244">/grp-rek</text> <text x="76" y="276">C1</text> <text x="220" y="276">C2</text> <text x="364" y="276">C3</text> <text x="516" y="276">C4</text> <text x="320" y="308">[TO</text> <text x="348" y="308">BE</text> <text x="396" y="308">EVICTED]</text> <text x="40" y="324">|</text> <text x="552" y="324">|</text> <text x="40" y="340">\</text> <text x="172" y="340">Stored</text> <text x="224" y="340">group</text> <text x="276" y="340">keying</text> <text x="340" y="340">material</text> <text x="408" y="340">(num=5)</text> <text x="552" y="340">/</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .----------------------------------------------------------------. | KDC | '----------------------------------------------------------------' | | | Group | Group | Group | keying | keying | keying | material | material | material | (num=6) | (num=6) | (num=6) | | | | | | | | | | v v v /grp-rek /grp-rek /grp-rek /grp-rek .--------. .--------. .--------. .--------. | C1 | | C2 | | C3 | | C4 | '--------' '--------' '--------' '--------' [TO BE EVICTED] | | \____________ Stored group keying material (num=5) _____________/ ]]></artwork> </artset> </figure> </section> <section anchor="one-to-many-rekeying"> <name>One-to-Many Group Rekeying</name> <t>This section provides high-level recommendations on how the KDC can rekey a group by means of a more efficient and scalable group rekeying scheme, e.g., <xreftarget="RFC2093"/><xref target="RFC2094"/><xreftarget="RFC2093"/>, <xref target="RFC2094"/>, and <xref target="RFC2627"/>. That is, each rekeying message might be, and likely is, intended for multiple target group members, and thus can be delivered to the whole group, although possible to decrypt only for the actual target group members.</t> <t>This yields an overall lower number of rekeying messages, thus potentially reducing the overall time required to rekey the group. On the other hand, it requires the KDC to provide and use additional administrative keying material to protect the rekeyingmessages,messages and to additionally sign them to ensure source authentication (see <xref target="one-to-many-rekeying-protection"/>).</t> <t>Compared to a group rekeying performed in a point-to-point fashion (see <xref target="point-to-point-rekeying"/>), a one-to-many group rekeying typically pays off in large-scalegroups,groups due to the reduced time for completing the rekeying, a more efficient utilization of network resources, and a reduced performance overhead at the KDC. To different extents, it also requires individual group members to locally perform additionaloperations,operations in order to handle the administrative keying material and verify source authentication of rekeying messages. Therefore, one-to-many group rekeying schemes and their employment ought to ensure that the experienced performance overhead on the group members also remains bearablealsofor resource-constrained devices.</t> <t>The exact set of rekeying messages to send, their content and format, the administrative keying material to use to protect them, as well as the set of target group members depend on the specific group rekeyingscheme,scheme and are typically affected by the reason that has triggered the group rekeying. Details about the data content and format of rekeying messages have to be defined by separate documents profiling the use of the group rekeyingscheme,scheme in the context of the used application profile of this specification.</t> <t>When one of these group rekeying schemes is used, the KDC providesa number ofrelated information to a Client joining the group in the Join Response message (see <xref target="gid-post"/>). In particular, 'rekeying_scheme' identifies the rekeying scheme used in the group (if no default can be assumed); 'control_group_uri', if present, specifies a URI whose addressing information is, e.g., a multicast IP address,andwhere the KDC will send the rekeying messages for that group by reaching all the group members; and 'mgt_key_material' specifies a subset of the administrative keying material intended for that particular joining Client to have, as used to protect the rekeying messages sent to the group whenintendedalsotointended for that joining Client.</t> <t>Rekeying messages can be protected at the applicationlayer,layer by using COSE and the administrative keying material as prescribed by the specific group rekeying scheme (see <xref target="one-to-many-rekeying-protection"/>). After that, the delivery of protected rekeying messages to the intended target group members can occur in different ways, such as the following ones.</t><ul<dl newline="false" spacing="normal"><li> <t>Over<dt>Over multicast- In-</dt> <dd><t>In this case, the KDC simply sends a rekeying message as a CoAP request addressed to the URI specified in the 'control_group_uri' parameter of the Join Response (see <xref target="gid-post"/>). </t> <t> If a particular rekeying message is intended for a single target group member, the KDC may alternatively protect the message using the security association with that groupmember,member and deliver the message like when using the "Point-to-Point" group rekeying scheme (see <xreftarget="point-to-point-rekeying"/>).</t> </li> <li> <t>Throughtarget="point-to-point-rekeying"/>).</t></dd> <dt>Through a pub-sub communication model- In-</dt> <dd><t>In this case, the KDC acts as a publisher and publishes each rekeying message to a specific "rekeying topic", which is associated with the group and is hosted at a broker server. Following their group joining, the group members subscribe to the rekeying topic at the broker, thus receiving the group rekeying messages as they are published by the KDC. </t> <t> In order to make such message delivery more efficient, the rekeying topic associated with a group can be further organized into subtopics. For instance, the KDC can use a particular subtopic to address a particular set of target group members during the rekeyingprocess,process as possibly aligned to a similar organization of the administrative keying material (e.g., a key hierarchy). </t> <t> The setup of rekeying topics at the broker as well as the discovery of the topics at the broker for group members are application specific. A possible way is for the KDC to provide such information in the Join Response message (see <xreftarget="gid-post"/>),target="gid-post"/>) by means of a new parameter analogous to 'control_group_uri' and specifying the URI(s) of the rekeying topic(s) that a group member has to subscribe to at thebroker.</t> </li> </ul>broker.</t></dd> </dl> <t>Regardless of the specifically used delivery method, the group rekeying scheme can perform a possibleroll-overrollover of the administrative keying material through the same sent rekeying messages. Actually, such aroll-overrollover occurs every time a group rekeying is performed upon the leaving of group members, which have to be excluded from future communications in the group.</t> <t>From ahigh levelhigh-level point of view, each group member stores only a subset of the overall administrative keying material, which is obtained upon joining the group. Then, when a group rekeying occurs:</t> <ul spacing="normal"> <li>Each rekeying message is protected by using a (most convenient) key from the administrative keying material such that: i) the used key is not stored by any node leaving the group, i.e., the key is safe to use and does not have to berenewed;renewed and ii) the used key is stored by all the target groupmembers,members that indeed have to be provided with new group keying material to protect communications in the group.</li> <li>Each rekeying message includes not only the new group keying material intended for all the rekeyed groupmembers,members but also any new administrative keys that: i) are pertaining to and supposed to be stored by the target groupmembers;members and ii) had to be updated since leaving group members to store the previous version.</li> </ul> <t>Further details depend on the specific rekeying scheme used in the group.</t> <t><xref target="fig-rekeying-example-2"/> provides an example of a one-to-many group rekeying over multicast. In particular, the example makes the followingassumptions.</t>assumptions:</t> <ul spacing="normal"> <li>The group currently consists of four group members, namely C1, C2, C3, and C4.</li> <li>Each group member, when joining the group, provided the KDC with a URI in the 'control_uri'parameter,parameter with url-path "grp-rek".</li> <li>Each group member, when joining the group, received from the KDC a URI in the 'control_group_uri' parameter, specifying the multicast address MULT_ADDR and url-path "grp-mrek".</li> <li>Before the group rekeying is performed, the keying material used in the group has version number num=5.</li> <li>The KDC performs the group rekeying in such a way to evict the group member C3, which has been found to be compromised.</li> </ul> <t>In the example, the KDC determines that the most convenient way to perform a group rekeying that evicts C3 is as follows.</t> <t>First, the KDC sends one rekeying message overmulticast,multicast to the multicast address MULT_ADDR and the url-path "grp-mrek". In the figure, the message is denoted with dashed lines. The message is protected with a non-compromised key from the administrative keying material that only C1 and C2 store. Therefore, even though all the group members receive this message, only C1 and C2 are able to decrypt it. The message includes: the new group keying material with version numbernum=6;num=6 and new keys from the administrative keying material to replace those stored by the group members C1, C2, and C3.</t> <t>After that, the KDC sends one rekeying message addressed individually to C4 and with url-path "grp-rek". In the figure, the message is denoted with a dotted line. The message is protected with the secure association shared between C4 and the KDC. The message includes: the new group keying material with version numbernum=6;num=6 and new keys from the administrative keying material to replace those stored by both C4 and C3.</t> <figure anchor="fig-rekeying-example-2"> <name>Example of Message Exchanges for a One-to-Many Group Rekeying</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="400" width="576" viewBox="0 0 576 400" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"> <path d="M 8,32 L 8,64" fill="none" stroke="black"/> <path d="M 8,288 L 8,320" fill="none" stroke="black"/> <path d="M 56,192 L 56,240" fill="none" stroke="black"/> <path d="M 80,288 L 80,320" fill="none" stroke="black"/> <path d="M 112,288 L 112,320" fill="none" stroke="black"/> <path d="M 160,192 L 160,240" fill="none" stroke="black"/> <path d="M 184,288 L 184,320" fill="none" stroke="black"/> <path d="M 216,288 L 216,320" fill="none" stroke="black"/> <path d="M 272,72 L 272,240" fill="none" stroke="black"/> <path d="M 312,288 L 312,320" fill="none" stroke="black"/> <path d="M 344,288 L 344,320" fill="none" stroke="black"/> <path d="M 392,192 L 392,240" fill="none" stroke="black"/> <path d="M 568,32 L 568,64" fill="none" stroke="black"/> <path d="M 568,288 L 568,320" fill="none" stroke="black"/> <path d="M 8,32 L 568,32" fill="none" stroke="black"/> <path d="M 8,64 L 568,64" fill="none" stroke="black"/> <path d="M 56,192 L 392,192" fill="none" stroke="black"/> <path d="M 8,288 L 80,288" fill="none" stroke="black"/> <path d="M 112,288 L 184,288" fill="none" stroke="black"/> <path d="M 216,288 L 312,288" fill="none" stroke="black"/> <path d="M 344,288 L 568,288" fill="none" stroke="black"/> <path d="M 8,320 L 80,320" fill="none" stroke="black"/> <path d="M 112,320 L 184,320" fill="none" stroke="black"/> <path d="M 216,320 L 312,320" fill="none" stroke="black"/> <path d="M 344,320 L 568,320" fill="none" stroke="black"/> <path d="M 12,376 L 132,376" fill="none" stroke="black"/> <path d="M 436,376 L 564,376" fill="none" stroke="black"/> <polygon class="arrowhead" points="400,240 388,234.4 388,245.6" fill="black" transform="rotate(90,392,240)"/> <polygon class="arrowhead" points="280,240 268,234.4 268,245.6" fill="black" transform="rotate(90,272,240)"/> <polygon class="arrowhead" points="168,240 156,234.4 156,245.6" fill="black" transform="rotate(90,160,240)"/> <polygon class="arrowhead" points="64,240 52,234.4 52,245.6" fill="black" transform="rotate(90,56,240)"/> <circle cx="8" cy="96" r="6" class="closeddot" fill="black"/> <circle cx="8" cy="112" r="6" class="closeddot" fill="black"/> <circle cx="336" cy="96" r="6" class="closeddot" fill="black"/> <circle cx="336" cy="128" r="6" class="closeddot" fill="black"/> <g class="text"> <text x="272" y="52">KDC</text> <text x="544" y="84">:</text> <text x="40" y="100">Group</text> <text x="92" y="100">keying</text> <text x="156" y="100">material</text> <text x="224" y="100">(num=6)</text> <text x="368" y="100">Group</text> <text x="420" y="100">keying</text> <text x="544" y="100">:</text> <text x="48" y="116">Updated</text> <text x="140" y="116">administrative</text> <text x="380" y="116">material</text> <text x="448" y="116">(num=6)</text> <text x="544" y="116">:</text> <text x="44" y="132">keying</text> <text x="108" y="132">material</text> <text x="160" y="132">for</text> <text x="188" y="132">C1</text> <text x="216" y="132">and</text> <text x="244" y="132">C2</text> <text x="376" y="132">Updated</text> <text x="468" y="132">administrative</text> <text x="544" y="132">:</text> <text x="372" y="148">keying</text> <text x="436" y="148">material</text> <text x="488" y="148">for</text> <text x="516" y="148">C4</text> <text x="544" y="148">:</text> <text x="544" y="164">:</text> <text x="544" y="180">:</text> <text x="544" y="196">:</text> <text x="544" y="212">:</text> <text x="544" y="228">:</text> <text x="544" y="244">v</text> <text x="48" y="276">/grp-mrek</text> <text x="152" y="276">/grp-mrek</text> <text x="256" y="276">/grp-mrek</text> <text x="384" y="276">/grp-mrek</text> <text x="532" y="276">/grp-rek</text> <text x="44" y="308">C1</text> <text x="148" y="308">C2</text> <text x="268" y="308">C3</text> <text x="452" y="308">C4</text> <text x="216" y="340">[TO</text> <text x="244" y="340">BE</text> <text x="292" y="340">EVICTED]</text> <text x="8" y="356">|</text> <text x="568" y="356">|</text> <text x="8" y="372">\</text> <text x="164" y="372">Stored</text> <text x="216" y="372">group</text> <text x="268" y="372">keying</text> <text x="332" y="372">material</text> <text x="400" y="372">(num=5)</text> <text x="568" y="372">/</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .---------------------------------------------------------------------. | KDC | '---------------------------------------------------------------------' | : * Group keying material (num=6) | * Group keying : * Updated administrative | material (num=6) : keying material for C1 and C2 | * Updated administrative : | keying material for C4 : | : | : +------------+-------------+--------------+ : | | | | : | | | | : v v v v v /grp-mrek /grp-mrek /grp-mrek /grp-mrek /grp-rek .--------. .--------. .-----------. .---------------------------. | C1 | | C2 | | C3 | | C4 | '--------' '--------' '-----------' '---------------------------' [TO BE EVICTED] | | \_______________ Stored group keying material (num=5) ________________/ ]]></artwork> </artset> </figure> <section anchor="one-to-many-rekeying-protection"> <name>Protection of Rekeying Messages</name> <t>When using a group rekeying scheme relying on one-to-many rekeying messages, the actual data content of each rekeying message is prepared according to what the rekeying scheme prescribes.</t> <t>The following describes one possible method for the KDC to protect the rekeying messages when using the administrative keying material.</t> <t>The method assumes that the following holds for the administrative keying material specified in the 'mgt_key_material' parameter of the Join Response (see <xref target="gid-post"/>).</t> <ul spacing="normal"> <li>The encryption algorithmSHOULD<bcp14>SHOULD</bcp14> be the same one used to protect communications in the group.</li> <li>The included symmetric encryption keys are accompanied by a corresponding and unique key identifier assigned by the KDC.</li> <li>A Base IV is alsoincluded,included with the same size of the AEAD nonce considered by the encryption algorithm to use.</li> </ul> <t>First, the KDC computes a COSE_Encrypt0 object as follows.</t> <ul spacing="normal"> <li>The encryption key to use is selected from the administrative keying material, as defined by the rekeying scheme used in the group.</li> <li>The plaintext is the actual data content of the rekeying message.</li> <li>The Additional Authenticated Data (AAD) isempty,empty unless otherwise specified by separate documents profiling the use of the group rekeying scheme.</li> <li> <t>Since the KDC is the only sender of rekeying messages, the AEAD nonce can be computed as follows, where NONCE_SIZE is the size in bytes of the AEAD nonce. Separate documents profiling the use of the group rekeying scheme may define alternative ways to compute the AEAD nonce. </t> <t> The KDC considers the following values. </t> <ul spacing="normal"><li>COUNT,<li>COUNT: as a 2-byte unsigned integer associated with the used encryption key. Its value is set to 0 when starting to perform a new group rekeyinginstance,instance and is incremented after each use of the encryption key.</li><li>NEW_NUM,<li>NEW_NUM: as the version number of the new group keying material to distribute in this rekeying instance, left-padded with zeros to exactly NONCE_SIZE - 2 bytes.</li> </ul> <t> Then, the KDC computes a Partial IV as the byte string concatenation of COUNT andNEW_NUM,NEW_NUM in this order. Finally, the AEAD nonce is computed as the XOR between the Base IV and the Partial IV. </t> <t> In order to comply with the security requirements of AEAD encryption algorithms, the KDCMUST NOT<bcp14>MUST NOT</bcp14> reuse the same pair (AEAD encryption key, AEAD nonce). For example, this includes not using the same encryption key from the administrative keying material more than2^162<sup>16</sup> times during the same rekeying instance.</t> </li> <li> <t>The protected header of the COSE_Encrypt0 objectMUST<bcp14>MUST</bcp14> include the following parameters. </t> <ul spacing="normal"><li>'alg',<li>'alg': specifying the used encryption algorithm.</li><li>'kid',<li>'kid': specifying the identifier of the encryption key from the administrative keying material used to protect this rekeying message.</li> </ul> </li> <li>The unprotected header of the COSE_Encrypt0 objectMUST<bcp14>MUST</bcp14> include the 'Partial IV'parameter,parameter with the value of the Partial IV computed above.</li> </ul> <t>In order to ensure source authentication, each rekeying message protected with the administrative keying materialMUST<bcp14>MUST</bcp14> be signed by the KDC. To this end, the KDC computes a countersignature of the COSE_Encrypt0 object, as described in Sections <xref target="RFC9338" section="3.2" sectionFormat="bare"/> and <xref target="RFC9338" section="3.3" sectionFormat="bare"/> of <xref target="RFC9338"/>. In particular, the following applies when computing the countersignature.</t> <ul spacing="normal"> <li>The Countersign_structure contains the context text string "CounterSignature0".</li> <li>The private key of the KDC is used as the signing key.</li> <li>The payload is the ciphertext of the COSE_Encrypt0 object.</li> <li>The Additional Authenticated Data (AAD) is empty, unless otherwise specified by separate documents profiling the use of a group rekeying scheme.</li> <li>The protected header of the signing objectMUST<bcp14>MUST</bcp14> include the parameter 'alg',specifyingwhich specifies the used signature algorithm.</li> </ul> <t>If the source authentication of messages exchanged in the group is also ensured by means of signatures, then rekeying messagesMUST<bcp14>MUST</bcp14> be signed using the same signature algorithm and related parameters. Also, the KDC's authentication credential including the public key to use for signature verificationMUST<bcp14>MUST</bcp14> be provided in the Join Response through the 'kdc_cred' parameter, together with the corresponding proof-of-possession (PoP) evidence in the 'kdc_cred_verify' parameter.</t> <t>If source authentication of messages exchanged in the group is not ensured by means of signatures, then the administrative keying material conveyed in the 'mgt_key_material' parameter of the Join Response sent by KDC (see <xref target="gid-post"/>)MUST<bcp14>MUST</bcp14> also comprise a KDC's authentication credential including the public key to use for signature verification, together withathe corresponding PoP evidence. Within the 'mgt_key_material' parameter, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to specify this information by using the same format and encoding used for the parameters 'kdc_cred', 'kdc_nonce', and 'kdc_cred_verify' in the Join Response. It is up to separate documents profiling the use of the group rekeying scheme to specify such details.</t> <t>After that, the KDC specifies the computed countersignature in the 'Countersignature0 version 2' header parameter of the COSE_Encrypt0 object.</t> <t>Finally, the KDC specifies the COSE_Encrypt0 object as payload of a CoAP request, which is sent to the target group members as per the used message delivery method.</t> </section> </section> <section anchor="sec-misalignment-keying-material"> <name>Misalignment of Group Keying Material</name> <t>A group member can receive a message shortly after the group has beenrekeyed,rekeyed and new keying material has been distributed by the KDC. In the following two cases, this may result in misaligned keying material between the group members.</t> <t>In the first case, the sender protects a message using the old group keying material. However, the recipient receives the message after having received the new group keying material, hence not being able to correctly process it. <!--[rfced] As "old, recent" seems to be contradictory, should the phrasing in the first sentence be updated to "old, retained", as used in the second sentence? Original: A possible way to limit the impact of this issue is to preserve the old, recent group keying material for a maximum amount of time defined by the application, during which it is used solely for processing incoming messages. By doing so, the recipient can still temporarily process received messages also by using the old, retained group keying material. --> A possible way to limit the impact of this issue is to preserve the old, recent group keying material for a maximum amount of time defined by the application, during which it is used solely for processing incoming messages. By doing so, the recipient can still temporarily process received messages also by using the old, retained group keying material. Note that a former (compromised) group member can take advantage of this by sending messages protected with the old, retained group keying material. Therefore, a conservative application policy should not admit the storage of old group keying material. Eventually, the sender will have obtained the new group keying materialtoo,too and can possiblyre-sendresend the message protected with such keying material.</t> <t>In the second case, the sender protects a message using the new group keying material, but the recipient receives that message before having received the new group keying material. Therefore, the recipient would not be able to correctly process the message and hence discards it. If the recipient receives the new group keying material shortly after that and the application at the sender endpoint performs retransmissions, the former will still be able to receive and correctly process the message. In any case, the recipient should actively ask the KDC for the latest group keying material according to an application-defined policy, forinstanceinstance, after a given number of unsuccessfully decrypted incoming messages.</t> </section> </section> <section anchor="sec-extended-scope"> <name>Extended Scope Format</name> <t>This section defines an extended format ofbinary encodedbinary-encoded scope, which additionally specifies the semantics used to express the same access control information from the corresponding original scope.</t> <t>As also discussed in <xref target="ssec-authorization-response"/>, this enables a Resource Server to unambiguously process a received access token, also in case the Resource Server runs multiple applications or application profiles that involve different scope semantics.</t> <t>The extended format is intended only for the 'scope' claim of accesstokens,tokens for the cases where the claim takesas valuea CBOR bytestring.string as the value. That is, the extended format does not apply to the 'scope' parameter included in ACE messages, i.e., the Authorization Request and Authorization Response exchanged between the Client and the Authorization Server (see Sections <xref target="RFC9200" section="5.8.1" sectionFormat="bare"/> and <xref target="RFC9200" section="5.8.2" sectionFormat="bare"/> of <xref target="RFC9200"/>), the AS Request Creation Hints message from the Resource Server (see <xref section="5.3" sectionFormat="of" target="RFC9200"/>), and the Introspection Response from the Authorization Server (see <xref section="5.9.2" sectionFormat="of" target="RFC9200"/>).</t> <t>The value of the 'scope' claim following the extended format is composed as follows. Given the original scope usingasemantics SEM and encoded as a CBOR byte string, the corresponding extended scope consists of the same CBOR byte string enclosed by a CBOR tag <xref target="RFC8949"/>, whose tag number identifies the semantics SEM.</t> <t>The resulting tagged CBOR byte string is used as the value of the 'scope' claim of the access token.</t><t><xref target="cddl-ex-0-ext"/><t>Figures <xref target="cddl-ex-0-ext" format="counter"/> and <xreftarget="cddl-ex-ext"/>target="cddl-ex-ext" format="counter"/> build on the examples in <xreftarget="ssec-authorization-response"/>,target="ssec-authorization-response"/> and show the corresponding extended scopes.</t> <figure anchor="cddl-ex-0-ext"> <name>Example CDDLdefinitionDefinition of scope,usingUsing thedefaultDefault Authorization Information Format</name> <sourcecode type="CDDL"><![CDATA[ ;# include rfc9237 gname = tstr permissions = uint .bits roles roles = &( Requester: 1, Responder: 2, Monitor: 3, Verifier: 4 ) scope_entries = AIF-Generic<gname, permissions> scope = bstr .cbor scope_entries extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope) ]]></sourcecode> </figure> <figure anchor="cddl-ex-ext"> <name>CDDLdefinitionDefinition of scope,using as example group name encodedUsing an Example Group Name Encoded as tstr androleRole as tstr</name> <sourcecode type="CDDL"><![CDATA[ gname = tstr role = tstr scope_entry = [ gname , ? ( role / [ 2*role ] ) ] scope_entries = [ * scope_entry ] scope = bstr .cbor scope_entries extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope) ]]></sourcecode> </figure> <t>The usage of the extended scope format is not limited to application profiles of this specification or to applications based on group communication. Rather, it is generally applicable to any application and application profile where access control information in the access token is expressed as abinary encodedbinary-encoded scope.</t> <t>Applications and application profiles using the extended format of scope have to specify which CBOR tag from <xref target="CBOR.Tags"/> is used for identifying the scopesemantics,semantics or to register a new CBOR tag if a suitable one does not exist already (REQ28). In case there is an already existing, suitable CBOR tag, a new CBOR tag should not be registered in order to avoid codepoint squatting.</t> <t>If thebinary encodedbinary-encoded scope usesasemantics associated with a registered CoAP Content-Format <xreftarget="RFC7252"/><xreftarget="RFC7252"/> <xref target="CoAP.Content.Formats"/>, then a suitable CBOR tag associated with that CoAP Content-Format would already be registered, as defined in <xref section="4.3" sectionFormat="of" target="RFC9277"/>.</t> <t>This is especially relevant when the binary encoded scope uses the AIF format. That is, it is expected that the definition of anAIF specificAIF-specific data model comes together with the registration of CoAP Content-Formats for the relevant combinations of its Toid and Tperm values. As discussed above, this yields the automatic registration of the CBOR tags associated with those CoAP Content-Formats.</t> </section> <section anchor="params"> <name>ACE Groupcomm Parameters</name> <t>This specification defines a number of parameters used during the second part of the messageexchange,exchange after the exchange of Token Transfer Request and Response. The table below summarizesthem,them and specifies the CBOR key to use instead of the full descriptive name.</t> <t>Note that the media type application/ace-groupcomm+cborMUST<bcp14>MUST</bcp14> be used when these parameters are transported in the respective message fields.</t><figure<table anchor="fig-ACE-Groupcomm-Parameters"> <name>ACE Groupcomm Parameters</name><artwork align="center"><![CDATA[ +-----------------------+------+---------------------+------------+ | Name | CBOR | CBOR Type | Reference | | | Key | | | +-----------------------+------+---------------------+------------+ | gid | 0 | array | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | gname | 1 | array of tstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | guri | 2 | array of tstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | scope | 3 | bstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | get_creds | 4 | array / | [RFC-XXXX] | | | | Simple value "null" | | +-----------------------+------+---------------------+------------+ | client_cred | 5 | bstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | cnonce | 6 | bstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | client_cred_verify | 24 | bstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | creds_repo | 25 | tstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | control_uri | 26 | tstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | gkty | 7 | int<thead> <tr> <th>Name</th> <th>CBOR Key</th> <th>CBOR Type</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>gid</td> <td>0</td> <td>array</td> <td>RFC 9594</td> </tr><tr> <td>gname</td> <td>1</td> <td>array of tstr</td> <td>RFC 9594</td> </tr><tr> <td>guri</td> <td>2</td> <td>array of tstr</td> <td>RFC 9594</td> </tr><tr> <td>scope</td> <td>3</td> <td>bstr</td> <td>RFC 9594</td> </tr><tr> <td>get_creds</td> <td>4</td> <td>array /Simple value "null"</td> <td>RFC 9594</td> </tr><tr> <td>client_cred</td> <td>5</td> <td>bstr</td> <td>RFC 9594</td> </tr><tr> <td>cnonce</td> <td>6</td> <td>bstr</td> <td>RFC 9594</td> </tr><tr> <td>client_cred_verify</td> <td>24</td> <td>bstr</td> <td>RFC 9594</td> </tr><tr> <td>creds_repo</td> <td>25</td> <td>tstr</td> <td>RFC 9594</td> </tr><tr> <td>control_uri</td> <td>26</td> <td>tstr</td> <td>RFC 9594</td> </tr><tr> <td>gkty</td> <td>7</td> <td>int /tstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | key | 8 | Seetstr</td> <td>RFC 9594</td> </tr><tr> <td>key</td> <td>8</td> <td>See the "ACE| [RFC-XXXX] | | | |Groupcomm Key| | | | |Types"registry | | +-----------------------+------+---------------------+------------+ | num | 9 | int | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | ace_groupcomm_profile | 10 | int | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | exp | 11 | uint | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | exi | 12 | uint | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | creds | 13 | array | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | peer_roles | 14 | array | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | peer_identifiers | 15 | array | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | group_policies | 16 | map | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | kdc_cred | 17 | bstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | kdc_nonce | 18 | bstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | kdc_cred_verify | 19 | bstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | rekeying_scheme | 20 | int | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | mgt_key_material | 27 | bstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | control_group_uri | 28 | tstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | sign_info | 29 | arrayregistry</td> <td>RFC 9594</td> </tr><tr> <td>num</td> <td>9</td> <td>int</td> <td>RFC 9594</td> </tr><tr> <td>ace_groupcomm_profile</td> <td>10</td> <td>int</td> <td>RFC 9594</td> </tr><tr> <td>exp</td> <td>11</td> <td>uint</td> <td>RFC 9594</td> </tr><tr> <td>exi</td> <td>12</td> <td>uint</td> <td>RFC 9594</td> </tr><tr> <td>creds</td> <td>13</td> <td>array</td> <td>RFC 9594</td> </tr><tr> <td>peer_roles</td> <td>14</td> <td>array</td> <td>RFC 9594</td> </tr><tr> <td>peer_identifiers</td> <td>15</td> <td>array</td> <td>RFC 9594</td> </tr><tr> <td>group_policies</td> <td>16</td> <td>map</td> <td>RFC 9594</td> </tr><tr> <td>kdc_cred</td> <td>17</td> <td>bstr</td> <td>RFC 9594</td> </tr><tr> <td>kdc_nonce</td> <td>18</td> <td>bstr</td> <td>RFC 9594</td> </tr><tr> <td>kdc_cred_verify</td> <td>19</td> <td>bstr</td> <td>RFC 9594</td> </tr><tr> <td>rekeying_scheme</td> <td>20</td> <td>int</td> <td>RFC 9594</td> </tr><tr> <td>mgt_key_material</td> <td>27</td> <td>bstr</td> <td>RFC 9594</td> </tr><tr> <td>control_group_uri</td> <td>28</td> <td>tstr</td> <td>RFC 9594</td> </tr><tr> <td>sign_info</td> <td>29</td> <td>array /| [RFC-XXXX] | | | |Simple value"null" | | +-----------------------+------+---------------------+------------+ | kdcchallenge | 30 | bstr | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ ]]></artwork> </figure> <t>Note to RFC Editor: In <xref target="fig-ACE-Groupcomm-Parameters"/>, please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.</t>"null"</td> <td>RFC 9594 </td> </tr><tr> <td>kdcchallenge</td> <td>30</td> <td>bstr</td> <td>RFC 9594</td> </tr> </tbody> </table> <t>The KDC is expected to support all the parameters above. Instead, a Client can support only a subset of such parameters, depending on the roles it expects to take in the joined groups or on other conditions defined in application profiles of this specification.</t> <t>In the following, the parameters are categorized according to the support expected by Clients. That is, a Client that supports a parameter is able to: i) use and specify it in a request message to theKDC;KDC and ii) understand and process it if specified in a response message from the KDC. It isREQUIRED<bcp14>REQUIRED</bcp14> of application profiles of this specification to sort their newly defined parameters according to the same categorization (REQ29).</t> <t>Note that the actual use of a parameter and its inclusion in a message depends on the specific exchange, the specific Client and group involved, as well as what is defined in the used application profile of this specification.</t><t>A<!--[rfced] To improve readability, would you like each parameter to be its own list item? Original: A Client MUST support the following parameters. * 'scope', 'cnonce', 'gkty', 'key', 'num', 'exp', 'exi', 'gid', 'gname', 'guri', 'creds', 'peer_identifiers', 'ace_groupcomm_profile', 'control_uri', 'rekeying_scheme'. Perhaps: A Client MUST support the following parameters. * 'scope' * 'cnonce' * 'gkty' * 'key' * 'num' * 'exp' * 'exi' * 'gid' * 'gname' * 'guri' * 'creds' * 'peer_identifiers' * 'ace_groupcomm_profile' * 'control_uri' * 'rekeying_scheme' --> <t>A Client <bcp14>MUST</bcp14> support the following parameters.</t> <ul spacing="normal"> <li>'scope', 'cnonce', 'gkty', 'key', 'num', 'exp', 'exi', 'gid', 'gname', 'guri', 'creds', 'peer_identifiers', 'ace_groupcomm_profile', 'control_uri', 'rekeying_scheme'.</li> </ul> <t>A ClientSHOULD<bcp14>SHOULD</bcp14> support the following parameter.</t> <ul spacing="normal"><li>'get_creds'.<li>'get_creds': That is, not supporting this parameter would yield the inconvenient and undesirable behavior where: i) the Client does not ask for the other group members' authentication credentials upon joining the group (see <xreftarget="ssec-key-distribution-exchange"/>);target="ssec-key-distribution-exchange"/>) and ii) later on as a group member, the Client only retrieves the authentication credentials of all group members (see <xref target="sec-key-retrieval-all"/>).</li> </ul> <t>The following conditional parameters are relevant only if specific conditions hold. It isREQUIRED<bcp14>REQUIRED</bcp14> of application profiles of this specification to define whether Clients must, should, or may support theseparameters,parameters and under which circumstances (REQ30).</t> <ul spacing="normal"> <li>'client_cred' and'client_cred_verify'.'client_cred_verify': These parameters are relevant for a Client that has an authentication credential to use in a joined group.</li><li>'kdcchallenge'.<li>'kdcchallenge': This parameter is relevant for a Client that has an authentication credential to use in a joined group and that provides the access token to the KDC through a Token Transfer Request (see <xref target="token-post"/>).</li><li>'creds_repo'.<li>'creds_repo': This parameter is relevant for a Client that has an authentication credential to use in a joined group and that makes it available from a key repository different than the KDC.</li><li>'group_policies'.<li>'group_policies': This parameter is relevant for a Client that is interested in the specific policies used in a group, but it does not know them or cannot become aware of them before joining that group.</li><li>'peer_roles'.<li>'peer_roles': This parameter is relevant for a Client that has to know about the roles of other group members, especially when retrieving and handling their corresponding authentication credentials.</li> <li>'kdc_nonce', 'kdc_cred','kdc_cred_verify'.and 'kdc_cred_verify': These parameters are relevant for a Client that joins a group for which, as per the used application profile of this specification, the KDC has an associated authentication credential and this is required for the correct group operation.</li><li>'mgt_key_material'.<li>'mgt_key_material': This parameter is relevant for a Client that supports an advanced rekeying scheme possibly used in the group, such as based on one-to-many rekeying messages sent over IP multicast.</li><li>'control_group_uri'.<li>'control_group_uri': This parameter is relevant for a Client that supports the hosting of localresourcesresources, each associated with a group (hence acting as CoAPserver)server), and the reception of one-to-many requests sent to those resources by the KDC (e.g., over IP multicast),targetingwhich targets multiple members of the corresponding group. Examples of related management operations that the KDC can perform by this means are the eviction of group members and the execution of a group rekeying process through an advanced rekeying scheme, such as based on one-to-many rekeying messages.</li> </ul> </section> <section anchor="error-types"> <name>ACE Groupcomm Error Identifiers</name> <t>This specification defines a number of values that the KDC can use as error identifiers. These are used in error responses with Content-Formatapplication/concise-problem-details+cbor,application/concise-problem-details+cbor as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' (see <xref target="kdc-if-errors"/>).</t><figure<table anchor="fig-ACE-Groupcomm-Error-Identifiers"> <name>ACE Groupcomm Error Identifiers</name><artwork align="center"><![CDATA[ +-------+---------------------------------------------+ | Value | Description | +-------+---------------------------------------------+ | 0 | Operation<thead> <tr> <th>Value</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Operation permitted only to groupmembers | +-------+---------------------------------------------+ | 1 | Requestmembers</td> </tr><tr> <td>1</td> <td>Request inconsistent with the currentroles | +-------+---------------------------------------------+ | 2 | Authenticationroles</td> </tr><tr> <td>2</td> <td>Authentication credential incompatible with| | |the groupconfiguration | +-------+---------------------------------------------+ | 3 | Invalidconfiguration</td> </tr><tr> <td>3</td> <td>Invalid proof-of-possessionevidence | +-------+---------------------------------------------+ | 4 | Noevidence</td> </tr><tr> <td>4</td> <td>No available nodeidentifiers | +-------+---------------------------------------------+ | 5 | Groupidentifiers</td> </tr><tr> <td>5</td> <td>Group membershipterminated | +-------+---------------------------------------------+ | 6 | Group deleted | +-------+---------------------------------------------+ ]]></artwork> </figure>terminated</td> </tr><tr> <td>6</td> <td>Group deleted</td> </tr> </tbody> </table> <t>If a Client supports the problem-details format <xref target="RFC9290"/> and the Custom Problem Detail entry 'ace-groupcomm-error' defined in <xreftarget="kdc-if-errors"/>,target="kdc-if-errors"/> and is able to understand the error specified in the 'error-id' field therein, then the Client can use that information to determine what actions to take next. If the Concise Problem Details data item specified in the error response includes the 'detail' entry and the Client supports it, such an entry may provide additional context.</t> <t>In particular, the following guidelines apply, and application profiles of this specification can define more detailed actions for the Client to take when learning that a specific error has occurred.</t> <ul spacing="normal"> <li>In case of error 0, the Client should stop sending the request in question to the KDC. Rather, the Client should first join the targeted group. If it has not happened already, this first requires the Client to obtain an appropriate access token authorizing access to the group and provide it to the KDC.</li> <li>In case of error 1, the Client as a group member shouldre-joinrejoin the group with all the roles needed to perform the operation in question. This might require the Client to first obtain a new access token and provide it to theKDC,KDC if the current access token does not authorize it to take those roles in the group. For operations admitted to a Clientwhichthat is not a group member (e.g., an external signature verifier), the Client should first obtain a new access token authorizing to also have the missing roles.</li> <li>In case of error 2, the Client has to obtain or self-generate a different asymmetric key pair, as aligned to the public key algorithms and parameters used in the targeted group. After that, the Client should provide the KDC with its new authentication credential, which is consistent with the format used in the targeted group and including the new public key.</li> <!--[rfced] To avoid the awkward phrasing of "should ensure to be computing", may we update this to be "should confirm its computing"? Original: * In case of error 3, the Client should ensure to be computing its proof-of-possession evidence by correctly using the parameters and procedures defined in the used application profile of this specification. Perhaps: * In case of error 3, the Client should confirm its computing of the proof-of-possession evidence by correctly using the parameters and procedures defined in the used application profile of this specification. Or: * In case of error 3, the Client should ensure that it is computing its proof-of-possession evidence by correctly using the parameters and procedures defined in the used application profile of this specification. --> <li>In case of error 3, the Client should ensure to be computing its proof-of-possession evidence by correctly using the parameters and procedures defined in the used application profile of this specification. In an unattended setup, it mightbenot be possible for a Client to autonomously diagnose the error and take an effective next action to address it.</li> <li>In case of error 4, the Client should wait for a certain (pre-configured) amount oftime,time before tryingre-sendingto resend its request to the KDC.</li> <li>In case of error 5, the Client may try joining the group again. This might require the Client to first obtain a new access token and provide it to the KDC, e.g., if the current access token has expired.</li> <li>In case of error 6, the Client should clean up its state regarding the group, just like if it has left the group with no intention tore-joinrejoin it.</li> </ul> </section> <section anchor="sec-cons"> <name>Security Considerations</name> <t>Security considerations are inherited from the ACE framework <xreftarget="RFC9200"/>,target="RFC9200"/> and from the specific transport profile of ACE used between the Clients and the KDC, e.g., <xref target="RFC9202"/> and <xref target="RFC9203"/>.</t> <t>When using the problem-details format defined in <xref target="RFC9290"/> for error responses, then the privacy and security considerations from Sections <xref target="RFC9290" section="4" sectionFormat="bare"/> and <xref target="RFC9290" section="5" sectionFormat="bare"/> of <xref target="RFC9290"/> also apply.</t> <t>Furthermore, the following security considerations apply.</t> <section anchor="sec-cons-communication"> <name>Secure Communication in the Group</name> <t>When a group member receives a message from a certain sender for the first time since joining the group, it needs to have a mechanism in place to avoid replayed messages and to assert their freshness, e.g., as described in <xref section="B.1.2" sectionFormat="of" target="RFC8613"/> or <xref section="10" sectionFormat="of" target="I-D.ietf-core-oscore-groupcomm"/>. Such a mechanism also aids the recipient group memberalsoin case it has rebooted and lost the security state used to protect previous group communications with that sender.</t> <t>By its nature, the KDC is invested with a large amount of trust, since it acts as a generator and provider of the symmetric keying material used to protect communications in each of its groups. While details depend on the specific communication and security protocols used in the group, the KDC is in the position to decrypt messages exchanged in the group as if it was also a group member, as long as those are protected through commonly shared group keying material.</t> <t>A compromised KDC would thus put the attacker in the same position, which also means that:</t> <ul spacing="normal"> <li>The attacker can generate and control new group keying material, hence possibly rekeying the group and evicting certain group members as part of a broader attack.</li> <li>The attacker can actively participate in communications in agroupgroup, even without having been authorized to join it, and can allow further unauthorized entities to do so.</li> <li>The attacker can build erroneous associations between node identifiers and group members' authentication credentials.</li> </ul> <t>On the other hand, as long as the security protocol used in the group ensures source authentication of messages (e.g., by means of signatures), the KDC is not able to impersonate group members since it does not have their private keys.</t> <t>Further security considerations are specific to the communication and security protocols used in the group, and thus have to be provided by those protocols and complemented by the application profiles of this specification using them.</t> </section> <section anchor="sec-cons-rekeying"> <name>Update of Group Keying Material</name> <t>The KDC can generate new group keying material and provide it to the group members (rekeying) through the rekeying scheme used in the group, as discussed in <xref target="sec-group-rekeying"/>.</t> <t>In particular, the KDC must renew the latest group keying materiallatestupon its expiration. Before then, the KDCMAY<bcp14>MAY</bcp14> also renew the group keying material on a regular or periodical fashion.</t> <t>Unless otherwise defined by an application profile of this specification, the KDCSHOULD<bcp14>SHOULD</bcp14> renew the group keying material upon a group membership change. As a possible exception, the KDC may not rekey the group upon the joining of a new groupmember,member if the application does not require backward security. As another possible exception discussed more in detail later in this section, the KDC may rely on a rekeying policy that reasonablytaketakes into account the expected rate of group membership changes and the duration of a group rekeying.</t> <t>Since the minimum number of group members is one, the KDCSHOULD<bcp14>SHOULD</bcp14> provide even a Client joining an empty group with new keying material never used before in that group. Similarly, the KDCSHOULD<bcp14>SHOULD</bcp14> also provide new group keying materialalsoto a Client that remains the only member in the group after the leaving of other group members.</t> <t>Note that the considerations in <xref target="sec-cons-communication"/> about dealing with replayed messages still hold, even in case the KDC rekeys the group upon every single joining of a new group member. However, if the KDC has renewed the group keying material upon a group member'sjoining,joining and the time interval between the end of the rekeying process and that member's joining is sufficiently small, then that group member is also on the safe side, since it would not accept replayed messages protected with the old group keying material previous to its joining.</t> <t>Once a joining node has obtained the new, latest keying material through a Join Response from the KDC (see <xref target="ssec-key-distribution-exchange"/>), the joining node becomes able to read any message that was exchanged in the group and protected with that keying material. This is the case if the KDC provides the current group members with the new, latest keying material before completing the joining procedure. However, the joining node is not able to read messages exchanged in the group and protected with keying material older than the one provided in the Join Response, i.e., having a strictly lower version number NUM.</t> <t>A node that has left the group should not expect any of its outgoing messages to be successfullyprocessed,processed if received by other nodes in the group after itsleaving,leaving due to a possible group rekeyingoccurredoccurring before the message reception.</t> <t>The KDC may enforce a rekeying policy that takes into account the overall time required to rekey the group, as well as the expected rate of changes in the group membership. That is, the KDC may not rekey the group at each and every group membership change, forinstanceinstance, if members' joining and leaving occur frequently and performing a group rekeying takes too long. Instead, the KDC might rekey the group after a minimum number of group members have joined or left within a given time interval,orafter a maximum amount of time since the last group rekeying was completed, or yet during predictable network inactivity periods.</t> <t>However, this would result in the KDC not constantly preserving backward and forward security in the group. That is:</t> <ul spacing="normal"> <li>Newly joining group members would be able to access the keying material used before their joining, and thus they could access past group communications if they have recorded old exchanged messages. This might still be acceptable for some applications and in situations where the new group members are freshly deployed through strictly controlled procedures.</li> <li>The leaving group members would remain able to access upcoming group communications, as protected with the current keying material that has not been updated. This is typically undesirable, especially if the leaving group member is compromised or suspected to be, and it might have an impact or compromise the security properties of the protocols used in the group to protect messages exchanged among the group members.</li> </ul> <t>The KDC should renew the group keying material in case it has rebooted, even if it stores the whole group keying material in persistent storage. This assumes that the secure associations with the current group members as well as any administrative keying material required to rekey the group are also stored in persistent storage.</t> <t>However, if the KDC relies on Observe notifications to distribute the new group keying material, the KDC would have lost all the current ongoing Observations with the group members after rebooting, and the group members would continue using the old group keying material. Therefore, the KDC willratherrely on each group member asking for the new group keying material (see Sections <xreftarget="ssec-key-material-retrieval"/>target="ssec-key-material-retrieval" format="counter"/> and <xreftarget="update-keys"/>),target="update-keys" format="counter"/>) orratherperform a group rekeying by actively sending rekeying messages to group members as discussed in <xref target="sec-group-rekeying"/>.</t> <t>The KDC needs to have a mechanism in place to detect DoS attacks from nodes repeatedly performing actions that might trigger a group rekeying. Such actions can include leaving and/orre-joiningrejoining the group at highrates,rates or often asking the KDC for new individual keying material. Ultimately, the KDC can resort to removing these nodes from the group and (temporarily) preventing them from joining the group again.</t> <t>The KDC also needs to have a congestion control mechanism inplace,place in order to avoid network congestion upon distributing new group keying material. For example, CoAP and Observe give guidance on such mechanisms, see <xref section="4.7" sectionFormat="of" target="RFC7252"/> and <xref section="4.5.1" sectionFormat="of" target="RFC7641"/>.</t> </section> <section anchor="block-wise-considerations"> <name>Block-Wise Considerations</name> <t>If the Block-Wise CoAP options <xref target="RFC7959"/> areused,used and the keying material is updated in the middle of a Block-Wise transfer, the sender of the blocks just changes the group keying material to the updated one and continues the transfer. As long as both sides get the new group keying material, updating the group keying material in the middle of a transfer will not cause any issue. Otherwise, the sender will have to transmit the messageagain,again when receiving an error message from the recipient.</t> <t>Compared to a scenario where the transfer does not use Block-Wise, depending on how fast the group keying material is changed, the group members might consume a larger amount of the network bandwidth by repeatedly resending the same blocks, which might be problematic.</t> </section> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name><t>This document<t>Per this document, IANA has completed the followingactions for IANA.</t> <t>Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.</t>actions.</t> <section anchor="media-type"> <name>Media Type Registrations</name> <t>This specificationregistershas registered the 'application/ace-groupcomm+cbor' media type for messages of the protocols defined in this document following the ACE exchange and carrying parameters encoded in CBOR. This registration follows the procedures specified in <xref target="RFC6838"/>.</t><t>Type name: application</t> <t>Subtype name: ace-groupcomm+cbor</t> <t>Required parameters: N/A</t> <t>Optional parameters: N/A</t> <t>Encoding considerations:<dl newline="false"> <dt>Type name:</dt><dd>application</dd> <dt>Subtype name:</dt><dd> ace-groupcomm+cbor</dd> <dt>Required parameters:</dt><dd> N/A</dd> <dt>Optional parameters:</dt><dd> N/A</dd> <dt>Encoding considerations:</dt><dd> Must be encoded as a CBOR map containing the parameters defined in[RFC-XXXX].</t> <t>Security considerations:RFC 9594.</dd> <dt>Security considerations:</dt><dd> See <xref target="sec-cons"/> of[RFC-XXXX].</t> <t>Interoperability considerations: N/A</t> <t>Published specification: [RFC-XXXX]</t> <t>ApplicationsRFC 9594.</dd> <dt>Interoperability considerations:</dt><dd> N/A</dd> <dt>Published specification:</dt><dd> RFC 9594</dd> <dt>Applications that use this mediatype:type:</dt><dd> The type is used by Authorization Servers, Clients, and Resource Servers that support the ACE groupcomm framework as specified in[RFC-XXXX].</t> <t>FragmentRFC 9594.</dd> <dt>Fragment identifierconsiderations: N/A</t> <t>Additional information: N/A</t> <t>Personconsiderations:</dt><dd> N/A</dd> <dt>Additional information:</dt><dd> N/A</dd> <dt>Person & email address to contact for furtherinformation:information:</dt><dd> ACE WG mailing list (ace@ietf.org) or IETF Applications and Real-Time Area(art@ietf.org)</t> <t>Intended usage: COMMON</t> <t>Restrictions on usage: None</t> <t>Author/Change controller: IETF</t> <t>Provisional registration: No</t>(art@ietf.org)</dd> <dt>Intended usage:</dt><dd> COMMON</dd> <dt>Restrictions on usage:</dt><dd> None</dd> <dt>Author/Change controller:</dt><dd> IETF</dd> <dt>Provisional registration:</dt><dd> No</dd> </dl> </section> <section anchor="content-type"> <name>CoAP Content-Formats</name> <t>IANAis asked to registerhas registered the following entrytoin the "CoAP Content-Formats" registry within the "CoRE Parameters" registry group.</t><t>Content Type: application/ace-groupcomm+cbor</t> <t>Content Coding: -</t> <t>ID: TBD</t> <t>Reference: [RFC-XXXX]</t><dl newline="false" spacing="compact"> <dt>Content Type:</dt><dd> application/ace-groupcomm+cbor</dd> <dt>Content Coding:</dt><dd> -</dd> <dt>ID:</dt><dd> 261</dd> <dt>Reference:</dt><dd> RFC 9594</dd> </dl> </section> <section anchor="iana-kinfo"> <name>OAuth Parameters</name> <t>IANAis asked to registerhas registered the following entries in the "OAuth Parameters"registryregistry, following the procedure specified in <xref section="11.2" sectionFormat="of" target="RFC6749"/>.</t><ul spacing="normal"> <li>Parameter name: sign_info</li> <li>Parameter<dl spacing="compact"> <dt>Parameter name:</dt><dd> sign_info</dd> <dt>Parameter usagelocation:location:</dt><dd> client-rs request, rs-clientresponse</li> <li>Change Controller: IETF</li> <li>Specification Document(s): [RFC-XXXX]</li> </ul> <t> </t> <ul spacing="normal"> <li>Parameter name: kdcchallenge</li> <li>Parameterresponse</dd> <dt>Change Controller:</dt><dd> IETF</dd> <dt>Specification Document(s):</dt><dd> RFC 9594</dd> </dl> <dl spacing="compact"> <dt>Parameter name:</dt><dd> kdcchallenge</dd> <dt>Parameter usagelocation:location:</dt><dd> rs-clientresponse</li> <li>Change Controller: IETF</li> <li>Specification Document(s): [RFC-XXXX]</li> </ul>response</dd> <dt>Change Controller:</dt><dd> IETF</dd> <dt>Specification Document(s):</dt><dd> RFC 9594</dd> </dl> </section> <section anchor="iana-kinfo-map"> <name>OAuth Parameters CBOR Mappings</name> <t>IANAis asked to registerhas registered the following entries in the "OAuth Parameters CBOR Mappings"registryregistry, following the procedure specified in <xref section="8.10" sectionFormat="of" target="RFC9200"/>.</t><ul spacing="normal"> <li>Name: sign_info</li> <li>CBOR Key: TBD (range -256 to 255)</li> <li>Value Type: Simple value "null" / array</li> <li>Reference: [RFC-XXXX]</li> </ul> <t> </t> <ul spacing="normal"> <li>Name: kdcchallenge</li> <li>CBOR Key: TBD (range -256 to 255)</li> <li>Value Type: Byte string</li> <li>Reference: [RFC-XXXX]</li> </ul><dl spacing="compact"> <dt>Name:</dt><dd>sign_info</dd> <dt>CBOR Key:</dt><dd>45</dd> <dt>Value Type:</dt><dd>Null or array</dd> <dt>Reference:</dt><dd>RFC 9594</dd> </dl> <dl spacing="compact"> <dt>Name:</dt><dd>kdcchallenge</dd> <dt>CBOR Key:</dt><dd>46</dd> <dt>Value Type:</dt><dd>byte string</dd> <dt>Reference:</dt><dd>RFC 9594</dd> </dl> </section> <section anchor="if-ace-group"> <name>Interface Description (if=) Link Target Attribute Values</name> <t>IANAis asked to registerhas registered the following entry in the "Interface Description (if=) Link Target Attribute Values" registry within the "CoRE Parameters" registry group.</t><ul spacing="normal"> <li>Value: ace.groups</li> <li>Description:<dl spacing="compact"> <dt>Value:</dt><dd> ace.groups</dd> <dt>Description:</dt><dd> The KDC interface at the parent resource of group-membership resources is used to retrieve names of security groups using the ACEframework.</li> <li>Reference:framework.</dd> <dt>Reference:</dt><dd> <xref target="kdc-if"/> of[RFC-XXXX]</li> </ul> <t> </t> <ul spacing="normal"> <li>Value: ace.group</li> <li>Description:RFC 9594</dd> </dl> <dl spacing="compact"> <dt>Value:</dt><dd> ace.group</dd> <dt>Description:</dt><dd> The KDC interface at a group-membership resource is used to provision keying material and related information and policies to members of the corresponding security group using the ACEframework.</li> <li>Reference:framework.</dd> <dt>Reference:</dt><dd> <xref target="kdc-if"/> of[RFC-XXXX]</li> </ul>RFC 9594</dd> </dl> </section> <section anchor="iana-custom-problem-details"> <name>Custom Problem Detail Keys Registry</name> <t>IANAis asked to registerhas registered the following entry in the "Custom Problem Detail Keys" registry within the "CoRE Parameters" registry group.</t><ul spacing="normal"> <li>Key Value: TBD</li> <li>Name: ace-groupcomm-error</li> <li>Brief<dl spacing="compact"> <dt>Key Value:</dt><dd>0</dd> <dt>Name:</dt><dd> ace-groupcomm-error</dd> <!--[rfced] We suggest moving the RFC number so that it's not used as an adjective before the noun. If this change is acceptable, we will ask IANA to update the registry (https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#core-custom-problem-detail-keys) accordingly. However, we note that the other registered value has a similar description ("Carry [RFC7807] problem details..."). Original: * Brief Description: Carry [RFC-XXXX] problem details in a Concise Problem Details dataitem.</li> <li>Change Controller: IETF</li> <li>Reference:item. Suggested: Brief Description: Carry problem details from RFC 9594 in a Concise Problem Details data item. --> <dt>Brief Description:</dt><dd>Carry RFC 9594 problem details in a Concise Problem Details data item.</dd> <dt>Change Controller:</dt><dd> IETF</dd> <dt>Reference:</dt><dd>RFC 9594, <xreftarget="kdc-if-errors"/> of [RFC-XXXX]</li> </ul>target="kdc-if-errors"/></dd> </dl> </section> <section anchor="iana-reg"> <name>ACE Groupcomm Parameters</name> <!--[rfced] In Sections 11.7 - 11.13, this paragraph seems unnecessary and redundant with the registration procedures described within each section. So, we suggest the paragraph be trimmed as follows in each of those sections. a) Is this acceptable? Original: The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 11.14. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well. Perhaps: Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in Section 11.14. b) If that change is not acceptable, did you intend for all registrations to be subject to expert review, including in the Private Use range? That is how the original text reads. Please revise as necessary. --> <t>This specificationestablisheshas established the "ACE Groupcomm Parameters" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t> <t>The registry has been created to use the "Expert Review" registration procedure <xref target="RFC8126"/>. ExpertreviewReview guidelines are provided in <xref target="review"/>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to theexpert review,Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.</t> <t>The columns of this registry are:</t><ul<dl spacing="normal"><li>Name:<dt>Name:</dt><dd> This is a descriptive name that enables easier reference to the item. The nameMUST<bcp14>MUST</bcp14> be unique. It is not used in theencoding.</li> <li>CBOR Key:encoding.</dd> <dt>CBOR Key:</dt><dd> This is the value used as the CBOR key of the item. These valuesMUST<bcp14>MUST</bcp14> be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <xref target="RFC8126"/>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to65535,65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "PrivateUse".</li> <li>CBOR Type:Use".</dd> <dt>CBOR Type:</dt><dd> This contains the CBOR type of theitem,item or a pointer to the registry that defines itstype,type when that depends on anotheritem.</li> <li>Reference:item.</dd> <dt>Reference:</dt><dd> This contains a pointer to the public specification for theitem.</li> </ul>item.</dd> </dl> <t>This registry has been initially populated with the values in <xref target="fig-ACE-Groupcomm-Parameters"/>.</t> </section> <section anchor="iana-key"> <name>ACE Groupcomm Key Types</name> <t>This specification establishes the "ACE Groupcomm Key Types" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t> <t>The registry has been created to use the "Expert Review" registration procedure <xref target="RFC8126"/>. ExpertreviewReview guidelines are provided in <xref target="review"/>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to theexpert review,Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.</t> <t>The columns of this registry are:</t><ul<dl spacing="normal"><li>Name:<dt>Name:</dt><dd> This is a descriptive name that enables easier reference to the item. The nameMUST<bcp14>MUST</bcp14> be unique. It is not used in theencoding.</li> <li>Keyencoding.</dd> <dt>Key TypeValue:Value:</dt><dd> This is the value used to identify the keying material. These valuesMUST<bcp14>MUST</bcp14> be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <xref target="RFC8126"/>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to65535,65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "PrivateUse".</li> <li>Profile:Use".</dd> <dt>Profile:</dt><dd> This field may contain one or more descriptive strings of application profiles to be used with this item. The values should be taken from theName"Name" column of the "ACE Groupcomm Profiles"registry.</li> <li>Description:registry.</dd> <dt>Description:</dt><dd> This field contains a brief description of the keyingmaterial.</li> <li>Reference:material.</dd> <dt>Reference:</dt><dd> This contains a pointer to the public specification for the format of the keying material, if oneexists.</li> </ul>exists.</dd> </dl> <t>This registry has been initially populated with the value in <xref target="fig-gkty"/>.</t> </section> <section anchor="ace-groupcomm-profiles"> <name>ACE Groupcomm Profiles</name> <t>This specification establishes the "ACE Groupcomm Profiles" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t> <t>The registry has been created to use the "Expert Review" registration procedure <xref target="RFC8126"/>. ExpertreviewReview guidelines are provided in <xref target="review"/>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to theexpert review,Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.</t> <t>The columns of this registry are:</t><ul<dl spacing="normal"><li>Name:<dt>Name:</dt><dd> The name of the applicationprofile,profile to be used as value of the profileattribute.</li> <li>Description:attribute.</dd> <dt>Description:</dt><dd> Text giving an overview of the application profile and the context it is developedfor.</li> <li>CBOR Value:for.</dd> <dt>CBOR Value:</dt><dd> CBOR abbreviation for the name of this application profile. These valuesMUST<bcp14>MUST</bcp14> be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <xref target="RFC8126"/>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "PrivateUse".</li> <li>Reference:Use".</dd> <dt>Reference:</dt><dd> This contains a pointer to the public specification of the abbreviation for this application profile, if oneexists.</li> </ul>exists.</dd> </dl> <t>This registry has been initially populated with the value in <xref target="ace-groupcomm-profile-0"/>.</t> </section> <section anchor="ace-groupcomm-policies"> <name>ACE Groupcomm Policies</name> <t>This specification establishes the "ACE Groupcomm Policies" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t> <t>The registry has been created to use the "Expert Review" registration procedure <xref target="RFC8126"/>. ExpertreviewReview guidelines are provided in <xref target="review"/>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to theexpert review,Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.</t> <t>The columns of this registry are:</t><ul<dl spacing="normal"><li>Name:<dt>Name:</dt><dd> The name of the group communicationpolicy.</li> <li>CBOR label:policy.</dd> <dt>CBOR Label:</dt><dd> The value to be used to identify this group communication policy. These valuesMUST<bcp14>MUST</bcp14> be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <xref target="RFC8126"/>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to65535,65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "PrivateUse".</li> <li>CBOR type: theUse".</dd> <dt>CBOR Type:</dt><dd> The CBOR type used to encode the value of this group communicationpolicy.</li> <li>Description:policy.</dd> <dt>Description:</dt><dd> This field contains a brief description for this group communicationpolicy.</li> <li>Reference:policy.</dd> <dt>Reference:</dt><dd> This field contains a pointer to the public specification providing the format of the group communication policy, if oneexists.</li> </ul>exists.</dd> </dl> <t>This registry has been initially populated with the values in <xref target="fig-ACE-Groupcomm-Policies"/>.</t> </section> <section anchor="sequence-number-synchronization-methods"> <name>Sequence Number Synchronization Methods</name> <t>This specification establishes the "Sequence Number Synchronization Methods" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t> <t>The registry has been created to use the "Expert Review" registration procedure <xref target="RFC8126"/>. ExpertreviewReview guidelines are provided in <xref target="review"/>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to theexpert review,Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.</t> <t>The columns of this registry are:</t><ul<dl spacing="normal"><li>Name:<dt>Name:</dt><dd> The name of the sequence number synchronizationmethod.</li> <li>Value:method.</dd> <dt>Value:</dt><dd> The value to be used to identify this sequence number synchronization method. These valuesMUST<bcp14>MUST</bcp14> be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <xref target="RFC8126"/>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to65535,65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "PrivateUse".</li> <li>Description:Use".</dd> <dt>Description:</dt><dd> This field contains a brief description for this sequence number synchronizationmethod.</li> <li>Reference:method.</dd> <dt>Reference:</dt><dd> This field contains a pointer to the public specification describing the sequence number synchronizationmethod.</li> </ul>method.</dd> </dl> </section> <section anchor="iana-ace-groupcomm-errors"> <name>ACE Groupcomm Errors</name> <t>This specification establishes the "ACE Groupcomm Errors" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t> <t>The registry has been created to use the "Expert Review" registration procedure <xref target="RFC8126"/>. ExpertreviewReview guidelines are provided in <xref target="review"/>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to theexpert review,Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.</t> <t>The columns of this registry are:</t><ul<dl spacing="normal"><li>Value:<dt>Value:</dt><dd> The value to be used to identify the error. These valuesMUST<bcp14>MUST</bcp14> be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <xref target="RFC8126"/>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "PrivateUse".</li> <li>Description:Use".</dd> <dt>Description:</dt><dd> This field contains a brief description of theerror.</li> <li>Reference:error.</dd> <dt>Reference:</dt><dd> This field contains a pointer to the public specification defining the error, if oneexists.</li> </ul>exists.</dd> </dl> <t>This registry has been initially populated with the values in <xref target="fig-ACE-Groupcomm-Error-Identifiers"/>. TheReference"Reference" column for all of these entries refers to this document.</t> </section> <section anchor="iana-ace-groupcomm-rekeying-schemes"> <name>ACE Groupcomm Rekeying Schemes</name> <t>This specification establishes the "ACE Groupcomm Rekeying Schemes" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t> <t>The registry has been created to use the "Expert Review" registration procedure <xref target="RFC8126"/>. ExpertreviewReview guidelines are provided in <xref target="review"/>. Values in this registry are covered by different registration policies as indicated. It should be noted that, in addition to theexpert review,Expert Review, some portions of the registry require a specification, potentially a Standards Track RFC, to be supplied as well.</t> <t>The columns of this registry are:</t><ul<dl spacing="normal"><li>Value:<dt>Value:</dt><dd> The value to be used to identify the group rekeying scheme. These valuesMUST<bcp14>MUST</bcp14> be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies <xref target="RFC8126"/>. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "PrivateUse".</li> <li>Name:Use".</dd> <dt>Name:</dt><dd> The name of the group rekeyingscheme.</li> <li>Description:scheme.</dd> <dt>Description:</dt><dd> This field contains a brief description of the group rekeyingscheme.</li> <li>Reference:scheme.</dd> <dt>Reference:</dt><dd> This field contains a pointer to the public specification defining the group rekeying scheme, if oneexists.</li> </ul>exists.</dd> </dl> <t>This registry has been initially populated with the value in <xref target="rekeying-scheme-0"/>.</t> </section> <section anchor="review"> <name>Expert Review Instructions</name> <t>The IANARegistriesregistries established in this document are defined asexpert review.Expert Review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude.</t> <t>ExpertreviewersReviewers should take into consideration the following points:</t> <ul spacing="normal"> <li>Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged asprivate use"Private Use" are intended for testing purposes and closedenvironments,environments; code points in other ranges should not be assigned for testing.</li> <li>Specifications are required for the standards track range of point assignment. Specifications should exist forspecification requiredSpecification Required ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.</li> <li>Experts should take into account the expected usage of fields when approving point assignments. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of the device it will be used on, and the number of code points left that encode to that size.</li> </ul> </section> </section> </middle> <back> <displayreference target="I-D.ietf-core-groupcomm-bis" to="GROUP-CoAP"/> <displayreference target="I-D.ietf-core-oscore-groupcomm" to="GROUP-OSCORE"/> <displayreference target="I-D.ietf-core-coap-pubsub" to="CoAP-PUBSUB"/> <displayreference target="I-D.ietf-cose-cbor-encoded-cert" to="C509-CERT"/> <displayreference target="I-D.tiloca-core-oscore-discovery" to="OSCORE-DISCOVERY"/> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC3629"> <front> <title>UTF-8, a transformation format of ISO 10646</title> <author fullname="F. Yergeau" initials="F." surname="Yergeau"/> <date month="November" year="2003"/> <abstract> <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t> </abstract> </front> <seriesInfo name="STD" value="63"/> <seriesInfo name="RFC" value="3629"/> <seriesInfo name="DOI" value="10.17487/RFC3629"/> </reference> <reference anchor="RFC6690"> <front> <title>Constrained RESTful Environments (CoRE) Link Format</title> <author fullname="Z. Shelby" initials="Z." surname="Shelby"/> <date month="August" year="2012"/> <abstract> <t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6690"/> <seriesInfo name="DOI" value="10.17487/RFC6690"/> </reference> <reference anchor="RFC6749"> <front> <title>The OAuth 2.0 Authorization Framework</title> <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt"/> <date month="October" year="2012"/> <abstract> <t>The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6749"/> <seriesInfo name="DOI" value="10.17487/RFC6749"/> </reference> <reference anchor="RFC6838"> <front> <title>Media Type Specifications and Registration Procedures</title> <author fullname="N. Freed" initials="N." surname="Freed"/> <author fullname="J. Klensin" initials="J." surname="Klensin"/> <author fullname="T. Hansen" initials="T." surname="Hansen"/> <date month="January" year="2013"/> <abstract> <t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t> </abstract> </front> <seriesInfo name="BCP" value="13"/> <seriesInfo name="RFC" value="6838"/> <seriesInfo name="DOI" value="10.17487/RFC6838"/> </reference> <reference anchor="RFC8126"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author fullname="M. Cotton" initials="M." surname="Cotton"/> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <date month="June" year="2017"/> <abstract> <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC8610"> <front> <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title> <author fullname="H. Birkholz" initials="H." surname="Birkholz"/> <author fullname="C. Vigano" initials="C." surname="Vigano"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="June" year="2019"/> <abstract> <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t> </abstract> </front> <seriesInfo name="RFC" value="8610"/> <seriesInfo name="DOI" value="10.17487/RFC8610"/> </reference> <reference anchor="RFC7252"> <front> <title>The Constrained Application Protocol (CoAP)</title> <author fullname="Z. Shelby" initials="Z." surname="Shelby"/> <author fullname="K. Hartke" initials="K." surname="Hartke"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="June" year="2014"/> <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> <seriesInfo name="RFC" value="7252"/> <seriesInfo name="DOI" value="10.17487/RFC7252"/> </reference> <reference anchor="RFC7967"> <front> <title>Constrained Application Protocol (CoAP) Option for No Server Response</title> <author fullname="A. Bhattacharyya" initials="A." surname="Bhattacharyya"/> <author fullname="S. Bandyopadhyay" initials="S." surname="Bandyopadhyay"/> <author fullname="A. Pal" initials="A." surname="Pal"/> <author fullname="T. Bose" initials="T." surname="Bose"/> <date month="August" year="2016"/> <abstract> <t>There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.</t> <t>This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.</t> </abstract> </front> <seriesInfo name="RFC" value="7967"/> <seriesInfo name="DOI" value="10.17487/RFC7967"/> </reference> <reference anchor="RFC8747"> <front> <title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)</title> <author fullname="M. Jones" initials="M." surname="Jones"/> <author fullname="L. Seitz" initials="L." surname="Seitz"/> <author fullname="G. Selander" initials="G." surname="Selander"/> <author fullname="S. Erdtman" initials="S." surname="Erdtman"/> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> <date month="March" year="2020"/> <abstract> <t>This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).</t> </abstract> </front> <seriesInfo name="RFC" value="8747"/> <seriesInfo name="DOI" value="10.17487/RFC8747"/> </reference> <reference anchor="RFC8949"> <front> <title>Concise Binary Object Representation (CBOR)</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="December" year="2020"/> <abstract> <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t> <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t> </abstract> </front> <seriesInfo name="STD" value="94"/> <seriesInfo name="RFC" value="8949"/> <seriesInfo name="DOI" value="10.17487/RFC8949"/> </reference> <reference anchor="RFC9052"> <front> <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title> <author fullname="J. Schaad" initials="J." surname="Schaad"/> <date month="August" year="2022"/> <abstract> <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services 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> <t>This document, along with RFC 9053, obsoletes RFC 8152.</t> </abstract> </front> <seriesInfo name="STD" value="96"/> <seriesInfo name="RFC" value="9052"/> <seriesInfo name="DOI" value="10.17487/RFC9052"/> </reference> <reference anchor="RFC9053"> <front> <title>CBOR Object Signing and Encryption (COSE): Initial Algorithms</title> <author fullname="J. Schaad" initials="J." surname="Schaad"/> <date month="August" year="2022"/> <abstract> <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).</t> <t>This document, along with RFC 9052, obsoletes RFC 8152.</t> </abstract> </front> <seriesInfo name="RFC" value="9053"/> <seriesInfo name="DOI" value="10.17487/RFC9053"/> </reference> <reference anchor="RFC9200"> <front> <title>Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)</title> <author fullname="L. Seitz" initials="L." surname="Seitz"/> <author fullname="G. Selander" initials="G." surname="Selander"/> <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/> <author fullname="S. Erdtman" initials="S." surname="Erdtman"/> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> <date month="August" year="2022"/> <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> <seriesInfo name="RFC" value="9200"/> <seriesInfo name="DOI" value="10.17487/RFC9200"/> </reference> <reference anchor="RFC9237"> <front> <title>An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE)</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="August" year="2022"/> <abstract> <t>Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as the Internet of Things.</t> <t>This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use with Representational State Transfer (REST) resources identified by URI path.</t> </abstract> </front> <seriesInfo name="RFC" value="9237"/> <seriesInfo name="DOI" value="10.17487/RFC9237"/> </reference> <reference anchor="RFC9290"> <front> <title>Concise Problem Details for Constrained Application Protocol (CoAP) APIs</title> <author fullname="T. Fossati" initials="T." surname="Fossati"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="October" year="2022"/> <abstract> <t>This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807.</t> </abstract> </front> <seriesInfo name="RFC" value="9290"/> <seriesInfo name="DOI" value="10.17487/RFC9290"/> </reference> <reference anchor="RFC9338"> <front> <title>CBOR Object Signing and Encryption (COSE): Countersignatures</title> <author fullname="J. Schaad" initials="J." surname="Schaad"/> <date month="December" year="2022"/> <abstract> <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052.</t> </abstract> </front> <seriesInfo name="STD" value="96"/> <seriesInfo name="RFC" value="9338"/> <seriesInfo name="DOI" value="10.17487/RFC9338"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6690.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7967.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8747.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9052.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9053.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9200.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9237.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9290.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9338.xml"/> <reference anchor="COSE.Algorithms"target="https://www.iana.org/assignments/cose/cose.xhtml#algorithms">target="https://www.iana.org/assignments/cose/"> <front> <title>COSE Algorithms</title> <author> <organization>IANA</organization> </author><date/></front> </reference> <reference anchor="COSE.Header.Parameters"target="https://www.iana.org/assignments/cose/cose.xhtml#header-parameters">target="https://www.iana.org/assignments/cose/"> <front> <title>COSE Header Parameters</title> <author> <organization>IANA</organization> </author><date/></front> </reference> <reference anchor="COSE.Key.Types"target="https://www.iana.org/assignments/cose/cose.xhtml#key-type">target="https://www.iana.org/assignments/cose/"> <front> <title>COSEkeyKey Types</title> <author> <organization>IANA</organization> </author><date/></front> </reference> <reference anchor="CBOR.Tags"target="https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml">target="https://www.iana.org/assignments/cbor-tags/"> <front> <title>Concise Binary Object Representation (CBOR) Tags</title> <author> <organization>IANA</organization> </author><date/></front> </reference> <reference anchor="CoAP.Content.Formats"target="https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats">target="https://www.iana.org/assignments/core-parameters/"> <front> <title>CoAP Content-Formats</title> <author> <organization>IANA</organization> </author><date/></front> </reference> </references> <references> <name>Informative References</name><reference anchor="RFC2093"> <front> <title>Group Key Management Protocol (GKMP) Specification</title> <author fullname="H. Harney" initials="H." surname="Harney"/> <author fullname="C. Muckenhirn" initials="C." surname="Muckenhirn"/> <date month="July" year="1997"/> <abstract> <t>This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="2093"/> <seriesInfo name="DOI" value="10.17487/RFC2093"/> </reference> <reference anchor="RFC2094"> <front> <title>Group Key Management Protocol (GKMP) Architecture</title> <author fullname="H. Harney" initials="H." surname="Harney"/> <author fullname="C. Muckenhirn" initials="C." surname="Muckenhirn"/> <date month="July" year="1997"/> <abstract> <t>This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="2094"/> <seriesInfo name="DOI" value="10.17487/RFC2094"/> </reference> <reference anchor="RFC2627"> <front> <title>Key Management for Multicast: Issues and Architectures</title> <author fullname="D. Wallner" initials="D." surname="Wallner"/> <author fullname="E. Harder" initials="E." surname="Harder"/> <author fullname="R. Agee" initials="R." surname="Agee"/> <date month="June" year="1999"/> <abstract> <t>This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="2627"/> <seriesInfo name="DOI" value="10.17487/RFC2627"/> </reference> <reference anchor="RFC3986"> <front> <title>Uniform Resource Identifier (URI): Generic Syntax</title> <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/> <author fullname="R. Fielding" initials="R." surname="Fielding"/> <author fullname="L. Masinter" initials="L." surname="Masinter"/> <date month="January" year="2005"/> <abstract> <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="66"/> <seriesInfo name="RFC" value="3986"/> <seriesInfo name="DOI" value="10.17487/RFC3986"/> </reference> <reference anchor="RFC5280"> <front> <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title> <author fullname="D. Cooper" initials="D." surname="Cooper"/> <author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="S. Farrell" initials="S." surname="Farrell"/> <author fullname="S. Boeyen" initials="S." surname="Boeyen"/> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="W. Polk" initials="W." surname="Polk"/> <date month="May" year="2008"/> <abstract> <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5280"/> <seriesInfo name="DOI" value="10.17487/RFC5280"/> </reference> <reference anchor="RFC7519"> <front> <title>JSON Web Token (JWT)</title> <author fullname="M. Jones" initials="M." surname="Jones"/> <author fullname="J. Bradley" initials="J." surname="Bradley"/> <author fullname="N. Sakimura" initials="N." surname="Sakimura"/> <date month="May" year="2015"/> <abstract> <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2093.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2094.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2627.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7641.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9202.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9203.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9277.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9431.xml"/> <!-- [I-D.ietf-core-groupcomm-bis] IESG state: I-D Exists asthe plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t> </abstract> </front> <seriesInfo name="RFC" value="7519"/> <seriesInfo name="DOI" value="10.17487/RFC7519"/> </reference> <reference anchor="RFC7641"> <front> <title>Observing Resources in the Constrained Application Protocol (CoAP)</title> <author fullname="K. Hartke" initials="K." surname="Hartke"/> <date month="September" year="2015"/> <abstract> <t>The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t> </abstract> </front> <seriesInfo name="RFC" value="7641"/> <seriesInfo name="DOI" value="10.17487/RFC7641"/> </reference> <reference anchor="RFC7959"> <front> <title>Block-Wise Transfers in the Constrained Application Protocol (CoAP)</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <author fullname="Z. Shelby" initials="Z." role="editor" surname="Shelby"/> <date month="August" year="2016"/> <abstract> <t>The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt workofsegmenting and resequencing, CoAP is based on datagram transports such02/26/24 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-core-groupcomm-bis.xml"/> <!-- [I-D.ietf-core-oscore-groupcomm] IESG state: I-D Exists asUDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.</t> <t>Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memoryofprevious block transfers. Essentially, the Block options provide a minimal02/26/24 Long wayto transfer larger representations in a block-wise fashion.</t> <t>A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.</t> </abstract> </front> <seriesInfo name="RFC" value="7959"/> <seriesInfo name="DOI" value="10.17487/RFC7959"/> </reference> <reference anchor="RFC8259"> <front> <title>The JavaScript Object Notation (JSON) Data Interchange Format</title> <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/> <date month="December" year="2017"/> <abstract> <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t> <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t> </abstract> </front> <seriesInfo name="STD" value="90"/> <seriesInfo name="RFC" value="8259"/> <seriesInfo name="DOI" value="10.17487/RFC8259"/> </reference> <reference anchor="RFC8392"> <front> <title>CBOR Web Token (CWT)</title> <author fullname="M. Jones" initials="M." surname="Jones"/> <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/> <author fullname="S. Erdtman" initials="S." surname="Erdtman"/> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> <date month="May" year="2018"/> <abstract> <t>CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.</t> </abstract> </front> <seriesInfo name="RFC" value="8392"/> <seriesInfo name="DOI" value="10.17487/RFC8392"/> </reference> <reference anchor="RFC8613"> <front> <title>Object Security for Constrained RESTful Environments (OSCORE)</title> <author fullname="G. Selander" initials="G." surname="Selander"/> <author fullname="J. Mattsson" initials="J." surname="Mattsson"/> <author fullname="F. Palombini" initials="F." surname="Palombini"/> <author fullname="L. Seitz" initials="L." surname="Seitz"/> <date month="July" year="2019"/> <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> <seriesInfo name="RFC" value="8613"/> <seriesInfo name="DOI" value="10.17487/RFC8613"/> </reference> <reference anchor="RFC9202"> <front> <title>Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)</title> <author fullname="S. Gerdes" initials="S." surname="Gerdes"/> <author fullname="O. Bergmann" initials="O." surname="Bergmann"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <author fullname="G. Selander" initials="G." surname="Selander"/> <author fullname="L. Seitz" initials="L." surname="Seitz"/> <date month="August" year="2022"/> <abstract> <t>This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory.</t> </abstract> </front> <seriesInfo name="RFC" value="9202"/> <seriesInfo name="DOI" value="10.17487/RFC9202"/> </reference> <reference anchor="RFC9203"> <front> <title>The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework</title> <author fullname="F. Palombini" initials="F." surname="Palombini"/> <author fullname="L. Seitz" initials="L." surname="Seitz"/> <author fullname="G. Selander" initials="G." surname="Selander"/> <author fullname="M. Gunnarsson" initials="M." surname="Gunnarsson"/> <date month="August" year="2022"/> <abstract> <t>This document 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 and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.</t> </abstract> </front> <seriesInfo name="RFC" value="9203"/> <seriesInfo name="DOI" value="10.17487/RFC9203"/> </reference> <reference anchor="RFC9277"> <front> <title>On Stable Storage for Items in Concise Binary Object Representation (CBOR)</title> <author fullname="M. Richardson" initials="M." surname="Richardson"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="August" year="2022"/> <abstract> <t>This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command.</t> </abstract> </front> <seriesInfo name="RFC" value="9277"/> <seriesInfo name="DOI" value="10.17487/RFC9277"/> </reference> <reference anchor="RFC9431"> <front> <title>Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework</title> <author fullname="C. Sengul" initials="C." surname="Sengul"/> <author fullname="A. Kirby" initials="A." surname="Kirby"/> <date month="July" year="2023"/> <abstract> <t>This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based on Message Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, areused toauthenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication.</t> </abstract> </front> <seriesInfo name="RFC" value="9431"/> <seriesInfo name="DOI" value="10.17487/RFC9431"/> </reference>fix "Mattsson, J. P."--> <referenceanchor="I-D.ietf-core-groupcomm-bis">anchor="I-D.ietf-core-oscore-groupcomm" target="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-21"> <front><title>Group Communication for the Constrained Application Protocol (CoAP)</title> <author fullname="Esko Dijk" initials="E." surname="Dijk"> <organization>IoTconsultancy.nl</organization> </author> <author fullname="Chonggang Wang" initials="C." surname="Wang"> <organization>InterDigital</organization> </author> <author fullname="Marco Tiloca" initials="M." surname="Tiloca"> <organization>RISE AB</organization> </author> <date day="23" month="October" year="2023"/> <abstract> <t> This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the<title> Group Object Security for Constrained RESTful Environments (Group OSCORE)protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-core-groupcomm-bis-10"/> </reference> <reference anchor="I-D.ietf-core-oscore-groupcomm"> <front> <title>Group Object Security for Constrained RESTful Environments (Group OSCORE)</title></title> <authorfullname="Marco Tiloca"initials="M."surname="Tiloca">surname="Tiloca" fullname="Marco Tiloca"> <organization>RISE AB</organization> </author> <authorfullname="Göran Selander"initials="G."surname="Selander">surname="Selander" fullname="Göran Selander"> <organization>Ericsson AB</organization> </author> <authorfullname="Francesca Palombini"initials="F."surname="Palombini">surname="Palombini" fullname="Francesca Palombini"> <organization>Ericsson AB</organization> </author> <author initials="J." surname="Preuß Mattsson" fullname="John PreußMattsson" initials="J. P." surname="Mattsson">Mattsson"> <organization>Ericsson AB</organization> </author> <authorfullname="Jiye Park" initials="J." surname="Park"> <organization>Universitaet Duisburg-Essen</organization>initials="R." surname="Höglund" fullname="Rikard Höglund"> <organization>RISE AB</organization> </author> <dateday="2" month="September" year="2023"/> <abstract> <t> This document defines the security protocol 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., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP-mappable HTTP. </t> </abstract>month="March" day="4" year="2024"/> </front> <seriesInfo name="Internet-Draft"value="draft-ietf-core-oscore-groupcomm-20"/>value="draft-ietf-core-oscore-groupcomm-21"/> </reference><reference anchor="I-D.ietf-core-coap-pubsub"> <front> <title>A publish-subscribe architecture for the Constrained Application Protocol (CoAP)</title> <author fullname="Jaime Jimenez" initials="J." surname="Jimenez"> <organization>Ericsson</organization> </author> <author fullname="Michael Koster" initials="M." surname="Koster"> <organization>Dogtiger Labs</organization> </author> <author fullname="Ari Keränen" initials="A." surname="Keränen"> <organization>Ericsson</organization> </author> <date day="20" month="October" year="2023"/> <abstract> <t> This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities<!-- [I-D.ietf-core-coap-pubsub] IESG state: I-D Exists as ofCoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting02/26/24 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-core-coap-pubsub.xml"/> <!-- [I-D.ietf-cose-cbor-encoded-cert] IESG state: I-D Exists asbroker. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-core-coap-pubsub-13"/> </reference>of 7/7/24 Long way used to fix "Mattsson, J. P."--> <referenceanchor="I-D.ietf-cose-cbor-encoded-cert">anchor="I-D.ietf-cose-cbor-encoded-cert" target="https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-11"> <front><title>CBOR<title> CBOR Encoded X.509 Certificates (C509Certificates)</title>Certificates) </title> <author initials="J." surname="Preuß Mattsson" fullname="John PreußMattsson" initials="J. P." surname="Mattsson">Mattsson"> <organization>Ericsson AB</organization> </author> <authorfullname="Göran Selander"initials="G."surname="Selander">surname="Selander" fullname="Göran Selander"> <organization>Ericsson AB</organization> </author> <authorfullname="Shahid Raza"initials="S."surname="Raza">surname="Raza" fullname="Shahid Raza"> <organization>RISE AB</organization> </author> <authorfullname="Joel Höglund"initials="J."surname="Höglund">surname="Höglund" fullname="Joel Höglund"> <organization>RISE AB</organization> </author> <authorfullname="Martin Furuhed"initials="M."surname="Furuhed">surname="Furuhed" fullname="Martin Furuhed"> <organization>Nexus Group</organization> </author> <dateday="20" month="October" year="2023"/> <abstract> <t> This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50%. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 COSE headers, a C509 TLS certificate type, and a C509 file format. </t> </abstract>month="July" day="8" year="2024"/> </front> <seriesInfo name="Internet-Draft"value="draft-ietf-cose-cbor-encoded-cert-07"/>value="draft-ietf-cose-cbor-encoded-cert-11"/> </reference><reference anchor="I-D.tiloca-core-oscore-discovery"> <front> <title>Discovery of OSCORE Groups with the CoRE Resource Directory</title> <author fullname="Marco Tiloca" initials="M." surname="Tiloca"> <organization>RISE AB</organization> </author> <author fullname="Christian Amsüss" initials="C." surname="Amsüss"> </author> <author fullname="Peter Van der Stok" initials="P." surname="Van der Stok"> <organization>Consultant</organization> </author> <date day="8" month="September" year="2023"/> <abstract> <t> Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory<!-- [I-D.tiloca-core-oscore-discovery] IESG state: I-D Exists assets of endpoints sharing a poolofresources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-tiloca-core-oscore-discovery-14"/> </reference>02/26/24 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-tiloca-core-oscore-discovery.xml"/> </references> </references> <section anchor="req"> <name>Requirements for Application Profiles</name> <t>This section lists the requirements for application profiles of thisspecification,specification for the convenience of application profile designers.</t> <section anchor="req-mandatory"> <name>Mandatory-to-Address Requirements</name><ul spacing="normal"> <li>REQ1: Specify<ol type="REQ%d:"> <li anchor="req1">Specify the format and encoding of 'scope'. This includes defining the set of possible roles and their identifiers, as well as the corresponding encoding to use in the scope entries according to the used scope format (see <xref target="ssec-authorization-request"/>).</li><li>REQ2: If<li>If the AIF format of 'scope' is used, register its specific instance of "Toid" and "Tperm" asMedia Typemedia type parameters and a corresponding Content-Format, as per the guidelines in <xref target="RFC9237"/>.</li><li>REQ3: If<li>If used, specify the acceptable values for 'sign_alg' (see <xref target="token-post"/>).</li><li>REQ4: If<li>If used, specify the acceptable values for 'sign_parameters' (see <xref target="token-post"/>).</li><li>REQ5: If<li>If used, specify the acceptable values for 'sign_key_parameters' (see <xref target="token-post"/>).</li><li>REQ6: Specify<li>Specify the acceptable formats for authentication credentials and, if used, the acceptable values for 'cred_fmt' (see <xref target="token-post"/>).</li><li>REQ7: If<li>If the value of the GROUPNAME URI path and the group name in the access token scope (gname in <xref target="ssec-authorization-response"/>) are not required to coincide, specify the mechanism to map the GROUPNAME value in the URI to the group name (see <xref target="kdc-if"/>).</li><li>REQ8: Define<li>Define whether the KDC has an authentication credential and if this has to be provided through the 'kdc_cred'parameter, seeparameter (see <xreftarget="gid-post"/>.</li> <li>REQ9: Specifytarget="gid-post"/>).</li> <li>Specify if any part of the KDC interface as defined in this document is not supported by the KDC (see <xref target="kdc-if"/>).</li><li>REQ10: Register<li>Register a Resource Type for the group-membership resource, which is used to discover the correct URL for sending a Join Request to the KDC (see <xref target="kdc-if"/>).</li><li>REQ11: Define<li>Define what specific actions (e.g., CoAP methods) are allowed on each resource provided by the KDC interface, depending on whether the Client is a current group member; the roles that a Client is authorized to take as per the obtained access token (see <xref target="ssec-authorization-request"/>); and the roles that the Client has as a current group member.</li><li>REQ12: Categorize<li>Categorize possible newly defined operations for Clients into primary operations expected to be minimally supported and secondaryoperations,operations and provide accompanying considerations (see <xref target="client-operations"/>).</li><li>REQ13: Specify<li>Specify the encoding of the group identifier (see <xref target="ace-group-fetch"/>).</li><li>REQ14: Specify<li>Specify the approaches used to compute and verify the PoP evidence to include in'client_cred_verify','client_cred_verify' and which of those approaches is used in which case (see <xref target="gid-post"/>).</li><li>REQ15: Specify<li>Specify how the nonce N_S isgenerated,generated if the token is not provided to the KDC through the Token Transfer Request to the authz-info endpoint (e.g., if it is used directly to validate TLS instead).</li><li>REQ16 Define<li>Define the initial value of the 'num' parameter (see <xref target="gid-post"/>).</li><li>REQ17: Specify<li>Specify the format of the 'key' parameter and register a corresponding entry in the "ACE Groupcomm Key Types" IANA registry (see <xref target="gid-post"/>).</li><li>REQ18: Specify<li>Specify the acceptable values of the 'gkty' parameter (see <xref target="gid-post"/>).</li><li>REQ19: Specify<li>Specify and register the application profile identifier (see <xref target="gid-post"/>).</li><li>REQ20: If<li>If used, specify the format and content of 'group_policies' and its entries. Specify thepoliciespolicies' default values (see <xref target="gid-post"/>).</li><li>REQ21: Specify<li>Specify the approaches used to compute and verify the PoP evidence to include in'kdc_cred_verify','kdc_cred_verify' and which of those approaches is used in which case (see Sections <xreftarget="gid-post"/>target="gid-post" format="counter"/> and <xreftarget="kdc-pub-key-get"/>).target="kdc-pub-key-get" format="counter"/>). If external signature verifiers are supported, specify how those provide a nonce to the KDC to be used for computing the PoP evidence (see <xref target="kdc-pub-key-get"/>).</li><li>REQ22: Specify<li>Specify the communication protocol that the members of the group must use (e.g., CoAP for group communication).</li><li>REQ23: Specify<li>Specify the security protocol the group members must use to protect their communication (e.g., group OSCORE). This must provide encryption, integrity, and replay protection.</li><li>REQ24: Specify<li>Specify how the communication is secured between the Client and KDC. Optionally, specify a transport profile of ACE <xref target="RFC9200"/> to use between Client and KDC (see <xref target="ssec-key-distribution-exchange"/>).</li><li>REQ25: Specify<li>Specify the format of the identifiers of group members (see Sections <xreftarget="gid-post"/>target="gid-post" format="counter"/> and <xreftarget="pubkey-fetch"/>).</li> <li>REQ26: Specifytarget="pubkey-fetch" format="counter"/>).</li> <li>Specify policies at the KDC to handle ids that are not included in 'get_creds' (see <xref target="pubkey-fetch"/>).</li><li>REQ27: Specify<li>Specify the format ofnewly-generatednewly generated individual keying material for group members, or of the information to derive it, and corresponding CBOR label (see <xref target="node-get"/>).</li><li>REQ28: Specify<li>Specify which CBOR tag is used for identifying the semantics of binary scopes, or register a new CBOR tag if a suitable one does not exist already (see <xref target="sec-extended-scope"/>).</li><li>REQ29: Categorize<li>Categorize newly defined parameters according to the same criteria of <xref target="params"/>.</li><li>REQ30: Define<li>Define whether Clients must, should, or may support the conditional parameters defined in <xreftarget="params"/>,target="params"/> and under which circumstances.</li></ul></ol> </section> <section anchor="req-optional"> <name>Optional-to-Address Requirements</name><ul spacing="normal"> <li>OPT1: Optionally,<ol type="OPT%d:"> <li>Optionally, if the textual format of 'scope' is used, specify CBOR values to use for abbreviating the role identifiers in the group (see <xref target="ssec-authorization-request"/>).</li><li>OPT2: Optionally,<li>Optionally, specify the additional parameters used in the exchange of Token Transfer Request and Response (see <xref target="token-post"/>).</li><li>OPT3: Optionally,<li>Optionally, specify the negotiation of parameter values for signature algorithm and signaturekeys,keys if 'sign_info' is not used (see <xref target="token-post"/>).</li><li>OPT4: Optionally,<li>Optionally, specify possible or required payload formats for specific error cases.</li><li>OPT5: Optionally,<li>Optionally, specify additional identifiers of errortypes,types as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' (see <xref target="kdc-if-errors"/>).</li><li>OPT6: Optionally,<li>Optionally, specify the encoding of 'creds_repo' if the default is not used (see <xref target="gid-post"/>).</li><li>OPT7: Optionally,<li>Optionally, specify the functionalities implemented at the 'control_uri' resource hosted at the Client, including message exchange encoding and other details (see <xref target="gid-post"/>).</li><li>OPT8: Optionally,<li>Optionally, specify the behavior of the handler in case of failure to retrieve an authentication credential for the specific node (see <xref target="gid-post"/>).</li><li>OPT9: Optionally,<li>Optionally, define a default group rekeyingscheme,scheme to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response (see <xref target="gid-post"/>).</li><li>OPT10: Optionally,<li>Optionally, specify the functionalities implemented at the 'control_group_uri' resource hosted at the Client, including message exchange encoding and other details (see <xref target="gid-post"/>).</li><li>OPT11: Optionally,<li>Optionally, specify policies that instruct Clients to retain messages and for howlong,long if they are unsuccessfully decrypted (see <xref target="update-keys"/>). This makes it possible to decrypt such messages after getting updated keying material.</li><li>OPT12: Optionally,<li>Optionally, specify for the KDC to perform group rekeying (together or instead of renewing individual keying material) when receiving a Key Renewal Request (see <xref target="new-keys"/>).</li><li>OPT13: Optionally,<li>Optionally, specify how the identifier of a group member's authentication credential is included in requests sent to other group members (see <xref target="update-pub-key"/>).</li><li>OPT14: Optionally,<li>Optionally, specify additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme (see <xref target="sec-group-rekeying"/>).</li></ul></ol> </section> </section> <section anchor="sec-future-cose-algs"> <name>Extensibility for Future COSE Algorithms</name> <t>As defined in <xref section="8.1" sectionFormat="of" target="RFC9053"/>, future algorithms can be registered in the "COSE Algorithms" registry <xref target="COSE.Algorithms"/> as specifying none or multiple COSE capabilities.</t> <t>To enable the seamless use of such future registered algorithms, this section defines a general, agile format for each 'sign_info_entry' of the 'sign_info' parameter in the Token TransferResponse,Response; see <xref target="sign-info"/>.</t> <t>If any of the currently registered COSE algorithmsisare considered, using this general format yields the same structure of 'sign_info_entry' defined in this document, thus ensuring backward compatibility.</t> <section anchor="sec-future-cose-algs-sign-info-entry"> <name>Format of 'sign_info_entry'</name> <t>The format of each 'sign_info_entry' (see <xref target="sign-info"/>) is generalized as follows.</t> <ul spacing="normal"> <li> <t>'sign_parameters' includes N >= 0 elements, each of which is a COSE capability of the signature algorithm indicated in 'sign_alg'. </t> <t> In particular, 'sign_parameters' has the same format and value of the COSE capabilities array for the signature algorithm indicated in 'sign_alg', as specified for that algorithm in the'Capabilities'"Capabilities" column of the "COSE Algorithms" registry <xref target="COSE.Algorithms"/>.</t> </li> <li> <t>'sign_key_parameters' is replaced by N elements 'sign_capab', each of which is a CBOR array. </t> <t> The i-th 'sign_capab' array (i = 0, ..., N-1) is the array of COSE capabilities for the algorithm capability specified in 'sign_parameters'[i]. </t> <t> In particular, each 'sign_capab' array has the same format and value of the COSE capabilities array for the algorithm capability specified in 'sign_parameters'[i]. </t> <t> Such a COSE capabilities array is currently defined for the algorithm capability COSE keytype,type in the "Capabilities" column of the "COSE Key Types" registry <xref target="COSE.Key.Types"/>.</t> </li> </ul> <figure anchor="fig-sign-info-entry-general"> <name>'sign_info_entry' withgeneral format</name>a General Format</name> <sourcecode type="CDDL"><![CDATA[ sign_info_entry = [ id : gname / [ + gname ], sign_alg : int / tstr, sign_parameters : [ * alg_capab : any ], * sign_capab : [ * capab : any ], cred_fmt : int / null ] gname = tstr ]]></sourcecode> </figure> </section> </section> <sectionanchor="sec-document-updates"> <name>Document Updates</name> <t>RFC EDITOR: PLEASE REMOVE THIS SECTION.</t> <section anchor="sec-17-18"> <name>Version -17 to -18</name> <ul spacing="normal"> <li>Provided more details when early introducing "backward security" and "forward security".</li> <li>Clarified definition and semantics of "group name" and "node name".</li> <li>Clarified definition of "individual keying material".</li> <li>Clarified definition of "Dispatcher".</li> <li>Enforced consistent use of leading slash in URI paths.</li> <li>Fixed CDDL definitions and examples in CBOR diagnostic notation.</li> <li>RFC 9290numbered="false" anchor="acknowledgments"> <!--[rfced] FYI - As John's last name isused instead of the custom format for error responses.</li> <li>Clarified which operations are limited to group members and which are allowed also to non group members.</li> <li>Improved examples of message exchange.</li> <li>Added ASCII-art diagrams with examples of group rekeying.</li> <li>Clarified for how long nonces are stored at the KDC.</li> <li>Clarified that the KDC might not"Preuß Mattsson" we haveto store the 'cnonce' from a Join Request.</li> <li>Consistency fix: Clients always support the 'cnonce' parameter.</li> <li>Added new parameter 'exi' providing the residual lifetime of the current group keying material.</li> <li>Clarified text about the KDC knowledge of compromised nodes.</li> <li>Clarified the impact on performance of a one-to-many group rekeying.</li> <li>Mentioned explicit exceptions to a group rekeying at each group membership change.</li> <li>Explained reasons for delaying a rekeying and halting communications.</li> <li>Fixes in current IANA registrations.</li> <li>Added integer abbreviation values for registrations in new IANA registries.</li> <li>IANA registration of two CoRE if= values: "ace.group" and "ace.groups".</li> <li>Editorial fixes and improvements.</li> </ul> </section> <section anchor="sec-16-17"> <name>Version -16 to -17</name> <ul spacing="normal"> <li>Expanded definition of "Dispatcher".</li> <li>Added definition of "Individual keying material" to the terminology.</li> <li>Early definition of "backward security" and "forward security".</li> <li>Clarified high-level breakdown of the key provisioning process in two phases.</li> <li>Fixed the CDDL definition of 'sign_info_entry'.</li> <li>Clarified meaning of the 'cred_fmt' and 'exp' parameters.</li> <li>Clarified that invariance applies to resources paths, not to resources.</li> <li>Relaxed rule about including the 'peer_roles' parameter.</li> <li>Ensured that the KDC always has a Client-side challenge for computing a proof-of-possession evidence.</li> <li>More guidelines for group membersmoved his name after Daniel Migault so thatfail to decrypt messages.</li> <li>Fetching the latest keying material can happen before the old, stored one expires.</li> <li>Renewing the current keying material can happen before it expires.</li> <li>Moved upthediscussion on misalignment of group keying material.</li> <li>Expanded security considerations on group rekeying for joining nodes.</li> <li>Revised size of integer for building AEAD nonces for group rekeying.</li> <li>Added reserved value to the "ACE Groupcomm Profiles" IANA registry.</li> <li>Revised the future-ready generalization of 'sign_info_entry'.</li> <li>Revised and fixed IANA considerations.</li> <li>Fixes and editorial improvements.</li> </ul> </section> <section anchor="sec-15-16"> <name>Version -15 to -16</name> <ul spacing="normal"> <li>Distinction between authentication credentials and public keys.</li> <li>Consistent renaming of parameters and URI paths.</li> <li>Updated format of scope entries when using AIF.</li> <li>Updated signaling of semantics for binary encoded scopes.</li> <li>Editorial fixes.</li> </ul> </section> <section anchor="sec-14-15"> <name>Version -14 to -15</name> <ul spacing="normal"> <li>Fixed nits.</li> </ul> </section> <section anchor="sec-13-14"> <name>Version -13 to -14</name> <ul spacing="normal"> <li>Clarified scope and goal of the document in abstract and introduction.</li> <li>Overall clarifications on semantics of operations and parameters.</li> <li>Major restructuringnames in thepresentation of the KDC interface.</li> <li>Revised error handling, also removing redundant text.</li> <li>Imported parameters and KDC resource about the KDC's public key from draft-ietf-ace-key-groupcomm-oscore.</li> <li>New parameters 'group_rekeying_scheme' and 'control_group_uri'.</li> <li>Provided example of administrative keying material transported in 'mgt_key_material'.</li> <li>Reasoned categorization of parameters, as expected support by ACE Clients.</li> <li>Reasoned categorization of KDC functionalities, as minimally/optional to support for ACE Clients.</li> <li>Guidelines on enhanced error responses using 'error' and 'error_description'.</li> <li>NewAcknowledgements sectionon group rekeying, discussing at a high-level a basic one-to-one approach and possible one-to-many approaches.</li> <li>Revised and expanded security considerations, also about the KDC.</li> <li>Updated list of requirements for application profiles.</li> <li>Several further clarifications and editorial improvements.</li> </ul> </section> <section anchor="sec-05-13"> <name>Version -05 to -13</name> <ul spacing="normal"> <li>Incremental revision of the KDC interface.</li> <li>Removed redundancy in parameters about signature algorithm and signature keys.</li> <li>Node identifiers always indicated with 'peer_identifiers'.</li> <li>Format of public keys changed from raw COSE Keys to be certificates, CWTs or CWT Claims Set (CCS). Adapted parameter 'pub_key_enc'.</li> <li>Parameters and functionalities imported from draft-ietf-key-groupcomm-oscore where early defined.</li> <li>Possible provisioning of the KDC's Diffie-Hellman public key in response to the Token transferring to /authz-info.</li> <li>Generalized proof-of-possession evidence, to be not necessarily a signature.</li> <li>Public keys of group members may be retrieved filtering by role and/or node identifier.</li> <li>Enhanced error handling with error code and error description.</li> <li>Extended "typed" format for the 'scope' claim, optional to use.</li> <li>Editorial improvements.</li> </ul> </section> <section anchor="sec-04-05"> <name>Version -04 to -05</name> <ul spacing="normal"> <li>Updated uppercase/lowercase URI segments for KDC resources.</li> <li>Supporting single Access Token for multiple groups/topics.</li> <li>Added 'control_uri' parameter in the Join Request.</li> <li>Added 'peer_roles' parameter to support legal requesters/responders.</li> <li>Clarification on stopping using owned keying material.</li> <li>Clarification on different reasons for processing failures, related policies, and requirement OPT11.</li> <li>Added a KDC sub-resource for group members to upload a new public key.</li> <li>Possible group rekeying following an individual Key Renewal Request.</li> <li>Clarified meaning of requirement REQ3; added requirement OPT12.</li> <li>Editorial improvements.</li> </ul> </section> <section anchor="sec-03-04"> <name>Version -03 to -04</name> <ul spacing="normal"> <li>Revised RESTful interface, as to methods and parameters.</li> <li>Extended processing of Join Request, as to check/retrieval of public keys.</li> <li>Revised and extended profile requirements.</li> <li>Clarified specific usage of parameters related to signature algorithms/keys.</li> <li>Included general content previously in draft-ietf-ace-key-groupcomm-oscore</li> <li>Registration of media type and content format application/ace-group+cbor</li> <li>Editorial improvements.</li> </ul> </section> <section anchor="sec-02-03"> <name>Version -02 to -03</name> <ul spacing="normal"> <li>Exchange of information on the signature algorithm and related parameters, during the Token POST (Section 3.3).</li> <li>Restructured KDC interface, with new possible operations (Section 4).</li> <li>Client PoP signature for the Join Request upon joining (Section 4.1.2.1).</li> <li>Revised text on group member removal (Section 5).</li> <li>Added more profile requirements (Appendix A).</li> </ul> </section> <section anchor="sec-01-02"> <name>Version -01 to -02</name> <ul spacing="normal"> <li>Editorial fixes.</li> <li>Distinction between transport profile and application profile (Section 1.1).</li> <li>New parameters 'sign_info' and 'pub_key_enc' to negotiate parameter values for signature algorithm and signature keys (Section 3.3).</li> <li>New parameter 'type' to distinguish different Key Distribution Request messages (Section 4.1).</li> <li>New parameter 'client_cred_verify' in the Key Distribution Request to convey a Client signature (Section 4.1).</li> <li>Encoding of 'pub_keys_repos' (Section 4.1).</li> <li>Encoding of 'mgt_key_material' (Section 4.1).</li> <li>Improved description on retrieval of new or updated keying material (Section 6).</li> <li>Encoding of 'get_pub_keys' in Public Key Request (Section 7.1).</li> <li>Extended security considerations (Sections 10.1 and 10.2).</li> <li>New "ACE Public Key Encoding" IANA registry (Section 11.2).</li> <li>New "ACE Groupcomm Parameters" IANA registry (Section 11.3), populated with the entries in Section 8.</li> <li>New "Ace Groupcomm Request Type" IANA registry (Section 11.4), populated with the values in Section 9.</li> <li>New "ACE Groupcomm Policy" IANA registry (Section 11.7) populated with two entries "Sequence Number Synchronization Method" and "Key Update Check Interval" (Section 4.2).</li> <li>Improved list of requirements for application profiles (Appendix A).</li> </ul> </section> <section anchor="sec-00-01"> <name>Version -00 to -01</name> <ul spacing="normal"> <li>Changed name of 'req_aud' to 'audience' in the Authorization Request (Section 3.1).</li> <li>Defined error handling on the KDC (Sections 4.2 and 6.2).</li> <li>Updated format of the Key Distribution Response as a whole (Section 4.2).</li> <li>Generalized format of 'pub_keys' in the Key Distribution Response (Section 4.2).</li> <li>Defined format for the message to request leaving the group (Section 5.2).</li> <li>Renewal of individual keying material and methods for group rekeying initiated by the KDC (Section 6).</li> <li>CBOR type for node identifiersappear in'get_pub_keys' (Section 7.1).</li> <li>Added section on parameter identifiers and their CBOR keys (Section 8).</li> <li>Added request types for requests to a Join Response (Section 9).</li> <li>Extended security considerations (Section 10).</li> <li>New IANA registries "ACE Groupcomm Key registry", "ACE Groupcomm Profile registry", "ACE Groupcomm Policy registry" and "Sequence Number Synchronization Method registry" (Section 11).</li> <li>Added appendix about requirements for application profiles of ACE on group communication (Appendix A).</li> </ul> </section> </section> <section numbered="false" anchor="acknowledgments">alphabetical order. --> <name>Acknowledgments</name> <t>The following individuals were helpful in shaping this document: <contact fullname="Christian Amsüss"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Martin Duke"/>, <contact fullname="Thomas Fossati"/>, <contact fullname="Vidhi Goel"/>, <contact fullname="Rikard Höglund"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Erik Kline"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Watson Ladd"/>, <contact fullname="Daniel Migault"/>, <contact fullname="John Preuß Mattsson"/>, <contactfullname="Daniel Migault"/>, <contactfullname="Zaheduzzaman Sarker"/>, <contact fullname="Jim Schaad"/>, <contact fullname="Ludwig Seitz"/>, <contact fullname="Göran Selander"/>, <contact fullname="Cigdem Sengul"/>, <contact fullname="Dave Thaler"/>, <contact fullname="Henry Thompson"/>, <contact fullname="Peter van der Stok"/>, and <contact fullname="Paul Wouters"/>.</t> <t>The work on this document has been partly supported by VINNOVA and the Celtic-Next projectCRITISEC;CRITISEC, by the H2020 project SIFIS-Home (Grant agreement952652);952652), and by the EIT-Digital High Impact Initiative ACTIVE.</t> </section></back><!--[rfced] Terminology a) The following terminology appears to be used inconsistently throughout the document. Please review and let us know if/how they may be made consistent. Broker vs. broker code point vs. codepoint b) Throughout the text, "ACE Framework" and "ACE framework" appears to be used inconsistently. May we update all instance to "ACE framework (lowercase) match more common usage in previous RFCs? c) May we make "Observable" lowercase as it is lowercase in RFC 7641? Original: Optionally, the KDC can make the sub-resource at /ace- group/GROUPNAME/nodes/NODENAME also Observable [RFC7641] for the associated node. ... * The KDC SHOULD make the /ace-group/GROUPNAME resource Observable [RFC7641]. --> <!--[rfced] Acronyms a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Authenticated Encryption with Associated Data (AEAD) Concise Binary Object Representation (CBOR) Concise Data Definition Language (CDDL) Constrained Application Protocol (CoAP) CBOR Object Signing and Encryption (COSE) b) Should instances of "AIF format" be updated to read simply "AIF" to avoid redundancy (if expanded, "AIF format" would read "Authorization Information Format format"). Please review and let us know if any updates are needed. --> <!--##markdown-source: H4sIAAAAAAAAA+y9+3YbR5I3+D+fopY6Z0h2AxRJ3Wm791Pr0taMLWlEaXq+ tb06RaBA1ghAYVCAaI6seZbvWfbJNq6ZkVlZBYCk3O4e8/hYJFCV18jIuP6i 3+9vfTzO7mxtLcrFuDjO/qW4zF7Pq49lXVbTcnqWjap59pd5tZxlT6rJZDkt B/kCvsqWNX77+Mmzrfz0dF58XP/VrWE1mOYT6Gw4z0eLflksRv18UPQ/FJf9 M3x+AI/3x/miqBdbW+Vsfpwt5st6cXRw8OjgaOvi7Bj7zf5azT9gN9TFFrR9 nNWL4Va9PJ2UNY5hcTmDTl48e/t8a2tQDeHZ42wJfT3cmpXHW1m2qAbH2WVR w691NV/Mi1Ht/r6c2D/hyWExW5wfZ3e3tvLl4ryaYwP405d/s6ycwvPP97PX +bianJbT0n3Ds30+z6eDoh7kiSeqOYzt2bwc1DWs7eM/uy9qGFYBM3tbzevz fDKtz/JFPs2O7rgnBuXiEha/rBe5/6waQocnz/qH9+/ePchOYPwfzqvxxDyw nC7m8N7JRTEspu7zYpKX4+NspEPdn+lQ/1cho9uH3UnP/fv97G05rgZ5NPHv 8/mgir+iGb95cfIsNdsXdT76j2o+1NkefdHZTnB8+wsa3/+al/t1sbU1reYT oNaPBe7zm+dPjg4PH8mvd+4f6a/37z860F8f3HWfPrzzUH59eHh03/364K7+ ev9QX3twdO9If310/4E+8OCu+/WRa/fRgXsWfr2jv8KxcL/eeeB+dSN7dIeH 8+TVybP9x+Ozal4uzic1E3BIzLQpLx6/fEx/D+EEAi3kY1gQ/FtYBLaT+Xb4 q3x+hht3vljM6uPbty8uLvbLfJrvQ4u3cziNZ9NJMV3UtwdVXdD/9n8+X0zG t3LbDo3w2yIfFvP91/kciGdRzK85UG4u881db7zn1Fx/ZpujYQP3238LDOea wwUemFEz1xsmslJkfzi6P796s/82P7vGwKrpoKyL7M/lNJ9fZq9O/6MYLLI3 xWxe1NA73we72M9ehh1tOPTTat5fwGv+N54Ejr16/Hoful/Ak/vP6UheZxqP X2fSWF8a23SV54XZ+vhvWfuBdDGSLrbK6SjmJgeP7vhflS0c3T/S43vn0UPl G/eOHjpmcc8xoQf37x46vnFPP3145H+98+jIsxvDLI78r/7TB45v3L1D7b7o P92ni5nm6G/l07Jufl3V4VPNJwZVPuvPlqdwOUdf1vAl7nsxRTY+7A+K+UIf YZYc9DEs4d+PBTDzrS1YZLwN4OGTZ989P862f4AJ9P8dfn7a3trq9/tZfgo3 Sj4AKeLteVlnIHgscSezYTEqp0WdnVcXcLeDLFNki/MiewxEhY2KiJNPh/QR MKj/4k9QogEKwkbh/WH2bPqxnFdMHdkuCCV7eHVOigsQTbBhGO1iXp4uFwUe bBRWgAzgIs3H1DhQyqg8W865cU9I1E9dDJbzIqNFzQZWgNrPnsDbJZK5fD0p Jqf4HkwVO8nr7Mm4pEFhN7nMAQYMY/qPqoSpabtwuw4rEH+y00u4xKFzaeIC eDI8hTLdU50EDvJJgQ9lu//y9Mme6e5NUVfL+aDIToo57E4PlqGaZBfn5eAc V/Yyq04XsGS0yvFKwJj89AruuYIH5+Hk9rO/npfjgvcOGzgrpjDcMXxf1/lZ kcl5w+FcFOMx/ovd0axGIF/SWlSzgpcbnvsIt39+Ck3mC3oS5tSDXyyh1MvZ DERD+KQcjYo5fpTPZvMqH5wXvLjwB8gb1Xj1pr2FKRXwUNGDOcBqwCv5HOcz LkDM4c2pC6QCWAXoZax0CF2MYOZ1Vo3C4fVwjvWsGMAy0vaCGLYgyQ2ew0kR Y4NthEaBqpfjfJ4ampsSTYjPBh2N4Kk6k/3jFnDoOHe4CorhPkr4MGDsO5sX /7ks5wUfClqUJTadmhA2Amy64kmMSmiJD+6kHA7HIIbdyl6A5FYNlwN68dOt Ev/8HJ/n02U5HsL6TL/AMfZr4vgFzhB0k5453z16DgikuNjsqENzsoyOkIuf B+f59KygFc+TO1b4EcOKrWYHqC9twBKUE/BhpLOxJiPAjiJmICtTz2DFSzxu uPxEn9RhD2cJsj48CEMxfGJaDHBBQOJILWi4hGsxkK2tF1NzFOKzrpuMfVs2 MR1aHpJkGobltHElnnThmSy2fVosLopiGmwNNLifPebGa5giiC8TIK+us4hb Ni/Gl3gAUoyqlxX7Z/u97DSvYcPhoclyjMejXmSfPnXc9J8/w8bg83Bzj8v6 vA/Xdz0AEihkergrcQvmqv/8mY8Fju/UsAscvR/nRX6Je2PYY7wvzCBrxzbl nEdMDDoi9gsygWXSy5o7VPpexWWJUYNAgLwpzVubbJgZLR2BzXktvrYRt+3F V5xwz8FmnGeGtpohc4DEQXFHspjWeKcN8PjWINkOLpmFlEPqfFh8LMbVjLYK VqaV2feAUoBxIk2NWk5enk2XOAJ8AuiZLsVB+mLZz6KzTI33JzCyfFHNL6Eb fJNuGRxlcCkR82m9kN48+9d3L948e4pzHy3H8MX4K2xDaAKItJjPedlOcSky WES4beD2ErYGdIIiA/GhbWhtGwcLK5cPdZjVDLvNx1cc5feP//cNjOzV67fb sNUvEzdWWROfmgp1wNlltoYbQnTr7j363tPpcobchcnovATal4tsd15wH3uw FiN6wc5M5g0MMR98uMjn5iTvlvsFsC68V8PLbbIE9kVcBQhwiiMhmTMf4K2B s+k6T7N5Wc1l6OWcLkAcHLKeAlmFDjc7z+l+qQYwnKxAxYP4MY1HR0LXp2u7 e4LA4JLzw2sivrCuN8V8tKBtx/mNi/zjZvODP4k561CwhQJvAyS04mM5cKPx E9/aeix9u+ZrYMHQGtymOEEmcrj8lkBjQytNVCO58hu02ENSdu0R25ehhWt1 wRPDFvg2pW2p/fD4KuJTNslFhUg1Ia/TjGu7ryRzrr5ry+lgvERrc1aMgCmX fqzRstTCLGvgCmIUwBtT/7ir1yd/cP/owefPKOwpH17AIOgkX+DRhqHNC6QH PrVCCiiOOVE2vljhZqzJPMQ9oKURGBIKKsBD84w0chjtfvZtdVGQVsdG/38+ efVSXjm6h6+UzN1wF6k56GRW1STsyfaNadru3p5Ca2ihh6UHOXToxX8c96dP J4XIR/f3D2kF7u8fYeNukLAMt25lb4v5pJxW4+rsksQHMp5doNk42/7+3cnb 7R7/m718Rb8rY8ffT759/N137pcteeLk21fvvnvqf/NvPnn1/ffPXj7ll+HT LPhoaxtY8jbvFvLVF69ePv5umzfBrjgeHuanJAbCuSaOWm8NC5araAH+/OT1 //d/Du/CQvxfYnmGNeY/0IgMfyClcm/VFKmA/kQ9ewsIsQDJA+UdkA8G+axc gILFiiIIGdMMpSxYvq03ZMjkG6/4ecZyGY9tlE9KuHLnRF3HW1t/QIkog/FO apUoBsUMlWI76ga5MYmgeRpGzFK0U8+8LvZCjWPwOxvlQAN78XxP374DVE9S yM9obqyd5sJvlP7tfTdKoQmiZLIRlYXjjSTFwMRx2eeD8xIlKpRucJdICqFh vsIxZkf7BzwKtO0D0cUiB+0tn/ZCLS7Z7hPgsrEGtPvmZK+XUET168cne/vr rjOZMWlY6DvAYb2bjnFlSOW5QENtCeogqkJDIgpqMdsGvjADjrjYxrmSUIyk AIs0HlcXeDpL6IknzmIpjhAGDbfBEJUdECUqEnHnMjnPvm4vqg8FS+C3SUHH 87xQDenxCU/9Nm7df/Vxy/SrNyfCVb0oWEG70JGzydF0/YCQDfip9MTEBC1s P57yZl/KHpWznIYrG0/tqLFme/3Vfvr0O+F19w8PkCPHDJMnR8Z7JtkD3BX9 9Y7+eufOQ+Jbj2F2Qzn/RS2Hzo8Yv0nrDV7kz8dzOLzxPPGL4EJTKW7OQhgo rZe8icRysm0m2O392JhCBhm6G3DdPH3QUtHCkcf1GLqrC5L5cUYir9bn+Zw1 MxhzSh1xgo/RRIgajSGEhZZIuGG1fopmPKJ0pBy69wyRkwRMAk2ebbueaFFw nlnG1EbPlkxnzPJQSaJRsN1zmm1b6Y0bUGJDkQlutOIjKSVCyfbxMWpENNmL 86ounHzBa5Pr6syqasyajp6nCifNzo7s2c85KD6sbTbGwmybVD/eAWT2vAvD YjauLlXlJQPC7PyyhtfH2byqJr1MDBHB3s2LM5QpRHnIUeFHZR/+mJWDxMoR jbQuX7btDQxrrN20WNB90bZuOLkxiTw8OCZyfSsfDuliQG4PElBRfiSaY/ML LDqSNAn6anDaz5BV8PLiCkRjxek11od1MdaCSZvmheL+Ct+be853K+LjDhqm 62pQkhL14rXpVmagyyxmn5B8s0l5dk7KgGmFVpvawak0qQRmCvvU86akxiNq mmltNBwFtPh8OSfTmjNhM+ukS1VOqoh5E+gNt0KNXHRKz+cF/B8dnLi43rhR LReqBNSDalY0jATEeDqtkMf0ttwBsb1xkk/ZXIUcBP/WCfK8ejxtY7shVlIg lQYKrtFtVZ1I+DPw8sJehaF5VSPkaTAnWc5Jwu5FLHgbQyjqbRzyttfm4QNs XnkBDITIlEQg4JxeL5kUOSo6zC/q5WSSs9H3tACm7nm5BGog7RmTAfIVpzvh 7bIofkYbwpx0G/bX4Rfv3j7vP+TLD2MjUCR5hQsH11tOdkMURMoF30cfYQQ5 MrgXCyeIyBXdYRrtOSnizQkusIzyUgcIlK5sAemcOBTaFTNY7P9cAn0Dwz0z 20irqgRX/Awk5fYI3xkWc39o0CBLK/Xm1bvXLx9//+xYJAe/GDqLd29e1Onh rbEgrn0ZNFzXcITqkP5oesHGjEGgXJ6Jm23IXFlN5yW0MQBJaQADMrvt95jP TLjnvrOYsiNTKkme5YdgaLhFbiIqIvvm1R6ELlwxbJPW3d4n0sgMfRtDmsBL FJ7aqRWPwYbE6jkYKdXe5VEXwDSAHRCdwM4Cd4Bv6uJM/EQ1cDKnq2Z39u+I ioq++8+f927+EAj9h+bfgNhE8PP0gediqkvWdSzcQ+5UqJmFL0BcFbPztBWv nj7b+DgkRrjWMtXZx3y8LBw1136f/Pxk5OYys0y7KegOhyXbYeGYtAi8okuy FjzPpzW6g9USiyKw/Ip9o/YLWzKD+Xm6uLf/cP+uow3WhnFXFnFjzghSJ5wb qrgIsdqvvECtzyjVwNXu/X5MPLGb3lASvF6N+vAfmm6K2phn0KY1wk1x3vDU s2yVzEgVRI/TYrDfXLFa10nUZjJ8OtdKz5kMvCEMI1YCQxhGqJAm9YfscdM4 breEhDHrujXiTw08AbqWqAC8r2VyZJ7TJa1hmUp2pxeXasRVB5H7cpJfts1n ZuJhe9DAx4q774VmdFFsI95HgmrCAUAdipveuX7gu0ExXM4lLCFyP/JyhX7x wbygc5mPj63Aa0wqDbEwVx3bWjlpmfljEHLJVUieqNhNGzeGffqnI42nbags yZAO/tfiNHtL1JbtPvnr23qPFfG/vgWKz0vQ6k8KZNNPnpzUYk3CmCikpX/f v3fwKMNII1w6ci3S9xhq5RT6xCMrwpaEKl9Mh6CDDNHGHW3ocbC4wCcWYocu fobFrEGTAEZkVBzmW3yfRYuHxpqkRKp+MzTqk6C+wnlu7x5hyM/RbsabITe4 aglNjxITzmA5b+VYxQQVUroHnFxjLgTi3k3bxS57rEFZnl/OFtXZPJ+dC1mZ IbgGU7QV2kKmGcVswND22FLoTs40JwsgrgtvDp+Ctk1sOJRD02Fn4I72aQyW HR35S9JYdFC8M3ts1l/XAHv2OlceOkqc1sJSrTtzoJihFIlqWNNkLbZXsYjh 2RuW+dm0guUc4IC4T1x4fh9Yb35GPfGlzRkCpVN6bmWvPiLzLC62th5jfNI5 KLes/vdUpQpYJ3M3uF1wDcV5z1R7UWWz8xzuIOZho3IOCjXqeHyN184s/dyZ pds0C1iRr3Q9KzKtF2oLEJcVDivg2Qn5jMM31PdmBijmA1xuZ5mV91AuQ0W1 aQk0MR72dPUyWE1YN9CF4ckBHnNmwLC4//3f/53lef3xbGu/b372s/An/HLr F/rw8Qn980v40J/ob5gYf7m1Y1/d0WflpfBLic/9f6POf9kK3ml8/rHxeXou 8fttE+T5yWrDa1+Hg082/ov5+I9uhfTLr+0ruEJmK+RL+DBuI71yWWrl3Id/ pFmy4uZXaLMfbMWZ067YRjjAHaQz/dn6dJzdGpVn/XlFvATjrb/ZbhhrXitt g/q0DceB7Hf9fFyeTb/ZHpAlZ/sze/K8ED4zL6nO5boCNQtYDWig+JSel9BD hGcyPrd0TXt/zTFfQsQrL6ifOCaOmKbtJ2Wh7whcZeXJuKLN4ce79Ryd695q Q3NzIlvSXXSsmgZ7WOwN1OR4xhFHypWIvrXK7LNqjH5qMV8ir+cgL1DNaTpy S5P6CNsSBg2C1DI1y+Q90kwMJJOg7bLWO/0CRGu6bm+TxTYf7q1j2xO7Ho0Q 3fcoOtVt9jd1JKSMbj0N2/1IamRJZloXgJeMi/RT3M+eLucaiMCXDZGEsySx gSPb/fQJbpE+Ngc02tMbl4hIQn2qsVNY35wk9y3oTC4l6g1axwQPImlq3nnB UDpwUX6NBv04fABPcg3J1anqsX/LLRp+wPl5qdVPRFVIxCyOa07apOhSQwwP iPwnYhJqSLdiOyJi8dzWUAZJMD7o3G1qIzjU36rUU11Mhxy7p1qTC34aNUzF /lQH7ifD/u3asocURYn+osLotEvXR8qsjIfa9T0HWXFWcrDb26gL9ZIS43Ca d7sZDS0OGLsxLvqu2fRsKaAARZ9AakSN85Ri1eEsyLblY2h7SmktZGdWI/q0 QlG0ZBXYxwj54bOjI1D37ORATmJh7s9z0O44lsE5pEBJRRX9K4phGueX8L2z hEf8WNR/GrFXlsRRk9d+X+mVemG8OBX5nIKt+Yq0H4xFHJSq7vJ2Id04X05s m6HREkXPjZuIvHdoG5mUi4X63HwjL147rxZHieqqy6H2tiM8E9NizCv6gow0 YsrkdUVHVzhk9dn7JZVlxtguRxKytg3aLuk0oQAu8ir0gLmVSz7b0z7ZSMmG OSlASZhfMrvN5SiUgbCLtzl5igJnHZCWntzw0oQjpT7HYUF6IX47EbU3H4rf eDbGCHJ1pMZGP29lw9ni+pX1BGno2N63zA7khtabwJ+umL37G4UDKWI2s07K Cz6dkB5iZs9igUpHkX5ILklgPqBJtfSMI8ehY5P6YV/eoXhUtrOxyR2fqjfp s8NsA9TYMjsdjhkFm3L4Iscbh8iMvQDtfWBbMm4kbWhyjaFzXGO4szgg+qsv cZPazjOMe0y0E8ZB6pxQZoJJTSqeErXwBhNEqAWi2b6XSgP3VGPXXPishvJT oG3evB6zFJ3yZLQNHgvwizc2qlImlJPrFDgRM7ZFMQE+gzkYk7ImSV3jvFOS V72ozJXu5dno4nzqvqhL0KslvIM4pLM2nWMgG0vvlHSD9lexQsE8h2OK38I+ 6sFSLRM8WTvQPo/QUTpZ6Fh/GAFJALk7kcYaIcg9heYJnaizpsJLdN+IRCxx w96X8TZ+WMYMXDifigdKLBMwkkN+QVuhJkVSQs4fmNQ9kaG9wqbMyFPq2K40 /6xviMPHmPi0FV5ccnE79ha7TmoT++GE24TVAzQQirQ8VWvU0OemUVyn0ETT 6yH+ADKqtZlT/mwlWvHsF+GCLOJ1vCjhBndeJQ2tKafLQqJY87Td0lrRfPYT GcuOEttFE6Kgo7yZddYaq6iyGiUP4dJIK07a5zQopBdDAhIrhzapyxkG9KDh c3COnHfI+ZveJF+ExFNy0DeRVhCbYoPyNKzO0AhvP3noFgENiCBgbFnBshAx sHC6epmN7y9YclgaSgiKj5lz0MM43RhDElUrp7cjpEZRB7Ephur0hNA0ODa+ pOMIh46kWjfMqxB0zwlhJF29/e4k0YxxftF7r06evHrzrOPBO5xZA33DgtxJ kKokf9i9UrMqRXHB0hSBh9aKXpdGS1I6EhJSa3Qr07H0FJ7lRIrExCXCqVXC 6594O0kqgaMFvdVojJKlQlN2CSMpB0hw75ZuKunUAtUsebJhZkPTfULUKPl7 xXSoCxkteeLMcGwcBZSZ1AqyGpwXgSNtOmyXK5nOKe5jPQHTBolhZzgMucjt jRB6FWIrm+VtbugBB9JjJedQvcZuZHYpYA3vJgjYnkw1AbU4QHq0FOzRdbkI 2Wi5aPIAdecWkuw3ds5cshtS4FjBUo9LCvUn2AmtuM8qojYcOXMbq1sFYYyO oIQwYO73EnNHOcLuqNvmrq3VhI2UrOay/2ANQXmbZXcwK8AaddXs+6TLJowe A/UMhD9ksXaNdFnq+dvUE9/zPKSV21dsJXMmb/j2l36/H5lV3wg/E0/H6iZu YBRfJ0Yhck2/39nE7h/2sq/bH9hoFDfQBC4nu+E52gOkGLOg6jy6+ih0JN1N oMelOQpeUPJXdDeR/XjttWh/YKMmnIMl+2eUye1K9tdYzhsaxRpNwAj/EjIw HNzmo9jVXNi9xii+jtfCHRD5+a2sxY01YSxtmzSRarI5iq+/4Z/spBWkJPtG f35xv629qZ2jILb1tOmkctliSX8iqdDiTvxe1Orn+Nk7NH9g5jLGg+7URCBA gx1exVsRu4Ur+J/ZvcNk/OmWs+iJybCWCD7NByJzJIe9i26hwSLOfqn6h9N3 A++lpqiGar4z3keOprexvuX8OrhuxqWHSUVBCErg7rOaTf2hVn+hwlHk8aJE lk4r++I9Lx7YWhfLvduXGVHkq2RAq6KAJl9MkP0o6eOR7IjG+XzqFEkYXeBo ktFLasmq0MMEOEi3SLxqVsx02Gj2ZG3tMWkQIf2RBLLKJe3qvgnBcCpUi1LJ cmEIYRZoIGp6ovScYTED/cOlY6xoOQj6Khcu5MtraLfzQfFHDHpzxMMOUAxx 8Z4N3F7zzuBi4R5fnJdzF5moTkuGQGrnC4wM0q5ny1SbABKaoGJ17Q7EEI/j 5BOZAvJ4jAbJYfkzyMPQujlje86maDXgPqdUscIAqjmebTLqxbZFd8R93mF+ Cg/th9K4C15Z/4ejeWACWxvzbvcCMX+SStJC83H2+hWQuWSAhkLKL9fu9+tU v3wgjzE99zDbfTIvUOfay7xAcP1++0lxMpiwsZu5Wd/MfFvE2OSEb6Df1L3b SsjJyxgIma7SYKO6ruL4LlYpF+7g9nuF+UD6RbJoOruDd9sJJy6j69HG5h8G kfnEExBeBY3Fal4IgpHkXhH2xZHxbC4ADu/NnkZAMHGQgUXcpWDtUMbbTk++ dC6ZIB1DcpNc0K1M0skRzhEguAAzl9mg0SbdL9OoacKYetkw/ruZ42KadJqc 40FPL9EmQdkfytgv5pi8JN/n83l+SfBAlNwHnc/LgkxPLEsFH3voJVqo4NqU lFZeWlh9Ak8pSrJ90G6/eO4EM7l1ip8peFM+dfetLD9M8A8qr5iXJSsH2kas Jj+8y2j+nOzhkAp0RHk08x9/eFuV0NpbeH7y408kIeVBsxpjW/u0atm0ikPP bDiahn6FIFTkNyBsVhMivY0db0fJJVHClkoqzX01WT20r2OmbJwFY2zTWLdp WnEnaZq7QDt/MKvIdJpxDmy4F+RPLEY5OiblU3LDrR1szacCCZkSO3OPQ1fV EvqXlxPx7VGIw2DhEFAc4XoPDFzWJbdi7IatQ3I4XzXiqFAmNiFiOSlDFkcs lRhYQtDmQfgRr+eA4LgpG44X69OnwXA47hc/95F/IchHzXEfnOCsGAYuTNuA GYjTlcnQJUD5lY+OR3SSOo9IQP38wiJ2f9Lw4X6vRZAsxoWnZE+ivW669A29 cjyPnY8cMRe0ylF384gpbU6pop1x0zhf5bcYZTXQvUJ/BfHVU9QSgPL6jCbs Q/c1Br0lwwOIBSiYyIyPNAiqJqgC+aeLwcJZxz4VNwDlerlEgfUo7av/YYqQ MLQoTkhnzFD13exKWk2+HJboKoa/dcEd4a1FdklSCylKzkPEnGh0JvXZUkNM C0JVnFXpcNwiBIVuRkEKI9/DIp4jJzBXeYMpZLvQ0+Ge8gbFg3Fnnj0UxNGd J8LHxi4oZsnMr4HuB7cfa6FDl8oql+GydmQZXaD2ynTKHz9jj3YCqUzVqwQ7 0MRMUrksSp6iRxDNurwazYIjyBa+hQgfiS+LFdP8HqPHCAmds7ECnbdng5/P liUGyE3ZPmNRg3BfjvbWn2lMjTBbFAWDNFElDaI8kupqm/DvM11k4xvUu/vq 9dtDDgba0UO103Ppdc1UbPZwd1h42PHjR2mtH6LFq4SK0qqDVQ0VTPdD53br q1vOCzYfDXBBt7bO6Ex+ky3gsG1teRmghs+WGDewf4oEQLS9tcUk/k32T7sc a8QBwPPj7LDHH9Be4wdH9MH31bRcVPDnHfrz34j14dd3t/a2toh23yt9f4NU 2f8LenvLwddnfEuYAf1JXoAHEQE82yezRdBGevKkAbn7VLWdZx4sRBmY7q8/ HajZtK9nuHZEFfqHH9YlfPZDxo/2sv8722XyuQ0fHv2Bfv0p28t+aq7GD3BJ 22Z+WmP+q6a/xuST7DtJ9YZnW3bdog2Knb9FHRSDnOiDJ+o4VXaVVBDzDg3w KNAAe1ago/v30iW5GuGgjHMF1AZ5blUXUdr8urgweBEA0TPsZL4M4XULia7D Wg6EwzrI60KAVbGH0XIsYoEKtqlZywqGevHjk1DscLx8zaXZz15Wi8IvhdcJ d0B7QXjL9+V0h3gm8JxKYpvLJucN4LTpjoW31b4w0eAiNdVGwhKlvjHPk6hz zLim0GcfSISCouoLxKWRhRo+LjkGXnNv0fMjjT68o5j9HxsVnuE0zwurpDaE Bn02CYf3xkGL2z3pMreLtT3W0TFQWgp0qEBNNnY5xCi9/ueSQ0ZIcZxa6lzd KZ++lcb4XWhphz95T5/ssHFzjxd2lZWF1jZn0CUNLxlgcjeZZDnZXiXOncF0 tJMm5TvOyoOFdQTj8slf3+59Re1PGwTY2gc82N7H/l3thfLMo15k4VubFqow SFxB+w/3D++Gpipt3lhpuPFQDWfgJ94UXG/gPFGOv1KiDsHTkYggae7S06Md 0J3QXOSRcC6hbhpNjf9mhy6nC0buOhbFR9kFb5Njcmw+pMOj154qbShM+Rnw Nvz5UhvS1HmaUsAXHDOQD5uDvynWwNGbVi2eBmk7cBW7zB/xZfL0wy6gB32y T98jbjVLlqhYiOYjbWjCCQrLoOti7D9rQIqmo2h/iujJm0yCRPteSxpJ6EHj RC/oWlCMT4m+/IiKKarOeBfEgJyUgAG8fIDD1CjI3IffWSbW40uy5Kv42Jkb kAHG7WKCkIYwSuhebnBTklhtqwxXLG/5aHreIbeeX0kq5brjGgmAm4MvOS0u 0U7C421Jplo5CjEKvEidOh0DrMkF4xbmgjJAy1C41LV41DgYn84XBjSjFa5e Op9xqkPB8FUk0asTu9x2wQAamqHeZSyaDBiCxLGRVv+lIoMTH+J3nS3JlJba 2vor51EqwGE+bRF1GSLcOUE4qZn48seyWtYoaDrBtaeoF2aZgeHVCwyepyBQ pGOQc0pEmJv2WcyLj4f6u2FF5sXMxyTi1Dlu3cuNbEHgMgxthwCXBb6eoNWN Sg/Qm1hqq6odE7bXGu+IS4oc5Ljl8PySJec49FHd9oxstTuqArgTtmwip8Fk vzAoXRqEvRzCIk8rKgdh9PE77A1GbOrAiUdx/Z9u0ThpFqK9yCbV5KfP28Lo bLKAuBcYzpY8kS7Ioj36n9PXtUTFQsI+4qj/CNDs3v7hQeQdw7lZFYAwx7n3 IVk9EOBetQ2UKNtMFmwkLRecT16ruVv97WRJ8fYMe+UTSu98aufRknDWiMw2 tSw0Lj14O7BIjbxmVtixSPkAezBxI8PkB2QN9QcxqZJNMBEdzbeDj64hgk5T AKVjS2pUXfSsYGUUlCguBDXJ8JD5AI6kBAsS5v1IFdZoFu1sll+Oq9w7jALD vpjmJ/lMXYD0mJqRYqqUYBZ5pclP7XsJ3eBmHbAgqLzHXYqEe/ycTgkRbeid pZHXdLFK69vT5Xi8ne0e/Dy6v2fqRIUy66li5JB0xNBDWgSz1/ZF4HkOnyGs HPOt7llguO6G1GoclaYzBCUs8mI0ERJQtQ7dEJzqayYt6eMzKg/kAHQlMMme HboF5WnNKk0nmzdgqqJD6FwfkjBCoWdZkc/HiqjrSgl6ARAd55p5hS2Oy+kH Zb9xatyKTBfMQDhj+Ay27S4cKAAH+sxoLgHeZliqh3VETvdk7LGueojMnRl4 qNNU1GbAUixjP5z43gxYF65VXPjk24JA7/QRFAaMdBfG8bVEufgbjq+4KOZF rX/CdlsaaWeK2yl2KIUb0HatDK607Cy0e5Hz1152cSRfuvSG5remEhhTt7Fp MK+5ZMYlE7cb5HoXdiPSQFM9rYRgs+LJeCsil1StMdtH8ZSyWug8bE/H9mIL G9v0ePIamJwxqUqzCK6D+OowxsYPw8HgHO6IYnpWRAzbfhXxbDQISlmEzD2T vXx/YmobSRAmu1y+y+WaicYuqdUmZNTl5wt0TV9j+hz2iyyeczVFc5DbCbWw tNiDyi3WOGwJgN19Xb3egxdmy4UPUcB9Xs6nTt9GgRYrkeYZPI01fIZ8XGPA FFZ3fQiu30abdUzhvJkZA4LmCU3M5uXHnGue8jrRlAfU+nukkPdsWI9MHp8+ nZVDFo+JcrneJ6ohKanW8xmiFdJWOtY2ARCo06VaP3BNL4FuxyiVCivEwxBk YcQRZhvQABknFPeCZ08t2a3wOVlDj/tDPNYlDfLlvmzez7IRBGjU2AQWtQj3 p8CM3S4abF8nghygBpJKxq4BJsAxeJtqL0swqjsNRvVWheDkwMSrMC/YlS1x NGitrfXYql0OIYjkSEtFqJDgeaBizwkW0YadE9/iuwqbaOdzHBZ1WiSAIYRA GqgUJOZwfaq8gZPANwUqyoTL4/zL9snW0QRlZkuJg3CVijzZ4Ow+FMWsDs5X miQcmCGH6RBFkqWX/W5D1ZvQyCsEYOwUiSOU+60690mnWtYERZp8PhQRLDUk UdMpxR8O3NkZ4VpmoGcTophcr37zxpeGxyfnGB8ntG6S3QjlIkqcTh3GOi5c tYoT8HVs1Q0fMeIEh7QO6NdKzFr2crQtNqzIrZKWCaKIgiNj5Sf2/MGM4S7a KYc7eIop/ssPgX3QO5EZn330VEBOoq4MEn/P2nOhj2ZjYincx2gxcthgrZ7S gpMhg0Cf45UXBMvfTVGdvOL+KEOZEhJHZ9RuQ/gmwiLpwCl2EtJL8A5pg0Vk jTHSkwme9TKtDKlForYo1s5GbPVKAeRNRha1p5UkILrbAq9wAwXVOh3MInzw QtEUbX4UhtVQrM8VOzTqpQcGLs6qhaDWUvSWIyQJ/NGYuZTCTsklVklnFPWI tqTS1ZDGf0fFdQFZXCclKBAvCR9BEJNIBeH7mQnWyHHQsHGgI/10UXZQL6fs BK3QMXllx/BTO7JAcjAjGwaAhxYowPn2J0XTVnln/46NVThSM+ytYL1fu/37 dMszNxY8WhgGMRst6Nf0LqqBx1S4LpLZgO2JYh34K29O0irefkJ0Ctz/uYc+ jnrj6ik+q7BhmMpbiVm+b7cicRAMcwcuqMDV31171hbBNR3YRuVdg1KKg+pw UK0sc5j1WHJUTOI4S4nBpFeBlCeKv0DhVFyzwT57r2Tr2nQd9XVWR9ylGt7b i0xurmpfAJYkJX1Dez5f3Chlq+/YhxWsk8dIviRr9WvxPFikIJMnafwYquCm z08oAqywmJrgerxBkZzEiH6VrdjUO8CXdBhZKhEzEqu1njWUopGkhgvvtELZ i+BCF824cSyKeXJjvOW7TWoJrHKbblAcqY8ofQZHTALcBYDU51bq5/Q+3DtV LZXc3BObm5EbC7efPUPBUoPsxb9aJ6gBpxYGDq13JhnvNIJNq12qSEvaAheO DFIWWBQufRUDLkczbyxuIPPGurasWeiOnWK45KjC6swusgA43KWsThRr6Ov8 NGLjdVZ4NbNKZ+uFwwx3KPB0x80wzJ8QAoKjtmPaxw07U/DQIFlIuJm7zROH NXEGXcyoY4IyKhG59teN7V9oVKMX5zRa25lx/TFA8YSSPDBk/M4eGizGRVji WgIzldTcLFyCHlUAfew/lrTJSziO+NW+/0rqhOAac0p0uMSeinca5zNaVUPw Wjzv5ta5dldxlEnOvLsaGZK4wr7Q+NXDKntDQvNivuSavCpeO8KvGoGOuF93 fe1cPCeL82g9Qfa+3pqiGTNMCk+67v5xV/ieWeFyZBeYjLmjyYJWVdIwI9YQ Le9VHZKr1pNsC3i9qEFntYc2GJmxi7lAEryJCOMLVhFzEy5XDNsHTzlstRcC 8TFbcBaXLIruBmpJeYDuufNdflqMQaCrxsvJVElwm7jLt1Sz2+sx9XaDy/Aj +/4R9IIQ3daVVkjDjEcdAEe2BTuE1TnxQblw2dyv0ryIx2vEX4QICq6cz3nO V/1pTsHQtsLS3k1wdz/UkJB7psafhU0zmyO1slZsMh6I+2qvbk+tlI1rFbsY 60VjEBr5Iu617JvMG8NA38xuB3/Xs62t8Ht4Aam8mfD/VVrYX7cYyFeJeKSw 73pGqSh/NAOUdJSb6Dsh7truJX9m6wdosxxmx5JGc5sGxL//hIlFylAzLMa1 gO8xCcd9YZj/MbyJeP3+rfAioQf+aDb12D+ubNF1gjuy9VOUQmUTb7ZsCC3l P4QFKQsKVEjd7oJZOb5sRltR+XH1qLM53MsnxPLIR06Q/06EwduOWABHJ5dz /niQz/LTcow1hiRKktEUuRYatAucxkAlaWqHZ/ctVmKJI2b7/JgUgiD2SjAb TVi8mcN5Lj4GE5fKclo45pLKRpA9KLT+W5NQ4DsWq1D49CaGodAYhMEsy/nU CpSdhp9eR8ZSw8u/H0M0OFUpN57uhpf7zYmthBJl2dyQlaXpUKEoNjeoDRzJ wkACb9I1nMu36F56vpwO2NBMRIJU4LD2W2HAiK6jF90q+hCCHssOQam2oKhZ C4p6WN3ViUAW692DkvI++brVYtryg+ZMK2yFlOtRjm6Ej3k5pivPSz1fRcYa RllnIZiOrotxSkzVt/2VVKywfMBXc7BmEZZDPDB5suZS5fF+vUvA47DiGoUC 19bWY6IW90zDBEGmaG2UXZsx+nabdbqMIwL63nekZsMAM5zjNkOiDY5FCpaj DIFZaFHWjTTwnn52jqI5yUQbJBB513FMkcoTGhooocfCBrdCtqVIfE2cYgVg ts40DczJOP8nLpUZbTTJt9RNNY0PgRf4V5FZr3EdE4+nBOeSjVoRjgncNC9S PdEt0y9Hcr8EC1fqEaGX4HCdm3B3bwd0JyZ2ys4rdCbNx1yDZRsaYRynbVan vN2ntNmRKJB85fND9FzNC6k0KWWaRK4m5sKuXLLV51OjbIKogEwb8/5BC2Ff lnpIwhIv5kwZbidhiwlPSmDjVCdl7jybpNRKYn7ewApgRuPa2jBgmtcQiZRi BaPsK9Hf+ygw4UVMKucYNTjvHfTB0946OY9i4+k7NQz5brNjMUlgZTlRzWmb HTO2dbKzinH6i+DroLI2395DqWjrTWHhHS/uEDrjgi5gKyfPl1M6fbwbSjlM qUl5wVEOhffgbHRXgnaJZYHeOy6HQl+2RA99e4oG0UKkFSf0oQ2V7RgiSHE6 0uOAE2h+NiUt6PKYgDZfxEZlyMBYS3dgmP+LJXa9qz+2xJr0dxHQ/J1U1plH +yMCcDjifVIRakne06tTQqJbUs7tlCiIQUuxclCSYaOoocj1aiKVKUNZgh8W WGlFj3/Yn5QIiAr4SFG/84ZR/7To8nYIjgxyQc8pn2pkNMY0lqNv9rLvMAL7 LWPSPNYQarXmwCv7bB7azso6i1Nny1HfnSSBdjNZi2xEkEqH4dUQSjjxmXPj Vp84KfEWAseKArkJJJOaXiC0Hx4PTx8eH+enooZVtVRmcPtomAB7l1F/QMat MelSWs7SMn7VF42LNMD79x8dCCWFyO4KZojfsMnoOPvLs7fZ7pNqWHxzsH9w uAffvJuX/W8rxDzchmtrX+a7D1SwLd++hrMM3+57NKHoGwxS14/+dQk6LHwG G2t2bmsrc9p9MB5hzzKmo/2DezimkGkfZ3cPsl3Lss0a4OOv+Yo4JkvD14Mq nx3fvv2D3YGf/Er/6SsYmqWqaN0C3nz7L29evXv98vH3z4BLIx+gDamXp323 JbBLZhvR91JRej0Z0pCfSMAfVc1D1uibDAySLO7XJE5aUb902GgdGQmNgE6t CN1DhiCVI417jXjZ5WSCDGnQUk1wc+4awQonpkwG3DGJds1y4JY/YythoY5G scO3VNHB6gnzIua4q2RpqYTWWS2tR7IK6lqY+HKDDO3L8bO8nVa+KGNrp1Bz pM5mh//Q3O63xOxwsSOG1+B3WlOyrCNtQLmTc1ThH557vXvzgoVWjTuyzulU +gnjqKlHpx3YwAWxAL8CPYAEReWSnDKi4mggO1I28SwaJI9dhoMjDqwtrOSE AuKIfyEGxOgBmgzy5tm/Ptjbb7sgbqNZqk4K81eS40WedN8GvLu7BmMugKsp 1TrFlYUnREMdcPQoW45tID1pdINFzSz8Go4zumGa6n1+NZF+9bokCyMFFX5N xxu0q+udrCzF8dAB7FMxoVpbPm1pVI7JpItFs4E61rzb4pKafRiHv9KaBTcT F9mNqB7RdCXzYrSZpuA0abWutJwyNK3g8v+tD5pB7guH3nrANjxh5xxLZkS7 9rEwB+a4Ose/dVQhF3M0dQU/rJaKt0PkO3vNcSILfShYRjd78PXorbNf3P/f H+lrrbxfifQFBUE7XesSWa0vNMX+1j0NB7CGfUUfbZjYzCJOl5Nfaf2UJLEy OY5X4iZdPkG3+vU3WO9ooC2eK++KbpZFXL1FeCVJP527hKgtt1++evqsU/eG ISZ19VYtPFH3Mrm2Ene5tC6xMhWfRDAE9LIbrDQeQwl4Lifx79FBS1WwZA1v WIJih8hZjVz9am5UfekgpIvm9l+dt7aVo7QICOzfaBvxV85VgNmWHTMLcY+p Y3Y6RqW815OUgkLniLMAvbu/jAWA1VdXD7whL61FrLd/RenErGD7xacMRyom K7HreHuxf/WmOI+lp+WMfTimLvWKhNsEBazBXuIk3LRmQ/hRInuVdrKyAC42 kIsbr8A/iIepWKU6U9eaz17vVidiJUmdiJQKN+OQZeh3tByPw1QwbwxyqBJU ZEgkPVJ/LkoYrpX5aDwbIaerb0nsiqbsuHgUmPe6mCR6akZ1iaW/5kA1109j GrQpQdULAxFQjHy0t3HeISO+GRejDIKqCjskd+Mc1vCIADQq9aBZAof2ri+j i/SaUPUOet1gHBJqeiA4Ju1uBFt/sKd7scKMvEgyODl3YdexUVIgagKN492b 7zg7zFWVDgJ7vIO4tQdy7ZtuItJzgaEpyPf0cmoWGFlJ3fvrgP3cwEY6PSpf mLEP+OISJxsh4oBkeF4NsSwDhQFyqigmSK4fpNOTeHMJ1bK6m4kDSdosvsp8 6ANXTWkNHaGECpNOlaxpv1ZBwa+cxJOu1EH6cJ0cL1P5oaaDvvLCwIllH6rx fbrFgWR9LzV81r31DDaY9wSO/IRrAyjMZxiwobUf5vDY/DKQR0jcsy5lDZES f7gJJUIR4/mzt0++teXXzZHMYmOlSGnGiZ1OOAoc1dgLoQri0NBEbiORkhJO 1G8QwrWLTXH9EHbsdMuOQQhcjKQBg2EDK44KWwwWo318bHptWZz17XcJ+yCP iWA70Ujj4+vZhseGO9zUXRoqXEoMaCO9E9dr73teTEiWc4Gwp5eCwWq3pWcK kAd9Sgqw0jVCoqBUA+MclwqSUMNJpfA+l6esQTJuodO0FqrMHWsb67mB+Ni9 4zSEp8++e/b22epRhCphOKBYLaCASb2ge7xt1uADhxO32kgY6fPM6XHXONEC 2c2XpYse6UnGK9dOYVQJQiKlUipa7cvIGsJ/QAqAC0Mn4mUNGwONjbm7Ba6A cXUp6Z0vGCuKpAAMlirPzgUHisEUK46AGworp2ty7Yt1bWpyBtw1SGota57L KJ4XYzgjpFOhPdVL4F/clLru3J0xbY25R+a39NlZ6/h2HZwNFH0NK0ur7PuS mzefqI1BRDeP8KhAqPlaw2ahgQsJ8JX17ppz1UzzbttDst6W6rrVcqzokatM GMCp50W/iSnnVyFA9l1rGbLnjNkyIeSnQL5zRXkCXZQvrjYdrw2M3MyYmQTl 110SuzxtRptgvFnHejpxY7PNu51gElbZXRe6a/V+aqurTBK/iR3t3h1nsFiH 1fkFvQHVBrWyM9ILvDTDqFyq4psblKpa+ISBqk1uTl2/PZc0oNtGKN5AhLhu eoNJI6QYHKli8Iyww75FxZyxujlOu0+YYqgDvIthzXQvWxDNuL7JeTH4kBng cwVbU1D1QBWSKGd4WHJwXGUXMUwRI3YI0K4XA7qeZ3cJ3und1OtiexEwGsz4 3XSslRccSVJIEn9mgtZUobzRibH1HD84dmADXE7Awqkt4igRV1ovxDONUmxM qIm3+qdgDXnGxdDNkdRMj35garBG48oXwQCacDsmocCssSV0Zb2NQRiF9UXk 9o0A+YO1ORXIE4uxUzMnyUZ5OV5BMndASanmp+UQGECDXpyVVMB1GYkRCxCc OIMN4YnhvL7F8Ouu9LUQ+JGYOFtsPBpjGJevYOMdgOaca2DJWU6Mh/Dw5T7E mOIlOASz8xZKLWBDUHX8kalepkYAQVURS156UQ+y3T/nQ12ixDGMx6z0vZxy YU4USLjqgoBR0EgTPdfAgMnvVp5NxZA8cc6kcrosFLTQ4+8qtNeV4NJchQpC 6wY2TDE+mo6hedRk31N1gyePe8w1EAm14QSVr3BZomQPFBcZ/Jif65vykgYG Jkalg6nALTPpDwuQx8YusbZZj4AiBrMT5EfxODZJFMGyBGVd9KN+mTiJn4Qo fHVz2krmeQzjJ+jFT7iL7DV3kT2VqcHi58CEi0kMFuYB0R4duNQw13YXvs2L RRN/+ckS2M8k6l0Y4E6QJ8N3ZrOSFWiweX9AzcTrpPnypa9nbeJiCi0q3FJu IPOlL0i9Q4cwHZUeXQPwyQ7TTjnc4VXAl9D8gBTqv9Ngamp3OZVKvQrZQOea YwYPuBWP0hE0EeFfRGUDeNurASlU1u0lbFaiEusGLsS/4RcNXAhEGf+LrjxL MRYVIiB42oDEVnUt/zoQB8ndd5u2AugAekm8n32TfWJwgH/a1cU9zg72sm/+ hAuLX30O8+eZaoFFxRiWJwtkUPNhinQpeGXeQdv4gBwrc5K4omwjFh95lT0y XT0DTTLt72S7So39oz10iTl4jhYcp4VxEZA4cL4EHtxH8FzM6QVVoczhGiB7 0NDEn8t2dRJgYV+mTktOStTCSVldjRZUxalAFJCCstnCsimIjj9gNPNpsUD0 exF7KnSXBVp3ianCp8uzM8WnUsGd8up+XoRQAGRK+4gaSjVtDFaz7AQdFxjp uDo7Cxwg/I5bd0ehy+m4/IBswlmJ0IY9hc+R2dDMgeU7ZGZa7mAwKm3oRY1Z yB4yEy2sITKxr6Dack/h3XvOuZRAeaPyDGSAfDYZF3w6TCB0eKS2TGy5Rpaf cJ2vDFQCl/bNUeb3QO7b24pjzNe91rZctDme1NtcLhb+jX76h8fZ9svK5JxT sIFxOmz36H1uu9FA/wjeB844PdMEQc5B4FTWfCWCiKoxbHr4KsM9J2eEdJti PjCGt39+eiws6HamHAi/ODjO7sK/K6aU3cbWP2+FTAqr67ZvZqLgLmulLsmc rqDo/scSupwHXOFlnz0bchVlyTznWiusCPSyGQLdFySoood9G2a5bapbxVee q1YPJxsZlEArVVcUCISRdsoBLKZM3VAZsD5zWD5n83x27quPJg/PVNFEnNtw 87GWlruTIuDAPigbhR0Dxlix78Ne5Ft343d0wzCFXBVgidWw0ezPY/Y6JxMl +iY4kTYPKwqR83iBxa/Vf6zuBnXCIoYgrNmnT0xwmKxs7/xQzFfICOJxJVmD RBfmccSl6mOEMTWIG6GIhLGNdI1yCqy2lOTkVcOgVUyjR8uYUOG4J5XZvHFD AD58+I8vkogTYAej6FliJuLPvhXd69Mt11Z/VCwG55LWH7yZuWoSDXdrkOvk nAjOdRS4btEfa/NrNPpHe+G7pzaGKTrXoU7WXakrXY2XlU6ucnwGu9kQUYx2 bHH1etoey+URymacHq31qmyhZG/N8Q97a4Cv43XZasQmW8odVX0kTiFMfy9x oahi9CJVA4lX3ziCOTNUkYdYlQs96HZX3De1fZnliKDAJtsfGBRj6H29+FLs PYgjTXEzUp58RhKPLEKEsaBVMz2FcqEmMV1g9hmKCCQXeIR43XhTI6lNIaOV /dI09V/FvFpFVG4fYswDAh+QkDt7IsWaWTRP4Ig1efjWYkfWcf4OT8hBSxpO ojYXnjVlut3UvGmEcoxiKEceCUvsrnGjT9QRzi7CL8FN9HNWusi7aMIJW2rb y8FyyMyX8/IGJo4sUFAZDH5hV3br38HyvEiEhsKVNrS4DYnmO6An4oOuebVh lZSuW+L0clGo6gnjp01A8K7FeaP+BI6bLDCSv2IitVhCDkLEhG8/PmnLqkGA m6GLMxNbbDJxEa3fFA4XBKANqxbweTW+q89ckGE03Udi6lpG5cqe2wsHQUmQ ebCYcAtEdvGdk20me0kc5NOtBspHaOQPChjSQqIdOMCG8hdheEHaW0zRtBn/ 2mX4+wcw95zDoYeBJGktrz2/bWKDXeD9rNu88NUtuwQXklvaIyjhEAu0uPaj jWqBp4TMxIHxFLlMhwRjCS5NIClFSTZC5SK/Vgy5J7l6nvoDy1ks5n0maRpV ucY3ZO8i6RljXj+WxYUzvEiYlY1MF72MEw0S7fWPoEWTgM8p6Vuh0i+CzVV/ EEgT/vnlyg3gy9RC3/wYyqfpYYL1Gxerphn5mT7+p186xsCbaXavYwzXn8XX qwcvRpZYUur3b2IMKYtBRBZqKvhejF7PEacByGydNXeYddvAMsk818/HwCa/ 2R4UaNNCg0JoUlLwBLUo8XY48IR7e1td0AkGHsFDkjWsTnFhzgh2a1utTdku HEi6l4ztT63Te4h88Cnbhjt1+zj74bCXHf2UwXQSVrEU3sKvNqYe/IncET/Y pkYPt/Ez/O1omxBkM/gTBCV6wmI20IP2A3g+S1uZGqwkYWDajGA+Rwq0j1xZ oUoHIcUm+wGvSvrOa9QOpZMVKfpWxRetOMeNBgkD5LKlwH3vgrexyL0IV0Re FiHIg89hzVyYBSLjCdvWS1mLBK8PxfgYo8TPy7NzkJc+FuKCDyaUD4dx3AD+ hcGcBI6dBg1wb62MgUw3a0UfanKnIxC51zBSrMpODVPeQ23VJordoPXi8f/u VDRvtlY4FdzpWX+gkcEHLvCrCawJE5jMFuKlRrJqpN4YaEXy0ivCpBfdaLyJ zLfYYWSl9os5MDK1wpjAlWaURlcWhmhvBYPs1jtODnZgnykrSnd0PYmOKSIP RNEGvrEI6nFhvoAhmBhfiZtZbzjRWePinh4CZ1kXyCIo34g9feUiWgiOAa3V yNBREkqDA+Pa5ooW4Bbh8YkF+/Tu7qhWA8f8Cfsi3udPQsjwYLJjjDyiHICe C8CZyrJiwMWUJjNivxVxdazdDiTFSTzs5WOglhethHBTOCmsKjvaM3OmU8yq u3fedxWZerWQVMcuAl573BSYKgUWlAOYelGrx5xziA8whss2uwc2BLRSGOvF DtEA5lS8H43zMziMO9jre04A2WEWslMO9QN70pWXZVm/WcnIh0w0euABt5by WsyXBa/yvb0bYg28uN7UWs5jT1sYmWcnvMuslQv5YPunUt6yxv5dogzWnGC8 WkHOVlPNitmOYJgy3bs3O12J1dWNj12LzRjJqIbQijUACSW5Bg0O2iiSt8H+ G+oKq0h58grJtQzNfk2bG60gmdhcljveZlSrnkCUQCw/Lae5Rjrw1bmeKBJf Lw1j8bV2NnAcuPtNKxdML5v4sTx2jJZLzUk2NW4A7xp0GYwL5T+4LFraXAeh QeNaaZACHUwLpsfadSkBL6CHUwEYUh56Zkd+/GEbnyPVBH85+iP+/872jz99 gaUMl9EXsXBTlbEE0z+tEBGbxrZNrHGbR5gk/JjuiTY9k1ZbrRJ4cPwM+xxe j7rzBqvDBQiTIn8L5O0ZlykogjgJPukgpO6YofWy07zmFGZ80AfVRReQEj5p AC1snQsUrc/f3MyNtZ3g1jrm7EbbnEhdpWhnmsWEk1H02CgfLAQ42RdWD9JH giFGMUbEHzC3j4MH4GOC4Mx1Bq3DbEW7c/cgYzlLNfaI5Dj1oi1nX3JgOsdt ROd2CSkl0YOYLHgyPeR0g0Jj7iRj0wN4t29e7D2JtLbAzhzrRk3UPAeYSjGS nJGZipK0c3QRkYwfPxyO+8XPfXhgtjxV3Bn2/VK0OVtq1Ct+3GAKTb+Z0fy+ 4vux8/GgaCOHjCcunRb3nHuAVsJpKD1ff0sU/J45zj/KecazMb7IL2sNqEYJ wt4rrncSFn50Yo1/0XFlVdSClxuUD0w51Qq1sJ99W12g00HkHiHbaYFGn3xe Sokk8tVQ3VCiOVclxbvrkwQdhulFIbAho8u+geuqGm9t0d5JqSjclPfywQ/Z 0R/o15+2jBBFX/xhl764nbnn9+CprXKIjWI77lbix+ELLEqlA9bSYVg0KxxU LzNdwYWmzfyUnBaZIJukrfbH+LSEJyRB/h1Ej7NiCxVOHF238AEaKv8Q1ARy 6kvLSWn4o3Enq3l5VmIUEZ4HSjSS3BB3ODyb26m70gyjG1hjWDTVxNgqyprR vgk3AGsh4DWHhqx5NbntTY0+04G737uKdcOHx+kUmF2EQN3jsabKRCZFvAa8 81SLIQRxCaYM4hVqVzrmrAklzhFsivaZgn8d0w/m5Cr4IY1M0Zm4mjw4w1nt Llg+RUVoaiB7+f5Js8KWpvF1b/9+TKxawGrFoNYlq+AchLKJPkmx2lVX6nsi 6sBRDWegifXI53SHEHQebitZpwxIoBr14T9TCGz3dfV6LyswIHxK8GaT2bKx upmDFvK2LngPNgseZqg1QZfuXMw9srjgjk79LF++P1n1WvKtJ6s7oxCwYxYG +zJCm35i7bdSV7Wh+Gvtd7+g4k4uR7qzpAW6mDpf9cemLzotwAVLhWBiGINA bVaTcsHR7TxqXB4Zs6/oJprDMK7ZwyNuq6cn7OmIklefMP6ajzxTXtdSpT5d 9Lz77Pg5PNE58EFuOcSmxpDdAWEfzS1Yp/cwR8ARLaNtEK2n69rx/UiNuq0N xUp0/wmQEb7Zp3ZFXkV8Phezq7VesXN30DiozUXONAqo8dhqH6WYKNenF2oY GAKCADB9LueXsGS1858BCHXBuidZ2mbpjJQ4KVWjFucagAr30rwC9byoHbKY bgY+FCyU9QJMW1g4xSbbrtjW7iwupr/SFz42GbEUw3pXbTBiameWe5HXkrIa lnCkAB2HPNB2agSReOH6HZaSIQvNUIox7uXb704yqei1p0/HGIGdWGv+Ttea oJ5ZCAfxZ44me0/vZpQH3yOI/E7koohuOF9kdD2BbAUZCfqZr0xM9gOpQKH5 98FFJgBk3huIjnT1b9l2YlNMSrMyGlkAUGFyaeXUp+p1S3a2UV03AGvAOHkn GcHlDPLg+2S4Zk4QkzjNFKsLZ+AuHVebDhpoRfnooZ5/TqQbF6XTGqK+2Gs1 JWsm15sjTRwXno7by1fi3HW9JvELOZVvFE43yZxabUe+3gFFntWYFsY6CVc/ MVVL4nJrPgCOMvNh61ypNClIQUI2tWuRzkzvuzkrCDAA273GpmpAwl5Pynfz fUMa7LToL6o+Su1xWVIEO0k798k2JNgGJuDWJVjpZRzg6u6RGELc0mEiqPTG xV7nxaTCkBMnNIikLrEWxaCPtNGXx9pyMBNYuiZzMYq3R8ENjhYJWGozFCW/ 055KO3thou65qkmCYhrymZXM9rNUsK8vX+KKl3jbgp1cKFz79FPN/7c8QXye Ni8mLl/bACK+DhvhfBuqh5K0DtCy9JD58/WIMpjYL7mrtlgqDKViyfWb7Hzn 4dH9+/cfPDi6P3pw78HBnUP44879e/eL+3fv33twtIMGKbheMnr24PBhfvTg 4ejBKM9P793L+dsn8u3Rvfzho0eHg+GDg4N8cHC4s7WVHGReG6mLyMKJdLUd 28HPd0fdozODg4cfxsMzo8Ov4/FtbXkNBx7F7rKV/WXZ3YdZ3BF+1mi91aST FCsTUWXXEmXReBMBY/jj4Up/6tmSPH9jPrGqi0mpo8Q4hQ+1xmnpxITlBOaP xfl+6PcyiKYWgSUBvkTXz2kBDPMMhK+FRT6NuvC4BTjCgDXAqcaZ2ww/FIRY WBV0mnPCqjotHMSRwaVTXKJycUWQkrdGM9T2a6NXd2P2tBsOxNqMQEK2uaId 06cJsd8N8KMx3o26eVbZlQFYDNwNoH88JFHgYG13rDXityw9WRHjquBPnUg+ QYaJVBVs2gW7wwETi4e2galcuGFIVihhSx5oVDlaLUarYhoJH4AljxhiVxJe Gbxk1KRCVJS8krRSM0rYExzAkjmTQZhQZNpo0mNZO5Etaa/o3NXuUxpkcXrU zgi2pjuaOYVSE+MWeD92iLqSC5yb1+Oi1SC9QUeZFJVaDENGOCYd2sHkxx26 mM1Ea/pd6470JCNeXTi+jgl1qK3vllRAl/UjHZdhYJ1weqeFwHat7bSX2mMo 2WkfwlXaOzrP9WjQljfKsPQaUjF+Zcwy+RiR+hbnk9S7ZARHXseoAI7ROnOS WWNT7bpZDEa1LtqDIDMLscpSCFcbXlu0PR6x7IaQnHQB2hOFQtTAz/vZX2HE MvWNQQh4GYISi3FSfRajox1lu9uPO+wehIe4oM1y28eUCBMnsAh6aTskcpPP F5nAxISf5vhOzNscAGB96xz30RjZTVve5FoJJu/k0hkQfkDHv1PwlSkYBJjt F1Pmla/VK/Tae4V09YlEX4y6/VbriSRtQk1neRdihBIjkxA+nR8kFIennTKt l2cZCBav8rVSTcI83BotEkEyqYKHeNNZt7PUP8eQBXyaWMhdEdV+ocpIMlOZ Mo3MighOAWwrXCp8h6ysVmQCi8Q15uzBrVsMyzC3vkm1M8kFT4ZEnwrqDd1P Xn3//bOXT589zRpuMnh1xhzRgCtyskwAp7DGWU8yRoto4q3AbFx5yMSPgstZ Ph8SmmulSnNeKwNi8Xqz0fCbkSDYAP90YiBrxx6vfqEeTBQRLSIa6uwgN7xH G6A1tgesyD/yHrrciSKw4Ls+focxUo6kyE3wfjRZ7LiISo0n0qG0pwNEkdtM ROLNWgUE7ywOVCqAu2QBdcM4DCwMUUzDdTYgG0mRm7wRXsbqpcT1c7IJr7ou EqqAww4h7p1AlA1QRHAV6ARgBFGAJPkcwxp7zRqmYWRgOtIw5Mndep9DEd4w ry6FJbDfaItAsCggN6jlF5jhxZhBjmuBBPGlCFvQvkN+Q7Gt22uAn2+nRsiM Vv3YYbSUG7E7Ms0r6VyxZ0IruWuaRPOA/bJlaLrJNln1/MoGiGMfed0yf8/l 1/AEyi4ulsggUDiuKGzWxzXHFfH8YEOIaZO1l7r59xPDViK9yoDl3lKK7uA4 8uSaaifaZpC1UMN6Mr2Vq4srxhZHAuVYR+JIWwRaxLRpWrLOpVRiNe6CtZe2 aXLuNFBW5BrdK/me5oMPFwjrSSemXFxqJJVgOmAWsr3PtUwH3ZHjcRHUOoQ1 E1vmZjVVzFo464haQzrcd4KcDwcd0fdVnKRIai1sn0zHNI44TilXfx+74kJ+ 5LOsTVJ1I+E6SEdr5LutSDL+ytCyLrCvErZ+0mnqBujZeEzPo0jsDQImDa47 fDgRW3k4Ua+4uWuZ0v6iSKdQDMGLm/wGwCK8EVzPergz6uglx4XqBLaOBPle obu70B2Xedrz5R714gn7J69IopqFFriW3KNxMVow5k1z3grH2sCR/q7iXSFM CHZZM5p4L0ZKRg84Oe6V5dk7tcuvsNldumLsN2RJtTbU62Lx+ST1WpKyPyww 1EiYultAtOdpgJf8HTCDhBW2uIyMr6vDVRQslLLwmuEfb8+dQ0XAGCWGZ1Qt p67n7X+BsWJpx+1ugGt9zGBcw50VxYnQAjqzkDBbtxgwfbL5EKNIsFuu3o7c OAykzOsI0XzN4dEO4cI2eFw3cEIgiHHhWAPV5KoXUHjVHMODSokkni4nzb7W K+DdOYIU2crm+0JbOW08RZFNKpDuqylB9aNkXDsKZqpILT5tnQkBV+jPaPhk maNApbfONHgdSnc2qCuGTeFwHqAPJyh4LfRO6Q14QiVsvUhCVlIbDxE1xEVp YEUiX/AtKAagk40nKvKQ1oSdOjflmtSaAIynYsk9o3qifsw4FXSTBgGerGI7 CFictl/lHS8jtwQKajlXcruHMER/9NBSf+xHP39s+Sr4649bvzDQDaEsucln hKsPH7yWYfySPTWg6b/AtUDyK9w52S83Mwq4aDBIawiNH0TgT+Y3A+sBf/3w 5vmT/r/Dz08wil9SbySa4IAe7SsAmbqBiaSiQ2jDJSCkldhaYadacKw5nhmb RkKMMaw/ffqnk2ffPf/82SBZYwOW0zVOLNJhF7R0KBAIpnz6TvZGGMYzLX6e NdFh4MNSCv8sykkrn+rkv82rNwbsFjbMBk+bSQwsBEVpHo9LY3IQA26lOFlf 0FcOHz046B8cwn9vDw6O6b//J3v39gl0uyjZNuT5Kn6OEX+3cXo9jkNjGRHr mHCzePzzcXVWLSkU4uJckO5dIzj9lzzWp6jHBJWDtJzJg3uHj9Av8ZdADHYx n0uxMTU0H8KLJ10fNyBIgV+4VXMc6lLQCI2Hv12rCsBqhAjKJhHAqnMZvHE5 Kr4oGbxQXwvQYii/efijOG7YxQ4YZJ0rEtTaE8V6pEobHgqpSY+nxeKiEHVX VTdq12jSerXQ5xeqHMc90kFEI3qesjmE62Xlvz2D7+5isepNzjaaBYZDp9/K zFJjKO2eYdTsog5nvQxr0QX6RST3Rc0FSNhrnhkOfJ/G85RwgMU1DgpamYMa 3hj3VVJa30VOaQj15XRwPgch8r8KWgaquoEBrINxNfjABwxYD4+FUB78PhIE Tjh9Rtl2Ir0zodgF0cWID4+LMIn3OzytjZKhBm/IdLVUFLt4v6kbWBtyCeTe 0kA+nCpJI70kGSq6uUvXKVEUHaEupnfYkvJ7aBGRfrB8rejaIFAv9bSYNnMT PGIKy6dzo6L12w0O04kQlY5I9LEJKIWcyIHd6bG/sKYujIivQ5pXhd0CYzVX lqNAwx132Py0WtKOCb6hVSmpuruYSEBqgBfmlw3FPgzLL9HANc4v1UniAgHH Y7R4ubMSn5A4UijPxtUU1WvdU78QvEeoaCFmmMlfPy1G5IWS+AZdj/SetsbO koXPEDaJTN5iiIc8HvwKK+GrmddrFk1LWSuIn3Vz3SCQH0iP753l5r1oIeGt HZk4PKy9KioUY1z+5xLNqWp+aVVwcD8TV3rg/u2Mh7GKXaoD4/TxzoixiY9z sAwNpI1IWhdlyGqGpKA+2ttALUvrDbE2ZHQyq3gFKg3tgipqaytk6/VvtLEQ SXGeVNMiVey6/cdKVBhFIxvbP0jrVH6XNlepWjr6VTQsze3bCUyeYV4fIkL8 qDgaHL8bxHjMNRPL2bJdiDuKNCa9PmHFDDBMIrPzxhCRLLgKPBU/MqHi2vw0 hZYwXhH7BMNKlcE8G8fS1emMItiLVgCpJAToFeEtQo98N8TFzSA8dLsyO/Af WgEeZkUx/5GgUDy5+RpxluA8QA+pQT6D/roEhgl1DrpRUv+zqUs7d6eoMyQr DmKLCWYX5ZdK4Ph9m4GbSNZH6uGU/UULDfnigkSDsHa79Z43pYeAUAlHDLXc 6YXV8Z/n4dDShM6j0qEaLwTW7XNjtHPJQ5xbylupFyyBabWzulBg4QDTuQX+ ds8UJG1k2woyQuRGY8WIEnsELogkNRYa8slpebasljWGsaPMgzAL42J45hRI xjYc8RIEa86Hea1C7mnXeoxOFGU4AR8jpS/0NGIMocdzw1u7CReDPsMYOoGV M0mfplfEAxQuAkxnOWnALkiWukMzU6ORsVO7zVzbeY7KPHrReFPcvGmh9SB0 BFSsXE+Je2MLU/oMpQpmyO7GZyK5qEyNpCSGhoBOTHCnT65IgKdHA/C1dVHP 5eLD4uDhQJ74gbyj3OC4ackYni1P2eWwF2gmMYScKUDfPWuLdpjYB3NUFbqw sf7wB6cIoqxOSw6cHxYrwMCzwZNauHoIhDIsfG5ZhHyHV5PcTGbth8VM8PVE 23eXpLhRr0eaRN8w+WDY9qo0gGmd8tnv12X6uozD7/4m16Zvru3qXB8GLYFD Gk9H3PyhNJeE4GvGrwTaeXcpvyNFBqEmfnyvkT9JpV0iKnA6hVRy1kQQBSLh kXDYkgFl4JgfWrCcrGJcWq12dnHGUvAxzyaThIpGnZN5x9sunUBdI8tDzZUp rkaDV8T+28q4sQ0ehd+VUQivZVlsjMTb9kKf2EIEL759ogN9yUfjJJrL98DR qmGNiL/o2BOO/oSY8guqjJyPt/ni337mDU5Pi/Ei31auQhUPl5NJzhW7HHIR zKbvZtPX2aDPJxknTwfsdFmOBUO29FXM29KIBlL9xdiKFKTEJas4HoKB10pB RIUHHUYQq+Kvtg00jBH4YwwiRMjkuuXfxIvbsJNERpHIKfxLNs5PizG9TIED rSWK2p3E15yXoyfu5UD+RbDG21iF6xehKKk3MChndC03/N5CjuFoA3d4hA9d peb1i6Xnfrod63kg5pJsxxyGlvE0jjyQVrOd5C5E7SCWQRbWv7pCOwaS0YUX XKUdvBxyjB93Pp2rtbNDZr0dE/Z1tXZwBDHXuko7MaeLn1i3HSEKZz5NtXNz 58swYezlUHortSzcL3gpjCl6R7gzstvm+WIO3jUv56/11uzE+ugd0N6OOaEs ywMfvuq+k44wUiJMjWd1O2gmrxehE+9K58v5tms1/11xXiw2Sg56cl43Rz/m jsZejqS3pRKQ47zGKZ8l6Icu+M55Ebtg3yDHkeTNea2zPlHACbuqr9AOiyLh rXGl8y74BDMDBX2VdkICbD6xMR16QrravcOQC2i2HcwvZ4v4ibXvC0w9J2+h IgY321lNz7/0kz/Bx+nItLRQ2eJXcQL01ULV2gTYhmuFPAYDju0YcKjoF/G2 fBgOvjQMNvDgjTCwXcq9z7WgEJDpenZN9m9yzLGLhdZIDDKuDZSZV7NiLo7W jZ0UFhbIDrFzXKVsEYFxVGz6iLBnyCjhdsXaJWBwDz26XQQ6uXKZI184WWkt Foiu0MYZqr8KgPeKkbX6eHAhbwzHG7e5AQKcqkLXBred2laPtR0eyJuG+l7Z d3bDINyUw7YSgdtjpG8Op23fx942gdb+AvjOcjxCNNA10J77MvzuwbRHU3ka t4Ffa3S8Dsp0TI5rQkwjVkgTX/qq8NJkNf8NYEsnztCXgK4xO74BxnSTcdwI zM3RobBSjdh6X8MbkyKRVeaQXvmJcP84rLHSC68jFDRAQTGmz7UTzpqySmiO 2CbDwop8sjc6mROaTHcmTBgyo+vQ53WoudRPkx5abIUdWRdr6mwaD0U/zmho ZepkPFVLANX1x5ORWQ8tDbBDiCxMv1BYlRYBGJYfKTAccXax/OiiTuiQjWno B+SfJY+Chif2jLLVopMk2pnlJTuokpAH67djwRHkqoKjQANs122uu86xbhOR YVuoWJPQW1UbZOEbcDuDUuOM6BEmNA+tx9s2Uk+oxwNpcJ2QBRjk1xiNW2JH ERKHQhNb1bLGMv1agW6Ts8V76Pq9Mr5Vop7U4AqT4R2+/hBUaGRPDAjf4KnK igPsJ1GPSH6u5kNefnYWljNJs/Gs2G2a1jsXTI81ZOHQz+tk0tWba8vQtPn/ HNaaXnMrqC0VGLafnVSTQuGAohc4wIVxPbnc0drLHuh4WrwZez3Na3h9O+SI 2y0DljiImT7Mv4Qh1KwVUoWlfPgRvY/DdGuCCLRi5BKIY3FPJrCiJS4PVeyq 5mc5ukCGscsThlZRcPoZbBQsAboPz0sQZueDcyeggTqxUIGMbaEY59MYUlaf 53MBzkgVS22WX2iGRDHUvUNxj93raIWFwz7i0QiGiB8uidxcJZzGmF46U5Xc tO+a1bFj6grGy2PgPn1gQQx0SUyOQYS15qyQrtaF2A4EwMs/Xi9PJSSEFhck QhxC95YLDS2CaH+aVo0hLcgOfMpxs3RHN9Gp4H8Zp9et5AIqEbcEtqcFK0k6 V3Aarignax6WBFl9gJWroIydYNk+gFAxHBMcUxahi4vZUKKgygY1pbU2eKO1 woarLLKy1AYKWq4AhuOTw+FcwOksgIDL46FLmaIshX5TMTD7ce3f0tFnzixj gHV2X7zW7nqC6sGyXpAWnwOZzBd6qXK9SF9dqqdsncjv3v2Hd2xqoLJ824Ja jrYHVT7bpgUIOapmkN7fP9Qc0qN7R4SbGKyY6lkeoUujC6WEyCbFTH7dOiaE a9IsZuKpKoWEmYhcY2MIHLTlDJfY1Z0wWVSoyga1RmCvsdDJqjonzGXHdIoc pIvT0tNUqgarFfVRpJLJBEtZd9VKiTCNkpVTPKLO6tIp1OHfrHaKmmrL+d9/ +ZSLZDpuo75d0vj2P6imymEceuR1QapPQnVKcPJrl1PpKoKSSWP47aAYHdw9 PcrzB48OTwf3h1giJexyVXGUzoImviv8Ou6sWe+kWbUEK5k03uusZBJaL9cu Y7KOrRTV6MecPC2xvAl+ezXPV1QowCPi4/qyLezKZmwSKyQmfA38fB/gvxl8 fobAtdRXE/BTODVGY8wl1TfP/vLsrasFIxw9eQnqjoZHWnLTdXQS6LHKkSa8 E5uUkHSsZKxh6T4LF63Zxo1FtxrPurmQwkZnXMA37zL0sqVVzBukHEd4o+f0 El0+qmZ4p41U1Yrs5r78R2g9cRJ0YP529B3lmcsOBZDwcBl8LC5hzsGMxJJh Ksb4fAbC2JoafEC1B8HQsQYAUo0Bnv2CBngPEduCJP/l7e4nHfUTN4xvDW2Z 0MaiGlRiGUqBHTLRVuY9CXfkZBi642igR3tS0u6Cl1Pu+gaihwfmx84JUuA8 iWTCzd7B+d+CH6ZJfJaBXT7dWpFrsrUlTih9ggALP38mJxWxU9SIP5YgjsmE Q4hEiylifIByrnsNqIARghlTG45zadX51ED6oGBgZaaLmrEz6FaJfAHS8lV+ YIhbKav0uj+/0NtqVg7ugePs9SugqiRkMT/+p19uoO+vrV075EjHMTymfVL6 DnEkv1kP7hH7TooCwdapKPC9wEo8H1cXqQuzr+PtMKYH3ekCb219C4peMZeV 3n0Co/zmYP/gaG/r3bzsf1vhJmwDy9lXuoGTs03f4WzhOzfX4NOzw+2tEKoS H+0Eq9zeei1AlbsdkmJvy20eMYfH795++/4JBoLgkXn96vX7Z//2Atb4yTOB T4yt2vUeCm6fsm0S6bePs6+/zn6AAeNYDrd72Q/bHN+MCQWCyTHf/in7KfvT nzLufBtuX06Thrd/WMzRHOLe+gl+/wn+t23y2eAxN0xpgsUg+CIh7YYvC5vf Pg4nBxvqaNRvopCp7COS7t7m2xDQc2r34wdws+PPiNybHw8ODw6vttH/8ux/ 9/wyvj+0fxyZh1/Qd0gM8NvRKiJAKDdY2sM7sOhw9OBX6md7upzgx0fwKygw +Oujo7uPHh0dHBzIDhY/l/Dx0T3+DGamBNE6yOwnedVn2+Hznt7SpBe8ZRKY qK8XT6GPF0+hbaCI1fykf5RQLggbP81OSE7kW/CfWVTqYDBUAYVcKB9LTqSF pkAixYpzIfaMrVpAcgPfaO5xNMx1ekatv5Mu77t7YoNVUyBnPjWcBS6YI88W WGyNrHfGtvv4yTO2eoU3NA2SwiM1xIgqGHSPLEC4CqbsrEfYChodVk7SCDGj 5ZxkIbdCkTmEBawlrCeb7BdkWUeJOwyc8zVaVnXeLZ+Q/d5vtF9i0gQScVzo oTglyF0H8WTQ6SkfGhWO5ViKG6faQEdXqdZtW0OggX0UOA2vMTC2vOk8ycie WrfutUJMx7iyZ3AyVM8kMyBdyWtom668ZFDHgbNVvcirJUXRmtZe6m1lKWFb c9IpW6LAtJrJdBIWeSuC8Q06+vTprBxKQUI52OGwaCS54oAlBmbjsWjpvDFt feveYwvAoMzxtrebIGtZKMuJSvqUC1MLqWeVSqNqiv7ZBOYS9k+fi33ZAdv5 4JUkqD48Oi407NaljeMfoaDKXpEYPMxr5pwwWzsdWW0k6uRgns1gbIYbTPJS ojjpBG0KYRMeXs+sxL6+XkWcNaJHQ8eDSf9nK5UFIyD0vlQtOQPmF9HsnhZN 44bRMqOAy1yCZuQhAjsRM5zLVZc4jl/0xATNiiVkqICGEnTRD1RFsncJYfuj 2yiHRT16fsnft5sC5Ryg62zFrFIzoaP0H0tJgg+/cZ6EsCbtW1fyBalO0Oyc ASxEgYRl6LSwpQyKDd7vWYgz7ndXv6S6CSB7DfL50FYo2rwMVjd77NhqLHxy kYsDnZ05q48QbeaUaigZSyDRK7672c4mDxqB5ZBVo1wopojnBU0Gw4YZMr5+ K5U9Pt3CJUA7KMMk43dx1Q+i2+7qHWsWowlrT3O0QmQOxjM3dU4YiyrcVdQw LFpkLJkhKAgFKoeVQsJSUUqRbRVMr1ak+X9s5Uc4kNuvNFkHRUhBVeKQnCq8 tLT8I0YthCXKguJknjqD4w9K+j3U12lF91rRc1fQ8VUrfbQV+jBXm9b0kMoR dBtiYYcOlrS19cwAGKXgM9tfTsM/Z25cyRmqC+uSUnpWvBQY+Gp2aQRs4DgV fN6MxRGuoK2jVkfDtsg6dh3bUD4Fp92DBHfzeibgTjjtJuJsC6a2NOef4/eC 5kqXnR+BsbVBa68AXG5BzVbj+xu9udns8C/czPfajDHGa9N9uezzMfo6RW61 gaQomBBxD3x6QCwjhMWmosGT3UD9p6KcrekJXE8369DJ1Lmgow2m3uVjQG3W +iu+oL8hObYv7HZwP9f1P7gf64ggGIOndvWcSwI3/st5JKLRWNdEakzGS2Fv kYaP4vqjSRkXk/ve5rNoW9Eb8F3gljjXxeENuC7EQH2c9dNmdgHtcWb2e1cw s1/RCC4W7Wa4/to27RZLccshThiMV+/kZ2Tm6cgIspPjzRlEeGlgFF8tuJ/I kZ4/e/vkWxWcatEC+EOvB8yWpzhiuIMG56IMBO95ZPVO9K+1FAEpquzVi277 RhO6slWT0KuEtllFimuWZxOEMvVW7TTy1EwQbyyFOT3Ytzmphl62NVVECdgN 5Bv0aPz4HoQaLLDE4kw59B/4xAzUJEEMKSazxaUr+weH4OnT73xEWPbjD/Bk BXcv/PLjT/IP/OeFID8zI8Gg5i0R+rx8vcACqYK+RoMQqtaYLcS9pmMiVpdW lM/e4vPqa6CHgUXNAhXd9KNx0OlKmIFMkhBHyGTDBgc9ZhzXa6Mx8eg4+QkY rwvJ7FvwN9jJKUVWVtP3o3F+tiOkI6WNm5Wt0SvKla3vERDn9gimJJ/c3es1 NL5AeQgIK6YrsbYq8QQwty7Q8gKdSLAM/JIlgK6AttqDu9IblQvsidNAGmO0 hO7S2P+rmFc4eUqSWYk/2FuPBXWunRkSphD9OuuUmllqyRLWcDrGEd+g0etB DBZWvpqLMWqKMTg4vWNTzdkT6o+bU2qsqK/L58NzqRlHY0rkgluJ+UeTP94m iFeNmivnDXzLQBG0S7F/nRlHR/FXnXJP1SBiTgyYhIR45WVAgk+gfXYMHo7P RYHZSYFA0OPRS/X0aoIIM+ofcYwgnLSzGVnQ0E1rNfbQx3Gf/s+YolY8cONb 15mSviiQr7DEUMCueNOhv9rPq/FQ65kr67M7oJVKXQabiy1spFcJ//gKt9Wk 5OvdhOzb502mFroXBSda+uTiBSY1LsJYxN7IQqk3J29dbBAy3e77Scdkt/mk yY3hmKs5CJidoW+nMeAD+2TbrbuhnVFrX0fKodYocubB9WROY5B0y5807ZGl J7rSXTFYoUPDodL1YDvtManCHbbJNWrRSzeuGkZ8WbXUa7C9BAjeFrE93WgT KjmFgdMsCCG1zUJ8/16zfAdx1MG8pCVyEoLKFFGWOguA1mG5AnfbTjyJK321 BbgW+75xVGfLh1P5O5zigId5M1+iH0A83rYju/7ZtAn7MHmSOTHIf3EeXSZI QAVmbg0Kz82CIyzocL0gPZ9f90A6jRV3SFoNqPNy6K7+CK08rbpFwSLovMxJ cl40VhX3IHXZaTk3nsxl+o7uIoEjQfJ6K3tfwxeUQMK5V7XcAPEqBO/MC4Gx 2kCC4gprjGoU1Z5z9UJBNMLIDgoYkcpq4l4W2WlC0VOU7e204I6TRAjeOFTr nZaIAzrpE3Lr6YZQIKUp+WBOSD6sZmS7QV5GK99rXWXvirDZAtGch0siaOY9 i2hdO2UhrhhBCv08VL55HdGd4VbRZYljxBv6+fryLMIlBDpLFibQ6aGim7Dp ttXYmWacxeMTBmbn4ALbJoYLDQtznkiGSCVK6MEwrWN+fGWgrEL5oLLeEId6 KRpijuefm0gNy+mOdi85OoDKvIdOmxzOn0IBtJbdcLeAy6+IDRGfyZnuxL9N 44oivTrfxCckJpTOPgJlIXUF5YbheGyEaFhNnxLbLdfJLyPeeV3fEo+/3Q0f WFY/O08Uw5vRhh12OaCcvwk5P6wg9nAKD4W+I9NaymHkzKi5d2DdoBPp2s6j pn+lvdqMcyHFr6/AXWr9SfmamIY6iKZz8FeY+9f9fuecIxeVT6S5du8pL4Yl zjZP1Mod8vHvcAZfnTr7egdHg2Zd7hyzte8lOuTKXi3eSefXuncDfi3zJ+cr fBm3lfNEJRJlMEGGUjMwb+H9neynn9pyWf5WTjabV2L+uBMmmRy5JJM7q5JM UqkhUdMtuSEtKSH2j2xFfohf6Ba/n2XACWffr3tYPqci/eQe8sF+KwPxVhpJ EnGYbYFYXmkN3YqJK7JHopmp4hkFIK3v8YmjogPYGlYF2LSVkkBcYJKL6rH1 vRIlJztjq349A0QoSj6GpbiGCEm+rBsWIwXFe87CiNR/j4VucfN9QeGyyyt4 jVClmxEqU2LinS4xUc2RKt21iod31xcPf5cP22OR2uKXmuLh30Q+9CFMX1o+ vPMry4d6btcVD3/lmKembPhbjYJqzQJul9YoS3YTmY2Dpe5puvbK5N6g7ytm +oZ/dEt1bkLrynZ3fz3ZLk3oHTFhipbTERaW2wyPZD5IjI9zU6Li2v60KGJ/ FaxPA4pwZdLaNfIxmkdvZcZAM94sQOeJYs28BTyFWt+zQvEai9MFv+4qbadL TCRBmdPuLjfaZjUDM9y8o0LC+uNswF5daaBtaEjBcIP0q3/YKhmBaZ9EQDSc H2flnnk5DebXikEmgFxBrlqcimURsBhK3vvKwsTuNgn5K9aoZKDkZGKYLj9u GPb64GewXBrFX6c8Hhb4LUyMXkl8TN48plUVe/+nFBdBM7VHA43zce15mxT5 1EcaoHY84VKMrgCSh2BbxG0R3V3kK7BSRb32JJDkINlmOPp/t1VDMnJKtiA3 C5As0yWbPgZEKx2avHjjKPXcyA2C5hp4yRaaNNPq87Q1nzv71JIlurwiINTF eNT3R4mPloD9AZ0Qt3ZL8d+Jny+NzHlw+mB4eniU56PRvfvD/M4XReaMO1sX mbPxXnKl0sicSQPp9bA5Q5uXF43aRfNboaybsHFtVL1u/aJ1vTia/UYMYSsk wevYsxwIZ4dJyyBsh8GWGqH0DvispJAon26xFAfgFRrlX6+lC7jkyLTw7Fik wYVcA+MifbumZUiqbJBAKAkSyuUqC/EZzKQjHNjqlINLVk6fs2q49ImxbHrY 1mpaiFE7vm8V8mL1fcuY11xKJImDmxSA/pHBPr10o3oznKo+kvNabv0h1XQ6 Tbv1U632i59Xp4SS0WCLjQZXtv2x2fZ6aY+/NFpA7rXSZBK3cFXbrbPfxrNo td86dtc9iyutAxpxV02/05B73TG0Xc4xjbVmn66zdxubu0zJ2d+kIVdJ4jdk y41NuOJh4Z/NMDzZQuo0RkLTbMigPf9UjMWJfUdfp9E24ZkWdMU0l0vlzH5x +uuwr2pk7xppt10WVm1mE/Pq75A4v0PifCFIHM3yULJcE8vpqkg5vlazS38x ERZc30aHstOWoWmsXs4WrkTs5hGWO+pORLDR1jqp5iQwK6DPWQEp8xmuSJyF gQNFgVryCnhN3RCbcfVlu/WDJM6DZoSH9xFpYXrDZG4My8WnNVxdk3TzvrIm uTLW1vJWhyjvFuPa8rhr/0ujslwfjkVjHjxVrMRe8Rt0AwAsCeQVM5JViCvX jltoC1zQIbQIuPFi/RZhVcyfOp1fVTJdK2Y1YOQgCH5CBHC4rceLnOBTDj63 OdvdEUtaCdu2p0Numy4n1xTZoIXfpbXfpbUbltbWD4TIp1oknUkCdo+DTrty f9fAOkSv5FLLrYJkNqcz4TEpyL8BrV9yOpl+xBCoayGDuhQ7cmPCdZuoL+Pg 1YphY1BiuSxp9TXdGz/Mz4r9EDlwTSFUFjIpRsUwef8mC/vpFqqmssybilQC XmxKdYJgsVxcfeeuI4JBR9eRvtrPqrLIz/vNKoR+nhGZGednRGZp9ENi4UBF eJaErspFREI6/TgVnQU43cNrS4LS0N9NVSBHy6ulQKSR1rjXTfs2AqAZwpcW /9LCn1Jhi+wXrdBvXPTD0MqrSH3rCnGHd7rWMCmdtS5gl3AWFHRCWQsLm9bL U5XVPq+W3XrZ63dvWTV8+uy7Z2+fWbC7K0ljFoZB29IaGHHgHpBGeN+7YLPf 5bm/e3lu1UaSHEDlNKpRtLNwCLgUuSNudSPic74E9YotbrHurdrjpBqDR+vL BPVuanl0dRvSF70Cl3UU6VAzpdbPpAJFXsYqplhiRmyD3ksMbBELglDO/dUs mMkwXnKTcwRvo6mGDbNdTBKjYWiBTQhBrsvwhAXdwjDC7v6RMa9xK52JmWo8 S7CcKedssJU4HM3EGKxNZ8w7E1g7K1qIsssqx+ctzVr6VAg1G2hKMxznpwWo AJubjh/sSYTIGapRc6XIMp/mffiQwjFfzXixxpf+fsHlnOQShQ0Xc99WhV/n TifieXWK5dipsMinT2+eP3lw/y7CHujqmigrfNvH0egoqNS5cl7iulFtdOQ9 qFYJBh6VDQFaR3sRhsDk9QeJzSoXUhmdIDtcZJErjgPTXU5rMjThcIDR3s12 X1aL7DkWtTLsTBQNGgyxCJCfgiif4mM5YHa+QRn3lwHgGzU+qJZwmQkiGx1E mFtFC6ocbtWehGhEp0p3BXE+1necx6RhKIC9ECxY3BJZPQkKuqCxcaExbAB4 2RnWjUetagy0iC3ZdakVSNgHyq0au7sNrkB8LAC6icN9X57lCy7+7iBNmB3Y wNaXlXciS4UnptpH9x8A1eKRwHhRUD4pHqpeICOXreCNCUK9rjLw1P2A97Nt 3sIBNoomNOcgUQPCklkkOmLaRqvInAFLYROP9n/+2dF53XQ5sbuJksA822vW GGA7Ebr10Q/113Mqh3SZwE0EOimmfj80AG5mKyexISh9Q5i6fsACzir6UgB6 mJFKurZptBR5YDC/nLGfTiLIYA2riW2BxEAKYAR+Us6DnW2YZoJ8blU2PNKh sXi4NA++kgXJNL5+d4v9MwZ2zsM4uz26RQhZajYv+iBbgXq2dNXZ/aB91GWT Q82LjxXwxdtiVWm/eslG5HCeckrWYYy5qVZESq9ItqtFQPYyoJ6zM7p5TO5P YpwOW4m655rVEVKqMHtBcU+Vq0rQiETkwgR02xeE9kX6peA4DZfSlL6vYzEF OSl5xU+h19DrMOGA8NbcwLgOHeJacs/MlwRIlLlqOSJ+onWmUFgup8tCmEAJ yoLBQhCboy2aGMSQYvByFCIsaTldWwxLIRH5xTSsNRpUVFzb2BjKAUm7Y1f1 QqevfA6KgDL890YTs1boOCwWztG4SfnzQqI/YTfMsZc6Wv6Sdg5FQdRGtkrl EasGVegatgH/23wo0kg58Ujx7LyN2N2gjjhZQkCSQxJmEoPvd0+LQb5kZQBV SvhIvhTpUKN4SXnKT8txubhsFn4r8LEcFPFokfZcOVQrdA6LGWblCuYmKNku 2qRSlUEutQZogXK7T59e9J/ul8ViBHwNmFtV0z/OBACSEotruNbYaF2E8SsI 0T5fDgzYnhwHCgZrcHiNKqCkEgL+2331+u3hoaZuiaRoWnKsUDkJCUi+Pdo5 IF0aATPIBo31MiCqc/bpTLlun+LpE2OCcQIrL80244XFUIUZsNJzWOGL/BI2 4fGIMfuJe8pGm8st5Kf5tMlRaQHkfYZLXYdKAw4xoQGhAA2tCv3Ysoc9Pact VzhdldDxGE7eUM5m3ZQ9JyBnlmhvbNBzLUPwTBy7VhLjTHG9ZZ3M76COmQBJ ziznXSm13zbi9YNyBDRYmWkXOolx4ZhjDy2tDo1uqzsgcVHtFQno63zNAGzp xebIfAaZA6VCuEOB/YwvVfH2y8CAlIWv/UuTaqellNIWSAl5gm8RMqDuaytJ x2j97mJFJr2cF47iovugtndKi+eUjB8s2tGNkkdpK0Hx2eAecpabFttO4wC4 /ALaT65BfoP5BYlWf42KUzdSbaoN1aWj6tRKZJd2p1goy8SjuIGJfN01/lUO sxsZRTI2O0Eh/wi1qawnDbc2RG45PPiNl68i3fvl0/e+lFUjur8XJgRsgxKK u7ktz5MoxvbBvpe7ybroX2RZqs2yuW6prJ7v/NiNuiUVIMmQrl496xa6BmMX yGypLhD8Up0YIg4Xtc9P5svFuQ8IUrj+wCImBrO0L00vSAll+wShAjtZTBn0 MFDpWitb4UiD6lZUs0X9F1fzc7I8wDrKaXFWTjVMWVQv64VdEaIGPbkMV07g bxZnEPxeRtyLlaMY1Z7reqAEflUX6IoiU/9jnaCH2e72GxeVlNoo9bMw5FIE 44+b6yQma+RAsyQbVn0hD65Khp5VSbhfcWyMTTgCS+/a7HvkCz1BAWhQZO+m +UdYNhzW75uuU7kLm/4SZqQr04BE/OK5JrDxsGMOeKG3qc9tc09tq6+OhmIw IP4xfHc42cXlDN4f29RzUK+AdgrlyMRl6fRQZQDcvqvvTFBFjdQL0I+rC4zl 621Sw8kVfUYUBHL2lLVFiHX+m3xwTlr2sByNCuJR+Qf8nudYs9nmaK/njEA5 KOtU2AydHIwIEgUFbLoEjE4rlhtnJsYGL86x3pNESjLn8z12FyFMDaKjaM+f MXrihmZjKsH8TWYTm8Etl0GbvHXT4+XREjDiPRL4YAs/apaicETGBnt0g02H rowD8NyKfBuxRBjYztDUwTYL942upNYKxfrnw+WYY7mHQObFYKmiEmOuYoGq j4SoM6/O8gV5C/ylS8YYOiHzYkzLWUMLc7TWqslQuDXxBTQA4ed9HUeADOzM eE/YQtDpw4MlVwfeY2fqy8mf7kYn4nAXne1nz82JFBeymMyNtS50sJEtrYt2 2QHGL57ncI/Ki4+fPX7KyD41mYHQrIYfFVNnRMrHZxWs3/nE4TvgLMSLiL0E vpU4mzCEyergl1SoDSMWuUjI1D5rRoNVxlMlj/QCbBoddQ+44k0kVYUt0zp5 lQUxdqxXLAiJanH/uNBHtuW9QXdhKuHaWZ3cDMhMLMVpIzeSVWmu60ZaJ3yd EZS0mZJ9Oy6Ab1VqoXFG+WLytAw3aI+LW/yytrhrWuHS9rcUgTQMb7HlDUlh A7PbtaxdKWubH+8KQ9s1e06ZPOI977KutR28K8Nm4MI7u9qd/2F2NeZSoRkt 98av2KLWW9+O5hshkX9NO9q6RrIml2gxkLWSy+cozmwuWLUqVw/QILS4KASM L9EWX4goyRcc4+aKfrf5eoiL2pAg8epLkTEyrEUSReflz3xTnDWLVAtNCbUZ FBJVhHDPd4gyIAlRxtFgqbB/cjugXfHzRooP3uJ8y4BAQgBwLPmpPqOzWO/S ddqPrzNAIjsmZYhlb4X5hWw3hCBG3jfG1jylS9CtkBdeyRFn9AQn9kr0uSRj RNbXYTEuFoUYYMN8DRPlGVsoaDzuHogCKtuLKKSNqdLrTdtTf8/i/U3avm4k i1fNYFFWRpATlA9YVwim34zydUB9oQHtKNt9SkfDxhgnSZP0uO+KPAD/uIWI ljX2RvPpS3VGq7eRh15891byHrumlP6mqqBFju1Afo9OkWpiKp6vFRp+wyL8 CvFdWI+9/XoSqyMRCONitPDdNTSui7I+dxDV6Kw/y8spnawpWVK0aGh42kHq QANLUGcyBLl2lvLzIBReK0lWH4qpb4iCghIRKG4b5kU/wtAelhL4aMIyNIxE o0WG5tLu651CMR9RlIaND2PVMxin482PT/bXzfu7vaJuATb3+tVJjNJAHzWc ewwkRkhB4uUzbzp1n2bhwTIlvrizIGqAEJ2+mfb8PYnVgRsWXt2lKATyGncZ TS64ydRS3gyo9AhKPT9OI/NpSIzLbWpiNDlIdcZX7TkceJaO7ZeKtpnEHI2r HCfeC7OUHCS4vEFRNBe5N4C1wEQpF5B4XecOaLO1H97do+gsH3puUj2r7HRZ jlnQNWD/AkJPQ6oH1ayQK6xRL1l5gkyanv0bIugrer709/L9iSYH8GkIRo2P w/N84hFiuruyQBKY3qSLafkAPVc+73AdDPoUuawHQ89vNpHoOZAVCODdizfP npJsm5LjyWBGAntATXzx1CuqrruixMgwZwv1nFIqSez7pgraf69OfbqSG4Xq f3fl/7Zc+SA2oNMjCPZGrGRTLaOrToYIEHTrK9TztTZSU2t9ymlqG69QkCfs JizLYxAJ84bTKloNzqzhmPAyVRMlfDyEBTdhzOEieajvuHutVZJqfGUdk57I NxFAoocD5xZ2yT9yiaTxCk0hIOJGXrjBeTH4YA53u4yUKBJjZAUh4rJmCXZ9 oElielcdky24EtfalJAAm5ev4njtfYE6Ti4Dxr4a5z1KvCt8gyyx1nAiOQPB phm5qtGSjzOWg0qRy+rYh31U1PZwaX7noBtwUFC6tx+30w4mimDiFe6a20fN veKEO3ppu+P4mFu1iKtKTQXav0sK5oG7sBeJrAok1OudyCAG4AuL1k4GCBbC IbLO4GgE4sHvpH1l0r4DpP1CMohea5mL177Mha7+hpFfLSg4YvtqQKY4Xrei VLAp3pG4M0LqtxXSgig2p4YHJO2eDswUKXd7h8mZJvZiam0Fipwc2A93uuT/ tW68ZqAdUMSq1ZMF6rKZ+2W43v0d7gUr99NV0YF3s12ONhnuNcQ9d/odaIex df534meL9OYe6qs9KYu0QR0mVtCx0tLDo/v37z94cHR/9ODeg4M7h/DHnfv3 7hf3796/9+CIqzKdZP9/e9+63MaRpfmfT1FBRTRFN0DxIurm9ezSFGVzbV1G pOzZ6fYyikSBrBaAQqMA0rRa+yr7FvNr//WLbZ5rnszKAkCRVs9ESzHTlgBU 5e3kuZ/vUM+mza0n+fbjJ/3H/Tw/3d3N14KOTpsPHz46zYv+2e6jra2t0z70 bEpNclHnJpnb5q8P+zq7F8HsDmh2ZnLYxymaXtQFKp5fs81TP5u/GxjRhMZP 0UD4Wfz25KFJ9DJhgC/dD2pJs19bQr0bAxkxhGZ7zZtCFbR3g7pVx/Ol0SJn Y/LckVd1TtPThs+AaCxyarZ1AFqY5TNvs95Ruf8tc3+s13L55J8Ht2tENT98 wH5KReyMpHuqOD1wNvvEIPmYqeru8oNaXvy5SvZuV2CWQQaMzRdamshM/tC/ /M3MAqloabKxs7iDhczvyK4LMAlFVghCKtEdzCLFYFuI5OZ92ltu+qdX8eF5 abrR9udJN4o6sq9+no48n9qNx03SyzjbZqfjvjENemKFQ1qsNwRk1IQn+5hO uuJaNE26erhu87RuQGZJaX5zGoO4tWK3ARwZhWlxMILvcaL2ajSv5WGUpg1F BrY0nSVCgKvBWd7GJTiy5gXzasFzmDO2GwOxdq6T8DXitromU9QGVMspllCQ gAZXP4QRCVKjFljuBPgLZi5XZ9UA3UgdycaaMEhyne7lKgY7Jg7tYIq4OwlM U6DkHkot4DZyH+41chlMckGL1cGwOpTY0wvz51sMIBblJWfKSDk/GE8SFzIp 494EnRR5TSboVoAXE6LA1YmMh07Dek8kUoB436YXa3gDAQv6gAuHOqpbXAkW SEXY5TOESoBk/Yqe4/o5Ct4KRscUElJGHHyNaJZhfNwGIpYc6D5UKzG9cD87 v9BrgE0bMdH7NMcZjMLqJA7sUi9JLWOYTmY1zQ8D7oy+4mj+cARfwZPPiykn +B1du98OO9yvtKzrGd2Idl0YGj96/MVhARpOeVZ3lFgZnAvBx/po5eZGHWbP pyCz0ZWA6BnkIgiyGhpMEkPsVWczSBhwJ7VjSYDbZkL2hVZrQTp+uNnpoImU hpAjJR9dD92NCvI1rFcBDgyLGIgKlEYYaEvdX3tH0p9Y0zvclleErQE9SCm2 csT/3N14Cot8+2L/6fbmZhBngR2qFLZRYOmwAA185HCZmGLmpaS0FOLAAEs6 fEKQRh1L3TriLQkT3+oo8w1B4noI4FZXfg6UuFPPi2O49zSbvZPDxdGRhETI 45BsaH/HQfdkC/GvbH9YNznIsxSUSKEp7GieQx36Nh7jjhgCqc1Y6BESxisb QChjOeaOAHd15mJVl24jrxfErhuVkLSc1CiURqqlitRHmXALo1THLr/rohwv AWE5vQGZyXBMYNg0g95v5x0AM0a5aUAkbgNQ0vuy5HA3m0eCSJL+pdxO/faH DtqLEWTE3JNzilv4+itLkJ01zakreyCSRc4uzLpaAy+FY4Qns0m55s9oTmKR zFjs/TBN0H0PCKGKlvnu7WHK7WgHbaTHBFc0ec/mra820KklXgN1BH8Kui2P 78uD1htbsABQNh0Eb3hF4aWEoquYpCQ8CVvSBEOZ9nv+uFQOEaH2Yvmys7HN 8oVweXkP3Z9/1ujJbnZ/9TvL7oBFkaoGpMLg8Id4oa8AkE0LMkvEihQnDmBY WdXbdyespyCmelblAfWNYmkYDE7p7Mk6Alygb9mDSwkQF9pR1nHakA/sW6gw NOr8Gt/iV8hgIpZLCjJpxQacjDh8VILKJsVbKTV+w7goZFxEj4B5EVYWkO6S T5BmIAQ5wewugydqFe15Jb3CTKPa3shQay/tjRITWit80Y5qLmKJqt8Nt0to 0XhVuG0ylFTGIHahp9mTbydxnA2S4L7nwhwj6EvS/kG4A34jqGC07KIXocC2 VXvL4cBiWLFsLqYJ1tkyW9K03QnMRgMgIjYZfXIdiW3Ym0kh9iEeajF0JkU+ KQeQVw86M92DeVW/HZsIehHXKtvJJmuf2XTtYHSrkfEXGvMEZIiMFrm232XA WQHyB0MEIvRXcu8XbBBZdnSrqyuKZhQjqMX2KX6Rf0HUvGyvVoA9XYSGRQRy 8SyfTHBsMM7yMMWPtKJqGL0ZD8WxC4DiHFwHBjTHMrzdKx6NUlGVxDCGx0im BUARQMfjCYj1gS+xAn7HW8lHCPEXpTvBaAK4JqJNWjzDmxubC+FWnSzNr/k9 5rb7HTTlUMeWNWsLLJJLYQ+wV+9eLqAn7X3lM/aZJOP8sZgcCP67Md4ftwKf 2Eb2enRWJNYhadi43VGmHykWpH4k4HRDDO4g3c327mrUo7X0fXueWHnLFfDk 4sNs6AZUJNEm1nOyhZhTNMaM2FlJMj8/CEQ1LJoZXFoUSawnY7jR2mBcBu9h AuT+Q/G8BC8hSEwD96D7jy4mij0C8yPP6aToO52H5WDNWni8xIBMxe/i5uxE PIMtr76ByFt3WnXxL6sxifBWcDde/in9xWsCuC/oj5UhvJvILQgslIPkDtxE AW168kntnNaaHrqgxYtcVkpKsLtgfWsN66UVvlGXYWwWMRm8P8mWWgCyHtRY uG2QAgt3bVv7YrPPSzJb+cI1OgPYEQR7noDn77xNTDAfOPHkPLK14fn0xC3y RK7tmm3vjcHwnhMTsKmkJbXhEqXIGp0eTsctLvORb66DlzUiWyg+aBIduLAT /WQMDXTYQ38T3tD5JMagrTDEdZ++x1HviDIlldBQITHnhmOPesxOFPJagZLB zcXTC3kcQv3e3K8USEw9MbRn8gQDEKQoS0eLKi6miMEjS2lmTjSrwMnzCyuL M8zUyI7gvdIohu4kuKxk//XLlwevnh88R/mjmEZ4rzwviX03QdmVW1YNzGBc FJMTnKHwBPzEgLm5zwfle22OCYfKswpaSKT4kfehHF945cqApzUPpWPiZagN SfENoaARmoPY3c2LrmvsmHCHYXB1Ab+YFqHJ606nHJL1TKaxjJ6617J6nMyv OpmbGdmsCxr4evKTQ1Htsu9A+hVtNMlKYP1C24jUFusmwr/uRhBj5O8hHPe+ Vo9Idq1uUfLNEvyYAo6A0/5KbOCKUdR4yhiiOHPabCZhK4PfxgYnNmqJYBVC 7+UifeLDB0fn8O3Q2UbmS+n0xtn3HTX+3F0ra0xhGBoKjSVLWArnJx6aMsw+ U5Z+hBQBbg47bpd+2ZUBQYq/mE2QH7WBfAkIWKCnNsyYnOzZMeKnt+GCUYlu SEuxj+bDvbadB3kZfhdPxsIOWrcoicqg81qD2bvloSKckHHJ9kiNF6ArDhG9 6AQD3qqbKw5gZMAW9QQB+XttegWsiEBKKyr+HheTT2ArOgRVJU/cDFElNg/t 7VP5L2UE4LXjW+Pm9d67v07z2mkEyzEG07RG/DEmvFA74iTzqyk0msKio/ca WbyMdEIjWS3RKHXeJbu5wc2hpgDmeE57pCtcppI1jIaOJxCbPMNwKDOmJHmo nZfSoWBcvewdR8Zdp/ASIO1Vfh2GPVnP1iZ5ySZm6otPd8IDVXkGnqxxpZ4x qkmLEQXtUo3Tdr4VrPkC/roFvaC02VcQ4kxujC9iBT3MtqELg2wm7iVTtpFL jpIS9c/q4Lu5G4hNKAi+FFKJIJtUwiKBAMEAGk3yDjr9UUdgiWHaHemkm//R TyRigPrDP2ss5ZHGUjj85KMneZKzepM6xwDhJ4QF8R6BrSK8pi0qH/MOTMog Yk5nh7RfMtPTJc/Qm+sm0sx0dm92i6IboulT+LGvgxrkqAkywS3BVQwvZ3Yk S7njLQxLiFljp+uUlODJEyYQXcrZKXuNMGfbLEN5xEgaRP6IRG6zDvSuisI8 d/80ggb7mKDIK9tgS+r2fWe2yJvvY0Q/5ri7owhmxlnHmFjgJJRv1xTUdmo+ OAcmVGbFPoSYToNuRItDKGGHv4CCozZvyf1ze3uDILk6vFhh90HzsLHQuoHY ZPWYIw9daBqrmVN5gBQxVxFNKozyMEjuRn5TXc+G4zDHiWM1moCkyi0mdswa UOFQVeB+tr/Vyfa33f/vkL2+/3DDvRA9nOGlwGhO48YJ8HLh/SxcWLX4YnNa snQbz1bPJxhfXYUZfOvjbHNcQ52kWdT0dQMriGIL7j/f7G4YTSnIJYvH1BJ5 CGyByIXQT8M5hLtI/tkoA9PHgziMRElt5qA9r/d6EEJhAR5h0w0VxI4nxZB6 x1lpQl5bOV862/UwBQeMnAZfBG0irM/I8ry+PKesi41mT6Ob/dnA1ywoL4Bt WFReAP+7dtvZrK2YVzYHWTAJmQkpEPaB5ieJP/5HK0LD5oHmJ4k//kcrnv71 geYniT/+RyvZfbgVj9bNmM1PEn/8j+5kO/+TveKy8W3zk8SfS0lTesB8zX+1 zCf6Eb1F792GfL/MJ+Yjeg0sfn8rM7uAn2w3Ptmxn9BHDzPdF713a/KLZT4x H5ntnfvnT8evs28PsoOfDvePD57/4hdxmz+8iD+fmD/Z0bwmzkjgu+uZfeLk wUoLAm6sFiSKTqTQ6eBXaXBOYOlznV1zipvu3ctek4fxJbSxbjjJku5H9tsI Sq6qLhfl+UV34HQ0bBTo7CsnaHwWxgVWgHizBF+nvgArXvIM8tGzot+HvDLB 3TrLqctLi+tHuqy+fbG/vfl05+NH+etD+euj7cfkk+AUp3RAWrI/SPRByAFS UyHgZkPUGkxKB+fUAyDtAMhl492bQSeKfABYhOcXHk3FNDpFuDrR99k1nQyQ 8alcg7mq5ZiQ8OaUP9JbtCQo8hl1aK7jakohJlQfejNF2ZEXQbaU5B70tKO0 jQy9Jk2CEmugch6rZFPpCmrJQXPVOogcLAiLTn1j9KQHTKuGc1Nrhd4/+P0Q tbARdssUMzMMtbFen6L8rvRSqEYUT9oHKBVJQGj4rDUQWULcL1Ll+3l9YYZr jQOsQ3aVmUw8CrfHwaSva7g+0LshGwCFdOHO8Nm4bTEFRni8MG040T5BIkNQ TE7ce+Yad3E2LQdScoLgy8hZ1Ojk7c91CN4FSstyhHRR5DY/FNtz+wgENsuZ 1h3qGlpXnnaMl6+RzzioeAck+86kXmgmWCdIpiJYB7pU8+kNlkNlhy0Ek7pS 6BijSrXOvNMj7lWLw7ycADDuoLqm6M0MWJGnV/VuQ7GVM4ZHrfubSnpjbR/M C2dJIWYTbHCf8rRxZRhIcfuAfrYe2CpFzaEmSisTZLyU17mW0vtyohFS336i s8xWMwZAeMOHTSwfmkXSk0tJC7IBmlLQIjSQVCeFuUS5o0QJrSxOZojtcfI1 1uCnndFROQGYJ7YjvYtSOWmCxei94GCxlILVzfBwOklP13knsWKOaGA6Bb6g bhmvFkBaU3Cl7o1AEA24V1kQKtbmlE1X500j/rGDpBnHiSAVFqe/AbbcCAEz c6cDiIBHz0rRW//aOy3w5+i6wGQVyJ/HsIs4gmt2dlA3JceyJty43m5HqXmu Oekc6H89fCO/JxL22PjkSHFXhaqCkxEiLSBTzWtScHq05McHd+rr9lQmWkU9 O5UrufiORxB0kOvgsw/kxMWBTGiJyAAE4Hiu7A8iPbQI9D/poMjyxGMdjrYB ReSpMP9pYSKugs1nbs0gv0bvr6CX7b8+OtAI6CLhEhdWLOZaN1BQsj100BIm OHIjk9Pg19QaRPS+ohSr9SkQNq6IocQOu71iByQnQn6VvQYvtifobgKeHaPq 1GZKyq4aynqu4CsKQk33wmva84ux/CVtDRy0hog5HtgPE2hSAfuA5t19cV+n TQeThA69sHz7DFBuDOHLuz1cXjLyz/GdPB6EgO58FFlehwlWeGH8i5fMyVmo xrLDmUK2OQBPAmxvXCRQuWm1UoPPxEPYyhqMDFiK/KtuMelQpuilWvWqc+Wk /qp4Xss6iZ/mEwKhtV5VMxPIs9NJ9R7zWSAiA/UQppCiFLc5s5hOQh0Dron3 3ivldl6Kd4zDsInmzOqivAxlYvP20rW7Rs1G9qZn64kkkK3aMIb58crKnimn CNX/TnKm0baJJcTMs8+ZP9XkPB9hrwBHGhAaOsXH62YfPe8kQNPQXi95ig28 CSYFBT+YpxzOJrGFY9JQa7G/rxXnlCinHJbwZp5/UB6zgL0L+gACrF6UzhSZ nF1cM+c4JlXWzc8qg7Qn4enHCjAkBFTCxzGpIfVQo7qZMhyM5JI74QSF9z1A pKI0bXpCe537FxoN5WYqWSfy9EDk2XPe3Jls1Xk1QwmUYtIegV0TbhyDv1+v +9pwu4/wxRwMiuAKBpuHysB5PulhDZZkV4k6zKAEPXNLsAy5k7qWzCDD6jDd bbe+QbcyNeSLTCSTlUTY/Ijq0LQ/99BVBCgzHIEyI4HQdswSZ44ugFSOn3df YNAcBpSqyCYenASv1H7BQsCeoKP0Z9MFlWhuw18QgAd4ETPyIpKnxI0GqGLs sAuTKsD5yi0dYj1UvFbzN7TD+CGyzGZuAHdCuaLs7WifaCuxG2+6uiNO1yPB mmf3h+4+gEF2WYyAsa4ji9DI9QIqwCMFwtY+DUiO8ArOG/ApnuB1wIxvOT0T hPUVGvxonfcVvh+1BMneMEeLrdqK3tckFBPjm7HZnkh7SQnBxSlG7sfm/RoZ lp67bflf3hiYT1itZyMtQWCB2hakfcBQjeOl4Vs1AKBrg1wQytOC7U8We9T+ BFFSFxPpKw7cCBgdVBKxKnsaN7BIbak/kotcnhJgJ0d3Z54GIlVEy9ecMXJZ Av/lqDdcSxbfnKDV5mFZaDm35z9st+c/zHGdVYEJ8SUXopkLcYMZkGIp7FoV 7uQMUjZTJ5bK3rYTLe3lux+PT/aeP39LPv9gxsMv6RseNcugXkRCQqbRWmWO D+IkawjFoknDNA9U/qKc1Kbkt2YAtkQyR3i5OmKiLDpVlASJkxWUaUSX5zUb CdkrHAcWht/L0VwZwE5QfmlSlvIVGVWjrq2yvokUxd1Cvr+/RRd3m1hh4L0v LjGJjuzWlH9MLg+ZrFpAFL0Yde8otgfAeMECWSA9WyCIUjXPmEpBAgAeRPmy 9EZYiF3s7R6ImnC1QWbQDpQXRk6mBaTlPTRBwpKbw/5D8ma2cLSbEFHuNBdM HAYyWkRF6j8pAu9JfYGhPSmf4NmJDf2f/eBOKzcUzxmPKZGYdeukLE4RWZRY sTgti9Irbp2WhX+WSBJZnAnyzImI79pzOmxmU/TD6CXvBFgzPMnmTJoDyEuy xhxAAfWsxcykbbRnN9mT5GgPb/iStj93+pI/2nMP/hH9q/vH9pcEw4VjRzNJ TOxOXxLkh4XJYlHqWCKTDPLGHojIhQ/a/5H4d2YSx4J8sPQ/Ev+O/xBb0KSx IF+M9gCTxcy/+Q8mjJn9WgkywtL/SPz7Bmwhzha7NYg1TzzIFPu0ZLEb5Iul QIrb8sXak77mJovdg6oaAU8FcDUR7i/F95xOGbNxKQ4jiyMk7S0z1VDWBEym LvmKXRtrd7NLRwMIy4zSdoLuWVeidceT0QidJEN4K1KQ7UnXUa8euQMTPtQ5 ocso7jJf8vNEeByKPhu7wU/wooJsMM0fW+BWasTJ5pS23yBMRtZWMUKtF+tD tdcYF/acFt6jCTsZR3sXOXiOL0z/1fp6OIRqkTM7JOpV3KcSsrZGXHCZR6gH aJyOyr/O2CfmYRLcLlNUIIikfJXtZd9CQeDhT9QhzQM59ExHWvLVlr9ppsbe wd5zbjdqWlLxq5NbRW65phnHnUQwFPr66ODkgB7ezKrTv8DeBSZg4ygwg497 b0D8fECK8ZIaaIAyrSkziz1BNA2nuZaUkSI1wOmLnLow+hIDx2wg2d2Qz+Et 9/f2nq8jQDU0HFdUNcxQhL5mYT/bW6fa4KyOSsGaYsw+dEePOJA9JwkzpAqK nmmPYH+M0hjk1etX+wcnR4f/fiCDIIGVI8Tgr5uUtpEd3XaBGJgWtAcfn8ao v21rEw2sAS8iWKL32CWHFZgK5br/+t2rYy5E3e5iV4HZiG8gUM257cTVi+Ad QgIHyJKaCzyRyDFHZJNYLmLPsQjwjhVvwxlvkEQoORqsmGdwOmgEo8QxWxhN g1f26uDnk1fvXnYknBcZhNL3ap7j2yJbcqw8MU/o/O6s6J46038rJhUeE6bz Da4tCXWzbaIbPaxRkse8ge1ys3D8judvOj7A2cLtG2mUFI+RmtTIsmXGGH7e yF6U3A4hugC2QTaP9G/QX8LAGQjjFcPcz60Z48YU1+vI4oeMCU4xpdsA0AQw hRQHjlv6vnoNxYSz2siucV5OHM+J3uAOpmNWth6hJzJkjglGmLwOeGvErpf1 DgzJler4yPb/3nqEkb4gBo7vbpCN587qJbnAjhpCmEkhE+CKhdfaA/7IBVhz W7rWcBnHF1f3XR97X/aajzV7WXzidjUzzOytisXObHS7/VnztNr05xOrCina XAZAASBPslL3vJT2tlKHhBtswRZpEXxDEcoaDbgitnFWzcCOQBQODAbP2S3W KiQtDiv+Gda5RlxnhBPf2JH+ATs7T6CyIxEBMvGeMffvA55P8xIKiqemZ7zv vzhxezI74yi26ZomKbX4P8wDV/m5I3nh5qq5VOUlyF8gTA+LKwmz2JPLPQVv IYHxVdD7mcX8WTl2CoBN5U3t4j9UQ2ox7BYyF1l927Ux+HrtTMQTmeUhh/32 BH61wqRGPYokiWZP1ywE3tHRBOOtadtF9yZi74npIoVLfrRhoNnewPSQ4B4g 6WYJIYCZafTM2j7YhH7kANxWpqtxyWSSTwCQ8753xh01DS9rgtCFttZYWriO fQvX+2+qN+u+ja7pQh62SPSNyG99siBxlzrYJTgkBuuub2NBY0KPmwawhaY1 bUApMexVYoLc70cL8SHG5rLteRygsMxHxStvCiEYXRmuokBYcoHmw6uvjc0N yqDSZof+jkqY4Aw2CCtF64J5COg31e2tRLtYDDBzbkVbME1z7ekKsRrQkKiy 8/vRF5tqYWyvCbttEGGLBAmU8+Zk2hwOIrBQEtgEbZNtuxCVKcYfa+amovuL 4N5eRrh35NX8gd2Tcj3vMSj/XLQ6D9Ef4I9QkDfXadQX1QQbcPGR2awDbpCE qUEdG9sLmIVvYWHwoq1SJRFPn1t8VVFPFbYawBonJG84fVlV0USdtlZTXDeq cdUJZBtoyjU7K1hS12bl/jICLnbSSMWOb5BhKBnDTmcpKVUR97EOwrcRkAzn osy1ggEHeoQdbqbcfVCi68ig0LoV1ECIs0cZrlA1WA5Lhj4ejqG6TcqesA8Y 6loVle0IXFEFjeVheu3QM+hdH+a/lsOZE+JDuIn4XsiyjPxkJhO3I2YZX46p KoR1NSi4AJhXQ7aa4wJhvue311GPKb/l2HAMm2MFPQJ4c3S7ff44Qh5fh8cM C+dEyZYDf1VNteMb5uk4S9ikZqw37xQg/TmBChjGmHTC+28Qe3ROCVtlqUkd +0QOdCkiTh1K7kYLk2u40QKJBGKeiIMR2jEbrZ3aDy7dTs88q+TLg7VYmNuo aaaLfDsV8QvMF5Z89EnR1YKuFusN5UgzSiDt3Qu39t4NL/ecu3c6m7bf63yq L2NU/xvd7ODQwkGSkFXN+x6wllGPOQVkzeeTHrEDbfKV5Evt5xMzfVZCovss yeS8y9rcWZPNAM3KaZnuYtRUm0xsHi8N1e/hfTWrVPmDAMRzVoxSA4Jl/rD9 KpnCcwalguaRKtlFdeKmcen1BxGzECa4K/yNbhM1ABOvEm9Yjt2iratzNgow wjg1ChXomMdBq52DXzkH9wi7JDK+oIj1gr/tYg/FGKiC5scppj6Vl8txT52m 43QKaWPPre6JIYdQAoEGVBfDHHRuX6FY/DqeyJmgssrdFDl/MtBs1TcVatXO CDwHxYtmAWohc+UYeBcWHbSB7AoYI7UtQ4cMkBDc8LcCrHdEKHKg/I/y4Wl5 PqtmtaGm3N9U2wmyI9Etj4AZv3LijtODYxjiqLHLTrPWmPlFObqsBpcWi5i6 YOruahl6eG62uC5AyljD59eys0FeDlENNQupO/o7alDnC2jp91NMGM4lZpA3 OhtHnZLiaWnaPKz4WpRcmZMF/+OQpdvTvf0DEwzymfl7QZdPCxEYfxM1re8F Sh+X1AqzCp/l0ws7qNXZ7saTDcoygr9JO7WgXefekU5pHxoLwtu+L8EkEgas JB7TSqMf6E48gEz2MOgjqgvVNy+xGGg3Gq+AaSoE/gzoJu6O1CA+0G+qOojO bWTflZe86eE91pwHzzOODl56I7awPTsMsXUSHELnQm+2merKd+L3wCgDnC3G vfFrp3gRaM6Tpw+fAs+gcnT4mHl0VCEfzJ13kCwQ3Kb8HAivMbLxb87ZbimB MlcVqwbOer2B4+3dTWDwirQon9Jnp7NyoFUJHFqpl+KSWGoh6ETzdrkOsyh9 OuX+8+c/rnx9Tx2Vk/7Z0+2dxysr51AhkH2TTd02rKyMIb+bBL77bAYKwcYp 9G7BxgcrK9Sh4ZvsD/ch3sHXCjqZb3XoA5wXfLCNH7ysRtCN4lm2g//8Cd02 8PXDlfWVFZzyCcDelvjWvcMX3e+gjVJ59t9wXp3MTOhf+AH3w1M32WwDcXiD d6ysyHacyE/vPdo43vvu5MXrtyfH3x8enTiS2Ht1fLh/dB9/sZ7cLsxgCo40 TlyC/SRpXYobj8WxV04FgCG8+4dGtpJuAIlL7YcWHhAcgP7Dr/3affanjH7a yf57dh8PLHvgPtz+Cv/6S7ae/dLc8j9lX2X2Nb/8gzbZbPGircVez3QKpACO OAAp7Ak2h7zTsHD+YPUjMYJZrXZcEbMozzRBMKLxzRW2Ka0gjStfTaIHat8b nIt3bKLQRvY2B9el+BupixjCvNArWLcGbTnQ3kdpXBRSE+aoc+yBC9pnU3N0 TnlH/p7SNEHHs8tqmUJtbkBCh6Wdllo6cTGSDqvsHsXmhw/w743j/Lx2zFPY M2rsxO81ohIpYh0+BIEl5lwJfXvZx0rMkpsVjgqvDCHavNMhnZ7Qu87uvz34 1+0nhNEi+uSk4D6S8iMBqO/4V8pInXhkY71jlaLCJgdN9C6rEgyoXkEWWf3X WT6FETwGdOp4YHvqQHI3i97NiOjxjDDQCRh/e3cb8OjgBxv8gw36Qc2Nhkd2 /3RxzUwX6ACeGIZMZNm/YCOCZC0bVM0eGt3r8WPuL0KtGRDCWEDhuN+Udmhs 3ypUyw5fMG0adZluIiBYoe9CUxZDnuRIAJ7W6kLMCCN0CHfDEaGk0d8I1+m7 VyY2xydC6lLc204ZzB6ZDojjYyARuIDHICAlLQla5URI/GxhMeQe3vzZtAJe cNaYDurgfJoppAls55SYMlq9YBugQxvYG+QESGzjwz00Jmo1dQN2qQavsbdN YIRK2E0+CDmJIIYuM1ZwX7YpOsbbrXDe7rfHyOqOwafh7LfASvExlGN09ANZ nxbQsbOeDYe5E91ELsOOqe7X+ALsmE1RHDlSprgCekxmgwEnCozRqQfSyu2Y d0XSInplDhhfxaJmehL4xJ0RKq+DaBLChUlHEx/n81Df3vBBsgh1xpU/tmSn /zH4T/pL/sfK37JXIJSbCee0XfyfY1iv/fJtgaa1M8Cyv7WmuP8NW/21lGCE RQ53tJZzd9lSQ23Sf/LJJL9ufPknx6q6/+b+/HJ38xilNvVv2ZadB9AdKEC/ 5zzchUztx/Znngcx8+Y8uGjj1A//O59LMcUAbR0N9dDux4N582indf7PUYkK L1mmqyPHVFZ/H1o/QycMLieYx+5n3tMzyrBsDPXoc8/D7wfH32mo7YefeR5A XyfQ3zEcansX/zP9bPPwRf7hPB593nlAj9Z4IBjqMf0HFOcH0Wx+l3mA5E/N 4wn956ggp+0q6EfpeSy8+16t+kEHi+7+wneAqK1XReW7Tr3jbvbDqXHJeTyl /8C5NL/8Hc7FqU4nqjqdiHnsZOXm552HMyOS+7FFVYezxER+p3kkRDbMY/vz zqMpJ3keBMv/2XQp3841msfDf8A8TBNZncfu550HQaZgXLT0e+LmQXwdGkl/ FvqQZLcGfTzOPqu81Sy8eB5PPv88IuWD5vH0884jgiXWobY/Mz+NczZ1Hp+Z PhpQQzIPoo/Ppgdh5j84eKOhtok+/kvZHo7Wzy7ywaAAl42Zx87m5zzbVCW7 0966qoZ1jXeLYxZt3q85perkAKrAo5kd9ChKdggez3njgQPWnQX4ogVVBQB/ EOMPHSfoIVz98OEPRwc/vvj4cdU7H2EcW76X7IhLnSLpW/AonU/y8QWHULkI xPtFK4J/m0wVdMg6obACyK0IvWEdD5mOqX78XAMVEVPE/Fs6DOXGdfboxUKR XU55HgQEDUl67OUC5DDJtcOMDvBtohsWPIcleVGNh3n50I5JQ5WYe6exaii+ cZwJaiR+i6v30YHJK9ddPL3mjamNBzoP+lPyM4wiK3kZteRdITyfoCFKQKWc UksPAZ02QMOcTOWR+GYQsYUcKHIp+5RUiJQEBfd5NonxUy0am+Sgvz3413eH bw+eo5t8+dAZEBTszRTRiUfF1eBaT8rucWNP86HZdW6RAqGbp+sNRyuXb2sJ kAV27aFrHSPkNYfKcpPRPWbAKBpT3P7e7Rx8bHJZpC8Apg/1glYRV3Tglh41 lfwmXQ+0nyl6h4XGwrzsoMbxK0lr6GRrZ1JssAY2NVYgFPgfxy3gP45U6T8l /gYLHNfQFYl/ofYBa6jXw19ihRY+Sxpj+JSBDEz0PrBLYxiGBYujtalDbs1c KsQcpacpnMA8jo6fglIYJ6GE65EBtSPEhV5RlxMODkC6qGMuGG5VhFOeqU+t qt9rOId4UJDXvtZeDlMv6KSL+SJur7qalg8pI0KLHz+u+9s94F6oFNhtQrnz pJEVSwdTjRS1zQ7uziBucyNz46nxy/KBk30Dn8vkD00ZsruQEQ/V4BdOy7Oh M8vFATjk9iyHkQLcSeIJMTPOhjOoBKGALQaUoY7BEF8QcukohUw4lH1WTs5m Q0osrZEb7WwSzsia8SgSWvRa08eIdJsI6+i+UBa/lRJQqQFh6dYKK41PuQet lKRZWd0LRw9uB5YZ3/3QnD4HHTYEXLWRnOAlVjZVbP6WYB5TID4YgLuseffp P2BxBO4K/aIu85JaxPUJSRq8hzCpGvS/a5NbijXxIlaJpwUG+k1XwVmok6I2 EUG9VGr2CxBKLqirkEVfGpb2fkRZaEO4Ek6Vo1QGCHhn+VWuNdNDSav3HExa PNBqvPvlU87DbTlOxDcxIrUQCiCafLZjMwSuqPwVWZOA6WCnLeaz2BoqQNtp 5YJ6cbRcr1HHd7srDZvnmXa/YubSaZSdLa0r+CI5IWsf5W+ncCJkSrbQ5nqa nkyZ/jxJbWZGm9OosLzhYXvVd0RVONBPrAF+JTUoDRgf3+RFc7DmYnVRwR8i yx6+McjNxEIa4MKfuhiYH/TpQLOmT73hfHs6gkJo61hxnypFoDyCcuEwI4Na fKxrOjIkx48lryNcMnJKW9pYoTEpg/vaPmkN0dgOyKvGYkjcOsmkFy2A8x7C S8Q49QeS9Gpaa7lpua2nmkjthOcVdmmzIbg3p1x8SyXQOefEI6AwLzeq0OQd KX4tzmaau9NohKhFKixh2sntpjSVyI45mEwccRwap++HewV81oUMkBtkylDe T3Oz0Bp0hITjGF1cWBBsm1wW+pHYdTVRW5SxZXNSAD6nrAvAy3OCbNjlwmDM Tulo9rTSwRotzFkNlG2C7+c7uu90LCcG39CbuDVdRomoa0HuSxffsiYC3rHW btmnD2uS8akMljZvUIuPaOVv2U/o42p6xJ5LAo87iIYL6hbjZRm5tl4L5VPC M+ICE9x/FdHzbcejsJMoTGjlQFo+lq4pBALBy7NQvd14FF7am1f3D1h3Uyp7 hRl4j+TfjOHj5omoynnyDG5/DhR+Ohw56i17SdgHBXy4k/EozPSqMjohtsBo hILuaH0UTvrO0tJFOc4I0B0Z8d3u5yMzHnkVUzlUdzPeYo8tctyu5bhJx22D Mc/x32JXNRbvgWSPGKPkPmNy7dPtp5tcHfJpDDDIjY3YoKK+SdK4ceyhCMTV NRE0Yw6NWc7lyCCKGNctYYlhPVzQElN7A5BTK+f6LPHOjopffUnrPomQaN01 pdCWU/dJY5KhlPJQZLgA2uk13jjd3OhsyqmI7hH/Ekx67fLsEYgYMIn8ve1w TeezEmAeUCZDDV2nPSM+7XyA7WTvA+Kg0TKKnm6eqNi+1yTuJZowgyKfeMvK NI+jnQL1nqMCPVRfJYUdQGfxF5uB+4cz0x05jrWynRRJERQZ/oVPWx2+Ur3Q fBVhNYAJg1+Sxqg+ByCFkow56t0zHhdA15wVzmnL9I6gObffCypX5wrfSTWe gLYc+g6kogpVZfnCCBV2dyMBlFO7sOSWbQXrbPjTZOWToqvL5g6fqMFLOx6U qqOi6DGYG2u26CVUPcBsOJsZ1PadNyPaC9oo2RHq5hNsRNtCsfGrlfnBY96T yRupTwMdsulQcRWbLpewA40yj0gFUkojs1aQFXx/uJHSlI6qoCdYnhhh/zhr p53q5myEoQiYDVQLUzEKZGGXhF2BS0qTwHYwKPsieDhgrsWg36UaHqBF49DJ PeQvOH0AhZGQQ30fPxQeHvjIgzrS8UVZ8S33KkbnCbdHaECMBSRMiHrgRrUp aZ0spSWyXGufDImjANcJe+npEtNbvJOauPQXrzzgLBZtErBRu652em2gCHxh kvXBSMirBzBatwzFELAB1KxPpbIM2idiTQnd31PCg1Gkl9BNUGF5xqgaUrV7 r8zPRxUXstPuoHRDUJIR9LzkhH4Qryw2bNvJcpre4oepLb7KS/FanFGjr+z+ eIId16mfSW89govpiJfPCVMCz+iK7MCaUZYdi9jqbjAbEMognJuxj/zczen3 ZYbEd+axxAssPxyXrXL1UWpvz5y4HgE2F+yL08imWAyUT3rBCjvZX5xCSD1u S5WPAJEby5JRRaACcuAicvDA72VHAhy7zzjGzIgJggIus1Ng9Udn4Y9yxOly Ur0MULZBU+7DrQF1WLRZKFInvUd/p4qIlqDYOwNvwTvVLPz3vhpzFDLOttZU 0793sALs5xCQvkXzDnRmr4QDqUfOD6PyIgrmGWmTdctOcZmighFQK5tdrVMj XR9b7IGC6DvVDRU4xquTbYPIo/f4WEF9tg2JmVGRpeUPuBuUmUpLg0jOKqJM HsbzPQdgeBjRROlqIVQUdetLNGpzZAvKTS290fHlEJgs6yHMlpsBSaEj5rFc B+BO1JYsd9xcswH67owuRtgFVwhDKgO/3dhS2IQnj7YcZYAk9t9vbcKXh93n G2Ux7bt9cZelqvE/al4BNusR9VHzc81LLpnz4DTB7gVQI3xZJ8VphT2eYBED 6I02vTBAznT1YxhfbWmYKBCuTTElHYajhW+vSWijQuR9+hjkuaQQDzuNByCR LdueUFwTD6+cmobVrLWwiGH+6EFPrfYyF5O42QcB/dlcuEh5ORvZzxfAEBY0 bAw7bwc3EUarzqpBnXL6B/tBtxkibGqpUmuzRbCbbleICV/lDG0Th8+BOVfk hSddGJtkKuiVOJNhGYStT+260pBSkOpg28SheobCA/tqjznQ5RSL/Ow9ArPQ ZuVDvzwFA4LZkoccG3gKpK0+DKanV1MRr4lKxReC2RnAL+3oZ80p8sRDdJ85 SBMwkYs3sT85Ij3StDaSs1QcKDLEy3FOgPJNMpPTwW54QP4QG0TsQrVekFBZ UHoMsxxYsPYAd7qb/zlI2ClWejq6gfSk9CQJ2QOEyaiAe2x6tNUq6RruPZ8c tERCiBv4NSO24DQhZhlRYNG8HomOk6RJ10vA0bIVlsabXQ+uGdpw7HUqh87y qytwKsZNXIXrRD17kcMb2Ona9HRtFYsTq2pUHHP6NH5Beoc7t1SLXww4weX2 r6ALA5Esbq3QhEtc5PtRpWVIop26orWjghrBLhfvo0/LDK5zOzJcWvGNknjk 9euZRU9e2DGFKvcj7C83ZfzSz/lj2qsGi4CMG+rcbKYVL4GR3zA7CuQJquJs e/nOrCbO/XLvfxE7XPTmitIbz2FSoEA4Ii6rHrRSz/p5fUEh7Xcx8rgBzAyh 5paNw3Na26LZ4YJD+YP+e5JcWPlvWrY7iUbhX7O7+TXeODwJM5B2ThdNTnve h7KObSK7Qr3FYoadOo545YwavXY0rxFxrObsDL2gA7QcsUbASWvShYPR8cLF QP8tOTSJ4hJGJupKkyIHHgSSitODQaU8Q0RiDghzBu6EL17L3nqzpDfzWAlx BNnRhu+pA/DbAK7qA7XhHSuxF1eDBuRqogBTn4CcC9j7AH8fmIEJxN4RQNqK jdWvBHRZ028gnb90NG4Rk6MJzOEgcJOsF4/3eqjdBlDRYQU5VKcUlUE6fKez dRopuxHjV86SsHI+ckZQr8gxnwc3qWlgEHLlBaKz4mZbvEDYDzzVOr4lBSI6 A+MeLLguBlq49B0UyD7AzvQ3u+lrtQznAefQBsOUrssIOxk16agjlcImakpa 9GJEu571+5AGho3F66FTi9QeziPTR5oNiMae98Eg7BXGsvBAqOA/GU8T55BG zG3ZFzWSQMWY6sRRLwI9RleCehbGPyI8245Ij2aXZckrDHHug07jy2bedgJu ipOhBLnaAKXmPUR00qx82OCrvN0UIcEdblbeWAj7xqQFB5qlnvyCFEvxbYWM SY9h3m4xVyEFSDuUyILVlRrBawcbEmmMuB8LzbHmHjRE+KBHvm9WlEcL+kMI hiVj/+YIBYieYmcQuDdFXa9evXuJVhouQXMRI/ecgXgiCYMHzdav403nVZBw RspmgC/LdxVKBcq+hzl1GgZxSxi+TvFWGIF5K6B1k4/Fi90o5Umig+rDvfBF HZo+Zkp/QOYWEPPFy5aUuYRJ2pC0kECGwa9yWPj8QTz3QBcJSiOSIlokcrB4 L7EjyNN5ag80occ0OzRZga+3iP8II7jse2PNS+ael2mwq+Ct+uuM+CiSLUX4 iMaiY6A9m1YVGnKmYEpXwJ7uaP6MVbxI1UCLhrOS3TqQWDkDS4COA0mCqe76 8jRIfK2KziBXFGZdELAx5g0FZc5fF1PBcHJM3KnUhLA0KjCzwg2NNj5aaahz gwpgeIdjFlccV5UuArI3cLKgBrizIahpRMKHgVQVRd90NQnU0ihayUSDXpJX WHUkJxtxR5yFAbyWwMBFS6cuf7OcfRtJ8Bk+B2YtoV3jm8Z+P2P/Rp9+jufp riegxfVQWnp26ZH2TYjEo3SjFM4l5lRjynaM5wce33I6E8+jYg7HCg7Z3+iU xSKt8aC6Nh4v5aPsVoKkBh9jUx+KXJrUNpNOGW81emv9I+EmUV50U6cQWdcU +7nPQEBH0Yx6kxs5ej0GCxBih778J8gnZwGbWoqg74pHD3Z9VvvqyVPp0yix QfKWj7TZw8Q83vDvuLuCnilW9eY4OKx3NiFl3e0OvHheDxfWr3kN823UFle4 6NjoS4VWBayCXF1UgzmvAicSh5y5vwEfS6OVcE1hkcDp1jj8hhtSBA0ia87v mDRHZlG/XlCFa2qcnZ65YWhGI3MmLJ7gKHt9Si08HCWqj6COumiG97DhnpWX 0vVBUsL4g6SdyEa4w0YVhIaMtyvaJhQEdJCB9ZG6sXDXy9Fsyd4rx2EDBUpG cFOdYEKRWvcopMOoS/0e3iQRqXZbNVbY5QtfmKYxRbr38KsaNXiICdI8fLvV SMyBw0dc0xL0btYTNNJ3l3aSyd1bLpQG2Xfudj+vjtgxzcFJ0hWd5VUAXxtc B6qIpOihPYgMyO3L+Tn1QAi9Gxwc4yfA3ShA0sL43EY+wFBqNxG4dwzBvR/V OEJnrRxhjeQo5fzhSOE4S7ebTmmHOt0G2bwbOBXE/ct6L6j3EZUOwwUdVpf8 2rrgHVBLztsS902nmXW0LsENzk5ZeqAtBcGfDt78+IjcRTjnVDkJqzRPrZPA fBWNyLwAvQHe1AQDqr0pSdCyFetCYKHCW0Dbw6RFVGSrESVD6szcwYRw9A83 HnNUlSBh+a74r3c3tuQHjx5uIdXeu5d9O6jO3nd/LhEs1HpuFL02+IWbZDXm 7ASEn326+xTG4goFz3IaIqIWcS3Cblj2egOu6zZjTLlKMOgqw1LzFH5WU9qF GBftAo4d5jIs2JcSOwPGR4/KcOj7lODMaQX9b9D6hiZiC1g5DhASXkJAxkuW gYmPomqcEyzANfWL2shei9+6pQMQLJCavggsKXeoAbLvSO0cGKTikcT8iQYW gAbMHUnsQ3r/RJL/6rNi5K5cZXRLnbf6k2HW/gAjEAiAwe/n9XTe5tR8mGxG hSyYWB2YDTNQgSlEPrFGzoU3Tk7dAV+VPXd6p9eWj4Kl4bNkMQhLtCQhWM32 4qQUQNzF3JzDvVd7jZuBio306qO0wougNazJCIYXbKTxQ978A6BBoLEdotci mutbgykM+UYIbItlTemqJoF+5kzu+eC3axYnt+8JL6EEB2l8dm/DfhmQjqQg wRQPnlAum8kQFOxo9y5EJCc1NEBP5sYaMglJJgzS2JG9PXqCjYCpfzksA3AU nllDDL86mp1OzbeNnViR9guolvq5PstePdjDL1+PG5X1/ssDaUgZ+tafZS+B EZ4WiWYfAADGbYUTSZRBihUTGC2yJcvsGSIjekc+JO3042cPwSmBecSn5SD1 DlnPG0gprS+KXkhdz/wL8WcBfD2qPVTNgOWEQljPCAQadl8w593VT/VvcXed M9c6AiNtu8fwEBawAshND9Jk0+UNUgn24YW7bUi8ppF421aYTsqmQsNsFcbm sz9kYF8PNFMUm5S50z2jFFBJhgheAbP/+bsMngMSGABU/n1Hm/8D8qo2qsn5 Oqh2hwfHL7JGo4C3hVO8j8F7tDcpcvfYZOof08PGjFns0PAsg76rr18xoZND gRDQR/KLV04A05rxcB7s0zVWnwMAKrnJ0LLBD1zTvtibC29BHpbEYv9w74w/ YQ6GzBtt0PdiDnKPgZBfU30J6wurqXcbLE5TEel++vYgwI/SX0nxPL8Hucez BWjh/tf7eN+fZV23hueOxL99vrKiaNvBPXF78Ro2NMRwL/NR3n0P5HDDXSi9 u3Y1fq9ZXciWlYXG10Jz+nzK36PH0BUIfUr+1cw4FRwt/JJ6gEDZNZEA4W90 J5qy3MkmdZc+1eRQeAVT2H5MYe6ro0CsPWdxc79eDzb3D6PTevx1cq4WgGP+ dH+nuaUOHln/S0dk7mRCMnDm9PgOSQFHWpGRPp0wnmxQuqdmJyNhvGpQAy7s h+Iar0J2f4J7193efQRr2N7dXXe/oWJgumcpDLwHhK7nfpm+Sf6wX6VO+KZT +NY3q2od0p0hCs0+qH+2aPl+2f9mPfuxHL3PjqmR8d5UHEs/UcG2O91+V3nI jZmdnOynjv/JDJF3CdWkDcovhQ/N6CTSMVVNJ8e+QzBN6CKR6JYAStcEgjw4 QulbKApUEt5eyo0TTYfmYNxgQeo8zjg4PSrjjDQgSz7x+pZbXt6+EruQsUjG ZLqYoDTYak8MaQlizLSaj/wQ7sqtNwUkdbJo9gdI2HgrtMGc6gx/GkMVfDJp t498C+IFTG8+YJDKwiwS1b/uu28dzfXDs98Hi8VvkdibmluNkb6FFbcbwJBa JUjiZLTquHlAc1rB4Km4TUgbg07y5qTIkyU1B1YTDzC55xHUQLMLJei3YH87 DRBtloPRZTmpsM96nd13Q64nzun4ovAfalP0swn6AwQCCsc/+BUiM27LLsvi ajU0E734ooaGW9uPoPKAH5ngI0Fd8STMYPjwgX4DDzHXFgNXJ4cQlBByJ8PF VyCGM5H7C1nuI0hzxLjXoVYsUZ1aQelC6KyUCmlRaws76w4FFBFcj/sUTe2W SYpgHudBjqspZTgjEugRFKtjB+TjSX72HsR4R3MkQNUlmxRiN3woztqfDUc+ zdbuwzMveyWglzd68ZCVJi1oi7wuMfwgjWimlTMfYCl4S5DT4lPah2dU/hVc a4faN87G3wo2tPGmG4Fv0nRIpZDWk/CJdhTiTdSR60LAVeLRj/VFmI5eUN5H iYsEoXCO5QrZqDjPw8+w3A+q3bVr7HNPMOQP9TgzQOOL6Ckg7EMaRp5H/6DR cIJ8Dz8HHBK0JKchbiE9Q+j1nFAq3E9XPZXskdb3M3iywovXMvij3d0dHN5N 47EvXOM5wbe7nSWmtZ2cVsDMxDvTnMk5cg1OVMIhlxgxeCg5/IL1DyhVwT3N mwCvGOaT9/z4G86/f1cXq55cj9kjUtbi/TE0ik4SQ6RMTti2juIaAQ/AiyYw RpCsBM93pIkVfqcYq5I0TLIpFEHhbBrjcX1xKFokXMjvOw5YhfJzbO+GrGhc jWeDPEgjuFSGuwijeSMhBkHMYxMOtaKK60+SgvqiL0LwixD8rycEhXxV502L Qkjy5S6fqejfF3H4RRx+ZnH4hup5mGIJKQmyS1kQYTQYQlKE5OOvl5l7sj6M Lja1cyRRAxdC7xlP1zMkSBgd+VAr9lmk+y/8JjabeCTP0DcSDgRdkxGsp2ht 9owbh0do1q7emYD2nYITA2H2FGw0Nt2tbyPIvRwH1PO0zJad+yRjVXf9i5T+ IqVvJqVZulbNkjvmGh3LNQRy0wTBsfAwFwdr4roDUz3XLA44AjzP9hE1DYfB 0bhJcq+4LAbVuMAca281sGzHv+enp7Dv4S336yvr1HC3l+8kymMJ/5nl+eeW 1Xcthn9/qXpLqSEE26SxNF3duQAJ3bQ8SnezRZ4wFX2SPOFnv8iTL/LkdvIk UTrBVVyegQ/y02LwzPBZI29C06xMotbIC7+YaV/MtH+A15LyuEI/pdAupbYZ Pi7XZ8G9+CR7SWXRgpfHYrDx6mWEIbFLia+GhlT7+HcoEtudo3zPRCweYXnk mbNeKev06Hp0duEEkcipl4WTWr0l5eSSL/siOL8IztsJzloIjXOl64jQhkho NiNlOfm55Hu/yNIvsvTzytLbibwbXJc7EX80iVOtyVh2+IaZhl0ANE6XSMRp 6dCywIKj134RQ1/E0LJiaHkpwujQX9xm/yRus9sEb4hS7pDt9n1JEL77c1gU jYYuQFhA37omCYohojkUwuHq60JT0TG8zQ0hTIVYSiK8lcLuI0Q/bJENUi3d JYzET5MS8VBf5MUXefF7yIsIzoBI9ov8+CeRH/M8wzFN3FbetL/17uVPcqw7 D/pEjN6He4JjQiivyYzLFj/cY35GdxmZOpcrAIF7qZCoWSaCoApbaj/hudEG yxiufzpHOH9kUAQIPLBMllrI5lPD1GxqyaCqBFuFOv9OAXIKRj8t4POQKOV5 ahlCeKtZXdFD/qUEMlbPThGlizF8y+msBzQQiAOEiKbnPGRrUOfKjk3t+g7k Qbhdb+CvWf3XWT5F5AQ/PsCtVDNA4XFM/60OBKsCVzB9g0AtxdRAYAYVL31E NjGMSduookOZWtPIvlK5HufBEdYOILTMKBhJsITSk5nbXWn5SdHzEJ1I8bgs 90PoCULtIE89+DLhbqE0J+b8WwWnPM3Pz+mIBFN7xtj0pdTYopFeUAfa8Wzi uHjBsNaDCl5eGEUBuv/0eCoohCkzl/m4wTs8RQwmamdkBsCrHrBDaXwcdRKu lUlPUSJSRZzjIrQL9G5U0eLXSZMguN+EbhaBDPBINGei7QIgcM1LBa0tEtt4 StqikSLUSJBFT5DCoe8dYSxCXwMg9uZisecPqzcESmE5pSo+IZRMCzVaUX7V oBS6qkgikpNxEN70BXjIRL9u25Ed15SfjS3WLvXSmX1j0utD6bjQ7aSgNFM6 QTiQWNsR3lZ71A8Amc+4m13bz6XlOG4PU6TSXDWbwsmQ3MlZ09hgpDl0oYkF xOgGxNI9q7gqynNgwAh34igJoEawqa+9APJ2fiUcLqAqMqIKtEirQAxelgyD y/B7M+oV7PFsPOCGfTujiWIyLsWpKvonvNkdZrfbRWxDQBJhpYK2ETbZVN1r /hkKnr+qKcJiAmr3pbdJ9JLlQew7pgf4yDH5Es2udJ4jyw7ClQPIEDhf6HkP jZP3GIQgWBDOG3oq0+8+osJw8K9bz/jyX9soF8J4CqiFm8Ga4/njQhp0a7fI QFeoiykxF8ZHpUZ2fDxl0De5gUwa1jjqyGwcSWsOmIOam3DXJvIrkhOAV4G/ 4VVYxLLcGnJdljfU6hj3YfuZdNPcO3xhgn28cqnw7PjKRmw9JR0TFNAUMGGO q7K3iitfPQZutgrLNKAuUbe0PFp+iGwQdKc3uofvvrTzmMuy3TJ2cBk009qc q0GrFG3c0doalnDng3PtBI1NuaDzm92bh5/wUr/G+e/e/YR3O21x6fc/Cuk7 RO1EUAq8pK19QjLsC1LKFOdMDR466Q+n8+fzWOksSDL87u3rd29e7b08yN69 PXQEMr2IsAHRruCLEDRQI4q/fy4/aKF3AjZwE1HxaVEYzxy3PCO8cbNZHmUN qpLzcTRT1eDhY5h20AAD5xP0Fze78OSZM4H61N22QPUHHhRQ93zUfiCE8Mns k/tF2vYitsnGmhv3BB5d81dOUNnOyx4fjczpqacU934QU9JZR+ZmysHnICKx pso4NYV2MzGg54392Np8xtYLogUq8s2xIDPpvqbKzzu++af4JlBLvywmnrs6 deLd2x9Jm2OoLcVnj/sKts9zyxwcSFHhfwKoxT1uEKGFIkL1OmN6AgZ4TzEo tXQ+bAwTbXSEVWaJhRsmoF6UAiX9msQxCiHWgswjQQcj6v/ouawC3QcXbRlp 8rXeWjOwmS1Sd52cr27xNtSgT4tz6g+r4nSESMpCdaYbLDolueMfaqHOShnm zg43v1FllG4LolyjYe6plNv7VKAn2mc7QZsbkLrDsbscTbQr2SBGf/FvsPSz E7Jjq2PQZhhIJn6fOoW7/WJ6dmHf9jBi7qBUO+Iq/D2g1qaUbo2NbumXb6o3 vqcp6P+MvuluwxrNH/nGCT2yRntAlwz5ATYn86OVHiWYfoS4vfdjTuMnvusn Dkox6q8V5tycHMHbpPlQT/FtiQaZt3hu56+sZXzH+ONjAQKMLjgQ729dsICg twXZH/e1UyclouNyeiU3enUPOmZfYkul4x+PUNtxdrZfzyPhCvB+dvuEAm7N 6eeGDc/bnMdJlVTe44S/fQ+BaijnjBVJCzexZN3nnJk9aVUmWBGQSUINzJKr NWInWAsTdEPxb16QxFu3N1vUKqPfMxQXKrl4v/58Iv7hNcbRrkXb3gjWrW5k x41ygJDn1c+Zz9bvcVNFvN/xNWVgVhB+49kpYh2fF7ga2NM5HbS5i5qwVL/z dMe56RnxUb7v9gJ7X1SfocpniloabIORztEEZbu3w+2O8hSlmZ1KpwhxhsUS YBeC+WVlOswskfvoR44YfLODnhlAAERlIIOrTiZjOG+eBz38+mj/9duDdcHm h1dov6cRNqREixoDJjCBDt8u6Jkjo5TYkIPm/bDJkcPRydqfUYcP6g4kjetH 2F1yQzEiAUxZjj5v79trev6KpZt+89K9cnQ1u/NYqO2Z2Ghw0XYbHKHByLEI 3jb2lQ8MTi1RQ2dF5Fuih7H9wTcZr+Oao1+8yt6aaxuwVTqggqTN4ntzYK8N FfOyGUSbxVfgGnT6DUbepMFlaKprcr9MG/Cx49toxAbxHcqizs+VI2FPFPZB en/KEBz8Z3hIp+UI1DI09mi2RugB9LF/JWAX17OS5BI4x9UjSP5c8ZELUTma Ap4Gfuwuvt9O/WmgjIY6qHVjxM4YRPA9g5bXbsMJ0gh/XhtXxWbDCBQ1dkhN ddGRiIuFwmAL/AlqqsBytsGmynh0bjOCZia2X06crUYOG/afydVd4D6r+Gfo PXv95tiJNXvpRVdz+zkjMmvzIgl7wGNj8ck8AP0RWoDFxADmRHBxg4YUSzu6 3JS3nyX5FErlXmpTA+gBwfZ1a2pRMhm5lTp+tXpC3ER22icycgQ3LbUkzetR xt/ixW8+APKcXgzJhtHPof0AnsmaIhWuBXgK82b3MD07NcfwBipe8PWgynuB R0ktY4L0Bk2jlnfvpt9ttj9i0fQOKLsg12mkbeLX3bK3xhFfk9OShlgjvXgt kYq5Fpr+ikqm+/Ko/dQChzEy8z+fOIELm97nEA2pi4kziHVGN9Lj9pH6s9EZ fUPdhEvTO5aFzxrD1p449WPNexucEmZ+RPymw6LIdJrwhK6LAtqiSJ0gwbVP /Un71E8L6I7mpQ1Jx4k2e4E4kXs7RkANKuJcl5gG/ITmsKNa+/SehtMjroko JnQ+LVF/nE+f0gdsh8c1+eUJ/dIaPnzUVtbDI2FfwPaZgl/sLogAV/QPIYWt rTZGIoCPGLrm1AaVgHT2gIOhmOzceQvVU+iD0NEmVtjcYRQ0veOm7P6ChS1Z RG2mBnNTz9amvp87t7OQ0bF1jVNsUCRJy4YUcAUsukXICKGyZijNYCJ6uz+t zkkf4E5x0M6wgtZ9Tv+AH7RrduuNngpo57+FJ92vRUaJrlZc6YbIzFukktgE xvo2XWu1+2f7HfVhM7wEmvBQg57v9iLRuTU6Ojb17GRbhFSexCyPrOdmcx05 nVVM/gBNCP+ymuYHVn+M++2sY2eGA9AqHVkR1jy8/cUMBfP+66ODbE+kdp3d 43bcffy6e+YM5a4T6pDwuRcpdQaXWGCJN3d3QMmjh70yUEtSnckFURzRcAIm afPDB/huw38HBpDE+XD1IwGmcZyyBAxjfNlZPiZQ/RLF/HHF4E+syedDTCmb EYPHm8XztZkqOii36ZPosmC85ZKD5JSA81JDWLi16FT3is4Jivg1VRGMBmSY 8yjtLZRunnzA7lH0FlKz8b404EQ9nBzZgyDjBjfEnEOQ5NFRyFp1c6qifE0J Emo/EE+EXar6ibW1RWBg92Y15RGVtnchuq6nTJCk978wKnr8/nttdNnVLeni TzkHzav7LYdxv7Gh697ZO8BoRF5L7wu85M1YqsbeX2X/8k22mRUk8xzJ4KBu cI0F5RFp6qmlVGfN5EVzXOPC0jgi6DDfnJV0WMFjMz7GwAXcuCiE9+3Vl+Wn 1QlbPNAbYEzzIBH+vhlvLQZ2uhEfMAcSB6Ax+xF7xGAY65WeCv8eF72WPiLE dIF94CYmIGS604vgSd6o+2XmjryTbWxsdLJX3a11AXqjr92Lm1ssm+t3xtBD APreONU//6n88y9JAjD0HUzwTsjgdjOlxmqtg5S14VnCQOaOjG/CHoWIrqki xLx7NUlXJsAQk5X7agO/Qqr6P/5Ptv/8+Y8rEePIvln5EyzNKR/Zs4wC/Q+y P2V/5L//0sFv5XK430BE50E2dUOar4xJ/8w9/RUsl47P/Rt4Or7nq8wfK/+u 8Zssk1wHHQsQ/Fd+WVmhGX2DY9uFrXx4lt2DspOIdXZFBEzL6aD4ZrXJNDFh OBQUq4CLrX0XsneoH3k1QuRAlxQnUCOwqdPzw+PXb59lb3482HPH8/bg5euf DrLj7w+PsqOD/ePD169IJPzEXaq7W48xTX3riZcEW4/dPz8yfB2F4BigjuwA 1D4pE7IEy6M3OwMJtKoiSPzhnB4Ud9JlzAV3yYjYKcFKq1ECl+Cqz7Pgt6HZ h/9ufw082K4/L3jweVk7AerUvwn98ID6V/dIvlOLTtZxBk5pR2VxkNcXcGsk r4UE24vyV9AUHLWbMcjG4Y576OJC7tgr8/ORs6rQsJ3m3m3vDvXp9tNNE9dR W4GUE/R9WCUJ/SiSDFNHi+XAkY+aYy5iOSw5cB51ntRQk01vwAaG7rcjyB2P 2r9+lR1C91loPq5rrPoNOxN/udcD2to72j887EIWCuwBuDPpOtjHo86S4ZKs vUgRJ45RUXNV76iPntPIkO+YrWmiU+7NyhY2vnWNijjChBJ6p1DGmePw5a/P 1MLNB1f5dR14dfVlyqrMXoCT26uua8WvzpYPETrcuRJRD8p+gZ21Qy21pc1j tHIoFs9Pq5lf//tRdTUoeuT1tA2IsRdmY+cK7Tc8EgtXMgNz8MeDYYVZsImT ewnWYjVCCoHQbwlOe+4dX1PHv8gYk8brLe3WJV95QAktVFVAWkGvGOT0CvO2 EbS6HUwpu8M2g9Zbi/dSdtRGzs3v6MSkhClAEzMe3OA5eCscsX1jybvbGAUP 9qrKsB9E2f+G3/osW9WeHswSfQ8T5ljY2Q+dZrgWjHPTraTk60gEUKWSkwRe BDxy//zI25pj9v8CLkm7Ef3osJ0HSwxlConwo2pQnROozQHKleg9nypZoIFs dwBwg5k7nfx9r7qycKS+jQnmqEPxYU1BB7ft4wv1ZhMfR7Uu5OVJkyqaA2So s7+Yrr9mUMIS3BUfG1bQvGjoN7t0/8brhbkSBXvOpMEMCpwO8i77OVdLDXKY /GQGcIx4473zD+czLorJCSZyxSzpAGtUIj7JHO2CmvxRFhQm0GuXoiiwn8PG Vv2u+z9wwLkdxoJWDvMTQwBGG1UchXIIpwAuY+u709b1eEYQQpVFQRVW3ezd Dr6SC7eFxUjqNjARDsJvLCuo4GtcTnT72BtnOezi1yJH8295ieJwRqml3MkZ qWfkxE7tjGIuJlFBl+LeehHrdHPETIWxMjrYR2lH7Nk4lDNhFjmXHQgHg1+f zsoBksbewd5zkaX+OAI2TjceeppOLrUuQrrXLYVrG0yHvN3og6DQrXoM8vlX TV6ArmO8qThIuDuGs6P6pRxyHl/cJb74yPDFXfdP5IuO/znyJteVJDTMT7CW SkRwxoZaA6QpO42WuUSUOB+qlO/YJ+3dMGHBAOrm5HzaO3wRPIKehwEP4pVs PHYKvEuJCwXgU6Ik3qGHtEO7Zoceun9+9FzTMcrGUzv01EPz1I7758eQ99HC YAvOq1xK8U0GstvvU5CVZ2R+iymimvPrSyAfdz3pjWf+mgQWhlWFR72YFb/M /0LKNHvpyDNPCWLYzncaYIoGeb0BdZJWjoGwEsIaqENr23FHKbNRLwcvuVPN RI2mnNWIHmAIDe8EOtxabUiMdNXeJO9Pu9AzE2EHMIlKY6GV2+EJzfKV1Ttr TpU7aYS8UGI1w00bga3Iejuqgj1IwiWF5rLZjVuThtjjMTyfotdJfiD3G9Q5 sL8kR6MZM6eIsSYAi74NPVgdI2JtfNHbsJ18GG/D12oi8QPJjEDzgMfAGqpo kO+8LANZN7oA4d2LLTO+p2sckyZ1AP5+Ysr81vR8xFHe4PMdlSmkKudW78mz 07x2JME6ObYf52RB7skmsX6jtPt0wgaHLRaIIabsgDADNoQdYDHQtUQNGZWB FpfkF+H+stGFXpqfbzI/3/F8Z9Px8x3kO4ejM5oM9nrl5nZzbvUQZbrc2zNM wLU3Fde/XPoGnTC4NWxGBCta3jeMRjGpa+Z3RB/ew2+EjPQzJ1Ywya8ycdlJ QclZMZnSTgKp7/98XEPQx/0X2HDpDPGjYprd398/Wt9w4j4fB+zIzWV2ivfV yQ3mASGrSgSv6bLHvCnFl7jZe+HtgYJwv94IxQbauz8qxwYBOKIsut8Xg4Gj Z8sVMSbIEXnWVSgyJA3lJ5zf9cAnkNOVNvGLeQqtwHGANj4qwKBwxIrYHXro tApzTo38RMgEw6AeJUaAXjMAlghxnmtKk3L7+8Cd1SgkG9bbA34jMoe9KpSp A4/hxcF/Gn7DuiaXfK+CP7i3at1LFGmjTK8zoJJOZtnirC4ixWHejST9YdPo D5sP3T8/Wobh+GwxgTyMB+B9wr+hUlQX5555WKnIXIP4M7rn3P+4LdujQhc6 776NbpLx/GBajZ1SYJTbML+mEVNs+IH4qaRJZWXGoDhHNoNPus14wNmWkQEo eOUjME+wyS2LDGfGtuQlNJ60ICneLcK2LhoJlIhTQ9EnoVdI1oZkEyufplQP s9Ic972enXZVI0nYbo4oxpg6Rkmc/jaG17lhvAhiQz6yyRCJVId2i9tOHrIx v4a0gaK5qO0b0Cxpr5tGe93ccf/8aCXl24Oj4/5sYGu8cm57iuViKVVTL505 HLcES2TyFieZz94/YPZAunFsXIQy278Zc7Ot7I02T9OrtKLfSDWhECDlpmir H+joh5IFIjENqcMYg2ytZjXGDpZRT2ktoVdsiFXGCNBsazwkFpfqbs6dzZc9 4206Y6spbLt/skfMp4fazBNGGmmT+Xq7jM7aI4PCS6E3r4+Os/uS/7GzscNJ ymp/FL24dhC5Ot4r1eS8RaOverjO54wp91Bo4ecpXD2ok5w5fqTOA/+aja2N 7Y2t9YDE0JschQLItHG7rI/urhvGgfGkFDVm9/fGWAv5a7a3Hp/KFp3KtjmV LffPj2lDNW2jNwsVsDo9UYOkM9+SBcdWksk3QeXd6kMYH+EM3+I2yb0JcngV RgngIqxxPSzIu1lZXxi+Dwzzuaml0CPWnCh7vMkREtWCIgNb304wPJeQuSdk 5xfWHPHA5tXyRtaYWQvVEvN/3rAbEw9oVCoAmxplAROFa+QOpiXxz7/1UWIS UNwh88bdYQ2P5BWn5MkLHus6hDW3efXkkTrb2tzYQvpwf9n2x4SuNjOWTKpR 8afkvNV4fJl2yfb5nfVOCu1KnFBu8T6FzQ/ktAMLWUhbAhkC84Z6mB7KAz3K b5+2LgkR6+eN8Xi9McRVpatZEiueQxJwBKS5ZvsgpRF1bXIJEQ9DlNsRUd7I KJ7LIzeJR24ZHrnp/km+NbYHBb5tzQ13ks96yDzW3F8QjEWvdggL2aDhHaHh 55xhEpkbLA+xtEuJ2C0d9+mRbEHTodnCVdhow7jD1UU1KBL7aY00U5cSXMv5 r2++87nPn7EmkAS0MeJCOzMo8ssQU84LP3mbaK6oO7SWbsEOiabY9L5z7XGM uhAxJ9/Eot+0E2utR/N702ROJKuN38lYQNZToeg30oTaiJQn9lWyU1jkweFR j4mWxxnzerVvyCsdh/QMLoq1piqkhSmsdloCF/N+gdzF/4C4wHIswzxl2JHd sFwuOvmTlsZdgjmqRhYVmEbMw5nFEvvH90ISE8FMFb1vVkfVqiZ+ij3mCRfw jZw0vygGY7J2svoiH2vmq/jqn2UfPnzYv5iAeuKMub1h/ff/V9cfIaEZvsgn EATJvsUcgpF8/LYC183zfHQ9KK/kw5eQn+c+nb0v5KPjC/fDOnvhtF+3QPn0 p7J3UWbfVcVA31e+h1Dx93//j/PBbNSTj791I/+Q92bv5YODSfk++wGct/LJ zznE/bIfZkNnJPkPpwBd+KOzJ+Wj/1ldAIRWMfv7/81e5tNp7X4g37l1lMUg e1meQ/GJfPrv+UXRm/32Ww5LPQLozYm+rBwCmm+e6+t/nPWuynMn78rpb/LZ d3//jwk86mwL8B7olpbnvcI9XzhlcOCncOnMjIt84H/3fTFyohB2cGzm+oYV VcjJBhC2ivaGSmQ/vHELyH521Ij4yZDaB9RxVU3eE8e3KDEKkgl5lQEQh2Nc Px2+evX6pz0FE9kvBtPyrPsKrAlHy3+BCun9t4fHh0cH+18Lp/t+e3N7U78+ OnxxeNT9HoAr7383gfBJfj4pyKx/urv9aHebwUr46YPD4+7z8rwEJ+/35fkF CGCIHx0SQ4UYxd7+8eFPBxsEmtYfzPr9lf8Pclo4HamtAwA=[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>