rfc9594.original.xml | rfc9594.xml | |||
---|---|---|---|---|
<?xml version='1.0' encoding='utf-8'?> | <?xml version='1.0' encoding='UTF-8'?> | |||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!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" | |||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft | ipr="trust200902" | |||
-ietf-ace-key-groupcomm-18" category="std" consensus="true" submissionType="IETF | docName="draft-ietf-ace-key-groupcomm-18" | |||
" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true" version="3"> | number="9594" | |||
<!-- xml2rfc v2v3 conversion 3.18.0 --> | category="std" | |||
consensus="true" | ||||
submissionType="IETF" | ||||
updates="" | ||||
obsoletes="" | ||||
tocDepth="4" | ||||
tocInclude="true" | ||||
sortRefs="true" | ||||
symRefs="true" | ||||
version="3" | ||||
xml:lang="en"> | ||||
<front> | <front> | |||
<title abbrev="Key Provisioning for Group Communication">Key Provisioning fo | <title abbrev="Key Provisioning for Group Communication">Key Provisioning fo | |||
r Group Communication using ACE</title> | r Group Communication Using Authentication and Authorization for Constrained Env | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-key-groupcomm-18"/> | ironments (ACE)</title> | |||
<seriesInfo name="RFC" value="9594"/> | ||||
<author initials="F." surname="Palombini" fullname="Francesca Palombini"> | <author initials="F." surname="Palombini" fullname="Francesca Palombini"> | |||
<organization>Ericsson AB</organization> | <organization>Ericsson AB</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Torshamnsgatan 23</street> | <street>Torshamnsgatan 23</street> | |||
<city>Kista</city> | <city>Kista, Stockholm</city> | |||
<code>16440 Stockholm</code> | <code>16440</code> | |||
<country>Sweden</country> | <country>Sweden</country> | |||
</postal> | </postal> | |||
<email>francesca.palombini@ericsson.com</email> | <email>francesca.palombini@ericsson.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="M." surname="Tiloca" fullname="Marco Tiloca"> | <author initials="M." surname="Tiloca" fullname="Marco Tiloca"> | |||
<organization>RISE AB</organization> | <organization>RISE AB</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Isafjordsgatan 22</street> | <street>Isafjordsgatan 22</street> | |||
<city>Kista</city> | <city>Kista</city> | |||
<code>16440 Stockholm</code> | <code>164 40</code> | |||
<country>Sweden</country> | <country>Sweden</country> | |||
</postal> | </postal> | |||
<email>marco.tiloca@ri.se</email> | <email>marco.tiloca@ri.se</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date year="2024" month="January" day="16"/> | ||||
<workgroup>ACE Working Group</workgroup> | <date year="2024" month="August"/> | |||
<area>sec</area> | ||||
<workgroup>ace</workgroup> | ||||
<keyword>Key Management</keyword> | ||||
<keyword>Access Control</keyword> | ||||
<keyword>Constrained Application Protocol (CoAP)</keyword> | ||||
<abstract> | <abstract> | |||
<t>This document defines how to use the Authentication and Authorization f or Constrained Environments (ACE) framework to distribute keying material and co nfiguration parameters for secure group communication. Candidate group members a cting as Clients and authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as Resource Server, from which they obtain the keying material to communicate with other group members. While defining gene ral message formats as well as the interface and operations available at the KDC , this document supports different approaches and protocols for secure group com munication. Therefore, details are delegated to separate application profiles of this document, as specialized instances that target a particular group communic ation approach and define how communications in the group are protected. Complia nce requirements for such application profiles are also specified.</t> | <t>This document defines how to use the Authentication and Authorization f or Constrained Environments (ACE) framework to distribute keying material and co nfiguration parameters for secure group communication. Candidate group members t hat act as Clients and are authorized to join a group can do so by interacting w ith a Key Distribution Center (KDC) acting as the Resource Server, from which th ey obtain the keying material to communicate with other group members. While def ining 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 p rofiles of this 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> | </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> | </front> | |||
<middle> | <middle> | |||
<section anchor="intro"> | <section anchor="intro"> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t>This document builds on the Authentication and Authorization for Constr ained Environments (ACE) framework and defines how to request, distribute, and r enew keying material and configuration parameters to protect message exchanges i n a group communication environment.</t> | <t>This document builds on the Authentication and Authorization for Constr ained Environments (ACE) framework and defines how to request, distribute, and r enew keying material and configuration parameters to protect message exchanges i n a group communication environment.</t> | |||
<t>Candidate group members acting as ACE Clients and authorized to join a | <t>Candidate group members that act as ACE Clients and are authorized to j | |||
group can interact with the Key Distribution Center (KDC) acting as ACE Resource | oin a group can interact with the Key Distribution Center (KDC) acting as the AC | |||
Server and responsible for that group, in order to obtain the necessary keying | E Resource Server that is responsible for that group in order to obtain the nece | |||
material and parameters to communicate with other group members.</t> | ssary keying material and parameters to communicate with other group members.</t | |||
<t>In particular, this document defines the operations and interface avail | > | |||
able at the KDC, as well as general message formats for the interactions between | <t>In particular, this document defines the operations and interface avail | |||
Clients and KDC. At the same time, communications in the group can rely on diff | able at the KDC, as well as general message formats for the interactions between | |||
erent approaches, e.g., based on multicast <xref target="I-D.ietf-core-groupcomm | Clients and the KDC. At the same time, communications in the group can rely on | |||
-bis"/> or on publish-subscribe messaging <xref target="I-D.ietf-core-coap-pubsu | different approaches, e.g., based on multicast <xref target="I-D.ietf-core-group | |||
b"/>, and can be protected in different ways.</t> | comm-bis"/> or publish-subscribe (pub-sub) messaging <xref target="I-D.ietf-core | |||
<t>Therefore, this document delegates details on the communication and sec | -coap-pubsub"/>, and can be protected in different ways.</t> | |||
urity approaches used in a group to separate application profiles. These are spe | <t>Therefore, this document delegates details on the communication and sec | |||
cialized instances of this document, targeting a particular group communication | urity approaches used in a group to separate application profiles. These are spe | |||
approach and defining how communications in the group are protected, as well as | cialized instances of this document that target a particular group communication | |||
the specific keying material and configuration parameters provided to group memb | approach and define how communications in the group are protected, as well as t | |||
ers.</t> | he specific keying material and configuration parameters provided to group membe | |||
<t>In order to ensure consistency and aid the development of such applicat | rs.</t> | |||
ion profiles, <xref target="req"/> of this document defines a number of related | <t>In order to ensure consistency and aid the development of such applicat | |||
compliance requirements. In particular, <xref target="req-mandatory"/> compiles | ion profiles, <xref target="req"/> of this document defines a number of related | |||
the requirements that application profiles are REQUIRED to fulfill; these are re | compliance requirements. In particular, <xref target="req-mandatory"/> compiles | |||
ferred to by an identifier that starts with "REQ". Instead, <xref target="req-op | the requirements that application profiles are <bcp14>REQUIRED</bcp14> to fulfil | |||
tional"/> compiles the requirements that application profiles MAY fulfill; these | l; these are referred to by an identifier that starts with "REQ". Instead, <xref | |||
are referred to by an identifier that starts with "OPT".</t> | target="req-optional"/> compiles the requirements that application profiles <bc | |||
p14>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 s ecurity (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 n ew members join the group. If the application requires forward security (i.e., f ormer group members must be prevented from accessing communications in the group after their leaving), then a rekeying has to occur every time current members l eave or are evicted from the group.</t> | <t>New keying material is intended to be generated and distributed to the group upon membership changes (rekeying). If the application requires backward s ecurity (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 n ew members join the group. If the application requires forward security (i.e., f ormer group members must be prevented from accessing communications in the group after their leaving), then a rekeying has to occur every time current members l eave or are evicted from the group.</t> | |||
<t>A group rekeying scheme performs the actual distribution of the new key | <t>A group rekeying scheme performs the actual distribution of the new key | |||
ing material, by rekeying the current group members when a new Client joins the | ing material by rekeying the current group members when a new Client joins the g | |||
group, and the remaining group members when a Client leaves the group. This can | roup and rekeying the remaining group members when a Client leaves the group. Th | |||
rely on different approaches, including efficient group rekeying schemes such as | is can rely on different approaches, including efficient group rekeying schemes | |||
<xref target="RFC2093"/>, <xref target="RFC2094"/>, and <xref target="RFC2627"/ | such as those described in <xref target="RFC2093"/>, <xref target="RFC2094"/>, a | |||
>.</t> | nd <xref target="RFC2627"/>.</t> | |||
<t>Consistently with what is recommended in the ACE framework, this docume | <t>Consistently with what is recommended in the ACE framework, this docume | |||
nt uses CBOR <xref target="RFC8949"/> for data encoding. However, using JSON <xr | nt uses Concise Binary Object Representation (CBOR) <xref target="RFC8949"/> for | |||
ef target="RFC8259"/> instead of CBOR is possible, by relying on the conversion | data encoding. However, using JSON <xref target="RFC8259"/> instead of CBOR is | |||
method specified in Sections <xref target="RFC8949" section="6.1" sectionFormat= | possible by relying on the conversion method specified in Sections <xref target= | |||
"bare"/> and <xref target="RFC8949" section="6.2" sectionFormat="bare"/> of <xre | "RFC8949" section="6.1" sectionFormat="bare"/> and <xref target="RFC8949" sectio | |||
f target="RFC8949"/>.</t> | n="6.2" sectionFormat="bare"/> of <xref target="RFC8949"/>.</t> | |||
<section anchor="terminology"> | <section anchor="terminology"> | |||
<name>Terminology</name> | <name>Terminology</name> | |||
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp | |||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", | 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | |||
"MAY", and "OPTIONAL" in this document are to be interpreted as | NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO | |||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and | MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
only when, they | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i | |||
nterpreted as | ||||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and | ||||
only when, they | ||||
appear in all capitals, as shown here.</t> | appear in all capitals, as shown here.</t> | |||
<t>Readers are expected to be familiar with:</t> | <t>Readers are expected to be familiar with the following:</t> | |||
<ul spacing="normal"> | <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="RFC 9237"/> to express authorization information. The terminology for entities in th e considered architecture is defined in OAuth 2.0 <xref target="RFC6749"/>. In p articular, this includes Client (C), Resource Server (RS), and Authorization Ser ver (AS).</li> | <li>The terms and concepts described in the ACE framework <xref target ="RFC9200"/> and in the Authorization Information Format (AIF) <xref target="RFC 9237"/> to express authorization information. The terminology for entities in th e considered architecture is defined in OAuth 2.0 <xref target="RFC6749"/>. In p articular, this includes Client (C), Resource Server (RS), and Authorization Ser ver (AS).</li> | |||
<li>The terms and concepts described in CoAP <xref target="RFC7252"/>. | <li>The terms and concepts described in the Constrained Application Pr | |||
Unless otherwise indicated, the term "endpoint" is used here following its OAut | otocol (CoAP) <xref target="RFC7252"/>. The term "endpoint" is used here followi | |||
h definition, aimed at denoting resources such as /token and /introspect at the | ng its OAuth definition, aimed at denoting resources such as /token and /introsp | |||
AS, and /authz-info at the RS. This document does not use the CoAP definition of | ect at the AS and /authz-info at the RS. This document does not use the CoAP de | |||
"endpoint", which is "An entity participating in the CoAP protocol".</li> | finition of "endpoint", which is "An entity participating in the CoAP protocol". | |||
<li>The terms and concepts described in CDDL <xref target="RFC8610"/>, | </li> | |||
CBOR <xref target="RFC8949"/>, and COSE <xref target="RFC9052"/><xref target="R | <li>The terms and concepts described in Concise Data Definition Langua | |||
FC9053"/><xref target="RFC9338"/>.</li> | ge (CDDL) <xref target="RFC8610"/>, CBOR <xref target="RFC8949"/>, and CBOR Obje | |||
ct Signing and Encryption (COSE) <xref target="RFC9052"/> <xref target="RFC9053" | ||||
/> <xref target="RFC9338"/>.</li> | ||||
</ul> | </ul> | |||
<t>A node interested to participate in group communication as well as al ready participating as a group member is interchangeably denoted as "Client".</t > | <t>A node interested in participating in group communication, as well as one that is already participating as a group member, is interchangeably denoted as "Client".</t> | |||
<t>This document also uses the following terms.</t> | <t>This document also uses the following terms.</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li> | ||||
<t>Group: a set of nodes that share common keying material and secur | <dt>Group:</dt><dd><t>A set of nodes that share common keying materi | |||
ity parameters used to protect their communications with one another. That is, t | al and security parameters used to protect their communications with one another | |||
he term refers to a "security group". </t> | . That is, the term refers to a "security group".</t> | |||
<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 s ame physical room, or the set of nodes registered to a pub-sub topic. </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 s ame physical room or the set of nodes registered to a pub-sub topic. </t> | |||
<t> | <t> | |||
This term is also not to be confused with a "multicast group", which has relevan ce at the network level and whose members all listen to a group network address for receiving messages sent to that group. An example of 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> | This term is also not to be confused with a "multicast group", which has relevan ce 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 th e set of nodes that are configured to receive messages that are sent to the grou p's associated IP multicast address. </t> | |||
<t> | <t> | |||
The same security group might be associated with multiple application groups. Al | The same security group might be associated with multiple application groups. Al | |||
so, the same application group can be associated with multiple security groups. | so, the same application group might be associated with multiple security groups | |||
Further details and considerations on the mapping between the three types of gro | . Further details and considerations on the mapping between the three types of g | |||
up are out of the scope of this document.</t> | roups are out of the scope of this document.</t> | |||
</li> | </dd> | |||
<li>Key Distribution Center (KDC): the entity responsible for managing | <dt>Key Distribution Center (KDC):</dt> | |||
one or multiple groups, with particular reference to the group membership and t | <dd>The entity responsible for managing one or multiple groups, with pa | |||
he keying material to use for protecting group communications.</li> | rticular reference to the group membership and the keying material to use for pr | |||
</ul> | otecting group communications.</dd> | |||
</dl> | ||||
<t>Furthermore, this document uses "names" or "identifiers" for groups a nd nodes. Their different meanings are summarized below.</t> | <t>Furthermore, this document uses "names" or "identifiers" for groups a nd nodes. Their different meanings are summarized below.</t> | |||
<ul spacing="normal"> | ||||
<li>Group name: The identifier of a group, as a text string encoded as | <dl spacing="normal"> | |||
UTF-8 <xref target="RFC3629"/>. Once established, it is invariant. It is used i | <dt>Group name:</dt><dd>The identifier of a group as a text string enc | |||
n the interactions between Client, AS, and RS to identify a group. A group name | oded as UTF-8 <xref target="RFC3629"/>. Once established, it is invariant. It is | |||
is always unique among the group names of the existing groups under the same KDC | used in the interactions between the Client, AS, and RS to identify a group. A | |||
.</li> | group name is always unique among the group names of the existing groups under t | |||
<li>GROUPNAME: The text string used in URIs to identify a group. Once | he same KDC.</dd> | |||
established, it is invariant. GROUPNAME uniquely maps to the group name of a gro | <dt>GROUPNAME:</dt><dd>The text string used in URIs to identify a grou | |||
up, although they do not necessarily coincide.</li> | p. Once established, it is invariant. GROUPNAME uniquely maps to the group name | |||
<li>Group identifier: the identifier of the group keying material used | of a group, although they do not necessarily coincide.</dd> | |||
in a group. Unlike group name and GROUPNAME, this identifier changes over time, | <dt>Group identifier:</dt><dd>The identifier of the group keying mater | |||
when the group keying material is updated.</li> | ial used in a group. Unlike group name and GROUPNAME, this identifier changes ov | |||
<li>Node name: The identifier of a node, as a text string encoded as U | er time when the group keying material is updated.</dd> | |||
TF-8 <xref target="RFC3629"/> and consistent with the semantics of URI path segm | <dt>Node name:</dt><dd>The identifier of a node as a text string encod | |||
ents (see <xref section="3.3" sectionFormat="of" target="RFC3986"/>). Once estab | ed as UTF-8 <xref target="RFC3629"/> and consistent with the semantics of URI pa | |||
lished, it is invariant. It is used in the interactions between Client and RS, a | th segments (see <xref section="3.3" sectionFormat="of" target="RFC3986"/>). Onc | |||
s well as to identify a member of a group. A node name is always unique among th | e established, it is invariant. It is used in the interactions between the Clien | |||
e node names of the current nodes within a group.</li> | t and RS, as well as to identify a member of a group. A node name is always uniq | |||
<li>NODENAME: The text string used in URIs to identify a member of a g | ue among the node names of the current nodes within a group.</dd> | |||
roup. Once established, it is invariant. Its value coincides with the node name | <dt>NODENAME:</dt><dd>The text string used in URIs to identify a membe | |||
of the associated group member.</li> | r of a group. Once established, it is invariant. Its value coincides with the no | |||
</ul> | de name of the associated group member.</dd> | |||
</dl> | ||||
<t>This document additionally uses the following terminology:</t> | <t>This document additionally uses the following terminology:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Transport profile: a profile of ACE as per <xref section="5.8.4.3" | <dt>Transport profile:</dt><dd>A profile of the ACE framework as per < | |||
sectionFormat="of" target="RFC9200"/>. A transport profile specifies the commun | xref section="5.8.4.3" sectionFormat="of" target="RFC9200"/>. | |||
ication protocol and communication security protocol between an ACE Client and R | A transport profile specifies the communication protocol and communication secur | |||
esource Server, as well as proof-of-possession methods, if it supports proof-of- | ity protocol between an ACE Client and Resource Server, as well as proof-of-poss | |||
possession access tokens, etc. Transport profiles of ACE include, for instance, | ession methods if it supports proof-of-possession access tokens. Transport profi | |||
<xref target="RFC9203"/>, <xref target="RFC9202"/>, and <xref target="RFC9431"/> | les of ACE include, for instance, those described in <xref target="RFC9202"/>, < | |||
.</li> | xref target="RFC9203"/>, and <xref target="RFC9431"/>.</dd> | |||
<li>Application profile: a profile that defines how applications enfor | <dt>Application profile:</dt><dd>A profile that defines how applicatio | |||
ce and use supporting security services they require. These services may include | ns enforce and use supporting security services they require. These services may | |||
, for instance, provisioning, revocation, and distribution of keying material. A | include, for instance, provisioning, revocation, and distribution of keying mat | |||
n application profile may define specific procedures and message formats.</li> | erial. An application profile may define specific procedures and message formats | |||
<li>Authentication credential: the set of information associated with | .</dd> | |||
an entity, including that entity's public key and parameters associated with the | <dt>Authentication credential:</dt><dd>The set of information associat | |||
public key. Examples of authentication credentials are CBOR Web Tokens (CWTs) a | ed with an entity, including that entity's public key and parameters associated | |||
nd CWT Claims Sets (CCSs) <xref target="RFC8392"/>, X.509 certificates <xref tar | with the public key. Examples of authentication credentials are CBOR Web Tokens | |||
get="RFC5280"/>, and C509 certificates <xref target="I-D.ietf-cose-cbor-encoded- | (CWTs) and CWT Claims Sets (CCSs) <xref target="RFC8392"/>, X.509 certificates < | |||
cert"/>.</li> | xref target="RFC5280"/>, and C509 certificates <xref target="I-D.ietf-cose-cbor- | |||
<li>Individual keying material: information pertaining exclusively to | encoded-cert"/>.</dd> | |||
a group member, as associated with its group membership and related to other key | <dt>Individual keying material:</dt><dd>Information pertaining exclusi | |||
ing material and parameters used in the group. For example, this can be an ident | vely to a group member, as associated with its group membership and related to o | |||
ifier that the secure communication protocol employs to uniquely identify a node | ther keying material and parameters used in the group. For example, this can be | |||
as a group member (e.g., a cryptographic key identifier uniquely associated wit | an identifier that the secure communication protocol employs to uniquely identif | |||
h the group member in question). The specific nature and format of individual ke | y a node as a group member (e.g., a cryptographic key identifier uniquely associ | |||
ying material used in a group is defined in application profiles of this specifi | ated with the group member in question). The specific nature and format of indiv | |||
cation. The individual keying material of a group member is not related to the s | idual keying material used in a group is defined in the application profiles of | |||
ecure association between that group member and the KDC.</li> | this specification. The individual keying material of a group member is not rela | |||
</ul> | ted to the secure association between that group member and the KDC.</dd> | |||
<t>Examples throughout this document are expressed in CBOR diagnostic no | </dl> | |||
tation without the tag and value abbreviations.</t> | ||||
<t>Throughout this document, examples for CBOR data items are expressed | ||||
in CBOR extended diagnostic notation as defined in <xref target="RFC8949" sectio | ||||
nFormat="of" section="8"/> and <xref target="RFC8610" sectionFormat="of" section | ||||
="G"/> ("diagnostic notation"), unless noted otherwise. We often use diagnostic | ||||
notation comments to provide a textual representation of the numeric parameter n | ||||
ames and values.</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="overview"> | <section anchor="overview"> | |||
<name>Overview</name> | <name>Overview</name> | |||
<t>At a high level, the key provisioning process is separated in two phase s: the first one follows the ACE Framework between Client, AS, and KDC; the seco nd one is the actual key distribution between Client and KDC. After the two phas es are completed, the Client is able to participate in the group communication, via a Dispatcher entity.</t> | <t>At a high level, the key provisioning process is separated in two phase s: the first one follows the ACE framework between the Client, AS, and KDC, whil e the second one is the actual key distribution between the Client and KDC. Afte r the two phases are completed, the Client is able to participate in the group c ommunication via a Dispatcher entity.</t> | |||
<figure anchor="fig-roles"> | <figure anchor="fig-roles"> | |||
<name>Key Distribution Participants</name> | <name>Key Distribution Participants</name> | |||
<artset> | <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"> | <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" viewBox="0 0 700 224" class="diagram" text-anchor="middle" fo nt-family="monospace" font-size="13px"> | |||
<path d="M 8,32 L 8,64" fill="none" stroke="black"/> | <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 8,128 L 8,176" fill="none" stroke="black"/> | |||
<path d="M 56,72 L 56,120" 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,32 L 112,64" fill="none" stroke="black"/> | |||
<path d="M 112,128 L 112,176" 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 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,32 L 240,64" fill="none" stroke="black"/> | |||
<path d="M 240,144 L 240,176" 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,32 L 344,64" fill="none" stroke="black"/> | |||
<path d="M 344,144 L 344,176" fill="none" stroke="black"/> | <path d="M 344,144 L 344,176" fill="none" stroke="black"/> | |||
skipping to change at line 183 ¶ | skipping to change at line 205 ¶ | |||
| Client |<-------' .------------. | .---------+-. | | Client |<-------' .------------. | .---------+-. | |||
| |<------------->| Dispatcher |<----->| | .---------+-. | | |<------------->| Dispatcher |<----->| | .---------+-. | |||
'------------' '------------' '-+ | Group | | '------------' '------------' '-+ | Group | | |||
'-+ members | | '-+ members | | |||
'-----------' | '-----------' | |||
]]></artwork> | ]]></artwork> | |||
</artset> | </artset> | |||
</figure> | </figure> | |||
<t>The following participants (see <xref target="fig-roles"/>) take part i n the authorization and key distribution.</t> | <t>The following participants (see <xref target="fig-roles"/>) take part i n the authorization and key distribution.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>Client (C): node that wants to join a group and take part in group c | <li>Client (C): A node that wants to join a group and take part in group | |||
ommunication with other group members. Within the group, the Client can have dif | communication with other group members. Within the group, the Client can have d | |||
ferent roles.</li> | ifferent roles.</li> | |||
<li>Authorization Server (AS): as per the AS defined in the ACE Framewor | <li>Authorization Server (AS): As per the AS defined in the ACE framewor | |||
k <xref target="RFC9200"/>, it enforces access policies that prescribe whether a | k <xref target="RFC9200"/>, it enforces access policies that prescribe whether a | |||
node is allowed to join a given group and with what roles and rights (e.g., wri | node is allowed to join a given group or not and with what roles and rights (e. | |||
te and/or read).</li> | g., write and/or read).</li> | |||
<li>Key Distribution Center (KDC): entity that maintains the keying mate | <li>Key Distribution Center (KDC): An entity that maintains the keying m | |||
rial to protect group communications, and provides it to Clients authorized to j | aterial to protect group communications and provides it to Clients authorized to | |||
oin a given group. During the first part of the exchange (<xref target="sec-auth | join a given group. During the first phase of the process (<xref target="sec-au | |||
"/>), the KDC takes the role of the RS in the ACE Framework. During the second p | th"/>), the KDC takes the role of the RS in the ACE framework. During the second | |||
art (<xref target="key-distr"/>), which is not based on the ACE Framework, the K | phase of the process (<xref target="key-distr"/>), which is not based on the AC | |||
DC distributes the keying material. In addition, the KDC provides the latest key | E framework, the KDC distributes the keying material. In addition, the KDC provi | |||
ing material to group members when requested or, if required by the application, | des the latest keying material to group members when requested or, if required b | |||
when group membership changes.</li> | y the application, when group membership changes.</li> | |||
<li> | <li><t>Group members: Nodes that have joined a group where they take part | |||
<t>Dispatcher: entity through which the Clients communicate with the g | in group communication with one another, protecting it with the group keying ma | |||
roup when sending a message intended for multiple group members. That is, the Di | terial obtained from the KDC.</t> | |||
spatcher distributes such a one-to-many message to the group members as intended | </li> | |||
recipients. The Dispatcher does not have access to the group keying material. A | <li><t>Dispatcher: An entity through which the Clients communicate wit | |||
single-recipient message intended for only one group member may be delivered by | h the group when sending a message intended for multiple group members. That is, | |||
alternative means, with no assistance from the Dispatcher. </t> | the Dispatcher distributes such a one-to-many message to the group members as i | |||
ntended recipients. The Dispatcher does not have access to the group keying mate | ||||
rial. A single-recipient message intended for only one group member may be deliv | ||||
ered by alternative means, i.e., with no assistance from the Dispatcher. </t> | ||||
<t> | <t> | |||
Examples of a Dispatcher are: the Broker in a pub-sub setting; a relayer for gro up communication that delivers group messages as multiple unicast messages to al l group members; an implicit entity as in a multicast communication setting, whe re messages are transmitted to a multicast IP address and delivered on the trans port channel. </t> | Examples of a Dispatcher are: the Broker in a pub-sub setting; a relayer for gro up communication that delivers group messages as multiple unicast messages to al l 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 t ransport channel. </t> | |||
<t> | <t> | |||
If it consists of an explicit entity such as a pub-sub Broker or a message relay er, the Dispatcher is comparable to an untrusted on-path intermediary, and as su ch it is able to see the messages sent by Clients in the group, but not to decry pt them and read their plain content.</t> | If it consists of an explicit entity, such as a pub-sub Broker or a message rela yer, the Dispatcher is comparable to an untrusted on-path intermediary; as such, it is able to see the messages sent by Clients in the group but not able to dec rypt them and read their plain content.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>This document specifies a mechanism for:</t> | <t>This document specifies a mechanism for:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>Authorizing a Client to join the group (<xref target="sec-auth"/>), | <li>Authorizing a Client to join the group (<xref target="sec-auth"/>) a | |||
and providing it with the group keying material to communicate with the other gr | nd providing it with the group keying material to communicate with the other gro | |||
oup members (<xref target="key-distr"/>).</li> | up members (<xref target="key-distr"/>),</li> | |||
<li>Allowing a group member to retrieve group keying material (<xref tar | <li>Allowing a group member to retrieve group keying material (Sections | |||
get="ssec-key-material-retrieval"/> and <xref target="update-keys"/>).</li> | <xref target="ssec-key-material-retrieval" format="counter"/> and <xref target=" | |||
<li>Allowing a group member to retrieve authentication credentials of ot | update-keys" format="counter"/>),</li> | |||
her group members (<xref target="sec-key-retrieval"/>) and to provide an updated | <li>Allowing a group member to retrieve authentication credentials of ot | |||
authentication credential (<xref target="update-pub-key"/>).</li> | her group members (<xref target="sec-key-retrieval"/>) and to provide an updated | |||
<li>Allowing a group member to leave the group (<xref target="ssec-group | authentication credential (<xref target="update-pub-key"/>),</li> | |||
-leaving"/>).</li> | <li>Allowing a group member to leave the group (<xref target="ssec-group | |||
<li>Evicting a group member from the group (<xref target="sec-node-remov | -leaving"/>),</li> | |||
al"/>).</li> | <li>Evicting a group member from the group (<xref target="sec-node-remov | |||
al"/>), and</li> | ||||
<li> | <li> | |||
<t>Renewing and re-distributing the group keying material (rekeying), e.g., upon a membership change in the group (<xref target="sec-group-rekeying"/> ). </t> | <t>Renewing and redistributing the group keying material (rekeying), e .g., upon a membership change in the group (<xref target="sec-group-rekeying"/>) . </t> | |||
<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 happ en and how they can be handled are discussed in <xref target="sec-misalignment-k eying-material"/>.</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 happ en and how they can be handled are discussed in <xref target="sec-misalignment-k eying-material"/>.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t><xref target="fig-flow"/> provides a high level overview of the message flow for a node joining a group. The message flow can be expanded as follows.</ t> | <t><xref target="fig-flow"/> provides a high-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> | <ol spacing="normal" type="1"><li> | |||
<t>The joining node requests an access token from the AS, in order to access one or more group-membership resources at the KDC and hence join the asso ciated groups. </t> | <t>The joining node requests an access token from the AS in order to a ccess one or more group-membership resources at the KDC and hence join the assoc iated groups. </t> | |||
<t> | <t> | |||
This exchange between Client and AS MUST be secured, as specified by the transpo rt profile of ACE used between Client and KDC. Based on the response from the AS , the joining node will establish or continue using a secure communication assoc iation with the KDC.</t> | This exchange between the Client and AS <bcp14>MUST</bcp14> be secured, as speci fied by the transport profile of ACE used between the Client and KDC. Based on t he response from the AS, the joining node will establish or continue using a sec ure communication association with the KDC.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The joining node transfers authentication and authorization informa tion to the KDC, by transferring the obtained access token. This is typically ac hieved by including the access token in a request sent to the /authz-info endpoi nt at the KDC. </t> | <t>The joining node transfers authentication and authorization informa tion to the KDC by transferring the obtained access token. This is typically ach ieved by including the access token in a request sent to the /authz-info endpoin t at the KDC. </t> | |||
<t> | <t> | |||
Once this exchange is completed, the joining node MUST have a secure communicati on association established with the KDC, before joining a group under that KDC. </t> | Once this exchange is completed, the joining node <bcp14>MUST</bcp14> have a sec ure communication association established with the KDC before joining a group un der that KDC. </t> | |||
<t> | <t> | |||
This exchange and the following secure communications between the Client and the KDC MUST occur in accordance with the transport profile of ACE used between Cli ent and KDC, such as the DTLS transport profile <xref target="RFC9202"/> and OSC ORE transport profile <xref target="RFC9203"/> of ACE.</t> | This exchange and the following secure communications between the Client and the KDC <bcp14>MUST</bcp14> occur in accordance with the transport profile of ACE u sed between the Client and KDC, such as the DTLS transport profile of ACE <xref target="RFC9202"/> or the OSCORE transport profile of ACE <xref target="RFC9203" />.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The joining node starts the joining process to become a member of t he group, by sending a request to the related group-membership resource at the K DC. Based on the application requirements and policies, the KDC may perform a gr oup 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>The joining node starts the joining process to become a member of t he group by sending a request to the related group-membership resource at the KD C. Based on the application requirements and policies, the KDC may perform a gro up rekeying by generating new group keying material and distributing it to the c urrent group members through the rekeying scheme used in the group. </t> | |||
<t> | <t> | |||
At the end of the joining process, the joining node has received from the KDC th e parameters and group keying material to securely communicate with the other gr oup 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> | At the end of the joining process, the joining node has received the parameters and group keying material from the KDC to securely communicate with the other gr oup members. Also, the KDC has stored the association between the authorization information from the access token and the secure communication association with the joining node.</t> | |||
</li> | </li> | |||
<li>The joining node and the KDC maintain the secure association, to sup | <li>The joining node and the KDC maintain the secure communication assoc | |||
port possible future communications. These especially include key management ope | iation to support possible future communications. These especially include key m | |||
rations, such as retrieval of updated keying material or participation to a grou | anagement operations, such as the retrieval of updated keying material or the pa | |||
p rekeying process.</li> | rticipation in a group rekeying process.</li> | |||
<li>The joining node can communicate securely with the other group membe | <li>The joining node can communicate securely with the other group membe | |||
rs, using the keying material provided in step 3.</li> | rs by using the keying material obtained in step 3.</li> | |||
</ol> | </ol> | |||
<figure anchor="fig-flow"> | <figure anchor="fig-flow"> | |||
<name>Message Flow Upon New Node's Joining</name> | <name>Message Flow upon a New Node's Joining</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
C AS KDC Group | C AS KDC Group | |||
| | | Members | | | | Members | |||
/ | | | | | / | | | | | |||
| |--- Authorization Request -->| | | | | |--- Authorization Request -->| | | | |||
| | | | | | | | | | | | |||
| |<-- Authorization Response --| | | | | |<-- Authorization Response --| | | | |||
(*) < | | | | | (*) < | | | | | |||
| | | | | | | | | | | | |||
| |--- Token Transfer Request ---->| | | | |--- Token Transfer Request ---->| | | |||
skipping to change at line 264 ¶ | skipping to change at line 288 ¶ | |||
| | | | | | | | |||
(*) Defined in the ACE framework | (*) Defined in the ACE framework | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</section> | </section> | |||
<section anchor="sec-auth"> | <section anchor="sec-auth"> | |||
<name>Authorization to Join a Group</name> | <name>Authorization to Join a Group</name> | |||
<t>This section describes in detail the format of messages exchanged by th e participants when a node requests access to a given group. This exchange is ba sed on ACE <xref target="RFC9200"/>.</t> | <t>This section describes in detail the format of messages exchanged by th e participants when a node requests access to a given group. This exchange is ba sed 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-authoriz ation-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-respons e"/>).</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-authoriz ation-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-respons e"/>).</t> | |||
<t>Communications between the Client and the AS MUST be secured, according | <t>Communications between the Client and the AS <bcp14>MUST</bcp14> be sec | |||
to what is defined by the used transport profile of ACE. The Content-Format use | ured according to what is defined by the used transport profile of ACE. The Cont | |||
d in the message also depends on the used transport profile of ACE. For example, | ent-Format used in the message also depends on the used transport profile of ACE | |||
it can be application/ace+cbor for the first two messages and application/cwt f | . | |||
or the third message, which are defined in the ACE framework.</t> | For example, it can be "application/ace+cbor" for the first two messages and "ap | |||
<t>The transport profile of ACE also defines a number of details such as t | plication/cwt" for the third message, which are defined in the ACE framework.</t | |||
he communication and security protocols used with the KDC (see Appendix C of <xr | > | |||
ef target="RFC9200"/>).</t> | <t>The transport profile of ACE also defines a number of details, such as | |||
the communication and security protocols used with the KDC (see <xref target="RF | ||||
C9200" sectionFormat="of" section="C"/>).</t> | ||||
<t><xref target="fig-group-member-registration"/> gives an overview of the exchange described above.</t> | <t><xref target="fig-group-member-registration"/> gives an overview of the exchange described above.</t> | |||
<figure anchor="fig-group-member-registration"> | <figure anchor="fig-group-member-registration"> | |||
<name>Message Flow of Join Authorization</name> | <name>Message Flow of Join Authorization</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client AS KDC | Client AS KDC | |||
| | | | | | | | |||
|---- Authorization Request: POST /token ------->| | | |---- Authorization Request: POST /token ------->| | | |||
| | | | | | | | |||
|<--- Authorization Response: 2.01 (Created) ----| | | |<--- Authorization Response: 2.01 (Created) ----| | | |||
| | | | | | | | |||
|---- Token Transfer Request: POST /authz-info ------->| | |---- Token Transfer Request: POST /authz-info ------->| | |||
| | | | | | | | |||
|<--- Token Transfer Response: 2.01 (Created) -------->| | |<--- Token Transfer Response: 2.01 (Created) -------->| | |||
| | | | | | | | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<section anchor="ssec-authorization-request"> | <section anchor="ssec-authorization-request"> | |||
<name>Authorization Request</name> | <name>Authorization Request</name> | |||
<t>The Authorization Request sent from the Client to the AS is defined i n <xref section="5.8.1" sectionFormat="of" target="RFC9200"/> and MAY contain th e following parameters, which, if included, MUST have the format and value as sp ecified below.</t> | <t>The Authorization Request sent from the Client to the AS is defined i n <xref section="5.8.1" sectionFormat="of" target="RFC9200"/> and <bcp14>MAY</bc p14> contain the following parameters, which, if included, <bcp14>MUST</bcp14> h ave the format and value as specified below.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>'scope', specifying the names of the groups that the Client reque sts to access, and optionally the roles that the Client requests to have in thos e groups. </t> | <t>'scope': specifying the names of the groups that the Client reque sts to access and optionally the roles that the Client requests to have in those groups. </t> | |||
<t> | <t> | |||
This parameter is encoded as a CBOR byte string, which wraps a CBOR array of sco pe entries. All the scope entries are specified according to a same format, i.e. , either the AIF format or the textual format defined below. </t> | This parameter is encoded as a CBOR byte string, which wraps a CBOR array of sco pe entries. All the scope entries are specified according to the same format, i. e., either the Authorization Information Format (AIF) or the textual format defi ned below. </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <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 id entifier "Toid" specifies the group name and MUST be encoded as a CBOR text stri ng, while the permission set "Tperm" specifies the roles that the Client wishes to take in the group. </t> | <t>If AIF is used, each scope entry is encoded as per <xref targ et="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 "T oid" specifies the group name and <bcp14>MUST</bcp14> be encoded as a CBOR text string, while the permission set "Tperm" specifies the roles that the Client wis hes to take in the group. </t> | |||
<t> | <t> | |||
The AIF format is the default format for application profiles of this specificat | AIF is the default format for application profiles of this specification and is | |||
ion, and is preferable for those that aim for a compact encoding of scope. This | preferable for those that aim for a compact encoding of scope. This is especiall | |||
is desirable especially for application profiles defining several roles, with th | y desirable for application profiles defining several roles, with the Client pos | |||
e Client possibly asking for multiple roles combined. </t> | sibly asking for multiple roles combined. </t> | |||
<t><xref target="cddl-ex-0"/> shows an example in CDDL notation | <t><xref target="cddl-ex-0"/> shows an example in CDDL notation | |||
<xref target="RFC8610"/> where scope uses the AIF format.</t> | <xref target="RFC8610"/> where scope uses AIF.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>If the textual format is used, each scope entry is a CBOR arr ay formatted as follows. </t> | <t>If the textual format is used, each scope entry is a CBOR arr ay formatted as follows. </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>As first element, the group name, encoded as a CBOR text s | <li>As the first element, the group name, encoded as a CBOR te | |||
tring.</li> | xt string.</li> | |||
<li>Optionally, as second element, the role or CBOR array of r | <li>Optionally, as the second element, the role or CBOR array | |||
oles that the Client wishes to take in the group. This element is optional since | of roles that the Client wishes to take in the group. This element is optional s | |||
roles may have been pre-assigned to the Client, as associated with its verifiab | ince roles may have been pre-assigned to the Client, as associated with its veri | |||
le identity credentials. Alternatively, the application may have defined a singl | fiable identity credentials. Alternatively, the application may have defined a s | |||
e, well-known role for the target resource(s) and audience(s).</li> | ingle, well-known role for the target resource(s) and audience(s).</li> | |||
</ul> | </ul> | |||
<t> | <t> | |||
<xref target="cddl-ex"/> shows an example in CDDL notation where scope uses the textual format, with group name and role identifiers encoded as CBOR text string s.</t> | <xref target="cddl-ex"/> shows an example in CDDL notation where scope uses the textual format with the group name and role identifiers encoded as CBOR text str ings.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t> | <t> | |||
It is REQUIRED of application profiles of this specification to specify the exac t format and encoding of scope (REQ1). This includes defining the set of possibl e roles and their identifiers, as well as the corresponding encoding to use in t he scope entries according to the used scope format. </t> | It is <bcp14>REQUIRED</bcp14> for application profiles of this specification to specify the exact format and encoding of scope (<xref target="req1" format="none ">REQ1</xref>). This includes defining the set of possible roles and their ident ifiers, as well as the corresponding encoding to use in the scope entries accord ing to the used scope format. </t> | |||
<t> | <t> | |||
If the application profile uses the AIF format, it is also REQUIRED to register its specific instance of "Toid" and "Tperm", as well as the corresponding Media Type and Content-Format, as per the guidelines in <xref target="RFC9237"/> (REQ2 ). </t> | If the application profile uses AIF, it is also <bcp14>REQUIRED</bcp14> to regis ter its specific instance of "Toid" and "Tperm", as well as the corresponding me dia type and Content-Format, as per the guidelines in <xref target="RFC9237"/> ( <xref target="req2" format="none">REQ2</xref>). </t> | |||
<t> | <t> | |||
If the application profile uses the textual format, it MAY additionally specify CBOR values to use for abbreviating the role identifiers (OPT1).</t> | If the application profile uses the textual format, it <bcp14>MAY</bcp14> additi onally specify CBOR values to use for abbreviating the role identifiers (<xref t arget="opt1" format="none">OPT1</xref>).</t> | |||
</li> | </li> | |||
<li>'audience', with an identifier of the KDC.</li> | <li>'audience': with an identifier of the KDC.</li> | |||
</ul> | </ul> | |||
<t>As defined in <xref target="RFC9200"/>, other additional parameters c an be included if necessary.</t> | <t>As defined in <xref target="RFC9200"/>, other additional parameters c an be included if necessary.</t> | |||
<figure anchor="cddl-ex-0"> | <figure anchor="cddl-ex-0"> | |||
<name>Example of scope using the AIF format</name> | <name>Example of scope Using AIF</name> | |||
<sourcecode type="CDDL"><![CDATA[ | <sourcecode type="CDDL"><![CDATA[ | |||
;# include rfc9237 | ;# include rfc9237 | |||
gname = tstr | gname = tstr | |||
permissions = uint .bits roles | permissions = uint .bits roles | |||
roles = &( | roles = &( | |||
Requester: 1, | Requester: 1, | |||
Responder: 2, | Responder: 2, | |||
skipping to change at line 336 ¶ | skipping to change at line 361 ¶ | |||
roles = &( | roles = &( | |||
Requester: 1, | Requester: 1, | |||
Responder: 2, | Responder: 2, | |||
Monitor: 3, | Monitor: 3, | |||
Verifier: 4 | Verifier: 4 | |||
) | ) | |||
scope_entries = AIF-Generic<gname, permissions> | scope_entries = AIF-Generic<gname, permissions> | |||
scope = bstr .cbor scope_entries | scope = bstr .cbor scope_entries | |||
]]></sourcecode> | ]]></sourcecode> | |||
</figure> | </figure> | |||
<figure anchor="cddl-ex"> | <figure anchor="cddl-ex"> | |||
<name>Example of scope using the textual format, with the role identif iers encoded as text strings</name> | <name>Example of scope Using the Textual Format, with the Role Identif iers Encoded as Text Strings</name> | |||
<sourcecode type="CDDL"><![CDATA[ | <sourcecode type="CDDL"><![CDATA[ | |||
gname = tstr | gname = tstr | |||
role = tstr | role = tstr | |||
scope_entry = [ gname , ? ( role / [ 2*role ] ) ] | scope_entry = [ gname , ? ( role / [ 2*role ] ) ] | |||
scope_entries = [ * scope_entry ] | scope_entries = [ * scope_entry ] | |||
scope = bstr .cbor scope_entries | scope = bstr .cbor scope_entries | |||
]]></sourcecode> | ]]></sourcecode> | |||
</figure> | </figure> | |||
</section> | </section> | |||
<section anchor="ssec-authorization-response"> | <section anchor="ssec-authorization-response"> | |||
<name>Authorization Response</name> | <name>Authorization Response</name> | |||
<t>The AS processes the Authorization Request as defined in <xref sectio | <t>The AS processes the Authorization Request as defined in <xref sectio | |||
n="5.8.2" sectionFormat="of" target="RFC9200"/>, especially verifying that the C | n="5.8.2" sectionFormat="of" target="RFC9200"/>, especially verifying that the C | |||
lient is authorized to access the specified groups with the requested roles, or | lient is authorized to access the specified groups with the requested roles or p | |||
possibly a subset of those.</t> | ossibly a subset of those.</t> | |||
<t>In case of successful verification, the Authorization Response sent f | <t>In case of successful verification, the Authorization Response sent f | |||
rom the AS to the Client is also defined in <xref section="5.8.2" sectionFormat= | rom 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 be omitted if | "of" target="RFC9200"/>. Note that the 'expires_in' parameter <bcp14>MAY</bcp14 | |||
the application defines how the expiration time is communicated to the Client vi | > be omitted if the application defines how the expiration time is communicated | |||
a other means, or if it establishes a default value.</t> | to the Client via other means or if it establishes a default value.</t> | |||
<t>Additionally, when included, the following parameter MUST have the co | <t>Additionally, when included, the following parameter <bcp14>MUST</bcp | |||
rresponding values:</t> | 14> have the corresponding values:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'scope' has the same format and encoding of 'scope' in the Authori zation Request, defined in <xref target="ssec-authorization-request"/>. If this parameter is not present, the granted scope is equal to the one requested in <xr ef target="ssec-authorization-request"/>.</li> | <li>'scope' has the same format and encoding of 'scope' in the Authori zation Request, as defined in <xref target="ssec-authorization-request"/>. If th is parameter is not present, the granted scope is equal to the one requested in <xref target="ssec-authorization-request"/>.</li> | |||
</ul> | </ul> | |||
<t>The proof-of-possession access token (in 'access_token' above) MUST c ontain the following parameters:</t> | <t>The proof-of-possession access token in the 'access_token' parameter <bcp14>MUST</bcp14> contain the following:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>a confirmation claim (see, for example 'cnf' defined in <xref sect | <li>a confirmation claim (for example, see 'cnf' defined in <xref sect | |||
ion="3.1" sectionFormat="of" target="RFC8747"/> for CWT);</li> | ion="3.1" sectionFormat="of" target="RFC8747"/> for CWTs)</li> | |||
<li>an expiration time claim (see, for example 'exp' defined in <xref | <li>an expiration time claim (for example, see 'exp' defined in <xref | |||
section="3.1.4" sectionFormat="of" target="RFC8392"/> for CWT);</li> | section="3.1.4" sectionFormat="of" target="RFC8392"/> for CWTs)</li> | |||
<li> | <li> | |||
<t>a scope claim (see, for example 'scope' registered in <xref secti | <t>a scope claim (for example, see 'scope' registered in <xref secti | |||
on="8.14" sectionFormat="of" target="RFC9200"/> for CWT). </t> | on="8.14" sectionFormat="of" target="RFC9200"/> for CWTs)</t> | |||
<t> | <t>If the 'scope' parameter is present in the Authorization Response | |||
This claim specifies the same access control information as in the 'scope' param | , this claim specifies the same access control information as in the 'scope' par | |||
eter of the Authorization Response, if the parameter is present in the message. | ameter. Instead, if the 'scope' parameter is not present in the Authorization Re | |||
If the parameter is not present, the claim specifies the access control informat | sponse, this claim specifies the same access control information as in the 'scop | |||
ion as in the 'scope' parameter of the Authorization Request, if present, or the | e' parameter of the Authorization Request, if the parameter is present therein, | |||
default scope that the AS is granting the Client, if not present. </t> | or the default scope that the AS is granting the Client otherwise.</t> | |||
<t> | <t> | |||
By default, this claim has the same encoding as the 'scope' parameter in the Aut horization Request, defined in <xref target="ssec-authorization-request"/>. </t > | By default, this claim has the same encoding as the 'scope' parameter in the Aut horization Request, as defined in <xref target="ssec-authorization-request"/>. </t> | |||
<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 use d to express the actual access control information, and according to which this has to be parsed. This enables a Resource Server to correctly process a received access token, also in case: </t> | Optionally, an alternative extended format of scope defined in <xref target="sec -extended-scope"/> can be used. This format explicitly signals the semantics use d to express the actual access control information, which has to be parsed. This enables a Resource Server to correctly process a received access token, also in case: </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The Resource Server implements a KDC that supports multiple ap | <li>The Resource Server implements a KDC that supports multiple ap | |||
plication profiles of this specification, using different scope semantics; and/o | plication profiles of this specification using different scope semantics and/or< | |||
r</li> | /li> | |||
<li>The Resource Server implements further services beyond a KDC f | <li>The Resource Server implements further services beyond a KDC f | |||
or group communication, using different scope semantics.</li> | or group communication using different scope semantics.</li> | |||
</ul> | </ul> | |||
<t> | <t> | |||
If the Authorization Server is aware that this applies to the Resource Server fo r which the access token is issued, the Authorization Server SHOULD use the exte nded format of scope defined in <xref target="sec-extended-scope"/>.</t> | If the Authorization Server is aware that this applies to the Resource Server fo r which the access token is issued, the Authorization Server <bcp14>SHOULD</bcp1 4> use the extended format of scope defined in <xref target="sec-extended-scope" />.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>The access token MAY additionally contain other claims that the trans | <t>The access token <bcp14>MAY</bcp14> additionally contain other claims | |||
port profile of ACE requires, or other optional parameters.</t> | that the transport profile of ACE or other optional parameters require.</t> | |||
<t>When receiving an Authorization Request from a Client that was previo | <t>When receiving an Authorization Request from a Client that was previo | |||
usly authorized, and for which the AS still stores a valid non-expired access to | usly authorized and for which the AS still stores a valid non-expired access tok | |||
ken, the AS MAY reply with that token. Note that it is up to application profile | en, the AS <bcp14>MAY</bcp14> reply with that token. Note that it is up to appli | |||
s of ACE to make sure that re-posting the same access token does not cause re-us | cation profiles of ACE to make sure that reposting the same access token does no | |||
e of keying material between nodes (for example, that is accomplished with the u | t cause reuse of keying material between nodes (for example, that is accomplishe | |||
se of random nonces in <xref target="RFC9203"/>).</t> | d with the use of random nonces in <xref target="RFC9203"/>).</t> | |||
</section> | </section> | |||
<section anchor="token-post"> | <section anchor="token-post"> | |||
<name>Token Transferring</name> | <name>Token Transferring</name> | |||
<t>The Client sends a Token Transfer Request to the KDC, i.e., a CoAP PO ST request including the access token and targeting the authz-info endpoint (see <xref section="5.10.1" sectionFormat="of" target="RFC9200"/>).</t> | <t>The Client sends a Token Transfer Request to the KDC, i.e., a CoAP PO ST request including the access token and targeting the /authz-info endpoint (se e <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 concernin g the authentication credentials used in the group to ensure source authenticati on, as well as for possible additional group parameters.</t> | <t>Note that this request deviates from the one defined in <xref target= "RFC9200"/>, since it allows asking the KDC for additional information concernin g the authentication credentials used in the group to ensure source authenticati on, as well as for possible additional group parameters.</t> | |||
<t>The joining node MAY ask for this information from the KDC through th | <t>The joining node <bcp14>MAY</bcp14> ask for this information from the | |||
e same Token Transfer Request. In this case, the message MUST have Content-Forma | KDC through the same Token Transfer Request. | |||
t set to application/ace+cbor defined in <xref section="8.16" sectionFormat="of" | In this case, the message <bcp14>MUST</bcp14> have Content-Format "applic | |||
target="RFC9200"/>, and the message payload MUST be formatted as a CBOR map, wh | ation/ace+cbor" registered in <xref section="8.16" sectionFormat="of" target="RF | |||
ich MUST include the access token. The CBOR map MAY additionally include the fol | C9200"/>, and the message payload <bcp14>MUST</bcp14> be formatted as a CBOR map | |||
lowing parameter, which, if included, MUST have the format and value as specifie | , which <bcp14>MUST</bcp14> include the access token. The CBOR map <bcp14>MAY</b | |||
d below.</t> | cp14> additionally include the following parameter, which, if included, <bcp14>M | |||
UST</bcp14> have the format and value as specified below.</t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'sign_info' defined in <xref target="sign-info"/>, specifying the CBOR simple value "null" (0xf6) to request information about the signature algor ithm, the signature algorithm parameters, the signature key parameters, and the exact format of authentication credentials used in the groups that the Client ha s been authorized to join.</li> | <li>'sign_info': defined in <xref target="sign-info"/>, specifying the CBOR simple value <tt>null</tt> (0xf6) to request information about the signatu re algorithm, the signature algorithm parameters, the signature key parameters, and the exact format of authentication credentials used in the groups that the C lient has been authorized to join.</li> | |||
</ul> | </ul> | |||
<t>Alternatively, such information may be pre-configured on the joining node, or may be retrieved by alternative means. For example, the joining node ma y have performed an early group discovery process and obtained the link to the a ssociated group-membership resource at the KDC, together with attributes descrip tive of the group configuration (see, e.g., <xref target="I-D.tiloca-core-oscore -discovery"/>).</t> | <t>Alternatively, such information may be pre-configured on the joining 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 as sociated group-membership resource at the KDC, along with attributes that descri be the group configuration (e.g., see <xref target="I-D.tiloca-core-oscore-disco very"/>).</t> | |||
<t>After successful verification, the Client is authorized to receive th e 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) respo nse.</t> | <t>After successful verification, the Client is authorized to receive th e 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) respo nse.</t> | |||
<t>The Token Transfer Response MUST have Content-Format "application/ace | <t>The Token Transfer Response <bcp14>MUST</bcp14> have Content-Format " | |||
+cbor", and its payload is a CBOR map. Note that this deviates from what is defi | application/ace+cbor", and its payload is a CBOR map. Note that this deviates fr | |||
ned in the ACE framework, where the response from the authz-info endpoint is def | om what is defined in the ACE framework, where the response from the /authz-info | |||
ined as conveying no payload (see <xref section="5.10.1" sectionFormat="of" targ | endpoint is defined as conveying no payload (see <xref section="5.10.1" section | |||
et="RFC9200"/>).</t> | Format="of" target="RFC9200"/>).</t> | |||
<t>If a scope entry in the access token specifies a role that requires t | <t>If a scope entry in the access token specifies a role that requires t | |||
he Client to send its own authentication credential to the KDC when joining the | he Client to send its own authentication credential to the KDC when joining the | |||
related group, then the CBOR map MUST include the parameter 'kdcchallenge' defin | related group, then the CBOR map <bcp14>MUST</bcp14> include the 'kdcchallenge' | |||
ed in <xref target="kdcchallenge"/>, specifying a dedicated challenge N_S genera | parameter defined in <xref target="kdcchallenge"/>, specifying a dedicated chall | |||
ted by the KDC.</t> | enge N_S generated by the KDC.</t> | |||
<t>Later, when joining the group (see <xref target="ssec-key-distributio | <t>Later, when joining the group (see <xref target="ssec-key-distributio | |||
n-exchange"/>), the Client uses the 'kdcchallenge' value and additional informat | n-exchange"/>), the Client uses the 'kdcchallenge' value and additional informat | |||
ion to build a proof-of-possession (PoP) input. This is in turn used to compute | ion to build a proof-of-possession (PoP) input. In turn, this is used to compute | |||
a PoP evidence, which the Client also provides to the KDC in order to prove poss | the PoP evidence that the Client also provides to the KDC, in order to prove po | |||
ession of its own private key (see the 'client_cred_verify' parameter in <xref t | ssession of its own private key (see the 'client_cred_verify' parameter in <xref | |||
arget="gid-post"/>).</t> | target="gid-post"/>).</t> | |||
<t>While storing the access token, the KDC MUST store the 'kdcchallenge' | <t>While storing the access token, the KDC <bcp14>MUST</bcp14> store the | |||
value associated with the Client at least until it receives a Join Request from | 'kdcchallenge' value associated with the Client at least until it receives a Jo | |||
the Client (see <xref target="ssec-key-distribution-exchange"/>), to be able to | in Request from the Client (see <xref target="ssec-key-distribution-exchange"/>) | |||
verify the PoP evidence provided during the join process, and thus that the Cli | to be able to verify the PoP evidence provided during the join process and thus | |||
ent possesses its own private key. The KDC deletes the 'kdcchallenge' value asso | that the Client possesses its own private key. The KDC deletes the 'kdcchalleng | |||
ciated with the Client upon deleting the access token (e.g., upon its expiration | e' value associated with the Client upon deleting the access token (e.g., upon i | |||
, see <xref section="5.10.3" sectionFormat="of" target="RFC9200"/>).</t> | ts expiration, see <xref section="5.10.3" sectionFormat="of" target="RFC9200"/>) | |||
<t>The same 'kdcchallenge' value MAY be reused several times by the Clie | .</t> | |||
nt, to generate a new PoP evidence, e.g., in case the Client provides the KDC wi | <t>The same 'kdcchallenge' value <bcp14>MAY</bcp14> be reused several ti | |||
th a new authentication credential while being a group member (see <xref target= | mes by the Client to generate new PoP evidence, e.g., in case the Client provide | |||
"update-pub-key"/>), or joins a different group where it intends to use a differ | s the KDC with a new authentication credential while being a group member (see < | |||
ent authentication credential. Therefore, it is RECOMMENDED that the KDC keeps s | xref target="update-pub-key"/>) or joins a different group where it intends to u | |||
toring the 'kdcchallenge' value after the first join is processed as well. If, u | se a different authentication credential. Therefore, it is <bcp14>RECOMMENDED</b | |||
pon receiving a Join Request from a Client, the KDC has already discarded the 'k | cp14> that the KDC keeps storing the 'kdcchallenge' value after the first join i | |||
dcchallenge' value, that will trigger an error response with a newly generated ' | s processed as well. If, upon receiving a Join Request from a Client, the KDC ha | |||
kdcchallenge' value that the Client can use to restart the join process, as spec | s already discarded the 'kdcchallenge' value, that will trigger an error respons | |||
ified in <xref target="ssec-key-distribution-exchange"/>.</t> | e with a newly generated 'kdcchallenge' value that the Client can use to restart | |||
<t>If 'sign_info' is included in the Token Transfer Request, the KDC SHO | the join process, as specified in <xref target="ssec-key-distribution-exchange" | |||
ULD include the 'sign_info' parameter in the Token Transfer Response, as per the | />.</t> | |||
format defined in <xref target="sign-info"/>. Note that the field 'id' of each | <t>If 'sign_info' is included in the Token Transfer Request, the KDC <bc | |||
'sign_info_entry' specifies the name, or array of group names, to which that 'si | p14>SHOULD</bcp14> include the 'sign_info' parameter in the Token Transfer Respo | |||
gn_info_entry' applies. As an exception, the KDC MAY omit the 'sign_info' parame | nse, as per the format defined in <xref target="sign-info"/>. Note that the fiel | |||
ter in the Token Transfer Response even if 'sign_info' is included in the Token | d 'id' of each 'sign_info_entry' specifies the name or array of group names to w | |||
Transfer Request, in case none of the groups that the Client is authorized to jo | hich that 'sign_info_entry' applies. As an exception, the KDC <bcp14>MAY</bcp14> | |||
in uses signatures to achieve source authentication.</t> | omit the 'sign_info' parameter in the Token Transfer Response even if 'sign_inf | |||
<t>Note that the CBOR map specified as payload of the 2.01 (Created) res | o' is included in the Token Transfer Request in case none of the groups that the | |||
ponse may include further parameters, e.g., according to the used transport prof | Client is authorized to join use signatures to achieve source authentication.</ | |||
ile of ACE. Application profiles of this specification MAY define additional par | t> | |||
ameters to use within this exchange (OPT2).</t> | <t>Note that the CBOR map specified as payload of the 2.01 (Created) res | |||
<t>Application profiles of this specification MAY define alternative spe | ponse may include further parameters, e.g., according to the used transport prof | |||
cific negotiations of parameter values for the signature algorithm and signature | ile of ACE. Application profiles of this specification <bcp14>MAY</bcp14> define | |||
keys, if 'sign_info' is not used (OPT3).</t> | additional parameters to use within this exchange (<xref target="opt2" format=" | |||
<t>If allowed by the used transport profile of ACE, the Client may provi | none">OPT2</xref>).</t> | |||
de the Access Token to the KDC by other means than the Token Transfer Request. A | <t>Application profiles of this specification <bcp14>MAY</bcp14> define | |||
n example is the DTLS transport profile of ACE, where the Client can provide the | alternative specific negotiations of parameter values for the signature algorith | |||
access token to the KDC during the secure session establishment (see <xref sect | m and signature keys if 'sign_info' is not used (<xref target="opt3" format="non | |||
ion="3.3.2" sectionFormat="of" target="RFC9202"/>).</t> | e">OPT3</xref>).</t> | |||
<t>If allowed by the used transport profile of ACE, the Client may provi | ||||
de the access token to the KDC by other means than the Token Transfer Request. A | ||||
n 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 sect | ||||
ion="3.3.2" sectionFormat="of" target="RFC9202"/>).</t> | ||||
<section anchor="sign-info"> | <section anchor="sign-info"> | |||
<name>'sign_info' Parameter</name> | <name>'sign_info' Parameter</name> | |||
<t>The 'sign_info' parameter is an OPTIONAL parameter of the request a nd response messages exchanged between the Client and the authz-info endpoint at the RS (see <xref section="5.10.1." sectionFormat="of" target="RFC9200"/>).</t> | <t>The 'sign_info' parameter is an <bcp14>OPTIONAL</bcp14> parameter o f the request and response messages exchanged between the Client and the /authz- info endpoint at the RS (see <xref section="5.10.1" sectionFormat="of" target="R FC9200"/>).</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>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, t | <t>In this specification and in application profiles building on it, t | |||
his parameter is used to exchange information about the signature algorithm and | his parameter is used to exchange information about the signature algorithm and | |||
about authentication credentials to be used with it, in the groups indicated by | about authentication credentials to be used with it in the groups indicated by t | |||
the transferred access token as per its 'scope' claim (see <xref target="ssec-au | he transferred access token as per its 'scope' claim (see <xref target="ssec-aut | |||
thorization-response"/>).</t> | horization-response"/>).</t> | |||
<t>When used in the Token Transfer Request sent to the KDC (see <xref | <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 valu | target="token-post"/>), the 'sign_info' parameter specifies the CBOR simple valu | |||
e "null" (0xf6). This is done to ask for information about the signature algorit | e <tt>null</tt> (0xf6). This is done to ask for information about the signature | |||
hm and about the authentication credentials used in the groups that, as per the | algorithm and about the authentication credentials used in the groups that, as p | |||
granted roles, the Client has been authorized to join or interact with (e.g., as | er the granted roles, the Client has been authorized to join or interact with (e | |||
an external signature verifier).</t> | .g., as an external signature verifier).</t> | |||
<t>When used in the following Token Transfer Response from the KDC (se | <t>When used in the following Token Transfer Response from the KDC (se | |||
e <xref target="token-post"/>), the 'sign_info' parameter is a CBOR array of one | e <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 t | or more elements. The number of elements is at most the number of groups that t | |||
he Client has been authorized to join or interact with. Each element contains in | he Client has been authorized to join or interact with. Each element contains in | |||
formation about signing parameters and about authentication credentials for one | formation about signing parameters and about authentication credentials for one | |||
or more groups, and is formatted as follows.</t> | or more groups and is formatted as follows.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The first element 'id' is a group name or a CBOR array of group | <li>The first element 'id' is a group name or a CBOR array of group | |||
names, associated with groups for which the next four elements apply. Each speci | names, which is associated with groups for which the next four elements apply. E | |||
fied group name is a CBOR text string and is hereafter referred to as 'gname'.</ | ach specified group name is a CBOR text string and is hereafter referred to as ' | |||
li> | gname'.</li> | |||
<li>The second element 'sign_alg' is a CBOR integer or a text string | <li>The second element 'sign_alg' is a CBOR integer or a text string | |||
, indicating the signature algorithm used in the groups identified by the 'gname | that indicates the signature algorithm used in the groups identified by the 'gn | |||
' values. It is REQUIRED of application profiles to define specific values that | ame' values. It is <bcp14>REQUIRED</bcp14> for application profiles to define sp | |||
this parameter can take (REQ3), selected from the set of signing algorithms of t | ecific values that this parameter can take (<xref target="req3" format="none">RE | |||
he COSE Algorithms registry <xref target="COSE.Algorithms"/>.</li> | Q3</xref>), which are selected from the set of signing algorithms of the "COSE A | |||
<li>The third element 'sign_parameters' is a CBOR array indicating t | lgorithms" registry <xref target="COSE.Algorithms"/>.</li> | |||
he parameters of the signature algorithm used in the groups identified by the 'g | <li>The third element 'sign_parameters' is a CBOR array that indicat | |||
name' values. Its content depends on the value of 'sign_alg'. It is REQUIRED of | es the parameters of the signature algorithm used in the groups identified by th | |||
application profiles to define the possible values and structure for the element | e 'gname' values. Its content depends on the value of 'sign_alg'. It is <bcp14>R | |||
s of this parameter (REQ4).</li> | EQUIRED</bcp14> for application profiles to define the possible values and struc | |||
<li>The fourth element 'sign_key_parameters' is a CBOR array indicat | tures for the elements of this parameter (<xref target="req4" format="none">REQ4 | |||
ing the parameters of the key used with the signature algorithm, in the groups i | </xref>).</li> | |||
dentified by the 'gname' values. Its content depends on the value of 'sign_alg'. | <li>The fourth element 'sign_key_parameters' is a CBOR array that in | |||
It is REQUIRED of application profiles to define the possible values and struct | dicates the parameters of the key used with the signature algorithm in the group | |||
ure for the elements of this parameter (REQ5).</li> | s identified by the 'gname' values. Its content depends on the value of 'sign_al | |||
<li>The fifth element 'cred_fmt' is either a CBOR integer indicating | g'. It is <bcp14>REQUIRED</bcp14> for application profiles to define the possibl | |||
the format of authentication credentials used in the groups identified by the ' | e values and structures for the elements of this parameter (<xref target="req5" | |||
gname' values, or has value the CBOR simple value "null" (0xf6) indicating that | format="none">REQ5</xref>).</li> | |||
the KDC does not act as repository of authentication credentials for group membe | <li>The fifth element 'cred_fmt' is either a CBOR integer indicating | |||
rs. Its acceptable integer values are taken from the 'Label' column of the "COSE | the format of authentication credentials used in the groups identified by the ' | |||
Header Parameters" registry <xref target="COSE.Header.Parameters"/>, with some | gname' values or has the CBOR simple value <tt>null</tt> (0xf6), which indicates | |||
of those values also indicating the type of container to use for exchanging the | that the KDC does not act as a repository of authentication credentials for gro | |||
authentication credentials with the KDC (e.g., a chain or bag of certificates). | up members. Its acceptable integer values are taken from the "Label" column of t | |||
It is REQUIRED of application profiles to define specific values to use for this | he "COSE Header Parameters" registry <xref target="COSE.Header.Parameters"/>, wi | |||
parameter, consistently with the acceptable formats of authentication credentia | th some of those values also indicating the type of container to use for exchang | |||
ls (REQ6).</li> | ing the authentication credentials with the KDC (e.g., a chain or bag of certifi | |||
cates). It is <bcp14>REQUIRED</bcp14> for application profiles to define specifi | ||||
c values to use for this parameter, consistently with the acceptable formats of | ||||
authentication credentials (<xref target="req6" format="none">REQ6</xref>).</li> | ||||
</ul> | </ul> | |||
<t>The CDDL notation <xref target="RFC8610"/> of the 'sign_info' param eter is given below.</t> | <t>The CDDL notation <xref target="RFC8610"/> of the 'sign_info' param eter is given below.</t> | |||
<sourcecode type="CDDL"><![CDATA[ | <sourcecode type="CDDL"><![CDATA[ | |||
sign_info = sign_info_req / sign_info_resp | sign_info = sign_info_req / sign_info_resp | |||
sign_info_req = null ; in the Token Transfer | sign_info_req = null ; in the Token Transfer | |||
; Request to the KDC | ; Request to the KDC | |||
sign_info_resp = [ + sign_info_entry ] ; in the Token Transfer | sign_info_resp = [ + sign_info_entry ] ; in the Token Transfer | |||
; Response from the KDC | ; Response from the KDC | |||
skipping to change at line 443 ¶ | skipping to change at line 467 ¶ | |||
sign_key_parameters : [ + parameter : any ], | sign_key_parameters : [ + parameter : any ], | |||
cred_fmt : int / null | cred_fmt : int / null | |||
] | ] | |||
gname = tstr | gname = tstr | |||
]]></sourcecode> | ]]></sourcecode> | |||
<t>This format is consistent with every signature algorithm currently defined in <xref target="RFC9053"/>, i.e., with algorithms that have only the CO SE key type as their COSE capability. <xref target="sec-future-cose-algs"/> desc ribes how the format of each 'sign_info_entry' can be generalized for possible f uture registered algorithms having a different set of COSE capabilities.</t> | <t>This format is consistent with every signature algorithm currently defined in <xref target="RFC9053"/>, i.e., with algorithms that have only the CO SE key type as their COSE capability. <xref target="sec-future-cose-algs"/> desc ribes how the format of each 'sign_info_entry' can be generalized for possible f uture registered algorithms having a different set of COSE capabilities.</t> | |||
</section> | </section> | |||
<section anchor="kdcchallenge"> | <section anchor="kdcchallenge"> | |||
<name>'kdcchallenge' Parameter</name> | <name>'kdcchallenge' Parameter</name> | |||
<t>The 'kdcchallenge' parameter is an OPTIONAL parameter of the respon se 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>The 'kdcchallenge' parameter is an <bcp14>OPTIONAL</bcp14> paramete r of the response message returned from the /authz-info endpoint at the RS, as d efined in <xref section="5.10.1" sectionFormat="of" target="RFC9200"/>. This par ameter contains a challenge generated by the RS and provided to the Client.</t> | |||
<t>In this specification and in application profiles building on it, t he Client can use this challenge to prove possession of its own private key in t he Join Request (see the 'client_cred_verify' parameter in <xref target="gid-pos t"/>).</t> | <t>In this specification and in application profiles building on it, t he Client can use this challenge to prove possession of its own private key in t he Join Request (see the 'client_cred_verify' parameter in <xref target="gid-pos t"/>).</t> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="key-distr"> | <section anchor="key-distr"> | |||
<name>KDC Functionalities</name> | <name>KDC Functionalities</name> | |||
<t>This section describes the functionalities provided by the KDC, as rela ted to the provisioning of the keying material as well as to the group membershi p management.</t> | <t>This section describes the functionalities provided by the KDC, as rela ted to the provisioning of the keying material as well as to the group membershi p management.</t> | |||
<t>In particular, this section defines the interface available at the KDC; | <t>In particular, this section defines the interface available at the KDC, | |||
specifies the handlers of each resource provided by the KDC interface; and desc | specifies the handlers of each resource provided by the KDC interface, and desc | |||
ribes how Clients interact with those resources to join a group and to perform a | ribes how Clients interact with those resources to join a group and to perform a | |||
dditional operations as group members.</t> | dditional operations as group members.</t> | |||
<t>A key operation that the Client can perform after transferring the acce | <t>A key operation that the Client can perform after transferring the acce | |||
ss token to the KDC is a Join Request-Response exchange with the KDC. In the Joi | ss token to the KDC is a Join Request-Response exchange with the KDC. In the Joi | |||
n Request, the Client specifies the group it requests to join (see <xref target= | n 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 a | "ssec-key-distribution-exchange"/>). The KDC will then check the stored access t | |||
nd that the Client is authorized to join the specified group. If so, the KDC pro | oken associated with the Client and verify that the Client is accordingly author | |||
vides the Client with the keying material to securely communicate with the other | ized to join the specified group. In case of successful verification, the KDC pr | |||
members of the group.</t> | ovides the Client with the keying material to securely communicate with the othe | |||
<t>Later on as a group member, the Client can also rely on the interface a | r members of the group.</t> | |||
t the KDC to perform additional operations, consistent with the roles it has in | <t>Later on as a group member, the Client can also rely on the interface a | |||
the group.</t> | t the KDC to perform additional operations consistent with the roles it has in t | |||
he group.</t> | ||||
<section anchor="kdc-if"> | <section anchor="kdc-if"> | |||
<name>Interface at the KDC</name> | <name>Interface at the KDC</name> | |||
<t>The KDC provides its interface by hosting the following resources. No | <t>The KDC provides its interface by hosting the following resources. No | |||
te that the root url-path "ace-group" used hereafter is a default name; implemen | te that the root url-path "ace-group" used hereafter is a default name; implemen | |||
tations are not required to use this name, and can define their own instead.</t> | tations are not required to use this name and can define their own instead.</t> | |||
<t>If request messages sent to the KDC as well as success response messa | <t>If request messages sent to the KDC as well as success response messa | |||
ges from the KDC include a payload and specify a Content-Format, those messages | ges from the KDC include a payload and specify a Content-Format, those messages | |||
MUST have Content-Format set to application/ace-groupcomm+cbor, defined in <xref | <bcp14>MUST</bcp14> have Content-Format "application/ace-groupcomm+cbor", which | |||
target="content-type"/>. CBOR labels for the message parameters are defined in | is registered in <xref target="content-type"/>. CBOR map keys used for the messa | |||
<xref target="params"/>.</t> | ge parameters are defined in <xref target="params"/>.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li><t>/ace-group : the path of this root resource is invariant once | |||
<t>/ace-group : the path of this root resource is invariant once the | the resource is established and indicates that this specification is used. If o | |||
resource is established, and indicates that this specification is used. If othe | ther applications run on a KDC implementing this specification and use this same | |||
r applications run on a KDC implementing this specification and use this same pa | path, those applications will collide, and a mechanism will be needed to differ | |||
th, those applications will collide, and a mechanism will be needed to different | entiate the endpoints. </t> | |||
iate the endpoints. </t> | ||||
<t> | <t> | |||
A Client can access this resource in order to retrieve a set of group names, eac h corresponding to one of the specified group identifiers. This operation is des cribed in <xref target="retrieval-gnames"/>. </t> | A Client can access this resource in order to retrieve a set of group names, eac h corresponding to one of the specified group identifiers. This operation is des cribed in <xref target="retrieval-gnames"/>. </t> | |||
<t> | <t> | |||
Clients may be authorized to access this resource even without being members of any group at the KDC, and even if they are not authorized to become group member s (e.g., when authorized to be external signature verifiers). </t> | Clients may be authorized to access this resource even without being members of any group managed by the KDC and even if they are not authorized to become group members (e.g., when authorized to be external signature verifiers). </t> | |||
<t> | <t> | |||
The Interface Description (if=) Link Target Attribute value "ace.groups" is regi stered in <xref target="if-ace-group"/> and can be used to describe the interfac e provided by this root resource. </t> | The Interface Description (if=) Link Target Attribute value "ace.groups" is regi stered in <xref target="if-ace-group"/> and can be used to describe the interfac e provided by this root resource. </t> | |||
<t> | <t> | |||
The example below shows an exchange with a KDC with address 2001:db8::ab that ho sts the resource /ace-group and returns a link to such a resource in link-format <xref target="RFC6690"/>. </t> | The example below shows an exchange with a KDC with address 2001:db8::ab that ho sts the resource /ace-group and returns a link to such a resource in link-format <xref target="RFC6690"/>. </t> | |||
<artwork><![CDATA[ | ||||
<artwork><![CDATA[ | ||||
Request: | Request: | |||
Header: GET (Code=0.01) | Header: GET (Code=0.01) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: ".well-known" | Uri-Path: ".well-known" | |||
Uri-Path: "core" | Uri-Path: "core" | |||
Uri-Query: "if=ace.groups" | Uri-Query: "if=ace.groups" | |||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Content (Code=2.05) | |||
Content-Format: 40 (application/link-format) | Content-Format: application/link-format | |||
Payload: | Payload: | |||
<coap://[2001:db8::ab]/ace-group>;if="ace.groups" | <coap://[2001:db8::ab]/ace-group>;if="ace.groups" | |||
]]></artwork> | ]]></artwork> | |||
</li> | </li> | |||
<li> | ||||
<t>/ace-group/GROUPNAME : one such sub-resource to /ace-group is hos | <li><t>/ace-group/GROUPNAME : one such sub-resource to /ace-group is | |||
ted for each group with name GROUPNAME that the KDC manages. In particular, it i | hosted for each group with the name GROUPNAME that the KDC manages. In particul | |||
s the group-membership resource associated with that group, of which it contains | ar, it is the group-membership resource associated with that group, and it conta | |||
the symmetric group keying material. </t> | ins the symmetric group keying material of that group. </t> | |||
<t> | <t> | |||
A Client can access this resource in order to join the group with name GROUPNAME , or later as a group member to retrieve the current group keying material. Thes e operations are described in <xref target="ssec-key-distribution-exchange"/> an d <xref target="ssec-key-material-retrieval"/>, respectively. </t> | A Client can access this resource in order to join the group with name GROUPNAME or later as a group member to retrieve the current group keying material. These operations are described in Sections <xref target="ssec-key-distribution-exchan ge" format="counter"/> and <xref target="ssec-key-material-retrieval" format="co unter"/>, respectively. </t> | |||
<t> | <t> | |||
The Interface Description (if=) Link Target Attribute value "ace.group" is regis tered in <xref target="if-ace-group"/> and can be used to describe the interface provided by a group-membership resource. </t> | The Interface Description (if=) Link Target Attribute value "ace.group" is regis tered in <xref target="if-ace-group"/> and can be used to describe the interface provided by a group-membership resource. </t> | |||
<t> | <t> | |||
The example below shows an exchange with a KDC with address 2001:db8::ab that ho sts the group-membership resource /ace-group/gp1 and returns a link to such a re source in link-format <xref target="RFC6690"/>. </t> | The example below shows an exchange with a KDC with address 2001:db8::ab that ho sts the group-membership resource /ace-group/gp1 and returns a link to such a re source in link-format <xref target="RFC6690"/>. </t> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Request: | Request: | |||
Header: GET (Code=0.01) | Header: GET (Code=0.01) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: ".well-known" | Uri-Path: ".well-known" | |||
Uri-Path: "core" | Uri-Path: "core" | |||
Uri-Query: "if=ace.group" | Uri-Query: "if=ace.group" | |||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Content (Code=2.05) | |||
Content-Format: 40 (application/link-format) | Content-Format: application/link-format | |||
Payload: | Payload: | |||
<coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group" | <coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group" | |||
]]></artwork> | ]]></artwork> | |||
<t> | ||||
If it is not required that the value of the GROUPNAME URI path and the group nam | <t> | |||
e in the access token scope ('gname' in <xref target="ssec-authorization-respons | If it is not required that the value of the GROUPNAME URI path and the group nam | |||
e"/>) coincide, the KDC MUST implement a mechanism to map the GROUPNAME value in | e in the access token scope ('gname' in <xref target="ssec-authorization-request | |||
the URI to the group name, in order to refer to the correct group (REQ7).</t> | "/>) coincide, the KDC <bcp14>MUST</bcp14> implement a mechanism to map the GROU | |||
PNAME value in the URI to the group name in order to refer to the correct group | ||||
(<xref target="req7" format="none">REQ7</xref>).</t> | ||||
</li> | </li> | |||
<li> | <li><t>/ace-group/GROUPNAME/creds : the path of this resource is inv | |||
<t>/ace-group/GROUPNAME/creds : the path of this resource is invaria | ariant once the resource is established. This resource contains the authenticati | |||
nt once the resource is established. This resource contains the authentication c | on credentials of all the members of the group with the name GROUPNAME. </t> | |||
redentials of all the members of the group with name GROUPNAME. </t> | ||||
<t> | <t> | |||
This resource is created only in case the KDC acts as a repository of authentica tion credentials for group members. </t> | This resource is created only in case the KDC acts as a repository of authentica tion credentials for group members. </t> | |||
<t> | <t> | |||
As a group member, a Client can access this resource in order to retrieve the au thentication credentials of other group members. That is, the Client can retriev e the authentication credentials of all the current group members, or a subset o f them by specifying filter criteria. These operations are described in <xref ta rget="sec-key-retrieval-all"/> and <xref target="sec-key-retrieval"/>, respectiv ely. </t> | As a group member, a Client can access this resource in order to retrieve the au thentication credentials of other group members. That is, the Client can retriev e the authentication credentials of all the current group members or a subset of them by specifying filter criteria. These operations are described in Sections <xref target="sec-key-retrieval-all" format="counter"/> and <xref target="sec-ke y-retrieval" format="counter"/>, respectively. </t> | |||
<t> | <t> | |||
Clients may be authorized to access this resource even without being group membe rs, e.g., if authorized to be external signature verifiers for the group.</t> | Clients may be authorized to access this resource even without being group membe rs, e.g., if authorized to be external signature verifiers for the group.</t> | |||
</li> | </li> | |||
<li> | <li><t>/ace-group/GROUPNAME/kdc-cred : the path of this resource is | |||
<t>/ace-group/GROUPNAME/kdc-cred : the path of this resource is inva | invariant once the resource is established. This resource contains the authentic | |||
riant once the resource is established. This resource contains the authenticatio | ation credential of the KDC for the group with the name GROUPNAME. </t> | |||
n credential of the KDC for the group with name GROUPNAME. </t> | ||||
<t> | <t> | |||
This resource is created only in case the KDC has an associated authentication c redential and this is required for the correct group operation. It is REQUIRED o f application profiles to define whether the KDC has such an associated authenti cation credential (REQ8). </t> | This resource is created only in case the KDC has an associated authentication c redential and this is required for the correct group operation. It is <bcp14>REQ UIRED</bcp14> for application profiles to define whether the KDC has such an ass ociated authentication credential (<xref target="req8" format="none">REQ8</xref> ). </t> | |||
<t> | <t> | |||
As a group member, a Client can access this resource in order to retrieve the cu rrent authentication credential of the KDC. </t> | As a group member, a Client can access this resource in order to retrieve the cu rrent authentication credential of the KDC. This operation is described in <xr ef target="kdc-pub-key"/>.</t> | |||
<t> | <t> | |||
Clients may be authorized to access this resource even without being group membe rs, e.g., if authorized to be external signature verifiers for the group.</t> | Clients may be authorized to access this resource even without being group membe rs, e.g., if authorized to be external signature verifiers for the group.</t> | |||
</li> | </li> | |||
<li> | <li><t>/ace-group/GROUPNAME/policies : the path of this resource is | |||
<t>/ace-group/GROUPNAME/policies : the path of this resource is inva | invariant once the resource is established. This resource contains the group pol | |||
riant once the resource is established. This resource contains the group policie | icies of the group with the name GROUPNAME. </t> | |||
s of the group with name GROUPNAME. </t> | ||||
<t> | <t> | |||
A Client can access this resource as a group member in order to retrieve the gro up policies. This operation is described in <xref target="policies"/>.</t> | A Client can access this resource as a group member in order to retrieve the gro up policies. This operation is described in <xref target="policies"/>.</t> | |||
</li> | </li> | |||
<li> | <li><t>/ace-group/GROUPNAME/num : the path of this resource is invar | |||
<t>/ace-group/GROUPNAME/num : the path of this resource is invariant | iant once the resource is established. This resource contains the current versio | |||
once the resource is established. This resource contains the current version nu | n number for the symmetric group keying material of the group with the name GROU | |||
mber for the symmetric group keying material of the group with name GROUPNAME. | PNAME. </t> | |||
</t> | ||||
<t> | <t> | |||
A Client can access this resource as a group member in order to retrieve the ver sion number of the keying material currently used in the group. This operation i s described in <xref target="key-version"/>.</t> | A Client can access this resource as a group member in order to retrieve the ver sion number of the keying material currently used in the group. This operation i s described in <xref target="key-version"/>.</t> | |||
</li> | </li> | |||
<li> | <li><t>/ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource o | |||
<t>/ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource of /a | f /ace-group/GROUPNAME is hosted for each group member of the group with the nam | |||
ce-group/GROUPNAME is hosted for each group member of the group with name GROUPN | e GROUPNAME. Each such resource is identified by the node name NODENAME of the a | |||
AME. Each such resource is identified by the node name NODENAME of the associate | ssociated group member and contains the group keying material and the individual | |||
d group member, and contains the group keying material and the individual keying | keying material for that group member. </t> | |||
material for that group member. </t> | ||||
<t> | <t> | |||
A Client as a group member can access this resource in order to retrieve the cur rent group keying material together with its individual keying material; request new individual keying material to use in the group; and leave the group. These operations are described in <xref target="update-keys"/>, <xref target="new-keys "/>, and <xref target="ssec-group-leaving"/>, respectively.</t> | A Client as a group member can access this resource in order to retrieve the cur rent group keying material together with its individual keying material, request new individual keying material to use in the group, and leave the group. These operations are described in Sections <xref target="update-keys" format="counter" />, <xref target="new-keys" format="counter"/>, and <xref target="ssec-group-lea ving" format="counter"/>, respectively.</t> | |||
</li> | </li> | |||
<li> | <li><t>/ace-group/GROUPNAME/nodes/NODENAME/cred : the path of this r | |||
<t>/ace-group/GROUPNAME/nodes/NODENAME/cred : the path of this resou | esource is invariant once the resource is established. This resource contains th | |||
rce is invariant once the resource is established. This resource contains the in | e individual authentication credential for the node with the name NODENAME as a | |||
dividual authentication credential for the node with name NODENAME, as group mem | group member of the group with the name GROUPNAME. </t> | |||
ber of the group with name GROUPNAME. </t> | ||||
<t> | <t> | |||
A Client can access this resource in order to upload at the KDC a new authentica tion credential to use in the group. This operation is described in <xref target ="update-pub-key"/>. </t> | A Client can access this resource in order to upload at the KDC a new authentica tion credential to use in the group. This operation is described in <xref target ="update-pub-key"/>. </t> | |||
<t> | <t> | |||
This resource is not created if the group member does not have an authentication credential to use in the group, or if the KDC does not store the authentication credentials of group members.</t> | This resource is not created if the group member does not have an authentication credential to use in the group or if the KDC does not store the authentication credentials of group members.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>The KDC is expected to fully provide the interface defined above. It | ||||
is otherwise REQUIRED of the application profiles of this specification to indic | <t>The KDC is expected to fully provide the interface defined above. It | |||
ate which resources are not hosted, i.e., which parts of the interface defined i | is otherwise <bcp14>REQUIRED</bcp14> for the application profiles of this speci | |||
n this section are not supported by the KDC (REQ9). Application profiles of this | fication to indicate which resources are not hosted, i.e., which parts of the in | |||
specification MAY extend the KDC interface, by defining additional handlers, as | terface defined in this section are not supported by the KDC (<xref target="req9 | |||
well as defining additional resources and their handlers.</t> | " format="none">REQ9</xref>). Application profiles of this specification <bcp14> | |||
<t>It is REQUIRED of application profiles of this specification to regis | MAY</bcp14> extend the KDC interface by defining additional handlers, as well as | |||
ter a Resource Type for the group-membership resource (REQ10), i.e., the group-m | defining additional resources and their handlers.</t> | |||
embership resource at /ace-group/GROUPNAME. This Resource Type can be used to di | <t>It is <bcp14>REQUIRED</bcp14> for application profiles of this specif | |||
scover the correct URL for sending a Join Request to the KDC. This Resource Type | ication to register a Resource Type for the group-membership resources (<xref ta | |||
can also be used to indicate which specific application profile of this specifi | rget="req10" format="none">REQ10</xref>). This Resource Type can be used to disc | |||
cation is used by a specific group-membership resource at the KDC.</t> | over the correct URL for sending a Join Request to the KDC. This Resource Type c | |||
<t>It is REQUIRED of application profiles of this specification to defin | an also be used to indicate which specific application profile of this specifica | |||
e what specific actions (e.g., CoAP methods) are allowed on each resource provid | tion is used by a specific group-membership resource at the KDC.</t> | |||
ed by the KDC interface, depending on whether the Client is a current group memb | <t>It is <bcp14>REQUIRED</bcp14> for application profiles of this specif | |||
er; the roles that a Client is authorized to take as per the obtained access tok | ication to define what specific actions (e.g., CoAP methods) are allowed on each | |||
en (see <xref target="ssec-authorization-request"/>); and the roles that the Cli | resource provided by the KDC interface, depending on whether the Client is a cu | |||
ent has as current group member (REQ11).</t> | rrent group member, the roles that a Client is authorized to take as per the obt | |||
ained access token (see <xref target="ssec-authorization-request"/>), and the ro | ||||
les that the Client has as current group member (<xref target="req11" format="no | ||||
ne">REQ11</xref>).</t> | ||||
<section anchor="client-operations"> | <section anchor="client-operations"> | |||
<name>Operations Supported by Clients</name> | <name>Operations Supported by Clients</name> | |||
<t>It is expected that a Client minimally supports the following set o f primary operations and corresponding interactions with the KDC.</t> | <t>It is expected that a Client minimally supports the following set o f primary operations and corresponding interactions with the KDC.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>FETCH request to /ace-group/ , in order to retrieve group names | <li>FETCH request to /ace-group/ in order to retrieve group names as | |||
associated with group identifiers.</li> | sociated with group identifiers.</li> | |||
<li>POST and GET requests to /ace-group/GROUPNAME/ , in order to joi | <li>POST and GET requests to /ace-group/GROUPNAME/ in order to join | |||
n a group (POST) and later retrieve the current group key material as a group me | a group (POST) and later retrieve the current group keying material as a group m | |||
mber (GET).</li> | ember (GET).</li> | |||
<li>GET and FETCH requests to /ace-group/GROUPNAME/creds , in order | <li>GET and FETCH requests to /ace-group/GROUPNAME/creds in order to | |||
to retrieve the authentication credentials of all the other group members (GET) | retrieve the authentication credentials of all the other group members (GET) or | |||
or only some of them by filtering (FETCH). While retrieving authentication crede | only some of them by filtering (FETCH). While retrieving authentication credent | |||
ntials remains possible by using GET requests, retrieval by filtering allows Cli | ials remains possible by using GET requests, retrieval by filtering allows Clien | |||
ents to greatly limit the size of exchanged messages.</li> | ts to greatly limit the size of exchanged messages.</li> | |||
<li>GET request to /ace-group/GROUPNAME/num , in order to retrieve t | <li>GET request to /ace-group/GROUPNAME/num in order to retrieve the | |||
he current version of the group key material as a group member.</li> | current version of the group keying material as a group member.</li> | |||
<li>DELETE request to /ace-group/GROUPNAME/nodes/NODENAME , in order | <li>DELETE request to /ace-group/GROUPNAME/nodes/NODENAME in order | |||
to leave the group.</li> | to leave the group.</li> | |||
</ul> | </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 t o consider the used application profile of this specification.</t> | <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 t o consider the used application profile of this specification.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>GET request to /ace-group/GROUPNAME/kdc-cred , in order to retri | <li>GET request to /ace-group/GROUPNAME/kdc-cred in order to retriev | |||
eve the current authentication credential of the KDC. This is relevant only if t | e the current authentication credential of the KDC. This is relevant only if the | |||
he KDC has an associated authentication credential and this is required for the | KDC has an associated authentication credential and this is required for the co | |||
correct group operation.</li> | rrect group operation.</li> | |||
<li>GET request to /ace-group/GROUPNAME/policies , in order to retri | <li>GET request to /ace-group/GROUPNAME/policies in order to retriev | |||
eve the current group policies as a group member.</li> | e the current group policies as a group member.</li> | |||
<li>GET request to /ace-group/GROUPNAME/nodes/NODENAME , in order to | <li>GET request to /ace-group/GROUPNAME/nodes/NODENAME in order to r | |||
retrieve the current group keying material and individual keying material. The | etrieve the current group keying material and individual keying material. The fo | |||
former can also be retrieved through a GET request to /ace-group/GROUPNAME/ (see | rmer can also be retrieved through a GET request to /ace-group/GROUPNAME/ (see a | |||
above).</li> | bove).</li> | |||
<li>PUT request to /ace-group/GROUPNAME/nodes/NODENAME , in order to | <li>PUT request to /ace-group/GROUPNAME/nodes/NODENAME in order to a | |||
ask for new individual keying material. Alternatively, the Client could obtain | sk for new individual keying material. Alternatively, the Client could obtain ne | |||
new individual keying material by re-joining the group through a POST request to | w individual keying material by rejoining the group through a POST request to /a | |||
/ace-group/GROUPNAME/ (see above). Furthermore, depending on its roles in the g | ce-group/GROUPNAME/ (see above). Furthermore, depending on its roles in the grou | |||
roup or on the application profile of this specification, the Client might simpl | p or on the application profile of this specification, the Client might simply n | |||
y not be associated with any individual keying material.</li> | ot be associated with any individual keying material.</li> | |||
<li>POST request to /ace-group/GROUPNAME/nodes/NODENAME/cred , in or | <li>POST request to /ace-group/GROUPNAME/nodes/NODENAME/cred in orde | |||
der to provide the KDC with a new authentication credential. Alternatively, the | r to provide the KDC with a new authentication credential. Alternatively, the Cl | |||
Client could provide a new authentication credential by re-joining the group thr | ient could provide a new authentication credential by rejoining the group throug | |||
ough a POST request to /ace-group/GROUPNAME/ (see above). Furthermore, depending | h a POST request to /ace-group/GROUPNAME/ (see above). Furthermore, depending on | |||
on its roles in the group, the Client might simply not have an associated authe | its roles in the group, the Client might simply not have an associated authenti | |||
ntication credential to provide.</li> | cation credential to provide.</li> | |||
</ul> | </ul> | |||
<t>It is REQUIRED of application profiles of this specification to cat egorize possible newly defined operations for Clients into primary operations an d secondary operations, and to provide accompanying considerations (REQ12).</t> | <t>It is <bcp14>REQUIRED</bcp14> for application profiles of this spec ification to categorize possible newly defined operations for Clients into prima ry and secondary operations and to provide accompanying considerations (<xref ta rget="req12" format="none">REQ12</xref>).</t> | |||
</section> | </section> | |||
<section anchor="kdc-if-errors"> | <section anchor="kdc-if-errors"> | |||
<name>Error Handling</name> | <name>Error Handling</name> | |||
<t>Upon receiving a request from a Client, the KDC MUST check that it | <t>Upon receiving a request from a Client, the KDC <bcp14>MUST</bcp14> | |||
is storing a valid access token from that Client. If this is not the case, the K | check that it is storing a valid access token from that Client. If this is not | |||
DC MUST reply with a 4.01 (Unauthorized) error response.</t> | the case, the KDC <bcp14>MUST</bcp14> reply with a 4.01 (Unauthorized) error res | |||
<t>Unless the request targets the /ace-group resource, the KDC MUST ch | ponse.</t> | |||
eck that it is storing a valid access token from that Client such that:</t> | <t>Unless the request targets the /ace-group resource, the KDC <bcp14> | |||
MUST</bcp14> check that it is storing a valid access token for that Client such | ||||
that:</t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The scope specified in the access token includes a scope entry r | <li>the scope specified in the access token includes a scope entry r | |||
elated to the group name GROUPNAME associated with the targeted resource; and</l | elated to the group name GROUPNAME associated with the targeted resource and</li | |||
i> | > | |||
<li>The set of roles specified in that scope entry allows the Client | <li>the set of roles specified in that scope entry allows the Client | |||
to perform the requested operation on the targeted resource (REQ11).</li> | to perform the requested operation on the targeted resource (<xref target="req1 | |||
1" format="none">REQ11</xref>).</li> | ||||
</ul> | </ul> | |||
<t>In case the KDC stores a valid access token but the verifications a | <t>In case the KDC stores a valid access token but the verifications a | |||
bove fail, the KDC MUST reply with a 4.03 (Forbidden) error response. This respo | bove fail, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error respo | |||
nse MAY be an AS Request Creation Hints, as defined in <xref section="5.3" secti | nse. This response <bcp14>MAY</bcp14> be an AS Request Creation Hints, as define | |||
onFormat="of" target="RFC9200"/>, in which case the Content-Format MUST be set t | d in <xref section="5.3" sectionFormat="of" target="RFC9200"/>, in which case th | |||
o application/ace+cbor.</t> | e Content-Format <bcp14>MUST</bcp14> be "application/ace+cbor".</t> | |||
<t>If the request is not formatted correctly (e.g., required fields ar | <t>If the request is not formatted correctly (e.g., required fields ar | |||
e not present or are not encoded as expected), the handler MUST reply with a 4.0 | e not present or are not encoded as expected), the KDC <bcp14>MUST</bcp14> reply | |||
0 (Bad Request) error response.</t> | with a 4.00 (Bad Request) error response.</t> | |||
<t>If the request includes unknown or non-expected fields, the handler | <t>If the request includes unknown or unexpected fields, the KDC <bcp1 | |||
MUST silently ignore them and continue processing the request. Application prof | 4>MUST</bcp14> silently ignore them and continue processing the request. Applica | |||
iles of this specification MAY define optional or mandatory payload formats for | tion profiles of this specification <bcp14>MAY</bcp14> define optional or mandat | |||
specific error cases (OPT4).</t> | ory payload formats for specific error cases (<xref target="opt4" format="none"> | |||
<t>Some error responses from the KDC can convey error-specific informa | OPT4</xref>).</t> | |||
tion according to the problem-details format defined in <xref target="RFC9290"/> | <t>Some error responses from the KDC can convey error-specific informa | |||
. Such error responses MUST have Content-Format set to application/concise-probl | tion according to the problem-details format defined in <xref target="RFC9290"/> | |||
em-details+cbor. The payload of these error responses MUST be a CBOR map specify | . Such error responses <bcp14>MUST</bcp14> have Content-Format "application/conc | |||
ing a Concise Problem Details data item (see <xref section="2" sectionFormat="of | ise-problem-details+cbor". The payload of these error responses <bcp14>MUST</bcp | |||
" target="RFC9290"/>). The CBOR map is formatted as follows.</t> | 14> be a CBOR map specifying a Concise Problem Details data item (see <xref sect | |||
ion="2" sectionFormat="of" target="RFC9290"/>). The CBOR map is formatted as fol | ||||
lows.</t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>It MUST include the Custom Problem Detail entry 'ace-groupcomm- error' registered in <xref target="iana-custom-problem-details"/> of this docume nt. </t> | <t>It <bcp14>MUST</bcp14> include the Custom Problem Detail entry 'ace-groupcomm-error', which is registered in <xref target="iana-custom-problem- details"/> of this document. </t> | |||
<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 val ue of 'error-id' is a CBOR integer specifying the error occurred at the KDC. Thi s value is taken from the 'Value' column of the "ACE Groupcomm Errors" registry defined in <xref target="iana-ace-groupcomm-errors"/> of this document. </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 val ue of 'error-id' is a CBOR integer specifying the error that occurred at the KDC . This value is taken from the "Value" column of the "ACE Groupcomm Errors" regi stry defined in <xref target="iana-ace-groupcomm-errors"/> of this document. </ t> | |||
<t> | <t> | |||
The CDDL notation <xref target="RFC8610"/> of the 'ace-groupcomm-error' entry is given below.</t> | The CDDL notation <xref target="RFC8610"/> of the 'ace-groupcomm-error' entry is given below.</t> | |||
</li> | ||||
</ul> | ||||
<sourcecode type="CDDL"><![CDATA[ | <sourcecode type="CDDL"><![CDATA[ | |||
ace-groupcomm-error = { | ace-groupcomm-error = { | |||
&(error-id: 0) => int | &(error-id: 0) => int | |||
} | } | |||
]]></sourcecode> | ]]></sourcecode> | |||
<ul spacing="normal"> | </li> | |||
<li> | <li> | |||
<t>It MAY include further Standard Problem Detail entries or Custo m Problem Detail entries (see <xref target="RFC9290"/>). </t> | <t>It <bcp14>MAY</bcp14> include further Standard Problem Detail e ntries or Custom Problem Detail entries (see <xref target="RFC9290"/>). </t> | |||
<t> | <t> | |||
In particular, it can include the Standard Problem Detail entry 'detail' (map ke y -2), whose value is a CBOR text string that specifies a human-readable, diagno stic description of the error occurred at the KDC. The diagnostic text is intend ed for software engineers as well as for device and network operators, in order to aid debugging and provide context for possible intervention. The diagnostic m essage SHOULD be logged by the KDC. The 'detail' entry is unlikely relevant in a n unattended setup where human intervention is not expected.</t> | In particular, it can include the Standard Problem Detail entry 'detail' (map ke y -2), whose value is a CBOR text string that specifies a human-readable, diagno stic description of the error occurred at the KDC. The diagnostic text is intend ed for software engineers as well as for device and network operators in order t o aid debugging and provide context for possible intervention. The diagnostic me ssage <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> | </li> | |||
</ul> | </ul> | |||
<t>An example of error response using the problem-details format is sh own in <xref target="fig-exapmle-error-response"/>.</t> | <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"> | <figure anchor="fig-exapmle-error-response"> | |||
<name>Example of Error Response with Problem Details</name> | <name>Example of an Error Response with Problem Details</name> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Response: | Response: | |||
Header: Service Unavailable (Code=5.03) | Header: Service Unavailable (Code=5.03) | |||
Content-Format: application/concise-problem-details+cbor | Content-Format: application/concise-problem-details+cbor | |||
Payload: | Payload: | |||
{ | { | |||
/ title / -1: "No available node identifiers", | / title / -1: "No available node identifiers", | |||
/ detail / -2: "Things will change after a | / detail / -2: "Things will change after a | |||
group rekeying; try later", | group rekeying; try later", | |||
/ ace-groupcomm-error / TBD: { | / ace-groupcomm-error / 0: { | |||
/ error-id / 0: 4 / "No available node identifiers" /, | / error-id / 0: 4 / "No available node identifiers" / | |||
} | } | |||
} | } | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>Note to RFC Editor: In the figure above, please replace "TBD" with | <t>The problem-details format (in general) and the Custom Problem Deta | |||
the unsigned integer assigned as key value to the Custom Problem Detail entry 'a | il entry 'ace-groupcomm-error' (in particular) are <bcp14>OPTIONAL</bcp14> for C | |||
ce-groupcomm-error' (see <xref target="iana-custom-problem-details"/>). Then, pl | lients to support. A Client supporting the entry 'ace-groupcomm-error' and that | |||
ease delete this paragraph.</t> | can understand the specified error may use that information to determine what ac | |||
<t>The problem-details format in general and the Custom Problem Detail | tions to take next.</t> | |||
entry 'ace-groupcomm-error' in particular are OPTIONAL to support for Clients. | <t><xref target="error-types"/> of this specification defines an initi | |||
A Client supporting the entry 'ace-groupcomm-error' and able to understand the s | al set of error identifiers as possible values for the 'error-id' field. Applica | |||
pecified error may use that information to determine what actions to take next.< | tion profiles of this specification inherit this initial set of error identifier | |||
/t> | s and <bcp14>MAY</bcp14> define additional values (<xref target="opt5" format="n | |||
<t><xref target="error-types"/> of this specification defines an initi | one">OPT5</xref>).</t> | |||
al set of error identifiers, as possible values for the 'error-id' field. Applic | ||||
ation profiles of this specification inherit this initial set of error identifie | ||||
rs and MAY define additional values (OPT5).</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="ace-group"> | <section anchor="ace-group"> | |||
<name>/ace-group</name> | <name>/ace-group</name> | |||
<t>This resource implements the FETCH handler.</t> | <t>This resource implements the FETCH handler.</t> | |||
<section anchor="ace-group-fetch"> | <section anchor="ace-group-fetch"> | |||
<name>FETCH Handler</name> | <name>FETCH Handler</name> | |||
<t>The FETCH handler receives group identifiers and returns the corres ponding group names and GROUPNAME URIs.</t> | <t>The FETCH handler receives group identifiers and returns the corres ponding group names and GROUPNAME URIs.</t> | |||
<t>The handler expects a request with payload formatted as a CBOR map, which MUST contain the following fields:</t> | <t>The handler expects a request with the payload formatted as a CBOR map, which <bcp14>MUST</bcp14> contain the following fields:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'gid', whose value is encoded as a CBOR array, containing one or more group identifiers. The exact encoding of the group identifier MUST be spec ified by the application profile (REQ13). The Client indicates that it wishes to receive the group names of all the groups having these identifiers.</li> | <li>'gid': its value is encoded as a CBOR array, containing one or m ore group identifiers. The exact encoding of the group identifier <bcp14>MUST</b cp14> be specified by the application profile (<xref target="req13" format="none ">REQ13</xref>). The Client indicates that it wishes to receive the group names of all the groups having these identifiers.</li> | |||
</ul> | </ul> | |||
<t>The handler identifies the groups where communications are secured by using the keying material identified by those group identifiers.</t> | <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 (Cont ent) response, whose payload is formatted as a CBOR map that MUST contain the fo llowing fields:</t> | <t>If all verifications succeed, the handler replies with a 2.05 (Cont ent) response, whose payload is formatted as a CBOR map that <bcp14>MUST</bcp14> contain the following fields:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'gid', whose value is encoded as a CBOR array, containing zero o | <li>'gid': its value is encoded as a CBOR array, containing zero or | |||
r more group identifiers. The handler indicates that those are the identifiers i | more group identifiers. The handler indicates that those are the identifiers it | |||
t is sending group names for. This CBOR array is a subset of the 'gid' array in | is sending group names for. This CBOR array is a subset of the 'gid' array in th | |||
the FETCH request.</li> | e FETCH request.</li> | |||
<li>'gname', whose value is encoded as a CBOR array, containing zero | <li>'gname': its value is encoded as a CBOR array, containing zero o | |||
or more group names. The elements of this array are encoded as text strings. Ea | r more group names. The elements of this array are encoded as text strings. Each | |||
ch element of index i in this CBOR array is associated with the element of index | element of index i in this CBOR array is associated with the element of index i | |||
i in the 'gid' array.</li> | in the 'gid' array.</li> | |||
<li>'guri', whose value is encoded as a CBOR array, containing zero | <li>'guri': its value is encoded as a CBOR array, containing zero or | |||
or more URIs, each indicating a group-membership resource. The elements of this | more URIs, each indicating a group-membership resource. The elements of this ar | |||
array are encoded as text strings. Each element of index i in this CBOR array is | ray are encoded as text strings. Each element of index i in this CBOR array is a | |||
associated with the element of index i in the 'gid' array.</li> | ssociated with the element of index i in the 'gid' array.</li> | |||
</ul> | </ul> | |||
<t>If the KDC does not find any group associated with the specified gr | <t>If the KDC does not find any group associated with the specified gr | |||
oup identifiers, the handler returns a response with payload formatted as a CBOR | oup identifiers, the handler returns a response with the payload formatted as a | |||
byte string of zero length.</t> | CBOR byte string of zero length (0x40).</t> | |||
<t>Note that the KDC only verifies that the node is authorized by the | <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 auth | AS to access this resource. Nodes that are not members of the group but are auth | |||
orized to do signature verification on the group messages may be allowed to acce | orized to do signature verification on the group messages may be allowed to acce | |||
ss this resource, if the application needs it.</t> | ss this resource if the application needs it.</t> | |||
<section anchor="retrieval-gnames"> | <section anchor="retrieval-gnames"> | |||
<name>Retrieve Group Names</name> | <name>Retrieve Group Names</name> | |||
<t>In case the joining node only knows the group identifier of the g roup 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 an d 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 a t the KDC formatted as defined in <xref target="ace-group-fetch"/>.</t> | <t>In case the joining node only knows the group identifier of the g roup 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 an d group-membership resource URI. In particular, it does so by sending a CoAP FET CH request to the /ace-group endpoint at the KDC formatted as defined in <xref t arget="ace-group-fetch"/>. The node can specify several group identifiers at onc e.</t> | |||
<t><xref target="fig-ace-group-fetch"/> gives an overview of the exc hanges described above, and <xref target="fig-ace-group-fetch-2"/> shows an exam ple.</t> | <t><xref target="fig-ace-group-fetch"/> gives an overview of the exc hanges described above, and <xref target="fig-ace-group-fetch-2"/> shows an exam ple.</t> | |||
<figure anchor="fig-ace-group-fetch"> | <figure anchor="fig-ace-group-fetch"> | |||
<name>Message Flow of Group Name and URI Retrieval Request-Respons e</name> | <name>Message Flow of Group Name and URI Retrieval Request-Respons e</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client KDC | Client KDC | |||
| | | | | | |||
|------------ Group Name and URI Retrieval Request: -------->| | |------------ Group Name and URI Retrieval Request: -------->| | |||
| FETCH /ace-group | | | FETCH /ace-group | | |||
| | | | | | |||
|<-- Group Name and URI Retrieval Response: 2.05 (Content) --| | |<-- Group Name and URI Retrieval Response: 2.05 (Content) --| | |||
skipping to change at line 672 ¶ | skipping to change at line 689 ¶ | |||
|------------ Group Name and URI Retrieval Request: -------->| | |------------ Group Name and URI Retrieval Request: -------->| | |||
| FETCH /ace-group | | | FETCH /ace-group | | |||
| | | | | | |||
|<-- Group Name and URI Retrieval Response: 2.05 (Content) --| | |<-- Group Name and URI Retrieval Response: 2.05 (Content) --| | |||
| | | | | | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<figure anchor="fig-ace-group-fetch-2"> | <figure anchor="fig-ace-group-fetch-2"> | |||
<name>Example of Group Name and URI Retrieval Request-Response</na me> | <name>Example of Group Name and URI Retrieval Request-Response</na me> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Request: | Request: | |||
Header: FETCH (Code=0.05) | Header: FETCH (Code=0.05) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation): | Payload (in CBOR diagnostic notation): | |||
{ "gid": [1, 2] } | { | |||
/ gid / 0: [1, 2] | ||||
} | ||||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Content (Code=2.05) | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation): | Payload (in CBOR diagnostic notation): | |||
{ "gid": [1, 2], "gname": ["group1", "group2"], | { | |||
"guri": ["/ace-group/g1", "/ace-group/g2"] } | / gid / 0: [1, 2], | |||
/ gname / 1: ["group1", "group2"], | ||||
/ guri / 2: ["/ace-group/g1", "/ace-group/g2"] | ||||
} | ||||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="ace-groupgroupname"> | <section anchor="ace-groupgroupname"> | |||
<name>/ace-group/GROUPNAME</name> | <name>/ace-group/GROUPNAME</name> | |||
<t>This resource implements the POST and GET handlers.</t> | <t>This resource implements the POST and GET handlers.</t> | |||
<section anchor="gid-post"> | <section anchor="gid-post"> | |||
<name>POST Handler</name> | <name>POST Handler</name> | |||
<t>The POST handler processes the Join Request sent by a Client to joi | <t>The POST handler processes the Join Request sent by a Client to joi | |||
n a group, and returns a Join Response as successful result of the joining proce | n a group and returns a Join Response as a successful result of the joining proc | |||
ss (see <xref target="ssec-key-distribution-exchange"/>). At a high level, the P | ess (see <xref target="ssec-key-distribution-exchange"/>). At a high level, the | |||
OST handler adds the Client to the list of current group members, adds the authe | POST handler adds the Client to the list of current group members, adds the auth | |||
ntication credential of the Client to the list of the group members' authenticat | entication credential of the Client to the list of the group members' authentica | |||
ion credentials, and returns the symmetric group keying material for the group i | tion credentials, and returns the symmetric group keying material for the group | |||
dentified by GROUPNAME.</t> | identified by GROUPNAME.</t> | |||
<t>The handler expects a request with payload formatted as a CBOR map, | <t>The handler expects a request with payload formatted as a CBOR map, | |||
which MAY contain the following fields, which, if included, MUST have the forma | which <bcp14>MAY</bcp14> contain the following fields, which, if included, <bcp | |||
t and value as specified below.</t> | 14>MUST</bcp14> have the format and value as specified below.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'scope', with value the specific group that the Client is attemp ting 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>'scope': its value specifies the name of the group that the Clie nt is attempting to join and the roles that the client wishes to have in the gro up. This value is encoded as a CBOR byte string wrapping one scope entry, as def ined in <xref target="ssec-authorization-request"/>.</li> | |||
<li> | <li> | |||
<t>'get_creds', if the Client wishes to receive the authentication credentials of the current group members from the KDC. This parameter may be in cluded in the Join Request if the KDC stores the authentication credentials of t he group members, while it is not useful to include it if the Client obtains tho se authentication credentials through alternative means, e.g., from the AS. Note that including this parameter might result in a following Join Response of larg e size, which can be inconvenient for resource-constrained devices. </t> | <t>'get_creds': it is included if the Client wishes to receive the authentication credentials of the current group members from the KDC. This para meter may be included in the Join Request if the KDC stores the authentication c redentials of the group members, while it is not useful to include it if the Cli ent obtains those authentication credentials through alternative means, e.g., fr om the AS. Note that including this parameter might result in a following Join R esponse of a large size, which can be inconvenient for resource-constrained devi ces. </t> | |||
<t> | <t> | |||
If the Client wishes to retrieve the authentication credentials of all the curre nt group members, the 'get_creds' parameter MUST encode the CBOR simple value "n ull" (0xf6). Otherwise, if the Client wishes to retrieve the authentication cred entials of nodes with specific roles, the 'get_creds' parameter MUST encode a no n-empty CBOR array, containing the three elements 'inclusion_flag', 'role_filter ', and 'id_filter' as defined below. </t> | If the Client wishes to retrieve the authentication credentials of all the curre nt group members, the 'get_creds' parameter <bcp14>MUST</bcp14> encode the CBOR simple value <tt>null</tt> (0xf6). Otherwise, if the Client wishes to retrieve t he authentication credentials of nodes with specific roles, the 'get_creds' para meter <bcp14>MUST</bcp14> encode a non-empty CBOR array containing the three ele ments 'inclusion_flag', 'role_filter', and 'id_filter', as defined below. </t> | |||
<ul spacing="normal"> | <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 c redentials of the nodes having their node identifier specified in 'id_filter' (i .e., selection by inclusive filtering). Instead, this element encodes the CBOR s imple value "false" (0xf4) if the Client wishes to receive the authentication cr edentials of the nodes not having the node identifiers specified in the third el ement 'id_filter' (i.e., selection by exclusive filtering). In the Join Request, this parameter encodes the CBOR simple value "true" (0xf5).</li> | <li>The first element, namely 'inclusion_flag', encodes the CBOR simple value <tt>true</tt> (0xf5) if the Client wishes to receive the authentic ation credentials of the nodes having their node identifier specified in 'id_fil ter' (i.e., selection by inclusive filtering). Instead, this element encodes the CBOR simple value <tt>false</tt> (0xf4) if the Client wishes to receive the aut hentication credentials of the nodes that do not have the node identifiers speci fied in the third element 'id_filter' (i.e., selection by exclusive filtering). In the Join Request, this parameter encodes the CBOR simple value <tt>true</tt> (0xf5).</li> | |||
<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 gr oup identified by GROUPNAME. This parameter indicates that the Client wishes to receive the authentication credentials of all the group members having any of th e specified roles or combination of roles (i.e., having any of those single role s, or at least all the roles indicated in any of those combinations of roles). </t> | <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 gr oup identified by GROUPNAME. This parameter indicates that the Client wishes to receive the authentication credentials of all the group members having any of th e specified roles or combination of roles (i.e., having any of those single role s or at least all the roles indicated in any of those combinations of roles). </t> | |||
<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 lea st "role1" or at least both "role2" and "role3". In the Join Request this parame ter is a non-empty array.</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 lea st "role1" or at least both "role2" and "role3". In the Join Request, this param eter is a non-empty array.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The third element, namely 'id_filter', is a CBOR array. Eac h element of the array contains a node identifier of a group member for the grou p identified by GROUPNAME. This parameter indicates that the Client wishes to re ceive the authentication credentials of the nodes that have or do not have the s pecified node identifiers, based on the value of 'inclusion_flag' (i.e., as a se lection by inclusive or exclusive filtering). In the Join Request, the Client do es not filter authentication credentials based on node identifiers, so this para meter is an empty array. </t> | <t>The third element, namely 'id_filter', is a CBOR array. Eac h element of the array contains a node identifier of a group member for the grou p identified by GROUPNAME. This parameter indicates that the Client wishes to re ceive the authentication credentials of the nodes that have or do not have the s pecified node identifiers based on the value of 'inclusion_flag' (i.e., as a sel ection by inclusive or exclusive filtering). In the Join Request, the Client doe s not filter authentication credentials based on node identifiers, so this param eter is an empty array. </t> | |||
<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 to re-join, the Client is not expected to include the 'get_creds' parameter in the Join Request altogether, s ince it can rather retrieve authentication credentials associated with specific group identifiers as defined in <xref target="sec-key-retrieval"/>.</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 to rejoin, the Client is not expected to include the 'get_creds' parameter in the Join Request altogether, si nce it can rather retrieve authentication credentials associated with specific g roup identifiers as defined in <xref target="sec-key-retrieval"/>.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t> | <t> | |||
The CDDL definition <xref target="RFC8610"/> of 'get_creds' is given in <xref ta rget="cddl-ex-getpubkeys"/>, using as example encoding: node identifier encoded as a CBOR byte string; role identifier encoded as a CBOR text string, and combin ation of roles encoded as a CBOR array of roles. </t> | The CDDL definition <xref target="RFC8610"/> of 'get_creds' is given in <xref ta rget="cddl-ex-getpubkeys"/>; as an example, it uses node identifiers encoded as CBOR byte strings, role identifiers encoded as CBOR text strings, and combinatio ns of roles encoded as CBOR arrays of role identifiers. </t> | |||
<t> | <t> | |||
Note that, for this handler, 'inclusion_flag' is always set to true, the array o | Note that, for this handler, 'inclusion_flag' is always set to true and the arra | |||
f roles 'role_filter' is always non-empty, while the array of node identifiers ' | y of roles 'role_filter' is always non-empty, while the array of node identifier | |||
id_filter' is always empty. However, this is not necessarily the case for other | s 'id_filter' is always empty. However, this is not necessarily the case for oth | |||
handlers using the 'get_creds' parameter.</t> | er handlers using the 'get_creds' parameter.</t> | |||
</li> | ||||
</ul> | ||||
<figure anchor="cddl-ex-getpubkeys"> | <figure anchor="cddl-ex-getpubkeys"> | |||
<name>CDDL definition of 'get_creds', using as example node identifi er encoded as bstr and role as tstr</name> | <name>CDDL Definition of 'get_creds', Using an Example Node Identifi er Encoded as bstr and Role as tstr</name> | |||
<sourcecode type="CDDL"><![CDATA[ | <sourcecode type="CDDL"><![CDATA[ | |||
inclusion_flag = bool | inclusion_flag = bool | |||
role = tstr | role = tstr | |||
comb_role = [ 2*role ] | comb_role = [ 2*role ] | |||
role_filter = [ *(role / comb_role) ] | role_filter = [ *(role / comb_role) ] | |||
id = bstr | id = bstr | |||
id_filter = [ *id ] | id_filter = [ *id ] | |||
get_creds = null / [ inclusion_flag, role_filter, id_filter] | get_creds = null / [ inclusion_flag, role_filter, id_filter ] | |||
]]></sourcecode> | ]]></sourcecode> | |||
</figure> | </figure> | |||
<ul spacing="normal"> | </li> | |||
<li>'client_cred', encoded as a CBOR byte string, whose value is the | <li>'client_cred': encoded as a CBOR byte string, whose value is the | |||
original binary representation of the Client's authentication credential. This | original binary representation of the Client's authentication credential. This | |||
parameter MUST be present if the KDC is managing (collecting from/distributing t | parameter <bcp14>MUST</bcp14> be present if the KDC is managing (collecting from | |||
o the Client) the authentication credentials of the group members and the Client | and distributing to Clients) the authentication credentials of the group member | |||
's role in the group will require the Client to send messages to one or more gro | s and the Client's role in the group will require the Client to send messages to | |||
up members. It is REQUIRED of application profiles to define the specific format | one or more group members. It is <bcp14>REQUIRED</bcp14> for application profil | |||
s that are acceptable to use for authentication credentials in the group (REQ6). | es to define the specific formats that are acceptable to use for authentication | |||
</li> | credentials in the group (<xref target="req6" format="none">REQ6</xref>).</li> | |||
<li>'cnonce', encoded as a CBOR byte string, and including a dedicat | <li>'cnonce': encoded as a CBOR byte string, whose value is a dedica | |||
ed nonce N_C generated by the Client. This parameter MUST be present.</li> | ted nonce N_C generated by the Client. This parameter <bcp14>MUST</bcp14> be pre | |||
sent.</li> | ||||
<li> | <li> | |||
<t>'client_cred_verify', encoded as a CBOR byte string. This param eter MUST be present if the 'client_cred' parameter is present and no authentica tion credential associated with the Client's token can be retrieved for that gro up. </t> | <t>'client_cred_verify': encoded as a CBOR byte string. This param eter <bcp14>MUST</bcp14> be present if the 'client_cred' parameter is present an d no authentication credential associated with the Client's access token can be retrieved for that group. </t> | |||
<t> | <t> | |||
This parameter contains a proof-of-possession (PoP) evidence computed by the Cli ent over the following PoP input: the scope (encoded as a CBOR byte string), con catenated with N_S (encoded as a CBOR byte string) concatenated with N_C (encode d as a CBOR byte string), where: </t> | The value of the CBOR byte string is the proof-of-possession (PoP) evidence comp uted by the Client over the following PoP input: the scope (encoded as a CBOR by te string) concatenated with N_S (encoded as a CBOR byte string) concatenated wi th N_C (encoded as a CBOR byte string), where: </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>scope is the CBOR byte string either specified in the 'scope | <li>scope is either specified in the 'scope' parameter above, if | |||
' parameter above, if present, or encoding a default scope entry that the handle | present, or a default scope entry that the handler is expected to know otherwis | |||
r is expected to know, if omitted.</li> | e;</li> | |||
<li>N_S is the challenge received from the KDC in the 'kdcchalle | <li>N_S is the challenge received from the KDC in the 'kdcchalle | |||
nge' parameter of the 2.01 (Created) response to the Token Transfer Request (see | nge' parameter of the 2.01 (Created) response to the Token Transfer Request (see | |||
<xref target="token-post"/>), encoded as a CBOR byte string.</li> | <xref target="token-post"/>), encoded as a CBOR byte string; and</li> | |||
<li>N_C is the nonce generated by the Client and specified in th e 'cnonce' parameter above, encoded as a CBOR byte string.</li> | <li>N_C is the nonce generated by the Client and specified in th e 'cnonce' parameter above, encoded as a CBOR byte string.</li> | |||
</ul> | </ul> | |||
<t> | <t> | |||
An example of PoP input to compute 'client_cred_verify' using CBOR encoding is g iven in <xref target="fig-client-cred-input"/>. </t> | An example of PoP input to compute 'client_cred_verify' using CBOR encoding is g iven in <xref target="fig-client-cred-input"/>. </t> | |||
<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 authent ication credential carried in the 'client_cred' parameter. Application profiles of this specification MUST specify the exact approaches used to compute the PoP evidence to include in 'client_cred_verify', and MUST specify which of those app roaches is used in which case (REQ14). </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 authent ication credential carried in the 'client_cred' parameter. Application profiles of this specification <bcp14>MUST</bcp14> specify the exact approaches used to c ompute the PoP evidence to include in 'client_cred_verify' and <bcp14>MUST</bcp1 4> specify which of those approaches is used in which case (<xref target="req14" format="none">REQ14</xref>). </t> | |||
<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 is REQUIRED of the specific ap plication profile to define how the challenge N_S is generated (REQ15).</t> | If the access token was not provided to the KDC through a Token Transfer Request (e.g., the access token is instead transferred during the establishment of a se cure communication association), it is <bcp14>REQUIRED</bcp14> of the specific a pplication profile to define how the challenge N_S is generated (<xref target="r eq15" format="none">REQ15</xref>).</t> | |||
</li> | </li> | |||
<li>'creds_repo', which can be present if the format of the Client's authentication credential in the 'client_cred' parameter is a certificate. In s uch a case, this parameter has as value the URI of the certificate. This paramet er is encoded as a CBOR text string. Alternative specific encodings of this para meter MAY be defined in application profiles of this specification (OPT6).</li> | <li>'creds_repo': it can be present if the format of the Client's au thentication credential conveyed in the 'client_cred' parameter is a certificate . In such a case, this parameter has as its value the URI of the certificate. Th is parameter is encoded as a CBOR text string. Alternative specific encodings of this parameter <bcp14>MAY</bcp14> be defined in application profiles of this sp ecification (<xref target="opt6" format="none">OPT6</xref>).</li> | |||
<li> | <li> | |||
<t>'control_uri', whose value is a full URI, encoded as a CBOR tex t string. A default url-path is /ace-group/GROUPNAME/node, although implementati ons can use different ones instead. The URI MUST NOT have url-path /ace-group/GR OUPNAME. </t> | <t>'control_uri': its value is a full URI, encoded as a CBOR text string. A default url-path is /ace-group/GROUPNAME/node, although implementation s can use different ones instead. The URI <bcp14>MUST NOT</bcp14> have url-path /ace-group/GROUPNAME. </t> | |||
<t> | <t> | |||
If 'control_uri' is specified in the Join Request, the Client acts as a CoAP ser ver and hosts a resource at this specific URI. The KDC MAY use this URI to send CoAP requests to the Client (acting as CoAP server in this exchange), for exampl e for one-to-one provisioning of new group keying material when performing a gro up rekeying (see <xref target="update-keys"/>), or to inform the Client of its r emoval from the group (see <xref target="sec-node-removal"/>). </t> | If 'control_uri' is specified in the Join Request, the Client acts as a CoAP ser ver and hosts a resource at this specific URI. The KDC <bcp14>MAY</bcp14> use th is URI to send CoAP requests to the Client (acting as a CoAP server in this exch ange), for example, for one-to-one provisioning of new group keying material whe n performing a group rekeying (see <xref target="point-to-point-rekeying"/>) or to inform the Client of its removal from the group (see <xref target="sec-node-r emoval"/>). </t> | |||
<t> | <t> | |||
In particular, this resource is intended for communications concerning exclusive ly the group identified by GROUPNAME and whose group name is specified in the 's cope' parameter, if present. If the KDC does not implement mechanisms using this resource for that group, it can ignore this parameter. Other additional functio nalities of this resource MAY be defined in application profiles of this specifi cations (OPT7).</t> | In particular, this resource is intended for communications exclusively concerni ng the group identified by GROUPNAME and whose group name is specified in the 's cope' parameter of the Join Request, if present therein. If the KDC does not imp lement mechanisms using this resource for that group, it can ignore this paramet er. Other additional functionalities of this resource <bcp14>MAY</bcp14> be defi ned in application profiles of this specifications (<xref target="opt7" format=" none">OPT7</xref>).</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<figure anchor="fig-client-cred-input"> | <figure anchor="fig-client-cred-input"> | |||
<name>Example of PoP input to compute 'client_cred_verify' using CBO R encoding</name> | <name>Example of PoP Input to Compute 'client_cred_verify' Using CBO R Encoding</name> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
scope, N_S, and N_C expressed in CBOR diagnostic notation: | scope, N_S, and N_C expressed in CBOR diagnostic notation: | |||
scope = h'826667726f7570316673656e646572' | scope = h'826667726f7570316673656e646572' | |||
N_S = h'018a278f7faab55a' | N_S = h'018a278f7faab55a' | |||
N_C = h'25a8991cd700ac01' | N_C = h'25a8991cd700ac01' | |||
scope, N_S, and N_C as CBOR encoded byte strings: | scope, N_S, and N_C as CBOR encoded byte strings: | |||
scope = 0x4f826667726f7570316673656e646572 | scope = 0x4f826667726f7570316673656e646572 | |||
N_S = 0x48018a278f7faab55a | N_S = 0x48018a278f7faab55a | |||
N_C = 0x4825a8991cd700ac01 | N_C = 0x4825a8991cd700ac01 | |||
PoP input: | PoP input: | |||
0x4f 826667726f7570316673656e646572 | 0x4f 826667726f7570316673656e646572 | |||
48 018a278f7faab55a 48 25a8991cd700ac01 | 48 018a278f7faab55a 48 25a8991cd700ac01 | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>If the request does not include a 'scope' field, the KDC is expecte | <t>If the request does not include the 'scope' parameter, the KDC is | |||
d to understand what roles the Client is requesting to join the group with. For | expected to understand what roles the Client is requesting to join the group wit | |||
example, as per the access token, the Client might have been granted access to t | h. For example, as per the access token, the Client might have been granted acce | |||
he group with only one role. If the KDC cannot determine which exact roles shoul | ss to the group with only one role. If the KDC cannot determine which exact role | |||
d be considered for the Client, it MUST reply with a 4.00 (Bad Request) error re | s should be considered for the Client, it <bcp14>MUST</bcp14> reply with a 4.00 | |||
sponse.</t> | (Bad Request) error response.</t> | |||
<t>The handler considers the scope specified in the access token assoc | <t>The handler considers the scope specified in the access token assoc | |||
iated with the Client, and checks the scope entry related to the group identifie | iated with the Client and checks the scope entry related to the group identified | |||
d by the GROUPNAME associated with the endpoint. In particular, the handler chec | by the GROUPNAME associated with the endpoint. In particular, the handler check | |||
ks whether the set of roles specified in that scope entry includes all the roles | s 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 | that the Client wishes to have in the group as per the Join Request. If this is | |||
not the case, the KDC MUST reply with a 4.03 (Forbidden) error response.</t> | not the case, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error re | |||
<t>If the KDC manages the group members' authentication credentials, t | sponse.</t> | |||
he handler checks if one is included in the 'client_cred' field. If so, the KDC | <t>If the KDC manages the group members' authentication credentials, t | |||
retrieves the authentication credential and performs the following actions.</t> | he handler checks if one is included in the 'client_cred' parameter. If so, the | |||
KDC retrieves the authentication credential and performs the following actions.< | ||||
/t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>If the access token was provided through a Token Transfer Reques t (see <xref target="token-post"/>) but the KDC cannot retrieve the 'kdcchalleng e' associated with this Client (see <xref target="token-post"/>), the KDC MUST r eply with a 4.00 (Bad Request) error response, which MUST also have Content-Form at application/ace-groupcomm+cbor. The payload of the error response is a CBOR m ap including a newly generated 'kdcchallenge' value, which is specified in the ' kdcchallenge' parameter. The KDC MUST store the newly generated value as the 'kd cchallenge' value associated with this Client, replacing the currently stored va lue (if any).</li> | <li>If the access token was provided through a Token Transfer Reques t (see <xref target="token-post"/>) but the KDC cannot retrieve the 'kdcchalleng e' associated with this Client (see <xref target="token-post"/>), the KDC <bcp14 >MUST</bcp14> reply with a 4.00 (Bad Request) error response, which <bcp14>MUST< /bcp14> also have Content-Format "application/ace-groupcomm+cbor". The payload o f the error response is a CBOR map including a newly generated 'kdcchallenge' va lue, which is specified in the 'kdcchallenge' parameter. The KDC <bcp14>MUST</bc p14> store the newly generated value as the 'kdcchallenge' value associated with this Client, replacing the currently stored value (if any).</li> | |||
<li> | <li> | |||
<t>The KDC checks the authentication credential to be valid for th e group identified by GROUPNAME. That is, it checks that the authentication cred ential has the format used in the group, is intended for the public key algorith m used in the group, and is aligned with the possible associated parameters used in the group. </t> | <t>The KDC checks the authentication credential to be valid for th e group identified by GROUPNAME. That is, it checks that the authentication cred ential has the format used in the group, is intended for the public key algorith m used in the group, and is aligned with the possible associated parameters used in the group. </t> | |||
<t> | <t> | |||
If this verification fails, the handler MUST reply with a 4.00 (Bad Request) err or response. The response MUST have Content-Format set to application/concise-pr oblem-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' field MUST be set to 2 ("Authentication credential incompatible wit h the group configuration").</t> | If this verification fails, the handler <bcp14>MUST</bcp14> reply with a 4.00 (B ad Request) error response. The response <bcp14>MUST</bcp14> have Content-Format "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' field <bcp14>MUST</bcp14> be set to 2 ("Au thentication credential incompatible with the group configuration").</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The KDC verifies the PoP evidence contained in the 'client_cred _verify' field. Application profiles of this specification MUST specify the exac t approaches used to verify the PoP evidence, and MUST specify which of those ap proaches is used in which case (REQ14). </t> | <t>The KDC verifies the PoP evidence conveyed in the 'client_cred_ verify' parameter. Application profiles of this specification <bcp14>MUST</bcp14 > specify the exact approaches used to verify the PoP evidence and <bcp14>MUST</ bcp14> specify which of those approaches is used in which case (<xref target="re q14" format="none">REQ14</xref>). </t> | |||
<t> | <t> | |||
If the PoP evidence does not pass verification, the handler MUST reply with a 4. 00 (Bad Request) error response. The response MUST have Content-Format set to ap plication/concise-problem-details+cbor and is formatted as defined in <xref targ et="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-erro r', the value of the 'error-id' field MUST be set to 3 ("Invalid Proof-of-Posse ssion evidence").</t> | If the PoP evidence does not pass verification, the handler <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. The response <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+cbor" and is formatte d as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field <bcp14>MUST</bc p14> be set to 3 ("Invalid proof-of-possession evidence").</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>If no authentication credential is included in the 'client_cred' fi | <t>If no authentication credential is conveyed in the 'client_cred' pa | |||
eld, the handler checks if an authentication credential is already associated wi | rameter, the handler checks if the KDC currently stores an authentication creden | |||
th the received access token and to the group identified by GROUPNAME (see also | tial that is associated with the access token and with the group identified by G | |||
<xref target="ssec-key-distribution-exchange"/>). Note that the same joining nod | ROUPNAME (see also <xref target="ssec-key-distribution-exchange"/>). Note that t | |||
e may use different authentication credentials in different groups, and all thos | he same joining node may use different authentication credentials in different g | |||
e authentication credentials would be associated with the same access token.</t> | roups, and all those authentication credentials would be associated with the sam | |||
<t>If an eligible authentication credential for the Client is neither | e access token.</t> | |||
present in the 'client_cred' field nor retrieved from the stored ones at the KDC | <t>If an eligible authentication credential for the Client is neither | |||
, it is RECOMMENDED that the handler stops the processing and replies with a 4.0 | present in the 'client_cred' parameter nor retrieved from the stored ones at the | |||
0 (Bad Request) error response. Application profiles MAY define alternatives (OP | KDC, it is <bcp14>RECOMMENDED</bcp14> that the handler stops the processing and | |||
T8).</t> | replies with a 4.00 (Bad Request) error response. Application profiles <bcp14>M | |||
<t>If, regardless of the reason, the KDC replies with a 4.00 (Bad Requ | AY</bcp14> define alternatives (<xref target="opt8" format="none">OPT8</xref>).< | |||
est) error response, the payload of the response MAY be a CBOR map. For instance | /t> | |||
, the CBOR map can include a 'sign_info' parameter formatted as 'sign_info_res' | <t>If, regardless of the reason, the KDC replies with a 4.00 (Bad Requ | |||
defined in <xref target="sign-info"/>, with the 'cred_fmt' element set to the CB | est) error response, the payload of the response <bcp14>MAY</bcp14> be a CBOR ma | |||
OR simple value "null" (0xf6) if the Client sent its own authentication credenti | p. For instance, the CBOR map can include a 'sign_info' parameter formatted as ' | |||
al and the KDC is not set to store authentication credentials of the group membe | sign_info_resp' defined in <xref target="sign-info"/>, with the 'cred_fmt' eleme | |||
rs. When the response payload is a CBOR map including such parameters, the error | nt set to the CBOR simple value <tt>null</tt> (0xf6) if the Client sent its own | |||
response has Content-Format set to application/ace-groupcomm+cbor.</t> | authentication credential and the KDC is not set to store authentication credent | |||
ials of the group members. When the response payload is a CBOR map including suc | ||||
h parameters, the error response has Content-Format "application/ace-groupcomm+c | ||||
bor".</t> | ||||
<t>If all the verifications above succeed, the KDC proceeds as follows .</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 h andler performs the following actions:</t> | <t>First, only in case the Client is not already a group member, the h andler performs the following actions:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The handler adds the Client to the list of current members of th e group.</li> | <li>The handler adds the Client to the list of current members of th e group.</li> | |||
<li>The handler assigns a name NODENAME to the Client, and creates a sub-resource to /ace-group/GROUPNAME at the KDC, i.e., "/ace-group/GROUPNAME/no des/NODENAME".</li> | <li>The handler assigns a name NODENAME to the Client and creates a sub-resource to /ace-group/GROUPNAME at the KDC, i.e., /ace-group/GROUPNAME/node s/NODENAME.</li> | |||
<li>The handler associates the node identifier NODENAME with the acc ess token and the secure communication association for the Client.</li> | <li>The handler associates the node identifier NODENAME with the acc ess token and the secure communication association for the Client.</li> | |||
</ul> | </ul> | |||
<t>Then, the handler performs the following actions.</t> | <t>Then, the handler performs the following actions.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>If the KDC manages the group members' authentication credential s: </t> | <t>If the KDC manages the group members' authentication credential s: </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The handler associates the retrieved Client's authentication | <li>The handler associates the retrieved Client's authentication | |||
credential to the tuple composed of the node name NODENAME, the group name GROU | credential with the tuple composed of the node name NODENAME, the group name GR | |||
PNAME, and the received access token.</li> | OUPNAME, and the access token.</li> | |||
<li>The handler adds the retrieved Client's authentication crede | <li>The handler adds the retrieved Client's authentication crede | |||
ntial to the stored list of authentication credentials stored for the group iden | ntial to the list of authentication credentials stored for the group identified | |||
tified by GROUPNAME. If such list already includes an authentication credential | by GROUPNAME. If such a list already includes an authentication credential for t | |||
for the Client, but a different authentication credential is specified in the 'c | he Client, but a different authentication credential is specified in the 'client | |||
lient_cred' field, then the handler MUST replace the old authentication credenti | _cred' parameter, then the handler <bcp14>MUST</bcp14> replace the old authentic | |||
al in the list with the one specified in the 'client_cred' field.</li> | ation credential in the list with the one specified in the 'client_cred' paramet | |||
er.</li> | ||||
</ul> | </ul> | |||
</li> | </li> | |||
<li>If backward security is prescribed by application policies insta | <li>If backward security is prescribed by application policies insta | |||
lled at the KDC or by the used application profile of this specification, then t | lled at the KDC or by the used application profile of this specification, then t | |||
he KDC MUST generate new group keying material and securely distribute it to the | he KDC <bcp14>MUST</bcp14> generate new group keying material and securely distr | |||
current group members (see <xref target="sec-group-rekeying"/>).</li> | ibute it to the current group members (see <xref target="sec-group-rekeying"/>). | |||
<li>The handler returns a successful Join Response as defined below, | </li> | |||
containing the symmetric group keying material; the group policies; and the aut | <li>The handler returns a successful Join Response, as defined below | |||
hentication credentials of the current members of the group, if the KDC manages | , which contains the symmetric group keying material, the group policies, and th | |||
those and the Client requested them.</li> | e authentication credentials of the current members of the group if the KDC mana | |||
ges those and the Client requested those.</li> | ||||
</ul> | </ul> | |||
<t>The Join Response MUST have response code 2.01 (Created) if the Cli | <t>The Join Response <bcp14>MUST</bcp14> have response code 2.01 (Crea | |||
ent has been added to the list of group members in this join exchange (see above | ted) if the Client has been added to the list of group members in this join exch | |||
), or 2.04 (Changed) otherwise, i.e., if the Client is re-joining the group with | ange (see above) or 2.04 (Changed) otherwise, i.e., if the Client is rejoining t | |||
out having left it.</t> | he group without having left it.</t> | |||
<t>The Join Response message MUST include the Location-Path CoAP optio | <t>The Join Response message <bcp14>MUST</bcp14> include the Location- | |||
n, specifying the URI path to the sub-resource associated with the Client, i.e., | Path CoAP Options, specifying the path to the sub-resource associated with the C | |||
"/ace-group/GROUPNAME/nodes/NODENAME".</t> | lient, i.e., /ace-group/GROUPNAME/nodes/NODENAME.</t> | |||
<t>The Join Response message MUST have Content-Format application/ace- | <t>The Join Response message <bcp14>MUST</bcp14> have Content-Format " | |||
groupcomm+cbor. The payload of the response is formatted as a CBOR map, which MU | application/ace-groupcomm+cbor". The payload of the response is formatted as a C | |||
ST contain the following fields and values.</t> | BOR map, which <bcp14>MUST</bcp14> contain the following fields with the values | |||
specified below:</t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'gkty', identifying the key type of the keying material specifie | <li>'gkty': identifying the key type of the keying material specifie | |||
d in the 'key' parameter. This parameter is encoded as a CBOR integer or a CBOR | d 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 | text string. Possible values are taken from the "Key Type Value" column of the " | |||
Groupcomm Key Types" registry. Implementations MUST verify that the key type ma | ACE Groupcomm Key Types" registry defined in <xref target="iana-key"/> of this s | |||
tches the application profile being used, if present, as registered in the "ACE | pecification. Implementations <bcp14>MUST</bcp14> verify that the key type speci | |||
Groupcomm Key Types" registry.</li> | fied by this parameter matches the application profile being used and, if applic | |||
<li>'key', containing the keying material for the group communicatio | able, that such an application profile is listed in the "Profile" column of the | |||
n, or information required to derive it.</li> | "ACE Groupcomm Key Types" registry for the key type in question.</li> | |||
<li>'num', containing the version number of the keying material for | <li>'key': containing the keying material used for securing the grou | |||
the group communication, formatted as a CBOR integer. This is a strictly monoton | p communication or information required to derive such keying material.</li> | |||
ic increasing field. The application profile MUST define the initial version num | <li>'num': containing the current version number of the group keying | |||
ber (REQ16).</li> | material, encoded as a CBOR integer. The version number has a value that increa | |||
ses in a strictly monotonic way as the group keying material changes. The applic | ||||
ation profile <bcp14>MUST</bcp14> define the initial value of the version number | ||||
(<xref target="req16" format="none">REQ16</xref>).</li> | ||||
</ul> | </ul> | |||
<t>The exact type of the keying material specified in the 'key' parame | <t>The format of the keying material conveyed in the 'key' parameter < | |||
ter MUST be defined in application profiles of this specification (REQ17), toget | bcp14>MUST</bcp14> be defined in application profiles of this specification (<xr | |||
her with values of 'gkty' accepted by the application (REQ18). Additionally, doc | ef target="req17" format="none">REQ17</xref>), together with corresponding key t | |||
uments specifying a type of keying material MUST register an entry in the "ACE G | ypes to specify as value of the 'gkty' parameter and that are accepted by the ap | |||
roupcomm Key Types" registry defined in <xref target="iana-key"/>, including its | plication (<xref target="req18" format="none">REQ18</xref>). Additionally, docum | |||
name, the corresponding value for the 'gkty parameter', and the application pro | ents specifying a type of keying material <bcp14>MUST</bcp14> register an entry | |||
file to be used with.</t> | in the "ACE Groupcomm Key Types" registry defined in <xref target="iana-key"/>, | |||
<figure anchor="fig-gkty"> | including its name, the corresponding key type to specify as value for the 'gkty | |||
<name>ACE Groupcomm Key Types</name> | ' parameter, and the application profile to be used with.</t> | |||
<artwork align="center"><![CDATA[ | ||||
+----------+----------------+---------+-------------+------------+ | <table anchor="fig-gkty"> | |||
| Name | Key Type Value | Profile | Description | Reference | | <name>ACE Groupcomm Key Types</name> | |||
+----------+----------------+---------+-------------+------------+ | <thead> | |||
| Reserved | 0 | | This value | [RFC-XXXX] | | <tr> | |||
| | | | is reserved | | | <th>Name</th> | |||
+----------+----------------+---------+-------------+------------+ | <th>Key Type Value</th> | |||
]]></artwork> | <th>Profile</th> | |||
</figure> | <th>Description</th> | |||
<t>Note to RFC Editor: In <xref target="fig-gkty"/>, please replace "[ | <th>Reference</th> | |||
RFC-XXXX]" with the RFC number of this specification and delete this paragraph.< | </tr> | |||
/t> | </thead> | |||
<t>The Join Response SHOULD contain the following parameters:</t> | <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 Response <bcp14>SHOULD</bcp14> contain the following field | ||||
s with the values specified below:</t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'exp', with value the expiration time of the keying material for | <li>'exp': its value specifies the expiration time of the group keyi | |||
the group communication, encoded as a CBOR unsigned integer. This field contain | ng material specified in the 'key' parameter, encoded as a CBOR unsigned integer | |||
s a numeric value representing the number of seconds from 1970-01-01T00:00:00Z U | . The value is the number of seconds from 1970-01-01T00:00:00Z UTC until the spe | |||
TC until the specified UTC date/time, ignoring leap seconds, analogous to what i | cified UTC date/time, ignoring leap seconds, analogous to what is specified for | |||
s specified for NumericDate in <xref section="2" sectionFormat="of" target="RFC7 | NumericDate in <xref section="2" sectionFormat="of" target="RFC7519"/>. After th | |||
519"/>. Group members MUST NOT use the keying material after the time indicated | e time indicated in this parameter, group members <bcp14>MUST NOT</bcp14> use th | |||
in this field, and they can retrieve the new group keying material from the KDC. | e group keying material specified in the 'key' parameter. The group members can | |||
</li> | retrieve the latest group keying material from the KDC.</li> | |||
<li>'exi', with value the residual lifetime of the keying material f | <li>'exi': its value specifies the residual lifetime of the group ke | |||
or the group communication, encoded as a CBOR unsigned integer. If the 'exp' par | ying material, encoded as a CBOR unsigned integer. If the 'exp' parameter is inc | |||
ameter is included, this parameter MUST also be included. This field contains a | luded, this parameter <bcp14>MUST</bcp14> also be included. The value represents | |||
numeric value representing the residual lifetime of the keying material in secon | the residual lifetime of the group keying material specified in the 'key' param | |||
ds, i.e., the number of seconds between the current time at the KDC and the time | eter, i.e., it is the number of seconds between the current time at the KDC and | |||
when the keying material expires (as specified in the 'exp' parameter, if prese | the time when the keying material expires (as specified in the 'exp' parameter, | |||
nt). A Client determines the expiration time of the keying material by adding th | if present). A Client determines the expiration time of the keying material by a | |||
e seconds specified in the 'exi' parameter to its current time upon receiving th | dding the seconds specified in the 'exi' parameter to its current time upon rece | |||
e response containing the 'exi' parameter. The Client MUST NOT use the keying ma | iving the Join Response containing the 'exi' parameter. After such an expiration | |||
terial after such an expiration time, and it can retrieve the new group keying m | time, the Client <bcp14>MUST NOT</bcp14> use the group keying material specifie | |||
aterial from the KDC.</li> | d in the 'key' parameter. The Client can retrieve the latest group keying materi | |||
al from the KDC.</li> | ||||
</ul> | </ul> | |||
<t>If a Client has a reliable way to synchronize its internal clock wi th UTC, and both the 'exp' and 'exi' parameters are present, then the Client MUS T use the 'exp' parameter value as expiration time for the group keying material . Otherwise, the Client uses the 'exi' parameter value.</t> | <t>If a Client has a reliable way to synchronize its internal clock wi th UTC, and both the 'exp' and 'exi' parameters are present, then the Client <bc p14>MUST</bcp14> use the 'exp' parameter value as expiration time for the group keying material. Otherwise, the Client uses the 'exi' parameter value to determi ne the expiration time as defined above.</t> | |||
<t>When a Client relies on the 'exi' parameter, the expiration time th at it computes is offset in the future with respect to the actual expiration tim e 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 i s, especially if the delivery of the response to the Client is delayed, the Clie nt will believe the keying material to be valid for a longer time than the KDC a ctually means. However, before approaching the actual expiration time, the KDC i s expected to rekey the group and distribute new keying material (see <xref targ et="sec-group-rekeying"/>).</t> | <t>When a Client relies on the 'exi' parameter, the expiration time th at it computes is offset in the future with respect to the actual expiration tim e 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 i s, especially if the delivery of the response to the Client is delayed, the Clie nt will believe the keying material to be valid for a longer time than the KDC a ctually means. However, before approaching the actual expiration time, the KDC i s expected to rekey the group and distribute new keying material (see <xref targ et="sec-group-rekeying"/>).</t> | |||
<t>Optionally, the Join Response MAY contain the following parameters, which, if included, MUST have the format and value as specified below.</t> | <t>Optionally, the Join Response <bcp14>MAY</bcp14> contain the follow ing parameters, which, if included, <bcp14>MUST</bcp14> have the format and valu e as specified below.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'ace_groupcomm_profile', with value a CBOR integer that MUST be | <li><t>'ace_groupcomm_profile': its value is encoded as a CBOR integ | |||
used to uniquely identify the application profile for group communication. Appli | er and <bcp14>MUST</bcp14> be used to uniquely identify the application profile | |||
cations of this specification MUST register an application profile identifier an | for group communication. Applications of this specification <bcp14>MUST</bcp14> | |||
d the related value for this parameter in the "ACE Groupcomm Profiles" registry | register an application profile identifier and the related value for this parame | |||
(REQ19).</li> | ter in the "ACE Groupcomm Profiles" registry (<xref target="req19" format="none" | |||
</ul> | >REQ19</xref>).</t> | |||
<figure anchor="ace-groupcomm-profile-0"> | ||||
<table anchor="ace-groupcomm-profile-0"> | ||||
<name>ACE Groupcomm Profiles</name> | <name>ACE Groupcomm Profiles</name> | |||
<artwork align="center"><![CDATA[ | <thead> | |||
+----------+------------------------+------------+------------+ | <tr> | |||
| Name | Description | CBOR Value | Reference | | <th>Name</th> | |||
+----------+------------------------+------------+------------+ | <th>Description</th> | |||
| Reserved | This value is reserved | 0 | [RFC-XXXX] | | <th>CBOR Value</th> | |||
+----------+------------------------+------------+------------+ | <th>Reference</th> | |||
]]></artwork> | </tr> | |||
</figure> | </thead> | |||
<t>Note to RFC Editor: In <xref target="ace-groupcomm-profile-0"/>, pl | <tbody> | |||
ease replace "[RFC-XXXX]" with the RFC number of this specification and delete t | <tr> | |||
his paragraph.</t> | <td>Reserved</td> | |||
<ul spacing="normal"> | <td>This value is reserved</td> | |||
<li>'creds', which MUST be present if 'get_creds' was present in the | <td>0</td> | |||
request, otherwise it MUST NOT be present. This parameter is a CBOR array speci | <td>RFC 9594</td> | |||
fying the authentication credentials of the group members, i.e., of all of them | </tr> | |||
or of the ones selected according to the 'get_creds' parameter in the request. I | </tbody> | |||
n particular, each element of the array is a CBOR byte string, whose value is th | </table> | |||
e original binary representation of a group member's authentication credential. | ||||
It is REQUIRED of application profiles to define the specific formats of authent | </li> | |||
ication credentials that are acceptable to use in the group (REQ6).</li> | <li>'creds': it <bcp14>MUST</bcp14> be present if 'get_creds' was pr | |||
esent in the Join Request; otherwise, it <bcp14>MUST NOT</bcp14> be present. Its | ||||
value is encoded as a CBOR array specifying the authentication credentials of t | ||||
he group members, i.e., of all of them or of the ones selected according to the | ||||
'get_creds' parameter in the Join Request. In particular, each element of the ar | ||||
ray is a CBOR byte string, whose value is the original binary representation of | ||||
a group member's authentication credential. It is <bcp14>REQUIRED</bcp14> for ap | ||||
plication profiles to define the specific formats of authentication credentials | ||||
that are acceptable to use in the group (<xref target="req6" format="none">REQ6< | ||||
/xref>).</li> | ||||
<li> | <li> | |||
<t>'peer_roles', which SHOULD be present if 'creds' is also presen t, otherwise it MUST NOT be present. This parameter is a CBOR array of n element s, where n is the number of authentication credentials included in the 'creds' p arameter (at most the number of members in the group). The i-th element of the a rray specifies the role(s) that the group member associated with the i-th authen tication credential in 'creds' has in the group. In particular, each array eleme nt is encoded like the role element of a scope entry, consistent with the used f ormat (see <xref target="ssec-authorization-request"/>). </t> | <t>'peer_roles': it <bcp14>SHOULD</bcp14> be present if 'creds' is also present; otherwise, it <bcp14>MUST NOT</bcp14> be present. Its value is en coded as a CBOR array of n elements, where n is the number of authentication cre dentials included in the 'creds' parameter (at most, the number of members in th e group). The i-th element of the array specifies the role(s) that the group mem ber associated with the i-th authentication credential in 'creds' has in the gro up. In particular, each array element is encoded like the role element of a scop e entry, which is consistent with the used format (see <xref target="ssec-author ization-request"/>). </t> | |||
<t> | <t> | |||
This parameter MAY be omitted if the Client can rely on other means to unambiguo usly gain knowledge of the role of each group member whose associated authentica tion credential is specified in the 'creds' parameter. For example, all such gro up 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 indica te the role(s) that the corresponding group member has in the group joined by th e Client. </t> | This parameter <bcp14>MAY</bcp14> be omitted if the Client can rely on other mea ns to unambiguously gain knowledge of the role of each group member whose associ ated authentication credential is specified in the 'creds' parameter. For exampl e, all such group members may have the same role in the group joined by the Clie nt, and such a role can be unambiguously assumed by the Client (e.g., based on w hat is defined in the used application profile of this specification). As anothe r example, each of the authentication credentials specified in the 'creds' param eter can indicate the role(s) that the corresponding group member has in the gro up joined by the Client. </t> | |||
<t> | <t> | |||
When receiving the authentication credential of a Client in the 'client_cred' pa rameter 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 ind icates the role(s) that the Client can have or has in the group in question. Whe n preparing a Join Response, the KDC can decide whether to include the 'peer_rol es' parameter depending on the specific set of authentication credentials specif ied in the 'creds' parameter of that Join Response.</t> | When receiving the authentication credential of a Client in the 'client_cred' pa rameter 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 ind icates the role(s) that the Client can have or has in the group in question. Whe n preparing a Join Response, the KDC can decide whether to include the 'peer_rol es' parameter, depending on the specific set of authentication credentials speci fied in the 'creds' parameter of that Join Response.</t> | |||
</li> | </li> | |||
<li>'peer_identifiers', which MUST be present if 'creds' is also pre | <li>'peer_identifiers': it <bcp14>MUST</bcp14> be present if 'creds' | |||
sent, otherwise it MUST NOT be present. This parameter is a CBOR array of n elem | is also present; otherwise, it <bcp14>MUST NOT</bcp14> be present. Its value is | |||
ents, where n is the number of authentication credentials included in the 'creds | encoded as a CBOR array of n elements, where n is the number of authentication | |||
' parameter (at most the number of members in the group). The i-th element of th | credentials included in the 'creds' parameter (at most, the number of members in | |||
e array specifies the node identifier that the group member associated with the | the group). The i-th element of the array specifies the node identifier that th | |||
i-th authentication credential in 'creds' has in the group. In particular, the i | e group member associated with the i-th authentication credential in 'creds' has | |||
-th array element is encoded as a CBOR byte string, whose value is the node iden | in the group. In particular, the i-th array element is encoded as a CBOR byte s | |||
tifier of the group member. The specific format of node identifiers of group mem | tring, whose value is the node identifier of the group member. The specific form | |||
bers is specified by the application profile (REQ25).</li> | at of node identifiers of group members is specified by the application profile | |||
<li>'group_policies', with value a CBOR map, whose entries specify h | (<xref target="req25" format="none">REQ25</xref>).</li> | |||
ow the group handles specific management aspects. These include, for instance, a | <li><t>'group_policies': its value is encoded as a CBOR map, whose e | |||
pproaches to achieve synchronization of sequence numbers among group members. Th | lements specify how the group handles specific management aspects. These include | |||
e elements of this field are registered in the "ACE Groupcomm Policies" registry | , for instance, approaches to achieve synchronization of sequence numbers among | |||
. This specification defines the three elements "Sequence Number Synchronization | group members. The possible elements of the CBOR map are registered in the "ACE | |||
Methods", "Key Update Check Interval", and "Expiration Delta", which are summar | Groupcomm Policies" registry defined in <xref target="ace-groupcomm-policies"/> | |||
ized in <xref target="fig-ACE-Groupcomm-Policies"/>. Application profiles that b | of this specification. This specification defines the three elements "Sequence N | |||
uild on this document MUST specify the exact content format and default value of | umber Synchronization Methods", "Key Update Check Interval", and "Expiration Del | |||
included map entries (REQ20).</li> | ta", which are summarized in <xref target="fig-ACE-Groupcomm-Policies"/>. Applic | |||
</ul> | ation profiles of this specification <bcp14>MUST</bcp14> specify the format, con | |||
<figure anchor="fig-ACE-Groupcomm-Policies"> | tent, and default values for the entries of the CBOR map conveyed in the 'group_ | |||
<name>ACE Groupcomm Policies</name> | policies' parameter (<xref target="req20" format="none">REQ20</xref>).</t> | |||
<artwork align="center"><![CDATA[ | <table anchor="fig-ACE-Groupcomm-Policies"> | |||
+--------------+-------+----------+----------------------+------------+ | <name>ACE Groupcomm Policies</name> | |||
| Name | CBOR | CBOR | Description | Reference | | <thead> | |||
| | label | type | | | | <tr> | |||
+--------------+-------+----------+----------------------+------------+ | <th>Name</th> | |||
| Sequence | 0 | tstr/int | Method for recipient | [RFC-XXXX] | | <th>CBOR Label</th> | |||
| Number | | | group members to | | | <th>CBOR Type</th> | |||
| Synchroniza- | | | synchronize with | | | <th>Description</th> | |||
| tion Method | | | sequence numbers of | | | <th>Reference</th> | |||
| | | | sender group | | | </tr> | |||
| | | | members. Its value | | | </thead> | |||
| | | | is taken from the | | | <tbody> | |||
| | | | 'Value' column of | | | <tr> | |||
| | | | the Sequence Number | | | <td>Sequence Number Synchronization Method</td> | |||
| | | | Synchronization | | | <td>0</td> | |||
| | | | Method registry | | | <td>int or tstr</td> | |||
+--------------+-------+----------+----------------------+------------+ | <td> Method for recipient group members to synchronize with sequence numb | |||
| Key Update | 1 | int | Polling interval in | [RFC-XXXX] | | ers of sender group members. Its value is taken from the "Value" column of the " | |||
| Check | | | seconds, for group | | | Sequence Number Synchronization Method" registry.</td> | |||
| Interval | | | members to check at | | | <td>RFC 9594</td> | |||
| | | | the KDC if the | | | </tr> | |||
| | | | latest group keying | | | <tr> | |||
| | | | material is the one | | | <td>Key Update Check Interval</td> | |||
| | | | that they store | | | <td>1</td> | |||
+--------------+-------+----------+----------------------+------------+ | <td>int</td> | |||
| Expiration | 2 | uint | Number of seconds | [RFC-XXXX] | | <td>Polling interval in seconds, for group members to check at the KDC if | |||
| Delta | | | from 'exp' until a | | | the latest group keying material is the one that they store.</td> | |||
| | | | UTC date/time, after | | | <td>RFC 9594</td> | |||
| | | | which group members | | | </tr> | |||
| | | | MUST stop using the | | | <tr> | |||
| | | | group keying | | | <td>Expiration Delta</td> | |||
| | | | material that they | | | <td>2</td> | |||
| | | | store to decrypt | | | <td>uint</td> | |||
| | | | incoming messages | | | <td>Number of seconds from 'exp' until a UTC date/time, after which group | |||
+--------------+-------+----------|----------------------|------------+ | members MUST stop using the group keying material that they store to decrypt in | |||
]]></artwork> | coming messages.</td> | |||
</figure> | <td>RFC 9594</td> | |||
<t>Note to RFC Editor: In <xref target="fig-ACE-Groupcomm-Policies"/>, | </tr> | |||
please replace all occurrences of "[RFC-XXXX]" with the RFC number of this spec | </tbody> | |||
ification and delete this paragraph.</t> | </table> | |||
<ul spacing="normal"> | </li> | |||
<li> | <li> | |||
<t>'kdc_cred', encoded as a CBOR byte string, whose value is the o riginal binary representation of the KDC's authentication credential. This param eter is used if the KDC has an associated authentication credential and this is required for the correct group operation. It is REQUIRED of application profiles to define whether the KDC has an authentication credential and if this has to b e provided through the 'kdc_cred' parameter (REQ8). </t> | <t>'kdc_cred': its value is the original binary representation of the KDC's authentication credential, encoded as a CBOR byte string. This paramet er is used if the KDC has an associated authentication credential and this is re quired for the correct group operation. It is <bcp14>REQUIRED</bcp14> for applic ation profiles to define whether the KDC has an authentication credential as req uired for the correct group operation and if this has to be provided through the 'kdc_cred' parameter (<xref target="req8" format="none">REQ8</xref>). </t> | |||
<t> | <t> | |||
In such a case, the KDC's authentication credential MUST have the same format us ed for the authentication credentials of the group members. It is REQUIRED of ap plication profiles to define the specific formats that are acceptable to use for the authentication credentials in the group (REQ6).</t> | If the KDC has an authentication credential as required for the correct group op eration, the KDC's authentication credential <bcp14>MUST</bcp14> have the same f ormat used for the authentication credentials of the group members. It is <bcp14 >REQUIRED</bcp14> for application profiles to define the specific formats that a re acceptable to use for the authentication credentials in the group (<xref targ et="req6" format="none">REQ6</xref>).</t> | |||
</li> | </li> | |||
<li>'kdc_nonce', encoded as a CBOR byte string, and including a dedi cated nonce N_KDC generated by the KDC. This parameter MUST be present if the 'k dc_cred' parameter is present.</li> | <li>'kdc_nonce': its value is a dedicated nonce N_KDC generated by t he KDC, encoded as a CBOR byte string. This parameter <bcp14>MUST</bcp14> be pre sent if the 'kdc_cred' parameter is present.</li> | |||
<li> | <li> | |||
<t>'kdc_cred_verify', encoded as a CBOR byte string. This paramete r MUST be present if the 'kdc_cred' parameter is present. </t> | <t>'kdc_cred_verify': its value is as defined below and is encoded as a CBOR byte string. This parameter <bcp14>MUST</bcp14> be present if the 'kd c_cred' parameter is present. </t> | |||
<t> | <t> | |||
This parameter contains a proof-of-possession (PoP) evidence computed by the KDC over the following PoP input: the nonce N_C (encoded as a CBOR byte string) con catenated with the nonce N_KDC (encoded as a CBOR byte string), where: </t> | The value of this parameter is the proof-of-possession (PoP) evidence computed b y the KDC over the following PoP input: the nonce N_C (encoded as a CBOR byte st ring) concatenated with the nonce N_KDC (encoded as a CBOR byte string), where: </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>N_C is the nonce generated by the Client and specified in th | <li>N_C is the nonce generated by the Client and specified in th | |||
e 'cnonce' parameter of the Join Request, encoded as a CBOR byte string.</li> | e 'cnonce' parameter of the Join Request.</li> | |||
<li>N_KDC is the nonce generated by the KDC and specified in the | <li>N_KDC is the nonce generated by the KDC and specified in the | |||
'kdc_nonce' parameter, encoded as a CBOR byte string.</li> | 'kdc_nonce' parameter.</li> | |||
</ul> | </ul> | |||
<t> | <t> | |||
An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is give n in <xref target="fig-kdc-cred-input"/>. </t> | An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is give n in <xref target="fig-kdc-cred-input"/>. </t> | |||
<t> | <t> | |||
A possible type of PoP evidence is a signature that the KDC computes by using it s own private key, whose corresponding public key is specified in the authentica tion credential carried in the 'kdc_cred' parameter. Application profiles of thi s specification MUST specify the exact approaches used by the KDC to compute the PoP evidence to include in 'kdc_cred_verify', and MUST specify which of those a pproaches is used in which case (REQ21).</t> | A possible type of PoP evidence is a signature that the KDC computes by using it s own private key, whose corresponding public key is specified in the authentica tion credential conveyed in the 'kdc_cred' parameter. Application profiles of th is specification <bcp14>MUST</bcp14> specify the approaches used by the KDC to c ompute the PoP evidence to include in 'kdc_cred_verify' and <bcp14>MUST</bcp14> specify which of those approaches is used in which case (<xref target="req21" fo rmat="none">REQ21</xref>).</t> | |||
</li> | </li> | |||
<li>'rekeying_scheme', identifying the rekeying scheme that the KDC | <li><t>'rekeying_scheme': identifying the rekeying scheme that the K | |||
uses to provide new group keying material to the group members. This parameter i | DC uses to provide new group keying material to the group members. The value of | |||
s encoded as a CBOR integer, whose value is taken from the "Value" column of the | this parameter is encoded as a CBOR integer and is taken from the "Value" column | |||
"ACE Groupcomm Rekeying Schemes" registry defined in <xref target="iana-ace-gro | of the "ACE Groupcomm Rekeying Schemes" registry defined in <xref target="iana- | |||
upcomm-rekeying-schemes"/> of this specification.</li> | ace-groupcomm-rekeying-schemes"/> of this specification.</t> | |||
</ul> | ||||
<figure anchor="rekeying-scheme-0"> | <table anchor="rekeying-scheme-0"> | |||
<name>ACE Groupcomm Rekeying Schemes</name> | <name>ACE Groupcomm Rekeying Schemes</name> | |||
<artwork align="center"><![CDATA[ | <thead> | |||
+-------+----------------+-------------------------------+------------+ | <tr> | |||
| Value | Name | Description | Reference | | <th>Value</th> | |||
+-------+----------------+-------------------------------+------------+ | <th>Name</th> | |||
| 0 | Point-to-Point | The KDC individually targets | [RFC-XXXX] | | <th>Description</th> | |||
| | | each node to rekey, using the | | | <th>Reference</th> | |||
| | | pairwise secure communication | | | </tr> | |||
| | | association with that node | | | </thead> | |||
+-------+----------------+-------------------------------+------------+ | <tbody> | |||
]]></artwork> | <tr> | |||
</figure> | <td>0</td> | |||
<t>Application profiles of this specification MAY define a default gro | <td>Point-to-Point</td> | |||
up rekeying scheme, to refer to in case the 'rekeying_scheme' parameter is not i | <td>The KDC individually targets each node to rekey, using the pair | |||
ncluded in the Join Response (OPT9).</t> | wise secure communication association with that node</td> | |||
<t>Note to RFC Editor: In <xref target="rekeying-scheme-0"/>, please r | <td>RFC 9594</td> | |||
eplace "[RFC-XXXX]" with the RFC number of this specification and delete this pa | </tr> | |||
ragraph.</t> | </tbody> | |||
<ul spacing="normal"> | </table> | |||
<t>Application profiles of this specification <bcp14>MAY</bcp14> defin | ||||
e a default group rekeying scheme to refer to in case the 'rekeying_scheme' para | ||||
meter is not included in the Join Response (<xref target="opt9" format="none">OP | ||||
T9</xref>).</t> | ||||
</li> | ||||
<li> | <li> | |||
<t>'mgt_key_material', encoded as a CBOR byte string and containin g the specific administrative keying material that the joining node requires in order to participate in the group rekeying process performed by the KDC. This pa rameter MUST NOT be present if the 'rekeying_scheme' parameter is not present an d the application profile does not specify a default group rekeying scheme to us e in the group. Some simple rekeying schemes may not require specific administra tive keying material to be provided, e.g., the basic "Point-to-Point" group reke ying scheme (see <xref target="point-to-point-rekeying"/>). </t> | <t>'mgt_key_material': encoded as a CBOR byte string and containin g the specific administrative keying material that the joining node requires in order to participate in the group rekeying process performed by the KDC. This pa rameter <bcp14>MUST NOT</bcp14> be present if the 'rekeying_scheme' parameter is not present and the application profile does not specify a default group rekeyi ng scheme to use in the group. Some simple rekeying schemes may not require spec ific administrative keying material to be provided, e.g., the basic "Point-to-Po int" group rekeying scheme (see <xref target="point-to-point-rekeying"/>). </t> | |||
<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 hierar chy, whose root key is the only administrative key shared by all the group membe rs. In such a case, each group member is exclusively associated with one leaf ke y in the 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 k eying material. </t> | In more advanced group rekeying schemes, the administrative keying material can be composed of multiple keys organized, for instance, into a logical tree hierar chy, whose root key is the only administrative key shared by all the group membe rs. In such a case, each group member is exclusively associated with one leaf ke y in the hierarchy and stores only the administrative keys from the associated l eaf 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 ke ying material. </t> | |||
<t> | <t> | |||
It is expected from separate documents to define how the advanced group rekeying scheme possibly indicated in the 'rekeying_scheme' parameter is used by an appl ication profile of this specification. This includes defining the format of the administrative keying material to specify in 'mgt_key_material', consistently wi th the group rekeying scheme and the application profile in question.</t> | It is expected from separate documents to define how the advanced group rekeying scheme, possibly indicated in the 'rekeying_scheme' parameter, i s used by an application profile of this specification. This includes defining t he format of the administrative keying material to specify in 'mgt_key_material' consistently with the group rekeying scheme and the application profile in ques tion.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>'control_group_uri', with a full URI as value, encoded as a CBO R text string. The URI MUST specify addressing information intended to reach all the members in the group. For example, this can be a multicast IP address, opti onally 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" sectionF ormat="of" target="RFC7252"/>). The URI MUST include GROUPNAME in the url-path. A default url-path is /ace-group/GROUPNAME, although implementations can use dif ferent ones instead. The URI MUST NOT have url-path /ace-group/GROUPNAME/node. </t> | <t>'control_group_uri': its value is a full URI, encoded as a CBOR text string. The URI <bcp14>MUST</bcp14> specify addressing information intende d 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 5 683, i.e., the default port number for the "coap" URI scheme (see <xref section= "6.1" sectionFormat="of" target="RFC7252"/>). The URI <bcp14>MUST</bcp14> includ e GROUPNAME in the url-path. A default url-path is /ace-group/GROUPNAME, althoug h implementations can use different ones instead. The URI <bcp14>MUST NOT</bcp14 > have url-path /ace-group/GROUPNAME/nodes. </t> | |||
<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 li sten to the specified addressing information. </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 li sten to the specified addressing information. </t> | |||
<t> | <t> | |||
The KDC MAY use this URI to send one-to-many CoAP requests to the Client group m embers (acting as CoAP servers in this exchange), for example for one-to-many pr ovisioning of new group keying material when performing a group rekeying (see <x ref target="update-keys"/>), or to inform the Clients of their removal from the group (see <xref target="sec-node-removal"/>). </t> | The KDC <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), for example, fo r one-to-many provisioning of new group keying material when performing a group rekeying (see <xref target="one-to-many-rekeying"/>) or to inform the Clients of their removal from the group (see <xref target="sec-node-removal"/>). </t> | |||
<t> | <t> | |||
In particular, this resource is intended for communications concerning exclusive ly 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. Oth er additional functionalities of this resource MAY be defined in application pro files of this specifications (OPT10).</t> | In particular, this resource is intended for communications exclusively concerni ng 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. Oth er additional functionalities of this resource <bcp14>MAY</bcp14> be defined in application profiles of this specifications (<xref target="opt10" format="none"> OPT10</xref>).</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<figure anchor="fig-kdc-cred-input"> | <figure anchor="fig-kdc-cred-input"> | |||
<name>Example of PoP input to compute 'kdc_cred_verify' using CBOR e ncoding</name> | <name>Example of PoP Input to Compute 'kdc_cred_verify' Using CBOR E ncoding</name> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
N_C and N_KDC expressed in CBOR diagnostic notation: | N_C and N_KDC expressed in CBOR diagnostic notation: | |||
N_C = h'25a8991cd700ac01' | N_C = h'25a8991cd700ac01' | |||
N_KDC = h'cef04b2aa791bc6d' | N_KDC = h'cef04b2aa791bc6d' | |||
N_C and N_KDC as CBOR encoded byte strings: | N_C and N_KDC as CBOR encoded byte strings: | |||
N_C = 0x4825a8991cd700ac01 | N_C = 0x4825a8991cd700ac01 | |||
N_KDC = 0x48cef04b2aa791bc6d | N_KDC = 0x48cef04b2aa791bc6d | |||
PoP input: | PoP input: | |||
0x48 25a8991cd700ac01 48 cef04b2aa791bc6d | 0x48 25a8991cd700ac01 48 cef04b2aa791bc6d | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>After sending the Join Response, if the KDC has an associated authe | <t>After sending the Join Response, if the KDC has an associated authe | |||
ntication credential, the KDC MUST store the N_C value specified in the 'cnonce' | ntication credential as required for the correct group operation, then the KDC < | |||
parameter of the Join Request, as a 'clientchallenge' value associated with the | bcp14>MUST</bcp14> store the N_C value specified in the 'cnonce' parameter of th | |||
Client, replacing the currently stored value (if any). If, as a group member, t | e Join Request as a 'clientchallenge' value associated with the Client, replacin | |||
he Client later sends a GET request to the /ace-group/GROUPNAME/kdc-cred resourc | g the currently stored value (if any). If, as a group member, the Client later s | |||
e for retrieving the latest KDC's authentication credential (see <xref target="k | ends a GET request to the /ace-group/GROUPNAME/kdc-cred resource for retrieving | |||
dc-pub-key-get"/>), then the KDC is able to use the stored 'clientchallenge' for | the latest KDC's authentication credential (see <xref target="kdc-pub-key-get"/> | |||
computing a PoP evidence to include in the response sent to the Client, hence p | ), then the KDC uses the stored 'clientchallenge' for computing the PoP evidence | |||
roving the possession of its own private key.</t> | to include in the response sent to the Client, hence proving the possession of | |||
<t>If the Join Response includes the 'kdc_cred_verify' parameter, the | its own private key.</t> | |||
Client verifies the conveyed PoP evidence and considers the group joining unsucc | <t>If the Join Response includes the 'kdc_cred_verify' parameter, the | |||
essful in case of failed verification. Application profiles of this specificatio | Client verifies the conveyed PoP evidence and considers the group joining unsucc | |||
n MUST specify the exact approaches used by the Client to verify the PoP evidenc | essful in case of failed verification. Application profiles of this specificatio | |||
e in 'kdc_cred_verify', and MUST specify which of those approaches is used in wh | n <bcp14>MUST</bcp14> specify the exact approaches used by the Client to verify | |||
ich case (REQ21).</t> | the PoP evidence in 'kdc_cred_verify' and <bcp14>MUST</bcp14> specify which of t | |||
<t>Specific application profiles that build on this document MUST spec | hose approaches is used in which case (<xref target="req21" format="none">REQ21< | |||
ify the communication protocol that members of the group use to communicate with | /xref>).</t> | |||
each other (REQ22) and how exactly the keying material is used to protect the g | <t>Application profiles of this specification <bcp14>MUST</bcp14> spec | |||
roup communication (REQ23).</t> | ify the communication protocol that members of the group use to communicate with | |||
each other (<xref target="req22" format="none">REQ22</xref>) and the security p | ||||
rotocol that they use to protect the group communication (<xref target="req23" f | ||||
ormat="none">REQ23</xref>).</t> | ||||
<section anchor="ssec-key-distribution-exchange"> | <section anchor="ssec-key-distribution-exchange"> | |||
<name>Join the Group</name> | <name>Join the Group</name> | |||
<t><xref target="fig-key-distr-join"/> gives an overview of the join exchange between the Client and the KDC, when the Client first joins a group, w hile <xref target="fig-key-distr-join-2"/> shows an example.</t> | <t><xref target="fig-key-distr-join"/> gives an overview of the join exchange between the Client and the KDC when the Client first joins a group, wh ile <xref target="fig-key-distr-join-2"/> shows an example.</t> | |||
<figure anchor="fig-key-distr-join"> | <figure anchor="fig-key-distr-join"> | |||
<name>Message Flow of the Join Request-Response</name> | <name>Message Flow of the Join Request-Response</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client KDC | Client KDC | |||
| | | | | | |||
|-------- Join Request: POST /ace-group/GROUPNAME ------>| | |-------- Join Request: POST /ace-group/GROUPNAME ------>| | |||
| | | | | | |||
|<------------ Join Response: 2.01 (Created) ----------- | | |<------------ Join Response: 2.01 (Created) ----------- | | |||
| Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | | | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<figure anchor="fig-key-distr-join-2"> | <figure anchor="fig-key-distr-join-2"> | |||
<name>Example of First Join Request-Response for Group Joining</na | <name>Example of the First Join Request-Response for Group Joining | |||
me> | </name> | |||
<artwork align="center"><![CDATA[ | <artwork> | |||
Request: | Request: | |||
Header: POST (Code=0.02) | Header: POST (Code=0.02) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Uri-Path: "g1" | Uri-Path: "g1" | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation, | Payload (in CBOR diagnostic notation): | |||
with AUTH_CRED and POP_EVIDENCE being CBOR byte strings): | { | |||
{ "scope": << [ "group1", ["sender", "receiver"] ] >> , | / scope / 3: <<["group1", ["sender", "receiver"]]>>, | |||
"get_creds": [true, ["sender"], []], "client_cred": AUTH_CRED, | / get_creds / 4: [true, ["sender"], []], | |||
"cnonce": h'25a8991cd700ac01', "client_cred_verify": POP_EVIDENCE } | / client_cred / 5: h'a2026008a101a5010202410a20012158 | |||
20bbc34960526ea4d32e940cad2a2341 | ||||
48ddc21791a12afbcbac93622046dd44 | ||||
f02258204519e257236b2a0ce2023f09 | ||||
31f1f386ca7afda64fcde0108c224c51 | ||||
eabf6072', | ||||
/ cnonce / 6: h'25a8991cd700ac01', | ||||
/ client_cred_verify / 24: h'66e6d9b0db009f3e105a673f88556117 | ||||
26caed57f530f8cae9d0b168513ab949 | ||||
fedc3e80a96ebe94ba08d3f8d3bf8348 | ||||
7458e2ab4c2f936ff78b50e33c885e35' | ||||
} | ||||
Response: | Response: | |||
Header: Created (Code=2.01) | Header: Created (Code=2.01) | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Location-Path: "kdc.example.com" | Location-Path: "ace-group" | |||
Location-Path: "g1" | Location-Path: "g1" | |||
Location-Path: "nodes" | Location-Path: "nodes" | |||
Location-Path: "c101" | Location-Path: "c101" | |||
Payload (in CBOR diagnostic notation, | Payload (in CBOR diagnostic notation): | |||
with KEY, AUTH_CRED_1, AUTH_CRED_2, | { | |||
ID_1, and ID_2 being CBOR byte strings): | / gkty / 7: 65600, | |||
{ "gkty": 13, "key": KEY, "num": 12, "exp": 1924992000, | / key / 8: h'73657373696f6e6b6579', | |||
"exi": 2592000, "creds": [ AUTH_CRED_1, AUTH_CRED_2 ], | / num / 9: 12, | |||
"peer_roles": ["sender", ["sender", "receiver"]], | / exp / 11: 1924992000, | |||
"peer_identifiers": [ ID1, ID2 ] } | / exi / 12: 2592000, | |||
]]></artwork> | / creds / 13: [h'a2026008a101a5010202410220012158 | |||
20cd4177ba62433375ede279b5e18e8b | ||||
91bc3ed8f1e174474a26fc0edb44ea53 | ||||
73225820a0391de29c5c5badda610d4e | ||||
301eaaa18422367722289cd18cbe6624 | ||||
e89b9cfd', | ||||
h'a2026008a101a5010202410320012158 | ||||
20ac75e9ece3e50bfc8ed60399889522 | ||||
405c47bf16df96660a41298cb4307f7e | ||||
b62258206e5de611388a4b8a8211334a | ||||
c7d37ecb52a387d257e6db3c2a93df21 | ||||
ff3affc8'], | ||||
/ peer_roles / 14: ["sender", ["sender", "receiver"]], | ||||
/ peer_identifiers / 15: [h'01', h'02'] | ||||
} | ||||
</artwork> | ||||
</figure> | </figure> | |||
<t>If not previously established, the Client and the KDC MUST first | <t>If not previously established, the Client and the KDC <bcp14>MUST | |||
establish a pairwise secure communication association (REQ24). This can be achie | </bcp14> first establish a pairwise secure communication association (<xref targ | |||
ved, for instance, by using a transport profile of ACE. The join exchange MUST o | et="req24" format="none">REQ24</xref>). This can be achieved, for instance, by u | |||
ccur over that secure communication association. The Client and the KDC MAY use | sing a transport profile of ACE. The join exchange <bcp14>MUST</bcp14> occur ove | |||
that same secure communication association to protect further pairwise communica | r that secure communication association. The Client and the KDC <bcp14>MAY</bcp1 | |||
tions that must be protected.</t> | 4> use that same secure communication association to protect further pairwise co | |||
<t>It is REQUIRED that the secure communication association between | mmunications that must be protected.</t> | |||
the Client and the KDC is established by using the proof-of-possession key bound | <t>It is <bcp14>REQUIRED</bcp14> that the secure communication assoc | |||
to the access token. As a result, the proof-of-possession to bind the access to | iation between the Client and the KDC is established by using the proof-of-posse | |||
ken to the Client is performed by using the proof-of-possession key bound to the | ssion key bound to the access token. As a result, the proof of possession to bin | |||
access token for establishing secure communication between the Client and the K | d the access token to the Client is performed by using the proof-of-possession k | |||
DC.</t> | ey bound to the access token for establishing the pairwise secure communication | |||
<t>To join the group, the Client sends a CoAP POST request to the /a | association between the Client and the KDC.</t> | |||
ce-group/GROUPNAME endpoint at the KDC, where the group to join is identified by | <t>To join the group, the Client sends a CoAP POST request to the /a | |||
GROUPNAME. The group name is specified in the scope entry conveyed by the 'scop | ce-group/GROUPNAME endpoint at the KDC, where the group to join is identified by | |||
e' parameter of the request (if present), formatted as specified in <xref target | GROUPNAME. The group name is specified in the scope entry conveyed by the 'scop | |||
="gid-post"/>. This group name is the same as in the scope entry corresponding t | e' parameter of the request (if present), formatted as specified in <xref target | |||
o that group, specified in the 'scope' parameter of the Authorization Request/Re | ="gid-post"/>. This group name is the same as in the scope entry corresponding t | |||
sponse, or it can be retrieved from it. Note that, in case of successful joining | o that group, specified in the 'scope' parameter of the Authorization Request/Re | |||
, the Client will receive the URI to retrieve individual keying material and to | sponse, or it can be determined from it. Note that, in case of successful joinin | |||
leave the group in the Location-Path option of the response.</t> | g, the Location-Path Options in the Join Response provide the Client with the pa | |||
<t>If the node is joining a group for the first time and the KDC mai | th of the URI to use for retrieving individual keying material and for leaving t | |||
ntains the authentication credentials of the group members, the Client is REQUIR | he group.</t> | |||
ED to send its own authentication credential and proof-of-possession (PoP) evide | <t>If the node is joining a group for the first time and the KDC mai | |||
nce in the Join Request (see the 'client_cred' and 'client_cred_verify' paramete | ntains the authentication credentials of the group members, the Client is <bcp14 | |||
rs in <xref target="gid-post"/>). The request is accepted only if both the authe | >REQUIRED</bcp14> to send its own authentication credential and proof-of-possess | |||
ntication credential is provided and the PoP evidence is successfully verified.< | ion (PoP) evidence in the Join Request (see the 'client_cred' and 'client_cred_v | |||
/t> | erify' parameters in <xref target="gid-post"/>). The request is accepted only if | |||
<t>If a node re-joins a group as authorized by the same access token | both the authentication credential is provided and the PoP evidence is successf | |||
and using the same authentication credential, it can omit the authentication cr | ully verified.</t> | |||
edential and the PoP evidence, or just the PoP evidence, from the Join Request. | <t>If a node rejoins a group as authorized by the same access token | |||
Then, the KDC will be able to retrieve the node's authentication credential asso | and using the same authentication credential, it can omit the authentication cre | |||
ciated with the access token for that group. If the authentication credential ha | dential and the PoP evidence, or just the PoP evidence, from the Join Request. T | |||
s been discarded, the KDC replies with a 4.00 (Bad Request) error response, as s | hen, the KDC will be able to retrieve the node's authentication credential assoc | |||
pecified in <xref target="gid-post"/>. If a node re-joins a group but wants to u | iated with the access token for that group. If the authentication credential has | |||
pdate its own authentication credential, it needs to include both its authentica | been discarded, the KDC replies with a 4.00 (Bad Request) error response, as sp | |||
tion credential and the PoP evidence in the Join Request like when it joined the | ecified in <xref target="gid-post"/>. If a node rejoins a group but wants to upd | |||
group for the first time.</t> | ate its own authentication credential, it needs to include both its authenticati | |||
on credential and the PoP evidence in the Join Request, like when it joined the | ||||
group for the first time.</t> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="gid-get"> | <section anchor="gid-get"> | |||
<name>GET Handler</name> | <name>GET Handler</name> | |||
<t>The GET handler returns the symmetric group keying material for the group identified by GROUPNAME.</t> | <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>The handler expects a GET request.</t> | |||
<t>In addition to what is defined in <xref target="kdc-if-errors"/>, t | <t>In addition to what is defined in <xref target="kdc-if-errors"/>, t | |||
he handler verifies that the Client is a current member of the group. If the ver | he handler verifies that the Client is a current member of the group. If the ver | |||
ification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The | ification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error | |||
response MUST have Content-Format set to application/concise-problem-details+cbo | response. The response <bcp14>MUST</bcp14> have Content-Format "application/con | |||
r and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Cust | cise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-e | |||
om Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field | rrors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the valu | |||
MUST be set to 0 ("Operation permitted only to group members").</t> | e of the 'error-id' field <bcp14>MUST</bcp14> be set to 0 ("Operation permitted | |||
<t>If all verifications succeed, the handler replies with a 2.05 (Cont | only to group members").</t> | |||
ent) response containing the symmetric group keying material. The payload of the | <t>If all verifications succeed, the handler replies with a 2.05 (Cont | |||
response is formatted as a CBOR map which MUST contain the parameters 'gkty', ' | ent) response containing the symmetric group keying material. The payload of the | |||
key', and 'num' specified in <xref target="gid-post"/>.</t> | response is formatted as a CBOR map that <bcp14>MUST</bcp14> contain the parame | |||
<t>Each of the following parameters specified in <xref target="gid-pos | ters 'gkty', 'key', and 'num', as specified in <xref target="gid-post"/>.</t> | |||
t"/> MUST also be included in the payload of the response, if they are included | <t>The payload <bcp14>MUST</bcp14> also include the parameters 'rekeyi | |||
in the payload of the Join Responses sent for the group: 'rekeying_scheme', 'mgt | ng_scheme' and 'mgt_key_material' as specified in <xref target="gid-post"/>, if | |||
_key_material'.</t> | they are included in the payload of the Join Responses sent for the group.</t> | |||
<t>The payload MAY also include the parameters 'ace_groupcomm_profile' | <t>The payload <bcp14>MAY</bcp14> also include the parameters 'ace_gro | |||
, 'exp', and 'exi' specified in <xref target="gid-post"/>. If the 'exp' paramete | upcomm_profile', 'exp', and 'exi', as specified in <xref target="gid-post"/>. If | |||
r is included, the 'exi' parameter MUST also be included. If the parameter 'exi' | the 'exp' parameter is included, the 'exi' parameter <bcp14>MUST</bcp14> also b | |||
is included, its value specifies the residual lifetime of the group keying mate | e included. If the 'exi' parameter is included, its value specifies the residual | |||
rial from the current time at the KDC.</t> | lifetime of the group keying material from the current time at the KDC.</t> | |||
<section anchor="ssec-key-material-retrieval"> | <section anchor="ssec-key-material-retrieval"> | |||
<name>Retrieve Group Keying Material</name> | <name>Retrieve Group Keying Material</name> | |||
<t>A node in the group can contact the KDC to retrieve the current g | <t>A node in the group can contact the KDC to retrieve the current g | |||
roup keying material, by sending a CoAP GET request to the /ace-group/GROUPNAME | roup keying material by sending a CoAP GET request to the /ace-group/GROUPNAME e | |||
endpoint at the KDC, where the group is identified by GROUPNAME.</t> | ndpoint at the KDC, where the group is identified by GROUPNAME.</t> | |||
<t><xref target="fig-retrieve-key-material"/> gives an overview of t | <t><xref target="fig-retrieve-key-material"/> gives an overview of t | |||
he key distribution exchange between the Client and the KDC, when the Client fir | he key distribution exchange between the Client and the KDC, while <xref target= | |||
st joins a group, while <xref target="fig-retrieve-key-material-2"/> shows an ex | "fig-retrieve-key-material-2"/> shows an example.</t> | |||
ample.</t> | ||||
<figure anchor="fig-retrieve-key-material"> | <figure anchor="fig-retrieve-key-material"> | |||
<name>Message Flow of Key Distribution Request-Response</name> | <name>Message Flow of Key Distribution Request-Response</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client KDC | Client KDC | |||
| | | | | | |||
|------ Key Distribution Request: GET /ace-group/GROUPNAME ------>| | |------ Key Distribution Request: GET /ace-group/GROUPNAME ------>| | |||
| | | | | | |||
|<----------- Key Distribution Response: 2.05 (Content) --------- | | |<----------- Key Distribution Response: 2.05 (Content) --------- | | |||
| | | | | | |||
]]></artwork> | ]]></artwork> | |||
skipping to change at line 1083 ¶ | skipping to change at line 1150 ¶ | |||
Header: GET (Code=0.01) | Header: GET (Code=0.01) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Uri-Path: "g1" | Uri-Path: "g1" | |||
Payload: - | Payload: - | |||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Content (Code=2.05) | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation, | Payload (in CBOR diagnostic notation): | |||
with KEY being a CBOR byte strings): | { | |||
{ "gkty": 13, "key": KEY, "num": 12 } | / gkty / 7: 65600, | |||
/ key / 8: h'73657373696f6e6b6579', | ||||
/ num / 9: 12 | ||||
} | ||||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="ace-groupgroupnamecreds"> | <section anchor="ace-groupgroupnamecreds"> | |||
<name>/ace-group/GROUPNAME/creds</name> | <name>/ace-group/GROUPNAME/creds</name> | |||
<t>This resource implements the GET and FETCH handlers.</t> | <t>This resource implements the GET and FETCH handlers.</t> | |||
<section anchor="pubkey-fetch"> | <section anchor="pubkey-fetch"> | |||
<name>FETCH Handler</name> | <name>FETCH Handler</name> | |||
<t>The FETCH handler receives identifiers of group members for the gro up identified by GROUPNAME and returns the authentication credentials of such gr oup members.</t> | <t>The FETCH handler receives identifiers of group members for the gro up identified by GROUPNAME and returns the authentication credentials of such gr oup members.</t> | |||
<t>The handler expects a request with payload formatted as a CBOR map, which MUST contain the following field.</t> | <t>The handler expects a request with the payload formatted as a CBOR map, which <bcp14>MUST</bcp14> contain the following field.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>'get_creds', whose value is encoded as in <xref target="gid-pos t"/> with the following modifications. </t> | <t>'get_creds': its value is encoded as in <xref target="gid-post" />, with the following modifications. </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>The arrays 'role_filter' and 'id_filter' MUST NOT both be e mpty, i.e., in CDDL notation: [ bool, [ ], [ ] ]. If the 'get_creds' parameter h as such a format, the request MUST be considered malformed, and the KDC MUST rep ly with a 4.00 (Bad Request) error response. </t> | <t>The arrays 'role_filter' and 'id_filter' <bcp14>MUST NOT</b cp14> both be empty, i.e., in CDDL notation: [ bool, [ ], [ ] ]. If the 'get_cre ds' parameter has such a format, the request <bcp14>MUST</bcp14> be considered m alformed, and the KDC <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. </t> | |||
<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> | 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> | |||
<li>The element 'inclusion_flag' encodes the CBOR simple value " | <li>The element 'inclusion_flag' encodes the CBOR simple value < | |||
true" (0xf5) or "false" (0xf4), as defined in <xref target="gid-post"/>.</li> | tt>true</tt> (0xf5) or <tt>false</tt> (0xf4), as defined in <xref target="gid-po | |||
<li>The array 'role_filter' can be empty, if the Client does not | st"/>.</li> | |||
wish to filter the requested authentication credentials based on the roles of t | <li>The array 'role_filter' can be empty if the Client does not | |||
he group members.</li> | wish to filter the requested authentication credentials based on the roles of th | |||
<li>The array 'id_filter' contains zero or more node identifiers | e group members.</li> | |||
of group members, for the group identified by GROUPNAME, as defined in <xref ta | <li>The array 'id_filter' contains zero or more node identifiers | |||
rget="gid-post"/>. The array may be empty, if the Client does not wish to filter | of group members for the group identified by GROUPNAME, as defined in <xref tar | |||
the requested authentication credentials based on the node identifiers of the g | get="gid-post"/>. The array may be empty if the Client does not wish to filter t | |||
roup members.</li> | he requested authentication credentials based on the node identifiers of the gro | |||
up members.</li> | ||||
</ul> | </ul> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>Note that, in case the 'role_filter' array and the 'id_filter' arra y are both non-empty:</t> | <t>Note that, in case the 'role_filter' array and the 'id_filter' arra y are both non-empty:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>If the 'inclusion_flag' encodes the CBOR simple value "true" (0x | <li>If the 'inclusion_flag' encodes the CBOR simple value <tt>true</ | |||
f5), the handler returns the authentication credentials of group members whose r | tt> (0xf5), the handler returns the authentication credentials of group members | |||
oles match with 'role_filter' and/or having their node identifier specified in ' | whose roles match with 'role_filter' and/or have their node identifier specified | |||
id_filter'.</li> | in 'id_filter'.</li> | |||
<li>If the 'inclusion_flag' encodes the CBOR simple value "false" (0 | <li>If the 'inclusion_flag' encodes the CBOR simple value <tt>false< | |||
xf4), the handler returns the authentication credentials of group members whose | /tt> (0xf4), the handler returns the authentication credentials of group members | |||
roles match with 'role_filter' and, at the same time, not having their node iden | whose roles match with 'role_filter' and, at the same time, do not have their n | |||
tifier specified in 'id_filter'.</li> | ode identifier specified in 'id_filter'.</li> | |||
</ul> | </ul> | |||
<t>The specific format of authentication credentials as well as identi fiers, roles, and combination of roles of group members MUST be specified by app lication profiles of this specification (REQ1, REQ6, REQ25).</t> | <t>The specific format of authentication credentials as well as the id entifiers, roles, and combination of roles of group members <bcp14>MUST</bcp14> be specified by application profiles of this specification (<xref target="req1" format="none">REQ1</xref>, <xref target="req6" format="none">REQ6</xref>, <xref target="req25" format="none">REQ25</xref>).</t> | |||
<t>The handler identifies the authentication credentials of the curren t group members for which either of the following holds:</t> | <t>The handler identifies the authentication credentials of the curren t group members for which either of the following holds:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>the role identifier matches with one of those indicated in the r | <li>The role identifier matches with one of those indicated in the r | |||
equest; note that the request can specify a combination of roles, in which case | equest; note that the request can specify a combination of roles, in which case | |||
the handler selects only the group members that have all the roles included in t | the handler selects only the group members that have all the roles included in t | |||
he combination.</li> | he combination.</li> | |||
<li>the node identifier matches with one of those indicated in the r | <li>The node identifier matches with one of those indicated in the r | |||
equest, or does not match with any of those, consistent with the value of the el | equest or does not match with any of those, which is consistent with the value o | |||
ement 'inclusion_flag'.</li> | f the element 'inclusion_flag'.</li> | |||
</ul> | </ul> | |||
<t>If all verifications succeed, the handler returns a 2.05 (Content) message response with payload formatted as a CBOR map, containing only the follo wing parameters from <xref target="gid-post"/>.</t> | <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 f ollowing parameters from <xref target="gid-post"/>.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'num', which encodes the version number of the current group key | <li>'num': encoding the version number of the current group keying m | |||
ing material.</li> | aterial.</li> | |||
<li>'creds', which encodes the list of authentication credentials of | <li>'creds': encoding the list of authentication credentials of the | |||
the selected group members.</li> | selected group members.</li> | |||
<li> | <li> | |||
<t>'peer_roles', which encodes the role(s) that each of the select ed group members has in the group. </t> | <t>'peer_roles': encoding the role(s) that each of the selected gr oup members has in the group. </t> | |||
<t> | <t> | |||
This parameter SHOULD be present and it MAY be omitted, according to the same cr iteria defined for the Join Response (see <xref target="gid-post"/>).</t> | This parameter <bcp14>SHOULD</bcp14> be present, and it <bcp14>MAY</bcp14> be om itted according to the same criteria defined for the Join Response (see <xref ta rget="gid-post"/>).</t> | |||
</li> | </li> | |||
<li>'peer_identifiers', which encodes the node identifier that each of the selected group members has in the group.</li> | <li>'peer_identifiers': encoding the node identifier that each of th e selected group members has in the group.</li> | |||
</ul> | </ul> | |||
<t>The specific format of authentication credentials as well as of nod | <t>The specific format of authentication credentials as well as of nod | |||
e identifiers of group members is specified by the application profile (REQ6, RE | e identifiers of group members is specified by the application profile (<xref ta | |||
Q25).</t> | rget="req6" format="none">REQ6</xref>, <xref target="req25" format="none">REQ25< | |||
<t>If the KDC does not store any authentication credential associated | /xref>).</t> | |||
with the specified node identifiers, the handler returns a response with payload | <t>If the KDC does not store any authentication credential associated | |||
formatted as a CBOR byte string of zero length.</t> | with the specified node identifiers, the handler returns a response with the pay | |||
<t>The handler MAY enforce one of the following policies, in order to | load formatted as a CBOR byte string of zero length (0x40).</t> | |||
handle possible node identifiers that are included in the 'id_filter' element of | <t>The handler <bcp14>MAY</bcp14> enforce one of the following policie | |||
the 'get_creds' parameter of the request but are not associated with any curren | s in order to handle possible node identifiers that are included in the 'id_filt | |||
t group member. Such a policy MUST be specified by the application profile (REQ2 | er' element of the 'get_creds' parameter of the request but are not associated w | |||
6).</t> | ith any current group member. Such a policy <bcp14>MUST</bcp14> be specified by | |||
application profiles of this specification (<xref target="req26" format="none">R | ||||
EQ26</xref>).</t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The KDC silently ignores those node identifiers.</li> | <li>The KDC silently ignores those node identifiers.</li> | |||
<li> | <li> | |||
<t>The KDC retains authentication credentials of group members for a given amount of time after their leaving, before discarding them. As long as such authentication credentials are retained, the KDC provides them to a request ing Client. </t> | <t>The KDC retains authentication credentials of group members for a given amount of time after their leaving before discarding them. As long as s uch authentication credentials are retained, the KDC provides them to a requesti ng Client. </t> | |||
<t> | <t> | |||
If the KDC adopts this policy, the application profile MUST also specify the amo unt of time during which the KDC retains the authentication credential of a form er group member after its leaving, possibly on a per-member basis.</t> | If the KDC adopts this policy, the application profile <bcp14>MUST</bcp14> also specify the amount of time during which the KDC retains the authentication crede ntial of a former group member after its leaving, possibly on a per-member basis .</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>Note that this resource handler only verifies that the node is auth orized by the AS to access this resource. Nodes that are not members of the grou p but are authorized to do signature verifications on the group messages may be allowed to access this resource, if the application needs it.</t> | <t>Note that this resource handler only verifies that the node is auth orized by the AS to access this resource. Nodes that are not members of the grou p but are authorized to do signature verifications on the group messages may be allowed to access this resource if the application needs it.</t> | |||
<section anchor="sec-key-retrieval"> | <section anchor="sec-key-retrieval"> | |||
<name>Retrieve a Subset of Authentication Credentials in the Group</ name> | <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 group members, by sending a CoAP FETCH request to the /ace-group/GROUPNAME/creds endpoint at t he KDC, where the group is identified by GROUPNAME, and formatted as defined in <xref target="pubkey-fetch"/>.</t> | <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 group members by sending a CoAP FETCH request to the /ace-group/GROUPNAME/creds endpoint at th e KDC, which is formatted as defined in <xref target="pubkey-fetch"/> and with t he group identified by GROUPNAME.</t> | |||
<t><xref target="fig-public-key-1"/> gives an overview of the exchan ge mentioned above, while <xref target="fig-public-key-2"/> shows an example of such an exchange.</t> | <t><xref target="fig-public-key-1"/> gives an overview of the exchan ge mentioned above, while <xref target="fig-public-key-2"/> shows an example of such an exchange.</t> | |||
<figure anchor="fig-public-key-1"> | <figure anchor="fig-public-key-1"> | |||
<name>Message Flow of Authentication Credential Request-Response t o Obtain the Authentication Credentials of Specific Group Members</name> | <name>Message Flow of Authentication Credential Request-Response t o Obtain the Authentication Credentials of Specific Group Members</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client KDC | Client KDC | |||
| | | | | | |||
| Authentication Credential Request: | | | Authentication Credential Request: | | |||
|-------------------------------------------------------->| | |-------------------------------------------------------->| | |||
| FETCH /ace-group/GROUPNAME/creds | | | FETCH /ace-group/GROUPNAME/creds | | |||
| | | | | | |||
skipping to change at line 1175 ¶ | skipping to change at line 1245 ¶ | |||
<figure anchor="fig-public-key-2"> | <figure anchor="fig-public-key-2"> | |||
<name>Example of Authentication Credential Request-Response to Obt ain the Authentication Credentials of Specific Group Members</name> | <name>Example of Authentication Credential Request-Response to Obt ain the Authentication Credentials of Specific Group Members</name> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Request: | Request: | |||
Header: FETCH (Code=0.05) | Header: FETCH (Code=0.05) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Uri-Path: "g1" | Uri-Path: "g1" | |||
Uri-Path: "creds" | Uri-Path: "creds" | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation): | Payload (in CBOR diagnostic notation): | |||
{ "get_creds": [true, [], [ ID_2, ID_3 ]] } | { | |||
/ get_creds / 4: [true, [], [h'02', h'03']] | ||||
} | ||||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Content (Code=2.05) | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation, | Payload (in CBOR diagnostic notation): | |||
with AUTH_CRED_2, AUTH_CRED_3, | { | |||
ID_2, and ID_3 being CBOR byte strings): | / creds / 13: [h'a2026008a101a5010202410320012158 | |||
{ "creds": [ AUTH_CRED_2, AUTH_CRED_3, ], | 20ac75e9ece3e50bfc8ed60399889522 | |||
"peer_roles": [ ["sender", "receiver"], "receiver" ], | 405c47bf16df96660a41298cb4307f7e | |||
"peer_identifiers": [ ID_2, ID_3 ] } | b62258206e5de611388a4b8a8211334a | |||
c7d37ecb52a387d257e6db3c2a93df21 | ||||
ff3affc8', | ||||
h'a2026008a101a5010202410920012158 | ||||
206f9702a66602d78f5e81bac1e0af01 | ||||
f8b52810c502e87ebb7c926c07426fd0 | ||||
2f225820c8d33274c71c9b3ee57d842b | ||||
bf2238b8283cb410eca216fb72a78ea7 | ||||
a870f800'], | ||||
/ peer_roles / 14: [["sender", "receiver"], "receiver"], | ||||
/ peer_identifiers / 15: [h'02', h'03'] | ||||
} | ||||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="pubkey-get"> | <section anchor="pubkey-get"> | |||
<name>GET Handler</name> | <name>GET Handler</name> | |||
<t>The handler expects a GET request.</t> | <t>The handler expects a GET request.</t> | |||
<t>If all verifications succeed, the KDC replies with a 2.05 (Content) | <t>If all verifications succeed, the KDC replies with a 2.05 (Content) | |||
response as in the FETCH handler in <xref target="pubkey-fetch"/>, but specifyi | response as in the FETCH handler in <xref target="pubkey-fetch"/>, but its payl | |||
ng in the payload the authentication credentials of all the group members, toget | oad specifies the authentication credentials of all the group members, together | |||
her with their roles and node identifiers.</t> | with their roles and node identifiers.</t> | |||
<t>The parameter 'peer_roles' SHOULD be present in the payload of the | <t>The 'peer_roles' parameter <bcp14>SHOULD</bcp14> be present in the | |||
response and it MAY be omitted, according to the same criteria defined for the J | payload of the response, and it <bcp14>MAY</bcp14> be omitted according to the s | |||
oin Response (see <xref target="gid-post"/>).</t> | ame criteria defined for the Join Response (see <xref target="gid-post"/>).</t> | |||
<section anchor="sec-key-retrieval-all"> | <section anchor="sec-key-retrieval-all"> | |||
<name>Retrieve All Authentication Credentials in the Group</name> | <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 reque st the authentication credentials, roles, and node identifiers of all the curren t group 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>In case the KDC maintains the authentication credentials of group members, a node in the group or an external signature verifier can contact the KDC to request the authentication credentials, roles, and node identifiers of al l the current group members, by sending a CoAP GET request to the /ace-group/GRO UPNAME/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 messag e exchange, while <xref target="fig-public-key-4"/> shows an example of such an exchange.</t> | <t><xref target="fig-public-key-3"/> gives an overview of the messag e exchange, while <xref target="fig-public-key-4"/> shows an example of such an exchange.</t> | |||
<figure anchor="fig-public-key-3"> | <figure anchor="fig-public-key-3"> | |||
<name>Message Flow of Authentication Credential Request-Response t o Obtain the Authentication Credentials of all the Group Members</name> | <name>Message Flow of Authentication Credential Request-Response t o Obtain the Authentication Credentials of All the Group Members</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client KDC | Client KDC | |||
| | | | | | |||
| Authentication Credential Request: | | | Authentication Credential Request: | | |||
|-------------------------------------------------------->| | |-------------------------------------------------------->| | |||
| GET /ace-group/GROUPNAME/creds | | | GET /ace-group/GROUPNAME/creds | | |||
| | | | | | |||
|<-- Authentication Credential Response: 2.05 (Content) --| | |<-- Authentication Credential Response: 2.05 (Content) --| | |||
| | | | | | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<figure anchor="fig-public-key-4"> | <figure anchor="fig-public-key-4"> | |||
<name>Example of Authentication Credential Request-Response to Obt ain the Authentication Credentials of all the Group Members</name> | <name>Example of Authentication Credential Request-Response to Obt ain the Authentication Credentials of All the Group Members</name> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Request: | Request: | |||
Header: GET (Code=0.01) | Header: GET (Code=0.01) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Uri-Path: "g1" | Uri-Path: "g1" | |||
Uri-Path: "creds" | Uri-Path: "creds" | |||
Payload: - | Payload: - | |||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Content (Code=2.05) | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation, | 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 / 9: 12, | |||
{ "num": 5, | / creds / 13: [h'a2026008a101a5010202410220012158 | |||
"creds": [ AUTH_CRED_1, AUTH_CRED_2, AUTH_CRED_3 ], | 20cd4177ba62433375ede279b5e18e8b | |||
"peer_roles": ["sender", ["sender", "receiver"], "receiver"], | 91bc3ed8f1e174474a26fc0edb44ea53 | |||
"peer_identifiers": [ ID_1, ID_2, ID_3 ] } | 73225820a0391de29c5c5badda610d4e | |||
301eaaa18422367722289cd18cbe6624 | ||||
e89b9cfd', | ||||
h'a2026008a101a5010202410320012158 | ||||
20ac75e9ece3e50bfc8ed60399889522 | ||||
405c47bf16df96660a41298cb4307f7e | ||||
b62258206e5de611388a4b8a8211334a | ||||
c7d37ecb52a387d257e6db3c2a93df21 | ||||
ff3affc8', | ||||
h'a2026008a101a5010202410920012158 | ||||
206f9702a66602d78f5e81bac1e0af01 | ||||
f8b52810c502e87ebb7c926c07426fd0 | ||||
2f225820c8d33274c71c9b3ee57d842b | ||||
bf2238b8283cb410eca216fb72a78ea7 | ||||
a870f800'], | ||||
/ peer_roles / 14: ["sender", ["sender", "receiver"], | ||||
"receiver"], | ||||
/ peer_identifiers / 15: [h'01', h'02', h'03'] | ||||
} | ||||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="ace-groupgroupnamekdc-cred"> | <section anchor="ace-groupgroupnamekdc-cred"> | |||
<name>/ace-group/GROUPNAME/kdc-cred</name> | <name>/ace-group/GROUPNAME/kdc-cred</name> | |||
<t>This resource implements a GET handler.</t> | <t>This resource implements a GET handler.</t> | |||
<section anchor="kdc-pub-key-get"> | <section anchor="kdc-pub-key-get"> | |||
<name>GET Handler</name> | <name>GET Handler</name> | |||
<t>The handler expects a GET request.</t> | <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 with a proof-of- possession (PoP) evidence. The response MUST have Content-Format set to applicat ion/ace-groupcomm+cbor. The payload of the response is a CBOR map, which include s the following fields.</t> | <t>If all verifications succeed, the handler returns a 2.05 (Content) message containing the KDC's authentication credential together with the proof-o f-possession (PoP) evidence. The response <bcp14>MUST</bcp14> have Content-Forma t "application/ace-groupcomm+cbor". The payload of the response is a CBOR map, w hich includes the following fields.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The 'kdc_cred' parameter, specifying the KDC's authentication cr | <li>'kdc_cred: specifying the KDC's authentication credential. This | |||
edential. This parameter is encoded like the 'kdc_cred' parameter in the Join Re | parameter is encoded like the 'kdc_cred' parameter in the Join Response (see <xr | |||
sponse (see <xref target="gid-post"/>).</li> | ef target="gid-post"/>).</li> | |||
<li>The 'kdc_nonce' parameter, specifying a nonce generated by the K | <li>'kdc_nonce': specifying a nonce generated by the KDC. This param | |||
DC. This parameter is encoded like the 'kdc_nonce' parameter in the Join Respons | eter is encoded like the 'kdc_nonce' parameter in the Join Response (see <xref t | |||
e (see <xref target="gid-post"/>).</li> | arget="gid-post"/>).</li> | |||
<li> | <li> | |||
<t>The 'kdc_cred_verify' parameter, specifying a PoP evidence comp uted by the KDC over the following PoP input: the nonce N_C (encoded as a CBOR b yte string) concatenated with the nonce N_KDC (encoded as a CBOR byte string), w here: </t> | <t>'kdc_cred_verify': specifying the 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"> | <ul spacing="normal"> | |||
<li>N_C is the nonce generated by the Client group member such t | <li>N_C is the nonce generated by the Client group member such t | |||
hat: i) the nonce was specified in the 'cnonce' parameter of the latest Join Req | hat: i) the nonce was specified in the 'cnonce' parameter of the latest Join Req | |||
uest that the Client sent to the KDC in order to join the group identified by GR | uest that the Client sent to the KDC in order to join the group identified by GR | |||
OUPNAME; and ii) the KDC stored the nonce as 'clientchallenge' value associated | OUPNAME; and ii) the KDC stored the nonce as a 'clientchallenge' value associate | |||
with this Client as group member after sending the corresponding Join Response ( | d with the Client after sending the corresponding Join Response (see <xref targe | |||
see <xref target="gid-post"/>). This nonce is encoded as a CBOR byte string.</li | t="gid-post"/>).</li> | |||
> | <li>N_KDC is the nonce generated by the KDC and specified in the | |||
<li>N_KDC is the nonce generated by the KDC and specified in the | 'kdc_nonce' parameter.</li> | |||
'kdc_nonce' parameter, encoded as a CBOR byte string.</li> | ||||
</ul> | </ul> | |||
<t> | <t> | |||
An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is give n in <xref target="fig-kdc-cred-input-2"/>. </t> | An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is give n in <xref target="fig-kdc-cred-input-2"/>. </t> | |||
<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 t arget="gid-post"/>). </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 t arget="gid-post"/>). </t> | |||
<t> | <t> | |||
Application profiles of this specification MUST specify the exact approaches use d by the KDC to compute the PoP evidence to include in 'kdc_cred_verify', and MU ST specify which of those approaches is used in which case (REQ21). </t> | Application profiles of this specification <bcp14>MUST</bcp14> specify the exact approaches used by the KDC to compute the PoP evidence to include in the 'kdc_c red_verify' parameter and <bcp14>MUST</bcp14> specify which of those approaches is used in which case (<xref target="req21" format="none">REQ21</xref>). </t> | |||
<t> | <t> | |||
If an application profile supports the presence of external signature verifiers that send GET requests to this resource, then the application profile MUST speci fy how external signature verifiers provide the KDC with a self-generated nonce to use as N_C (REQ21).</t> | If an application profile supports the presence of external signature verifiers that send GET requests to this resource, then the application profile <bcp14>MUS T</bcp14> specify how external signature verifiers provide the KDC with a self-g enerated nonce to use as N_C (<xref target="req21" format="none">REQ21</xref>).< /t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<figure anchor="fig-kdc-cred-input-2"> | <figure anchor="fig-kdc-cred-input-2"> | |||
<name>Example of PoP input to compute 'kdc_cred_verify' using CBOR e ncoding</name> | <name>Example of PoP Input to Compute 'kdc_cred_verify' Using CBOR E ncoding</name> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
N_C and N_KDC expressed in CBOR diagnostic notation: | N_C and N_KDC expressed in CBOR diagnostic notation: | |||
N_C = h'25a8991cd700ac01' | N_C = h'25a8991cd700ac01' | |||
N_KDC = h'0b7db12aaff56da3' | N_KDC = h'0b7db12aaff56da3' | |||
N_C and N_KDC as CBOR encoded byte strings: | N_C and N_KDC as CBOR encoded byte strings: | |||
N_C = 0x4825a8991cd700ac01 | N_C = 0x4825a8991cd700ac01 | |||
N_KDC = 0x480b7db12aaff56da3 | N_KDC = 0x480b7db12aaff56da3 | |||
PoP input: | PoP input: | |||
0x48 25a8991cd700ac01 48 0b7db12aaff56da3 | 0x48 25a8991cd700ac01 48 0b7db12aaff56da3 | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<section anchor="kdc-pub-key"> | <section anchor="kdc-pub-key"> | |||
<name>Retrieve the KDC's Authentication Credential</name> | <name>Retrieve the KDC's Authentication Credential</name> | |||
<t>In case the KDC has an associated authentication credential as re | <t>In case the KDC has an associated authentication credential as re | |||
quired for the correct group operation, a group member or an external signature | quired for the correct group operation, a group member or an external signature | |||
verifier can contact the KDC to request the KDC's authentication credential, by | verifier can contact the KDC to request the KDC's authentication credential by s | |||
sending a CoAP GET request to the /ace-group/GROUPNAME/kdc-cred endpoint at the | ending a CoAP GET request to the /ace-group/GROUPNAME/kdc-cred endpoint at the K | |||
KDC, where GROUPNAME identifies the group.</t> | DC, where GROUPNAME identifies the group.</t> | |||
<t>Upon receiving the 2.05 (Content) response, the Client retrieves | <t>Upon receiving the 2.05 (Content) response, the Client retrieves | |||
the KDC's authentication credential from the 'kdc_cred' parameter, and MUST veri | the KDC's authentication credential from the 'kdc_cred' parameter and <bcp14>MUS | |||
fy the proof-of-possession (PoP) evidence specified in the 'kdc_cred_verify' par | T</bcp14> verify the proof-of-possession (PoP) evidence specified in the 'kdc_cr | |||
ameter. In case of successful verification of the PoP evidence, the Client MUST | ed_verify' parameter. In case of successful verification of the PoP evidence, th | |||
store the obtained KDC's authentication credential and replace the currently sto | e Client <bcp14>MUST</bcp14> store the obtained KDC's authentication credential | |||
red one.</t> | and replace the currently stored one.</t> | |||
<t>The PoP evidence is verified by means of the same method used whe | <t>The PoP evidence is verified by means of the same method used whe | |||
n processing the Join Response (see <xref target="gid-post"/>). Application prof | n processing the Join Response (see <xref target="gid-post"/>). Application prof | |||
iles of this specification MUST specify the exact approaches used by the Client | iles of this specification <bcp14>MUST</bcp14> specify the exact approaches used | |||
to verify the PoP evidence in 'kdc_cred_verify', and MUST specify which of those | by the Client to verify the PoP evidence in 'kdc_cred_verify' and <bcp14>MUST</ | |||
approaches is used in which case (REQ21).</t> | bcp14> specify which of those approaches is used in which case (<xref target="re | |||
q21" format="none">REQ21</xref>).</t> | ||||
<t><xref target="fig-kdc-pub-key-req-resp"/> gives an overview of th e exchange described above, while <xref target="fig-kdc-pub-key-req-resp-ex"/> s hows an example.</t> | <t><xref target="fig-kdc-pub-key-req-resp"/> gives an overview of th e exchange described above, while <xref target="fig-kdc-pub-key-req-resp-ex"/> s hows an example.</t> | |||
<figure anchor="fig-kdc-pub-key-req-resp"> | <figure anchor="fig-kdc-pub-key-req-resp"> | |||
<name>Message Flow of KDC Authentication Credential Request-Respon se to Obtain the Authentication Credential of the KDC</name> | <name>Message Flow of KDC Authentication Credential Request-Respon se to Obtain the Authentication Credential of the KDC</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Group | Group | |||
Member KDC | Member KDC | |||
| | | | | | |||
| KDC Authentication Credential Request | | | KDC Authentication Credential Request | | |||
|------------------------------------------------------------>| | |------------------------------------------------------------>| | |||
| GET /ace-group/GROUPNAME/kdc-cred | | | GET /ace-group/GROUPNAME/kdc-cred | | |||
skipping to change at line 1319 ¶ | skipping to change at line 1420 ¶ | |||
Header: GET (Code=0.01) | Header: GET (Code=0.01) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Uri-Path: "g1" | Uri-Path: "g1" | |||
Uri-Path: "kdc-cred" | Uri-Path: "kdc-cred" | |||
Payload: - | Payload: - | |||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Content (Code=2.05) | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation, with AUTH_CRED_KDC | Payload (in CBOR diagnostic notation): | |||
and POP_EVIDENCE being CBOR byte strings): | { | |||
{ | / kdc_cred / 17: h'a2026008a101a5010202419920012158 | |||
"kdc_nonce": h'0b7db12aaff56da3', | 2065eda5a12577c2bae829437fe33870 | |||
"kdc_cred": AUTH_CRED_KDC, | 1a10aaa375e1bb5b5de108de439c0855 | |||
"kdc_cred_verify": POP_EVIDENCE | 1d2258201e52ed75701163f7f9e40ddf | |||
} | 9f341b3dc9ba860af7e0ca7ca7e9eecd | |||
0084d19c', | ||||
/ kdc_nonce / 18: h'0b7db12aaff56da3', | ||||
/ kdc_cred_verify / 19: h'3fc54702aa56e1b2cb20284294c9106a | ||||
63f91bac658d69351210a031d8fc7c5f | ||||
f3e4be39445b1a3e83e1510d1aca2f2e | ||||
8a7c081c7645042b18aba9d1fad1bd9c' | ||||
} | ||||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="ace-groupgroupnamepolicies"> | <section anchor="ace-groupgroupnamepolicies"> | |||
<name>/ace-group/GROUPNAME/policies</name> | <name>/ace-group/GROUPNAME/policies</name> | |||
<t>This resource implements the GET handler.</t> | <t>This resource implements the GET handler.</t> | |||
<section anchor="policies-get"> | <section anchor="policies-get"> | |||
<name>GET Handler</name> | <name>GET Handler</name> | |||
<t>The handler expects a GET request.</t> | <t>The handler expects a GET request.</t> | |||
<t>In addition to what is defined in <xref target="kdc-if-errors"/>, t | <t>In addition to what is defined in <xref target="kdc-if-errors"/>, t | |||
he handler verifies that the Client is a current member of the group. If the ver | he handler verifies that the Client is a current member of the group. If the ver | |||
ification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The | ification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error | |||
response MUST have Content-Format set to application/concise-problem-details+cbo | response. The response <bcp14>MUST</bcp14> have Content-Format "application/con | |||
r and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Cust | cise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-e | |||
om Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field | rrors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the valu | |||
MUST be set to 0 ("Operation permitted only to group members").</t> | e of the 'error-id' field <bcp14>MUST</bcp14> be set to 0 ("Operation permitted | |||
<t>If all verifications succeed, the handler replies with a 2.05 (Cont | only to group members").</t> | |||
ent) response containing the list of policies for the group identified by GROUPN | <t>If all verifications succeed, the handler replies with a 2.05 (Cont | |||
AME. The payload of the response is formatted as a CBOR map including only the p | ent) response containing the list of policies for the group identified by GROUPN | |||
arameter 'group_policies' defined in <xref target="gid-post"/> and specifying th | AME. The payload of the response is formatted as a CBOR map including only the ' | |||
e current policies in the group. If the KDC does not store any policy, the paylo | group_policies' parameter defined in <xref target="gid-post"/> and specifying th | |||
ad is formatted as a zero-length CBOR byte string.</t> | e current policies in the group. If the KDC does not store any policy, the paylo | |||
<t>The specific format and meaning of group policies MUST be specified | ad is formatted as a CBOR byte string of zero length (0x40).</t> | |||
in the application profile (REQ20).</t> | <t>The specific format and meaning of group policies <bcp14>MUST</bcp1 | |||
4> be specified in application profiles of this specification (<xref target="req | ||||
20" format="none">REQ20</xref>).</t> | ||||
<section anchor="policies"> | <section anchor="policies"> | |||
<name>Retrieve the Group Policies</name> | <name>Retrieve the Group Policies</name> | |||
<t>A node in the group can contact the KDC to retrieve the current g roup policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/policie s endpoint at the KDC, where GROUPNAME identifies the group, and formatted as de fined in <xref target="policies-get"/></t> | <t>A node in the group can contact the KDC to retrieve the current g roup policies by sending a CoAP GET request to the /ace-group/GROUPNAME/policies endpoint at the KDC, which is formatted as defined in <xref target="policies-ge t"/> and with the group identified by GROUPNAME.</t> | |||
<t><xref target="fig-policies"/> gives an overview of the exchange d escribed above, while <xref target="fig-policies-2"/> shows an example.</t> | <t><xref target="fig-policies"/> gives an overview of the exchange d escribed above, while <xref target="fig-policies-2"/> shows an example.</t> | |||
<figure anchor="fig-policies"> | <figure anchor="fig-policies"> | |||
<name>Message Flow of Policies Request-Response</name> | <name>Message Flow of Policies Request-Response</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client KDC | Client KDC | |||
| | | | | | |||
|-- Policies Request: GET /ace-group/GROUPNAME/policies -->| | |-- Policies Request: GET /ace-group/GROUPNAME/policies -->| | |||
| | | | | | |||
|<----------- Policies Response: 2.05 (Content) -----------| | |<----------- Policies Response: 2.05 (Content) -----------| | |||
| | | | | | |||
skipping to change at line 1371 ¶ | skipping to change at line 1479 ¶ | |||
Header: GET (Code=0.01) | Header: GET (Code=0.01) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Uri-Path: "g1" | Uri-Path: "g1" | |||
Uri-Path: "policies" | Uri-Path: "policies" | |||
Payload: - | Payload: - | |||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Content (Code=2.05) | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload(in CBOR diagnostic notation): | Payload(in CBOR diagnostic notation): | |||
{ "group_policies": {"exp-delta": 120} } | { | |||
/ group_policies / 16: { | ||||
/ Expiration Delta / 2: 120 | ||||
} | ||||
} | ||||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="ace-groupgroupnamenum"> | <section anchor="ace-groupgroupnamenum"> | |||
<name>/ace-group/GROUPNAME/num</name> | <name>/ace-group/GROUPNAME/num</name> | |||
<t>This resource implements the GET handler.</t> | <t>This resource implements the GET handler.</t> | |||
<section anchor="num-get"> | <section anchor="num-get"> | |||
<name>GET Handler</name> | <name>GET Handler</name> | |||
<t>The handler expects a GET request.</t> | <t>The handler expects a GET request.</t> | |||
<t>In addition to what is defined in <xref target="kdc-if-errors"/>, t | <t>In addition to what is defined in <xref target="kdc-if-errors"/>, t | |||
he handler verifies that the Client is a current member of the group. If the ver | he handler verifies that the Client is a current member of the group. If the ver | |||
ification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The | ification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error | |||
response MUST have Content-Format set to application/concise-problem-details+cbo | response. The response <bcp14>MUST</bcp14> have Content-Format "application/con | |||
r and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Cust | cise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-e | |||
om Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field | rrors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the valu | |||
MUST be set to 0 ("Operation permitted only to group members").</t> | e of the 'error-id' field <bcp14>MUST</bcp14> be set to 0 ("Operation permitted | |||
<t>If all verifications succeed, the handler returns a 2.05 (Content) | only to group members").</t> | |||
message containing an integer that represents the version number of the symmetri | <t>If all verifications succeed, the handler returns a 2.05 (Content) | |||
c group keying material. This number is incremented on the KDC every time the KD | message containing an integer that represents the version number of the symmetri | |||
C updates the symmetric group keying material, before the new keying material is | c group keying material. This number is incremented on the KDC every time the KD | |||
distributed. This number is stored in persistent storage.</t> | C updates the symmetric group keying 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> | <t>The payload of the response is formatted as a CBOR integer.</t> | |||
<section anchor="key-version"> | <section anchor="key-version"> | |||
<name>Retrieve the Keying Material Version</name> | <name>Retrieve the Keying Material Version</name> | |||
<t>A node in the group can contact the KDC to request information ab out the version number of the symmetric group keying material, by sending a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the KDC, where GROUPNAM E identifies the group, formatted as defined in <xref target="num-get"/>. In par ticular, the version is incremented by the KDC every time the group keying mater ial is renewed, before it is distributed to the group members.</t> | <t>A node in the group can contact the KDC to request information ab out the version number of the symmetric group keying material by sending a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the KDC, which is format ted as defined in <xref target="num-get"/> and with the group identified by GROU PNAME. In particular, the version is incremented by the KDC every time the group keying material is renewed before it is distributed to the group members.</t> | |||
<t><xref target="fig-version"/> gives an overview of the exchange de scribed above, while <xref target="fig-version-2"/> shows an example.</t> | <t><xref target="fig-version"/> gives an overview of the exchange de scribed above, while <xref target="fig-version-2"/> shows an example.</t> | |||
<figure anchor="fig-version"> | <figure anchor="fig-version"> | |||
<name>Message Flow of Version Request-Response</name> | <name>Message Flow of Version Request-Response</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client KDC | Client KDC | |||
| | | | | | |||
|---- Version Request: GET /ace-group/GROUPNAME/num ---->| | |---- Version Request: GET /ace-group/GROUPNAME/num ---->| | |||
| | | | | | |||
|<---------- Version Response: 2.05 (Content) -----------| | |<---------- Version Response: 2.05 (Content) -----------| | |||
| | | | | | |||
skipping to change at line 1418 ¶ | skipping to change at line 1530 ¶ | |||
Header: GET (Code=0.01) | Header: GET (Code=0.01) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Uri-Path: "g1" | Uri-Path: "g1" | |||
Uri-Path: "num" | Uri-Path: "num" | |||
Payload: - | Payload: - | |||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Content (Code=2.05) | |||
Payload(in CBOR diagnostic notation): | Payload (in CBOR diagnostic notation): | |||
13 | 13 | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="node-subresource"> | <section anchor="node-subresource"> | |||
<name>/ace-group/GROUPNAME/nodes/NODENAME</name> | <name>/ace-group/GROUPNAME/nodes/NODENAME</name> | |||
<t>This resource implements the GET, PUT, and DELETE handlers.</t> | <t>This resource implements the GET, PUT, and DELETE handlers.</t> | |||
<t>In addition to what is defined in <xref target="kdc-if-errors"/>, eac h of the handlers performs the following two verifications.</t> | <t>In addition to what is defined in <xref target="kdc-if-errors"/>, eac h of the handlers performs the following two verifications.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The handler verifies that the Client is a current member of the gr oup. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-prob lem-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' field MUST be set to 0 ("Operation permitted only to group members"). </li> | <li>The handler verifies that the Client is a current member of the gr oup. If the verification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (F orbidden) error response. The response <bcp14>MUST</bcp14> have Content-Format " application/concise-problem-details+cbor" and is formatted as defined in <xref t arget="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-e rror', the value of the 'error-id' field <bcp14>MUST</bcp14> be set to 0 ("Oper ation 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 wi th a 4.03 (Forbidden) error response.</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 wi th a 4.03 (Forbidden) error response.</li> | |||
</ul> | </ul> | |||
<section anchor="node-get"> | <section anchor="node-get"> | |||
<name>GET Handler</name> | <name>GET Handler</name> | |||
<t>The handler expects a GET request.</t> | <t>The handler expects a GET request.</t> | |||
<t>If all verifications succeed, the handler replies with a 2.05 (Cont | <t>If all verifications succeed, the handler replies with a 2.05 (Cont | |||
ent) response containing both the group keying material and the individual keyin | ent) response containing both the group keying material and the individual keyin | |||
g material for the Client, or information enabling the Client to derive it.</t> | g material for the Client or information enabling the Client to derive it.</t> | |||
<t>The payload of the response is formatted as a CBOR map, which inclu | <t>The payload of the response is formatted as a CBOR map, which inclu | |||
des the same fields of the response defined in <xref target="gid-get"/>. In part | des the same fields of the response defined in <xref target="gid-get"/>. In part | |||
icular, the format for the group keying material is the same as defined in the r | icular, the format for the group keying material is the same as defined in the r | |||
esponse of <xref target="gid-get"/>. If the 'exp' parameter is included, the 'ex | esponse of <xref target="gid-get"/>. If the 'exp' parameter is included, the 'ex | |||
i' parameter MUST also be included. If the parameter 'exi' is included, its valu | i' parameter <bcp14>MUST</bcp14> also be included. If the parameter 'exi' is inc | |||
e specifies the residual lifetime of the group keying material from the current | luded, its value specifies the residual lifetime of the group keying material fr | |||
time at the KDC.</t> | om the current time at the KDC.</t> | |||
<t>The CBOR map can include additional parameters that specify the ind | <t>The CBOR map can include additional parameters that specify the ind | |||
ividual keying material for the Client. The specific format of individual keying | ividual keying material for the Client. The specific format of individual keying | |||
material for group members, or of the information to derive it, and correspondi | material for group members or of the information to derive such keying material | |||
ng CBOR label, MUST be specified in the application profile (REQ27) and register | <bcp14>MUST</bcp14> be defined in application profiles of this specification (< | |||
ed in <xref target="iana-reg"/>.</t> | xref target="req27" format="none">REQ27</xref>), together with the corresponding | |||
<t>Optionally, the KDC can make the sub-resource at /ace-group/GROUPNA | CBOR map key that has to be registered in the "ACE Groupcomm Parameters" regist | |||
ME/nodes/NODENAME also Observable <xref target="RFC7641"/> for the associated no | ry defined in <xref target="iana-reg"/>.</t> | |||
de. In case the KDC removes that node from the group without having been explici | <t>Optionally, the KDC can make the sub-resource at /ace-group/GROUPNA | |||
tly asked for it, this allows the KDC to send an unsolicited 4.04 (Not Found) re | ME/nodes/NODENAME also observable <xref target="RFC7641"/> for the associated no | |||
sponse to the node as a notification of eviction from the group (see <xref targe | de. In case the KDC removes that node from the group without having been explici | |||
t="sec-node-removal"/>).</t> | tly asked for it, this allows the KDC to send an unsolicited 4.04 (Not Found) re | |||
<t>Note that the node could have also been observing the resource at / | sponse to the node as a notification of eviction from the group (see <xref targe | |||
ace-group/GROUPNAME, in order to be informed of changes in the keying material. | t="sec-node-removal"/>).</t> | |||
In such a case, this method would result in largely overlapping notifications re | <t>Note that the node could have also been observing the resource at / | |||
ceived for the resource at /ace-group/GROUPNAME and the sub-resource at /ace-gro | ace-group/GROUPNAME in order to be informed of changes in the group keying mater | |||
up/GROUPNAME/nodes/NODENAME.</t> | ial. In such a case, this method would result in largely overlapping notificatio | |||
<t>In order to mitigate this, a node that supports the No-Response opt | ns received for the resource at /ace-group/GROUPNAME and the sub-resource at /ac | |||
ion <xref target="RFC7967"/> can use it when starting the observation of the sub | e-group/GROUPNAME/nodes/NODENAME.</t> | |||
-resource at /ace-group/GROUPNAME/nodes/NODENAME. In particular, the GET observa | <t>In order to mitigate this, a node that supports the CoAP No-Respons | |||
tion request can also include the No-Response option, with value set to 2 (Not i | e Option <xref target="RFC7967"/> can use it when starting the observation of th | |||
nterested in 2.xx responses).</t> | e sub-resource at /ace-group/GROUPNAME/nodes/NODENAME. In particular, the GET ob | |||
servation request can also include the No-Response option, with value set to 2 ( | ||||
Not interested in 2.xx responses).</t> | ||||
<section anchor="update-keys"> | <section anchor="update-keys"> | |||
<name>Retrieve Group and Individual Keying Material</name> | <name>Retrieve Group and Individual Keying Material</name> | |||
<t>When any of the following happens, a node MUST stop using the sto red group keying material to protect outgoing messages, and SHOULD stop using it to decrypt and verify incoming messages.</t> | <t>When any of the following happens, a node <bcp14>MUST</bcp14> sto p using the stored group keying material to protect outgoing messages and <bcp14 >SHOULD</bcp14> stop using it to decrypt and verify incoming messages.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>Upon expiration of the keying material, according to what is i ndicated by the KDC with the 'exp' and/or 'exi' parameter (e.g., in a Join Respo nse), or to a pre-configured value.</li> | <li>Upon expiration of the keying material, according to what is i ndicated by the KDC through the 'exp' and/or 'exi' parameter (e.g., in a Join Re sponse) or to a pre-configured value.</li> | |||
<li>Upon receiving a notification of revoked/renewed keying materi al from the KDC, possibly as part of an update of the keying material (rekeying) triggered by the KDC.</li> | <li>Upon receiving a notification of revoked/renewed keying materi al 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 the KDC, that the Client was not able t o receive or decrypt.</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 the KDC that the Client was not able to receive or decrypt.</li> | |||
</ul> | </ul> | |||
<t>In either case, if it wants to continue participating in the grou p communication, the Client has to request the latest keying material from the K DC. 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="nod e-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>In either case, if it wants to continue participating in the grou p communication, the Client has to request the latest keying material from the K DC. 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="nod e-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 set up, so that the Client sends a Key | <t>Note that policies can be set up so that the Client sends a Key D | |||
Distribution Request to the KDC only after a given number of received messages c | istribution Request to the KDC only after a given number of received messages co | |||
ould not be decrypted (because of failed decryption processing or inability to r | uld not be decrypted (because of failed decryption processing or the inability t | |||
etrieve the necessary keying material).</t> | o retrieve the necessary keying material).</t> | |||
<t>It is application dependent and pertaining to the particular mess | <t>It is application dependent and pertaining to the used secure mes | |||
age exchange (e.g., <xref target="I-D.ietf-core-oscore-groupcomm"/>) to set up t | sage exchange (e.g., <xref target="I-D.ietf-core-oscore-groupcomm"/>) to set up | |||
hese policies for instructing Clients to retain incoming messages and for how lo | these policies for instructing Clients to retain incoming messages and for how l | |||
ng (OPT11). This allows Clients to possibly decrypt such messages after getting | ong (<xref target="opt11" format="none">OPT11</xref>). This allows Clients to po | |||
updated keying material, rather than just consider them invalid messages to disc | ssibly decrypt such messages after getting updated keying material, rather than | |||
ard right away.</t> | just consider them invalid messages to discard right away.</t> | |||
<t>After having failed to decrypt messages from another group member | <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 | 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 suc | retrieving the same, latest group keying material that it already stores. In suc | |||
h a case, multiple failed decryptions might be due to the message sender and/or | h 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 | the KDC that have changed their authentication credential. Hence, the Client can | |||
retrieve such latest authentication credentials, by sending to the KDC an Authe | retrieve such latest authentication credentials by sending to the KDC an Authen | |||
ntication Credential Request (see <xref target="sec-key-retrieval"/> and <xref t | tication Credential Request (see Sections <xref target="sec-key-retrieval" forma | |||
arget="sec-key-retrieval-all"/>) and a KDC Authentication Credential Request (se | t="counter"/> and <xref target="sec-key-retrieval-all" format="counter"/>) and a | |||
e <xref target="kdc-pub-key"/>), respectively.</t> | KDC Authentication Credential Request (see <xref target="kdc-pub-key"/>), respe | |||
ctively.</t> | ||||
<t>The Client can also send to the KDC a Key Distribution Request wi thout having been triggered by a failed decryption of a message from another gro up member, if the Client wants to be sure that it currently stores the latest gr oup keying material. If that is the case, the Client will receive from the KDC t he same group keying material it already stores.</t> | <t>The Client can also send to the KDC a Key Distribution Request wi thout having been triggered by a failed decryption of a message from another gro up member, if the Client wants to be sure that it currently stores the latest gr oup keying material. If that is the case, the Client will receive from the KDC t he same group keying material it already stores.</t> | |||
<t><xref target="fig-key-redistr-req-resp"/> gives an overview of th e exchange described above, while <xref target="fig-key-redistr-req-resp-2"/> sh ows an example.</t> | <t><xref target="fig-key-redistr-req-resp"/> gives an overview of th e exchange described above, while <xref target="fig-key-redistr-req-resp-2"/> sh ows an example.</t> | |||
<figure anchor="fig-key-redistr-req-resp"> | <figure anchor="fig-key-redistr-req-resp"> | |||
<name>Message Flow of Key Distribution Request-Response</name> | <name>Message Flow of Key Distribution Request-Response</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client KDC | Client KDC | |||
| | | | | | |||
|------------------ Key Distribution Request: --------------->| | |------------------ Key Distribution Request: --------------->| | |||
| GET /ace-group/GROUPNAME/nodes/NODENAME | | | GET /ace-group/GROUPNAME/nodes/NODENAME | | |||
| | | | | | |||
skipping to change at line 1484 ¶ | skipping to change at line 1596 ¶ | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Uri-Path: "g1" | Uri-Path: "g1" | |||
Uri-Path: "nodes" | Uri-Path: "nodes" | |||
Uri-Path: "c101" | Uri-Path: "c101" | |||
Payload: - | Payload: - | |||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Content (Code=2.05) | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation, | Payload (in CBOR diagnostic notation, with "ind-key" being the | |||
with KEY and IND_KEY being CBOR byte strings, | profile-specified label for individual keying material): | |||
and "ind-key" being the profile-specified label | { | |||
for individual keying material): | / gkty / 7: 65600, | |||
{ "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY } | / key / 8: h'73657373696f6e6b6579', | |||
/ num / 9: 12, | ||||
"ind-key": h'fcae9023' | ||||
} | ||||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="node-put"> | <section anchor="node-put"> | |||
<name>PUT Handler</name> | <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 gro up.</t> | <t>The PUT handler processes requests from a Client that asks for new individual keying material, as required to process messages exchanged in the gro up.</t> | |||
<t>The handler expects a PUT request with empty payload.</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"/> an | <t>In addition to what is defined in <xref target="kdc-if-errors"/> an | |||
d at the beginning of <xref target="node-subresource"/>, the handler verifies th | d at the beginning of <xref target="node-subresource"/>, the handler verifies th | |||
at this operation is consistent with the set of roles that the Client has in the | at this operation is consistent with the set of roles that the Client has in the | |||
group (REQ11). If the verification fails, the KDC MUST reply with a 4.00 (Bad R | group (<xref target="req11" format="none">REQ11</xref>). If the verification fa | |||
equest) error response. The response MUST have Content-Format set to application | ils, the KDC <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) error response. | |||
/concise-problem-details+cbor and is formatted as defined in <xref target="kdc-i | The response <bcp14>MUST</bcp14> have Content-Format "application/concise-probl | |||
f-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the v | em-details+cbor" and is formatted as defined in <xref target="kdc-if-errors"/>. | |||
alue of the 'error-id' field MUST be set to 1 ("Request inconsistent with the c | Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the ' | |||
urrent roles").</t> | error-id' field <bcp14>MUST</bcp14> be set to 1 ("Request inconsistent with the | |||
<t>If the KDC is currently not able to serve this request, i.e., to ge | current roles").</t> | |||
nerate new individual keying material for the requesting Client, the KDC MUST re | <t>If the KDC is currently not able to serve this request, i.e., to ge | |||
ply with a 5.03 (Service Unavailable) error response. The response MUST have Con | nerate new individual keying material for the requesting Client, the KDC <bcp14> | |||
tent-Format set to application/concise-problem-details+cbor and is formatted as | MUST</bcp14> reply with a 5.03 (Service unavailable) error response. The respons | |||
defined in <xref target="kdc-if-errors"/>. Within the Custom Problem Detail entr | e <bcp14>MUST</bcp14> have Content-Format "application/concise-problem-details+c | |||
y 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 4 ("N | bor" and is formatted as defined in <xref target="kdc-if-errors"/>. Within the C | |||
o available node identifiers").</t> | ustom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' fi | |||
<t>If all verifications succeed, the handler replies with a 2.05 (Cont | eld <bcp14>MUST</bcp14> be set to 4 ("No available node identifiers").</t> | |||
ent) response containing newly generated, individual keying material for the Cli | <t>If all verifications succeed, the handler replies with a 2.04 (Chan | |||
ent. The payload of the response is formatted as a CBOR map. The specific format | ged) response containing newly generated individual keying material for the Clie | |||
of newly-generated individual keying material for group members, or of the info | nt. The payload of the response is formatted as a CBOR map. The specific format | |||
rmation to derive it, and corresponding CBOR label, MUST be specified in the app | of newly generated individual keying material for group members or of the inform | |||
lication profile (REQ27) and registered in <xref target="iana-reg"/>.</t> | ation to derive such keying material <bcp14>MUST</bcp14> be defined in applicati | |||
<t>The typical successful outcome consists in replying with newly gene | on profiles of this specification (<xref target="req27" format="none">REQ27</xre | |||
rated, individual keying material for the Client, as defined above. However, app | f>), together with the corresponding CBOR map key that has to be registered in t | |||
lication profiles of this specification MAY also extend this handler in order to | he "ACE Groupcomm Parameters" registry defined in <xref target="iana-reg"/>.</t> | |||
achieve different akin outcomes (OPT12), for instance:</t> | <t>The typical successful outcome consists in replying with newly gene | |||
rated individual keying material for the Client, as defined above. However, appl | ||||
ication profiles of this specification <bcp14>MAY</bcp14> also extend this handl | ||||
er in order to achieve different akin outcomes (<xref target="opt12" format="non | ||||
e">OPT12</xref>), for instance:</t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>Not providing the Client with newly generated, individual keying | <li>Not providing the Client with newly generated individual keying | |||
material, but rather rekeying the whole group, i.e., providing all the current | material, but rather rekeying the whole group, i.e., providing all the current g | |||
group members with newly generated group keying material.</li> | roup members with newly generated group keying material.</li> | |||
<li>Both providing the Client with newly generated, individual keyin | <li>Both providing the Client with newly generated individual keying | |||
g material, as well as rekeying the whole group, i.e., providing all the current | material, as well as rekeying the whole group, i.e., providing all the current | |||
group members with newly generated group keying material.</li> | group members with newly generated group keying material.</li> | |||
</ul> | </ul> | |||
<t>In either case, the handler may specify the new group keying materi | <t>In either case, the handler may specify the new group keying materi | |||
al as part of the 2.05 (Content) response.</t> | al as part of the 2.04 (Changed) response.</t> | |||
<t>Note that this handler is not intended to accommodate requests from | <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 a | a group member to trigger a group rekeying, whose scheduling and execution is a | |||
n exclusive prerogative of the KDC (see also related security considerations in | n exclusive prerogative of the KDC (also see related security considerations in | |||
<xref target="sec-cons-rekeying"/>).</t> | <xref target="sec-cons-rekeying"/>).</t> | |||
<section anchor="new-keys"> | <section anchor="new-keys"> | |||
<name>Request to Change Individual Keying Material</name> | <name>Request to Change Individual Keying Material</name> | |||
<t>A Client may ask the KDC for new, individual keying material. For | <t>A Client may ask the KDC for new individual keying material. For | |||
instance, this can be due to the expiration of such individual keying material, | instance, this can be due to the expiration of such individual keying material o | |||
or to the exhaustion of AEAD nonces, if an AEAD encryption algorithm is used fo | r to the exhaustion of Authenticated Encryption with Associated Data (AEAD) nonc | |||
r protecting communications in the group. An example of individual keying materi | es if an AEAD encryption algorithm is used for protecting communications in the | |||
al can simply be an individual encryption key associated with the Client. Hence, | group. An example of individual keying material can simply be an individual encr | |||
the Client may ask for a new individual encryption key, or for new input materi | yption key associated with the Client. Hence, the Client may ask for a new indiv | |||
al to derive it.</t> | idual encryption key or for new input material to derive it.</t> | |||
<t>To this end, the Client performs a Key Renewal Request-Response e | <t>To this end, the Client performs a Key Renewal Request-Response e | |||
xchange with the KDC, i.e., it sends a CoAP PUT request to the /ace-group/GROUPN | xchange with the KDC, i.e., it sends a CoAP PUT request to the /ace-group/GROUPN | |||
AME/nodes/NODENAME endpoint at the KDC, where GROUPNAME identifies the group and | AME/nodes/NODENAME endpoint at the KDC, which is formatted as defined in <xref | |||
NODENAME is its node name, and formatted as defined in <xref target="node-get"/ | target="node-get"/> and with the group identified by GROUPNAME.</t> | |||
>.</t> | ||||
<t><xref target="fig-renewal-req-resp"/> gives an overview of the ex change described above, while <xref target="fig-renewal-req-resp-2"/> shows an e xample.</t> | <t><xref target="fig-renewal-req-resp"/> gives an overview of the ex change described above, while <xref target="fig-renewal-req-resp-2"/> shows an e xample.</t> | |||
<figure anchor="fig-renewal-req-resp"> | <figure anchor="fig-renewal-req-resp"> | |||
<name>Message Flow of Key Renewal Request-Response</name> | <name>Message Flow of Key Renewal Request-Response</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client KDC | Client KDC | |||
| | | | | | |||
|---------------- Key Renewal Request: ---------------->| | |---------------- Key Renewal Request: ---------------->| | |||
| PUT /ace-group/GROUPNAME/nodes/NODENAME | | | PUT /ace-group/GROUPNAME/nodes/NODENAME | | |||
| | | | | | |||
|<-------- Key Renewal Response: 2.05 (Content) --------| | |<-------- Key Renewal Response: 2.04 (Changed) --------| | |||
| | | | | | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<figure anchor="fig-renewal-req-resp-2"> | <figure anchor="fig-renewal-req-resp-2"> | |||
<name>Example of Key Renewal Request-Response</name> | <name>Example of Key Renewal Request-Response</name> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Request: | Request: | |||
Header: PUT (Code=0.03) | Header: PUT (Code=0.03) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Uri-Path: "g1" | Uri-Path: "g1" | |||
Uri-Path: "nodes" | Uri-Path: "nodes" | |||
Uri-Path: "c101" | Uri-Path: "c101" | |||
Payload: - | Payload: - | |||
Response: | Response: | |||
Header: Content (Code=2.05) | Header: Changed (Code=2.04) | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation, with IND_KEY being a | Payload (in CBOR diagnostic notation, with "ind-key" being the | |||
CBOR byte string, and "ind-key" being the profile-specified | profile-specified label for individual keying material): | |||
label for individual keying material): | { | |||
{ "ind-key": IND_KEY } | "ind-key": h'b71acc28' | |||
} | ||||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>Note that there is a difference between the Key Renewal Request i n 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 as ks the KDC for the current group keying material together with the current indiv idual keying material.</t> | <t>Note that there is a difference between the Key Renewal Request i n 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 as ks the KDC for the current group keying material together with the current indiv idual keying material.</t> | |||
<t>As discussed in <xref target="node-put"/>, application profiles o f this specification may define alternative outcomes for the Key Renewal Request -Response exchange (OPT12), where the provisioning of new individual keying mate rial is replaced by or combined with the execution of a whole group rekeying.</t > | <t>As discussed in <xref target="node-put"/>, application profiles o f this specification may define alternative outcomes for the Key Renewal Request -Response exchange (<xref target="opt12" format="none">OPT12</xref>), where the provisioning of new individual keying material is replaced by or combined with t he execution of a whole group rekeying.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="node-delete"> | <section anchor="node-delete"> | |||
<name>DELETE Handler</name> | <name>DELETE Handler</name> | |||
<t>The DELETE handler removes the node identified by NODENAME from the group identified by GROUPNAME.</t> | <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 empty payload.</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"/>, t | <t>In addition to what is defined in <xref target="kdc-if-errors"/>, t | |||
he handler verifies that the Client is a current member of the group. If the ver | he handler verifies that the Client is a current member of the group. If the ver | |||
ification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The | ification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.03 (Forbidden) error | |||
response MUST have Content-Format set to application/concise-problem-details+cbo | response. The response <bcp14>MUST</bcp14> have Content-Format "application/con | |||
r and is formatted as defined in <xref target="kdc-if-errors"/>. Within the Cust | cise-problem-details+cbor" and is formatted as defined in <xref target="kdc-if-e | |||
om Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field | rrors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the valu | |||
MUST be set to 0 ("Operation permitted only to group members").</t> | e of the 'error-id' field <bcp14>MUST</bcp14> be set to 0 ("Operation permitted | |||
<t>If all verification succeeds, the handler performs the actions defi | only to group members").</t> | |||
ned in <xref target="sec-node-removal"/> and replies with a 2.02 (Deleted) respo | <t>If all verification succeeds, the handler performs the actions defi | |||
nse with empty payload.</t> | ned in <xref target="sec-node-removal"/> and replies with a 2.02 (Deleted) respo | |||
nse with an empty payload.</t> | ||||
<section anchor="ssec-group-leaving"> | <section anchor="ssec-group-leaving"> | |||
<name>Leave the Group</name> | <name>Leave the Group</name> | |||
<t>A Client can actively request to leave the group. In this case, t | <t>A Client can actively request to leave the group. In this case, t | |||
he Client sends a CoAP DELETE request to the endpoint /ace-group/GROUPNAME/nodes | he 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 n | /NODENAME at the KDC, where GROUPNAME identifies the group and NODENAME is the C | |||
ode name, formatted as defined in <xref target="node-delete"/></t> | lient's node name.</t> | |||
<t>Note that, after having left the group, the Client may wish to jo | <t>Note that, after having left the group, the Client may wish to jo | |||
in it again. Then, as long as the Client is still authorized to join the group, | in 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 to re-j | i.e., the associated access token is still valid, the Client can request to rejo | |||
oin the group directly to the KDC (see <xref target="ssec-key-distribution-excha | in the group directly to the KDC (see <xref target="ssec-key-distribution-exchan | |||
nge"/>), without having to retrieve a new access token from the AS.</t> | ge"/>) without having to retrieve a new access token from the AS.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="ace-groupgroupnamenodesnodenamecred"> | <section anchor="ace-groupgroupnamenodesnodenamecred"> | |||
<name>/ace-group/GROUPNAME/nodes/NODENAME/cred</name> | <name>/ace-group/GROUPNAME/nodes/NODENAME/cred</name> | |||
<t>This resource implements the POST handler.</t> | <t>This resource implements the POST handler.</t> | |||
<section anchor="node-pub-key-post"> | <section anchor="node-pub-key-post"> | |||
<name>POST Handler</name> | <name>POST Handler</name> | |||
<t>The POST handler is used to replace the stored authentication crede | <t>The POST handler is used to replace the stored authentication crede | |||
ntial of this Client (identified by NODENAME) with the one specified in the requ | ntial of this Client (identified by NODENAME) with the one specified in the requ | |||
est at the KDC, for the group identified by GROUPNAME.</t> | est at the KDC for the group identified by GROUPNAME.</t> | |||
<t>The handler expects a POST request with payload as specified in <xr | <t>The handler expects a POST request with the payload as specified in | |||
ef target="gid-post"/>, with the difference that it includes only the parameters | <xref target="gid-post"/>, with the difference that the payload includes only t | |||
'client_cred', 'cnonce', and 'client_cred_verify'.</t> | he parameters 'client_cred', 'cnonce', and 'client_cred_verify'.</t> | |||
<t>The PoP evidence included in the 'client_cred_verify' parameter is | <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 | computed in the same way considered in <xref target="gid-post"/> and defined by | |||
the specific application profile (REQ14), by using the following to build the Po | the specific application profile (<xref target="req14" format="none">REQ14</xref | |||
P input: i) the same scope entry specified by the Client in the 'scope' paramete | >) by using the following to build the PoP input: i) the same scope entry specif | |||
r of the latest Join Request that the Client sent to the KDC in order to join th | ied by the Client in the 'scope' parameter of the latest Join Request that the C | |||
e group identified by GROUPNAME; ii) the latest N_S value stored by the Client; | lient sent to the KDC in order to join the group identified by GROUPNAME; ii) th | |||
iii) a new N_C nonce generated by the Client and specified in the parameter 'cno | e latest N_S value stored by the Client; and iii) a new N_C nonce generated by t | |||
nce' of this request.</t> | he 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>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 is REQUIRED of application profiles to define the specific forma | <t>It is <bcp14>REQUIRED</bcp14> for application profiles to define th | |||
ts of authentication credentials that are acceptable to use in the group (REQ6). | e specific formats of authentication credentials that are acceptable to use in t | |||
</t> | he group (<xref target="req6" format="none">REQ6</xref>).</t> | |||
<t>In addition to what is defined in <xref target="kdc-if-errors"/> an | <t>In addition to what is defined in <xref target="kdc-if-errors"/> an | |||
d at the beginning of <xref target="node-subresource"/>, the handler verifies th | d at the beginning of <xref target="node-subresource"/>, the handler verifies th | |||
at this operation is consistent with the set of roles that the node has in the g | at this operation is consistent with the set of roles that the node has in the g | |||
roup. If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) er | roup. If the verification fails, the KDC <bcp14>MUST</bcp14> reply with a 4.00 ( | |||
ror response. The response MUST have Content-Format set to application/concise-p | Bad Request) error response. The response <bcp14>MUST</bcp14> have Content-Forma | |||
roblem-details+cbor and is formatted as defined in <xref target="kdc-if-errors"/ | t "application/concise-problem-details+cbor" and is formatted as defined in <xre | |||
>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of th | f target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcom | |||
e 'error-id' field MUST be set to 1 ("Request inconsistent with the current rol | m-error', the value of the 'error-id' field <bcp14>MUST</bcp14> be set to 1 ("R | |||
es").</t> | equest inconsistent with the current roles").</t> | |||
<t>If the KDC cannot retrieve the 'kdcchallenge' associated with this | <t>If the KDC cannot retrieve the 'kdcchallenge' associated with this | |||
Client (see <xref target="token-post"/>), the KDC MUST reply with a 4.00 (Bad Re | Client (see <xref target="token-post"/>), the KDC <bcp14>MUST</bcp14> reply with | |||
quest) error response, which MUST also have Content-Format application/ace-group | a 4.00 (Bad Request) error response, which <bcp14>MUST</bcp14> also have Conten | |||
comm+cbor. The payload of the error response is a CBOR map including a newly gen | t-Format "application/ace-groupcomm+cbor". The payload of the error response is | |||
erated 'kdcchallenge' value. This is specified in the 'kdcchallenge' parameter. | a CBOR map including the 'kdcchallenge' parameter, which specifies a newly gener | |||
In such a case the KDC MUST store the newly generated value as the 'kdcchallenge | ated 'kdcchallenge' value. In such a case, the KDC <bcp14>MUST</bcp14> store the | |||
' value associated with this Client, replacing the currently stored value (if an | newly generated value as the 'kdcchallenge' value associated with this Client, | |||
y).</t> | replacing the currently stored value (if any).</t> | |||
<t>Otherwise, the handler checks that the authentication credential sp | <t>Otherwise, the handler checks that the authentication credential sp | |||
ecified in the 'client_cred' field is valid for the group identified by GROUPNAM | ecified in the 'client_cred' field is valid for the group identified by GROUPNAM | |||
E. That is, the handler checks that the authentication credential is encoded acc | E. That is, the handler checks that the authentication credential is encoded acc | |||
ording to the format used in the group, is intended for the public key algorithm | ording 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 | used in the group, and is aligned with the possible associated parameters used | |||
in the group. If that cannot be successfully verified, the handler MUST reply wi | in the group. If that cannot be successfully verified, the handler <bcp14>MUST</ | |||
th a 4.00 (Bad Request) error response. The response MUST have Content-Format se | bcp14> reply with a 4.00 (Bad Request) error response. The response <bcp14>MUST< | |||
t to application/concise-problem-details+cbor and is formatted as defined in <xr | /bcp14> have Content-Format "application/concise-problem-details+cbor" and is f | |||
ef target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupco | ormatted as defined in <xref target="kdc-if-errors"/>. Within the Custom Problem | |||
mm-error', the value of the 'error-id' field MUST be set to 2 ("Authentication | Detail entry 'ace-groupcomm-error', the value of the 'error-id' field <bcp14>M | |||
credential incompatible with the group configuration").</t> | UST</bcp14> be set to 2 ("Authentication credential incompatible with the group | |||
<t>Otherwise, the handler verifies the PoP evidence contained in the ' | configuration").</t> | |||
client_cred_verify' field of the request, by using the authentication credential | <t>Otherwise, the handler verifies the PoP evidence conveyed in the 'c | |||
specified in the 'client_cred' field, as well as the same way considered in <xr | lient_cred_verify' parameter of the request, by using the authentication credent | |||
ef target="gid-post"/> and defined by the specific application profile (REQ14). | ial specified in the 'client_cred' parameter as well as the same way considered | |||
If the PoP evidence does not pass verification, the handler MUST reply with a 4. | in <xref target="gid-post"/> and defined by the specific application profile (<x | |||
00 (Bad Request) error response. The response MUST have Content-Format set to ap | ref target="req14" format="none">REQ14</xref>). If the PoP evidence does not pas | |||
plication/concise-problem-details+cbor and is formatted as defined in <xref targ | s verification, the handler <bcp14>MUST</bcp14> reply with a 4.00 (Bad Request) | |||
et="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-erro | error response. The response <bcp14>MUST</bcp14> have Content-Format "applicatio | |||
r', the value of the 'error-id' field MUST be set to 3 ("Invalid Proof-of-Posse | n/concise-problem-details+cbor" and is formatted as defined in <xref target="kdc | |||
ssion evidence").</t> | -if-errors"/>. Within the Custom Problem Detail entry 'ace-groupcomm-error', the | |||
value of the 'error-id' field <bcp14>MUST</bcp14> be set to 3 ("Invalid proof- | ||||
of-possession evidence").</t> | ||||
<t>If all verifications succeed, the handler performs the following ac tions.</t> | <t>If all verifications succeed, the handler performs the following ac tions.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The handler associates the authentication credential from the 'c | <li>The handler associates the authentication credential from the 'c | |||
lient_cred' field of the request with the node identifier NODENAME, as well as w | lient_cred' parameter of the request with the node identifier NODENAME, as well | |||
ith the access token associated with the node identified by NODENAME.</li> | as with the access token associated with the node identified by NODENAME.</li> | |||
<li>In the stored list of group members' authentication credentials | <li>In the stored list of group members' authentication credentials | |||
for the group identified by GROUPNAME, the handler replaces the authentication c | for the group identified by GROUPNAME, the handler replaces the authentication c | |||
redential of the node identified by NODENAME with the authentication credential | redential of the node identified by NODENAME with the authentication credential | |||
specified in the 'client_cred' field of the request.</li> | specified in the 'client_cred' parameter of the request.</li> | |||
</ul> | </ul> | |||
<t>Then, the handler replies with a 2.04 (Changed) response, which doe s not include a payload.</t> | <t>Then, the handler replies with a 2.04 (Changed) response, which doe s not include a payload.</t> | |||
<figure anchor="fig-client-cred-input-2"> | <figure anchor="fig-client-cred-input-2"> | |||
<name>Example of PoP input to compute 'client_cred_verify' using CBO R encoding</name> | <name>Example of PoP Input to Compute 'client_cred_verify' Using CBO R Encoding</name> | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
scope, N_S, and N_C expressed in CBOR diagnostic notation: | scope, N_S, and N_C expressed in CBOR diagnostic notation: | |||
scope = h'826667726f7570316673656e646572' | scope = h'826667726f7570316673656e646572' | |||
N_S = h'018a278f7faab55a' | N_S = h'018a278f7faab55a' | |||
N_C = h'0446baefc56111bf' | N_C = h'0446baefc56111bf' | |||
scope, N_S, and N_C as CBOR encoded byte strings: | scope, N_S, and N_C as CBOR encoded byte strings: | |||
scope = 0x4f826667726F7570316673656E646572 | scope = 0x4f826667726F7570316673656E646572 | |||
N_S = 0x48018a278f7faab55a | N_S = 0x48018a278f7faab55a | |||
N_C = 0x480446baefc56111bf | N_C = 0x480446baefc56111bf | |||
PoP input: | PoP input: | |||
0x4f 826667726f7570316673656e646572 | 0x4f 826667726f7570316673656e646572 | |||
48 018a278f7faab55a 48 0446baefc56111bf | 48 018a278f7faab55a 48 0446baefc56111bf | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<section anchor="update-pub-key"> | <section anchor="update-pub-key"> | |||
<name>Uploading an Authentication Credential</name> | <name>Uploading an Authentication Credential</name> | |||
<t>In case the KDC maintains the authentication credentials of group | <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 | members, a node in the group can contact the KDC to upload a new authentication | |||
credential to use in the group, and to replace the currently stored one.</t> | credential to use in the group and to replace the currently stored one.</t> | |||
<t>To this end, the Client performs an Authentication Credential Upd | <t>To this end, the Client performs an Authentication Credential Upd | |||
ate Request-Response exchange with the KDC, i.e., it sends a CoAP POST request t | ate Request-Response exchange with the KDC, i.e., it sends a CoAP POST request t | |||
o the /ace-group/GROUPNAME/nodes/NODENAME/cred endpoint at the KDC, where GROUPN | o the /ace-group/GROUPNAME/nodes/NODENAME/cred endpoint at the KDC, where GROUPN | |||
AME identifies the group and NODENAME is its node name.</t> | AME identifies the group and NODENAME is the Client's node name.</t> | |||
<t>The request is formatted as specified in <xref target="node-pub-k ey-post"/>.</t> | <t>The request is formatted as specified in <xref target="node-pub-k ey-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> | <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"> | <figure anchor="fig-pub-key-update-req-resp"> | |||
<name>Message Flow of Authentication Credential Update Request-Res ponse</name> | <name>Message Flow of Authentication Credential Update Request-Res ponse</name> | |||
<artwork align="center"><![CDATA[ | <artwork align="center"><![CDATA[ | |||
Client KDC | Client KDC | |||
| | | | | | |||
|----------- Authentication Credential Update Request: --------->| | |----------- Authentication Credential Update Request: --------->| | |||
| POST /ace-group/GROUPNAME/nodes/NODENAME/cred | | | POST /ace-group/GROUPNAME/nodes/NODENAME/cred | | |||
| | | | | | |||
skipping to change at line 1633 ¶ | skipping to change at line 1749 ¶ | |||
<artwork><![CDATA[ | <artwork><![CDATA[ | |||
Request: | Request: | |||
Header: POST (Code=0.02) | Header: POST (Code=0.02) | |||
Uri-Host: "kdc.example.com" | Uri-Host: "kdc.example.com" | |||
Uri-Path: "ace-group" | Uri-Path: "ace-group" | |||
Uri-Path: "g1" | Uri-Path: "g1" | |||
Uri-Path: "nodes" | Uri-Path: "nodes" | |||
Uri-Path: "c101" | Uri-Path: "c101" | |||
Uri-Path: "cred" | Uri-Path: "cred" | |||
Content-Format: "application/ace-groupcomm+cbor" | Content-Format: application/ace-groupcomm+cbor | |||
Payload (in CBOR diagnostic notation, with AUTH_CRED | Payload (in CBOR diagnostic notation): | |||
and POP_EVIDENCE being CBOR byte strings): | { | |||
{ "client_cred": AUTH_CRED, "cnonce": h'0446baefc56111bf', | / client_cred / 5: h'a2026008a101a501020241fc20012158 | |||
"client_cred_verify": POP_EVIDENCE } | 20bac5b11cad8f99f9c72b05cf4b9e26 | |||
d244dc189f745228255a219a86d6a09e | ||||
ff22582020138bf82dc1b6d562be0fa5 | ||||
4ab7804a3a64b6d72ccfed6b6fb6ed28 | ||||
bbfc117e', | ||||
/ cnonce / 6: h'0446baefc56111bf', | ||||
/ client_cred_verify / 24: h'e2aeafd40d69d19dfe6e52077c5d7ff4 | ||||
e408282cbefb5d06cbf414af2e19d982 | ||||
ac45ac98b8544c908b4507de1e90b717 | ||||
c3d34816fe926a2b98f53afd2fa0f30a' | ||||
} | ||||
Response: | Response: | |||
Header: Changed (Code=2.04) | Header: Changed (Code=2.04) | |||
Payload: - | Payload: - | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>Additionally, after updating its own authentication credential, a group member MAY send to the group a number of requests including an identifier of the updated authentication credential, to notify other group members that th ey have to retrieve it. How this is done depends on the group communication prot ocol used, and therefore is application profile specific (OPT13).</t> | <t>Additionally, after updating its own authentication credential, a group member <bcp14>MAY</bcp14> send to the group a number of requests, includi ng 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 co mmunication protocol used and therefore is application profile specific (<xref t arget="opt13" format="none">OPT13</xref>).</t> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="sec-node-removal"> | <section anchor="sec-node-removal"> | |||
<name>Removal of a Group Member</name> | <name>Removal of a Group Member</name> | |||
<t>A Client identified by NODENAME may be removed from a group identified | <t>A Client identified by NODENAME may be removed from a group identified | |||
by GROUPNAME where it is a member, for example due to the following reasons.</t> | by GROUPNAME where it is a member, for example, due to the following reasons.</t | |||
<ol spacing="normal" type="1"><li>The Client explicitly asks to leave the | > | |||
group, as defined in <xref target="ssec-group-leaving"/>.</li> | <ol spacing="normal" type="1"> | |||
<li>The node has been found compromised or is suspected so. The KDC is e | <li>The Client explicitly asks to leave the group, as defined in <xref ta | |||
xpected to determine that a group member has to be evicted either through its ow | rget="ssec-group-leaving"/>.</li> | |||
n means, or based on information that it obtains from a trusted source (e.g., an | <li>The node has been found compromised or is suspected so. The KDC is e | |||
Intrusion Detection System, or an issuer of authentication credentials). Additi | xpected to determine that a group member has to be evicted either through its ow | |||
onal mechanics, protocols, and interfaces at the KDC that can support this are o | n means or based on information that it obtains from a trusted source (e.g., an | |||
ut of the scope of this document.</li> | Intrusion Detection System or an issuer of authentication credentials). Addition | |||
al 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 rol es 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 Cli ent is still authorized.</li> | <li>The Client's authorization to be a group member with the current rol es 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 Cli ent is still authorized.</li> | |||
</ol> | </ol> | |||
<t>In either case, the KDC performs the following actions.</t> | <t>In all cases, the KDC performs the following actions.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The KDC removes the Client from the list of current members of the g roup. When doing so, the KDC deletes the currently stored value of 'clientchalle nge' for that Client, which was specified in the latest Join Request that the Cl ient sent to the KDC in order to join the group (see <xref target="gid-post"/>). </li> | <li>The KDC removes the Client from the list of current members of the g roup. When doing so, the KDC deletes the currently stored value of 'clientchalle nge' for that Client, which was specified in the latest Join Request that the Cl ient 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 d eletes the authentication credential of the removed Client, if it acts as a repo sitory of authentication credentials for group members.</li> | <li>In case of forced eviction, i.e., for cases 2 and 3 above, the KDC d eletes the authentication credential of the removed Client if it acts as a repos itory of authentication credentials for group members.</li> | |||
<li>If the removed Client is registered as an observer of the group-memb ership resource at /ace-group/GROUPNAME, the KDC removes the Client from the lis t of observers of that resource.</li> | <li>If the removed Client is registered as an observer of the group-memb ership resource at /ace-group/GROUPNAME, the KDC removes the Client from the lis t of observers of that resource.</li> | |||
<li> | <li> | |||
<t>If the sub-resource nodes/NODENAME was created for the removed Clie nt, the KDC deletes that sub-resource. </t> | <t>If the sub-resource /nodes/NODENAME was created for the removed Cli ent, the KDC deletes that sub-resource. </t> | |||
<t> | <t> | |||
In case of forced eviction, i.e., for cases 2 and 3 above, the KDC MAY explicitl y inform the removed Client, by means of the following methods. </t> | In case of forced eviction, i.e., for cases 2 and 3 above, the KDC <bcp14>MAY</b cp14> explicitly inform the removed Client by means of the following methods. < /t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>If the evicted Client implements the 'control_uri' resource spec ified in <xref target="gid-post"/>, the KDC sends a DELETE request, targeting th e URI specified in the 'control_uri' parameter of the Join Request (see <xref ta rget="gid-post"/>).</li> | <li>If the evicted Client implements the 'control_uri' resource (see <xref target="gid-post"/>), the KDC sends a DELETE request to that resource, ta rgeting the URI specified in the 'control_uri' parameter of the Join Request (se e <xref target="gid-post"/>).</li> | |||
<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 Observe option and indicates that the observed resource has been deleted (see < xref section="3.2" sectionFormat="of" target="RFC7641"/>). </t> | <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 Observe Option and indicates that the observed resource has been deleted (see < xref section="3.2" sectionFormat="of" target="RFC7641"/>). </t> | |||
<t> | <t> | |||
The response MUST 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' f ield MUST be set to 5 ("Group membership terminated").</t> | The response <bcp14>MUST</bcp14> have Content-Format "application/concise-proble m-details+cbor" and is formatted as defined in <xref target="kdc-if-errors"/>. W ithin the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'e rror-id' field <bcp14>MUST</bcp14> be set to 5 ("Group membership terminated"). </t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</li> | </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 KD C MUST generate new group keying material and securely distribute it to all the current group members except the leaving node (see <xref target="sec-group-rekey ing"/>).</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 KD C <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> | </ul> | |||
</section> | </section> | |||
<section anchor="sec-group-rekeying"> | <section anchor="sec-group-rekeying"> | |||
<name>Group Rekeying Process</name> | <name>Group Rekeying Process</name> | |||
<t>A group rekeying is started and driven by the KDC. The KDC is not inten | <t>A group rekeying is started and driven by the KDC. The KDC is not inten | |||
ded to accommodate explicit requests from group members to trigger a group rekey | ded to accommodate explicit requests from group members to trigger a group rekey | |||
ing. That is, the scheduling and execution of a group rekeying is an exclusive p | ing. That is, the scheduling and execution of a group rekeying is an exclusive p | |||
rerogative of the KDC. Reasons that can trigger a group rekeying are a change in | rerogative of the KDC. | |||
the group membership, the current group keying material approaching its expirat | Some reasons that can trigger a group rekeying include a change in the gro | |||
ion time, or a regularly scheduled update of the group keying material.</t> | up membership, the current group keying material approaching its expiration time | |||
<t>The KDC can perform a group rekeying before the current group keying ma | , or a regularly scheduled update of the group keying material.</t> | |||
terial expires, unless it is acceptable or there are reasons to temporarily paus | <t>The KDC can perform a group rekeying before the current group keying ma | |||
e secure communications in the group, following the expiration of the current ke | terial expires, unless it is acceptable or there are reasons to temporarily paus | |||
ying material. For example, a pause in the group communication might have been s | e secure communications in the group, following the expiration of the current ke | |||
cheduled to start anyway when the group keying material expires, e.g., to allow | ying material. For example, a pause in the group communication might have been s | |||
maintenance operations on the group members. As another example, the KDC might b | cheduled to start anyway when the group keying material expires, e.g., to allow | |||
e carrying out a verification that some group members are seemingly compromised | maintenance operations on the group members. As another example, the KDC might b | |||
and to be evicted, and this requires to be completed in order to appropriately d | e carrying out a verification that some group members are seemingly compromised | |||
efine and schedule the exact rekeying process to perform. As a result, the KDC c | and to be evicted, and this needs to be completed in order to appropriately defi | |||
ould delay the execution of the group rekeying.</t> | ne and schedule the exact rekeying process to perform. As a result, the KDC coul | |||
<t>The KDC MUST increment the version number NUM of the current keying mat | d delay the execution of the group rekeying.</t> | |||
erial, before distributing the newly generated keying material with version numb | <t>The KDC <bcp14>MUST</bcp14> increment the version number NUM of the cur | |||
er NUM+1 to the group. Once the group rekeying is completed, the KDC MUST delete | rent keying material before distributing the newly generated keying material wit | |||
the old keying material and SHOULD store the newly distributed keying material | h version number NUM+1 to the group. Once the group rekeying is completed, the K | |||
in persistent storage.</t> | DC <bcp14>MUST</bcp14> delete the old keying material and <bcp14>SHOULD</bcp14> | |||
<t>Distributing the new group keying material requires the KDC to send mul | store the newly distributed keying material in persistent storage.</t> | |||
tiple rekeying messages to the group members. Depending on the rekeying scheme u | <t>Distributing the new group keying material requires the KDC to send mul | |||
sed in the group and the reason that has triggered the rekeying process, each re | tiple rekeying messages to the group members. Depending on the rekeying scheme u | |||
keying message can be intended for one or multiple group members, hereafter refe | sed in the group and the reason that has triggered the rekeying process, each re | |||
rred to as target group members. The KDC MUST support at least the "Point-to-Poi | keying message can be intended for one or multiple group members, hereafter refe | |||
nt" group rekeying scheme in <xref target="point-to-point-rekeying"/> and MAY su | rred to as target group members. The KDC <bcp14>MUST</bcp14> support at least th | |||
pport additional ones.</t> | e "Point-to-Point" group rekeying scheme described in <xref target="point-to-poi | |||
<t>Each rekeying message MUST have Content-Format set to application/ace-g | nt-rekeying"/> and <bcp14>MAY</bcp14> support additional ones.</t> | |||
roupcomm+cbor and its payload formatted as a CBOR map, which MUST include at lea | <t>Each rekeying message <bcp14>MUST</bcp14> have Content-Format "applica | |||
st the information specified in the Key Distribution Response message (see <xref | tion/ace-groupcomm+cbor" and its payload is formatted as a CBOR map, which <bcp1 | |||
target="gid-get"/>), i.e., the parameters 'gkty', 'key', and 'num' defined in < | 4>MUST</bcp14> include at least the information specified in the Key Distributio | |||
xref target="gid-post"/>. The CBOR map SHOULD also include the parameters 'exp' | n Response message (see <xref target="gid-get"/>), i.e., the parameters 'gkty', | |||
and 'exi'. If the 'exp' parameter is included, the 'exi' parameter MUST also be | 'key', and 'num' defined in <xref target="gid-post"/>. The CBOR map <bcp14>SHOUL | |||
included. The CBOR map MAY include the parameter 'mgt_key_material' specifying n | D</bcp14> also include the parameters 'exp' and 'exi'. If the 'exp' parameter is | |||
ew administrative keying material for the target group members, if relevant for | included, the 'exi' parameter <bcp14>MUST</bcp14> also be included. The CBOR ma | |||
the used rekeying scheme.</t> | p <bcp14>MAY</bcp14> include the parameter 'mgt_key_material' to specify new adm | |||
<t>A rekeying message may include additional information, depending on the | inistrative keying material for the target group members if it is relevant for t | |||
rekeying scheme used in the group, the reason that has triggered the rekeying p | he used rekeying scheme.</t> | |||
rocess, and the specific target group members. In particular, if the group rekey | <t>A rekeying message may include additional information, depending on the | |||
ing is performed due to one or multiple Clients that have joined the group and t | rekeying scheme used in the group, the reason that has triggered the rekeying p | |||
he KDC acts as a repository of authentication credentials of the group members, | rocess, and the specific target group members. In particular, if the group rekey | |||
then a rekeying message MAY also include the authentication credentials that tho | ing is performed due to one or multiple Clients that have joined the group and t | |||
se Clients use in the group, together with the roles and node identifier that th | he KDC acts as a repository of authentication credentials of the group members, | |||
e corresponding Client has in the group. It is RECOMMENDED to specify this infor | then a rekeying message <bcp14>MAY</bcp14> also include the authentication crede | |||
mation by means of the parameters 'creds', 'peer_roles', and 'peer_identifiers', | ntials that those Clients use in the group, together with the roles and node ide | |||
like it is done in the Join Response message (see <xref target="gid-post"/>).</ | ntifier that each of such Clients has in the group. It is <bcp14>RECOMMENDED</bc | |||
t> | p14> to specify this information by means of the parameters 'creds', 'peer_roles | |||
<t>The complete format of a rekeying message, including the encoding and c | ', and 'peer_identifiers', like it is done in the Join Response message (see <xr | |||
ontent of the 'mgt_key_material' parameter, has to be defined in separate specif | ef target="gid-post"/>).</t> | |||
ications aimed at profiling the used rekeying scheme in the context of the used | <t>The complete format of a rekeying message, including the encoding and c | |||
application profile of this specification. As a particular case, an application | ontent of the 'mgt_key_material' parameter, has to be defined in separate specif | |||
profile of this specification MAY define additional information to include in re | ications aimed at profiling the used rekeying scheme in the context of the used | |||
keying messages for the "Point-to-Point" group rekeying scheme in <xref target=" | application profile of this specification. As a particular case, an application | |||
point-to-point-rekeying"/> (OPT14).</t> | profile of this specification <bcp14>MAY</bcp14> define additional information t | |||
<t>Consistently with the used group rekeying scheme, the actual delivery o | o include in rekeying messages for the "Point-to-Point" group rekeying scheme de | |||
f rekeying messages can occur through different approaches, as discussed in the | fined in <xref target="point-to-point-rekeying"/> (<xref target="opt14" format=" | |||
following <xref target="point-to-point-rekeying"/> and <xref target="one-to-many | none">OPT14</xref>).</t> | |||
-rekeying"/>.</t> | <t>Consistently with the used group rekeying scheme, the actual delivery o | |||
f rekeying messages can occur through different approaches, as discussed in Sect | ||||
ions <xref target="point-to-point-rekeying" format="counter"/> and <xref target= | ||||
"one-to-many-rekeying" format="counter"/>.</t> | ||||
<t>The possible, temporary misalignment of the keying material stored by t he 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> | <t>The possible, temporary misalignment of the keying material stored by t he 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"> | <section anchor="point-to-point-rekeying"> | |||
<name>Point-to-Point Group Rekeying</name> | <name>Point-to-Point Group Rekeying</name> | |||
<t>A point-to-point group rekeying consists in the KDC sending one indiv | <t>A point-to-point group rekeying consists in the KDC sending one indiv | |||
idual rekeying message to each target group member. In particular, the rekeying | idual rekeying message to each target group member. In particular, the rekeying | |||
message is protected by means of the security association between the KDC and th | message is protected by means of the secure communication association between th | |||
e target group member in question, as per the used application profile of this s | e KDC and the target group member in question, as per the used application profi | |||
pecification and the used transport profile of ACE.</t> | le of this specification and the used transport profile of ACE.</t> | |||
<t>This is the approach taken by the basic "Point-to-Point" group rekeyi | <t>This is the approach taken by the basic "Point-to-Point" group rekeyi | |||
ng scheme, that the KDC can explicitly signal in the Join Response (see <xref ta | ng scheme, which the KDC can explicitly indicate in the Join Response (see <xref | |||
rget="gid-post"/>), through the 'rekeying_scheme' parameter specifying the value | target="gid-post"/>), through the 'rekeying_scheme' parameter specifying the va | |||
0.</t> | lue 0.</t> | |||
<t>When taking this approach in the group identified by GROUPNAME, the K | <t>When taking this approach in the group identified by GROUPNAME, the K | |||
DC can practically deliver the rekeying messages to the target group members in | DC can practically deliver the rekeying messages to the target group members in | |||
different, co-existing ways.</t> | different, coexisting ways.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<t>The KDC SHOULD make the /ace-group/GROUPNAME resource Observable <xref target="RFC7641"/>. Thus, upon performing a group rekeying, the KDC can di stribute the new group keying material through individual notification responses sent to the target group members that are also observing that resource. </t> | <t>The KDC <bcp14>SHOULD</bcp14> make the /ace-group/GROUPNAME resou rce observable <xref target="RFC7641"/>. Thus, upon performing a group rekeying, the KDC can distribute the new group keying material through individual notific ation responses sent to the target group members that are also observing that re source. </t> | |||
<t> | <t> | |||
In case the KDC deletes the group (and thus deletes the /ace-group/GROUPNAME res ource), relying on CoAP Observe as discussed above also allows the KDC to send a n unsolicited 4.04 (Not Found) response to each observer group member, as a noti fication of group termination. The response MUST have Content-Format set to appl ication/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' field MUST be set to 6 ("Group deleted").</t> | In case the KDC deletes the group (and thus deletes the /ace-group/GROUPNAME res ource), relying on CoAP Observe as discussed above also allows the KDC to send a n unsolicited 4.04 (Not Found) response to each observer group member as a notif ication of group termination. The response <bcp14>MUST</bcp14> have Content-Form at "application/concise-problem-details+cbor" and is formatted as defined in <xr ef target="kdc-if-errors"/>. Within the Custom Problem Detail entry 'ace-groupco mm-error', the value of the 'error-id' field <bcp14>MUST</bcp14> be set to 6 (" Group deleted").</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>If a target group member specified a URI in the 'control_uri' par ameter 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 s ending a unicast POST request to that URI. </t> | <t>If a target group member specified a URI in the 'control_uri' par ameter 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 s ending a unicast POST request to that URI. </t> | |||
<t> | <t> | |||
A Client that does not plan to observe the /ace-group/GROUPNAME resource at the KDC SHOULD provide a URI in the 'control_uri' parameter of the Join Request upon joining the group.</t> | A Client that does not plan to observe the /ace-group/GROUPNAME resource at the KDC <bcp14>SHOULD</bcp14> specify a URI in the 'control_uri' parameter of the Jo in Request upon joining the group.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<t>If the KDC has to send a rekeying message to a target group member, b | <t>If the KDC has to send a rekeying message to a target group member, b | |||
ut this did not include the 'control_uri' parameter in the Join Request and is n | ut this did not include the 'control_uri' parameter in the Join Request and is n | |||
ot a registered observer for the /ace-group/GROUPNAME resource, then that target | ot 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, | group member will not be able to participate in the group rekeying. Later on, a | |||
after having repeatedly failed to successfully exchange secure messages in the g | fter having repeatedly failed to successfully exchange secure messages in the gr | |||
roup, that group member can retrieve the current group keying material from the | oup, that group member can retrieve the current group keying material from the K | |||
KDC, by sending a GET request to /ace-group/GROUPNAME or /ace-group/GROUPNAME/no | DC, by sending a GET request to the /ace-group/GROUPNAME or /ace-group/GROUPNAME | |||
des/NODENAME (see <xref target="gid-get"/> and <xref target="node-get"/>, respec | /nodes/NODENAME resource at the KDC (see Sections <xref target="gid-get" format= | |||
tively).</t> | "counter"/> and <xref target="node-get" format="counter"/>, respectively).</t> | |||
<t><xref target="fig-rekeying-example-1"/> provides an example of point- | <t><xref target="fig-rekeying-example-1"/> provides an example of point- | |||
to-point group rekeying. In particular, the example makes the following assumpti | to-point group rekeying. In particular, the example makes the following assumpti | |||
ons.</t> | ons:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The group currently consists of four group members, namely C1, C2, C3, and C4.</li> | <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, with url-path "grp-rek".</li> | <li>Each group member, when joining the group, provided the KDC with a URI in the 'control_uri' parameter with url-path "grp-rek".</li> | |||
<li>Before the group rekeying is performed, the keying material used i n the group has version number num=5.</li> | <li>Before the group rekeying is performed, the keying material used i n the group has version number num=5.</li> | |||
<li>The KDC performs the group rekeying in such a way to evict the gro up member C3, which has been found to be compromised.</li> | <li>The KDC performs the group rekeying in such a way to evict the gro up member C3, which has been found to be compromised.</li> | |||
</ul> | </ul> | |||
<t>In the example, the KDC individually rekeys the group members intende d to remain in the group (i.e., C1, C2, and C4), by means of one rekeying messag e each.</t> | <t>In the example, the KDC individually rekeys the group members intende d to remain in the group (i.e., C1, C2, and C4) by means of one rekeying message each.</t> | |||
<figure anchor="fig-rekeying-example-1"> | <figure anchor="fig-rekeying-example-1"> | |||
<name>Example of Message Exchanges for a Point-to-Point Group Rekeying </name> | <name>Example of Message Exchanges for a Point-to-Point Group Rekeying </name> | |||
<artset> | <artset> | |||
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="384" width="560" viewBox="0 0 560 384" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px"> | <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" viewBox="0 0 700 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 32,32 L 32,64" fill="none" stroke="black"/> | |||
<path d="M 40,256 L 40,288" 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 80,72 L 80,208" fill="none" stroke="black"/> | |||
<path d="M 112,256 L 112,288" 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 184,256 L 184,288" fill="none" stroke="black"/> | |||
<path d="M 224,72 L 224,208" 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 256,256 L 256,288" fill="none" stroke="black"/> | |||
<path d="M 328,256 L 328,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 400,256 L 400,288" fill="none" stroke="black"/> | |||
<path d="M 480,256 L 480,288" fill="none" stroke="black"/> | <path d="M 480,256 L 480,288" fill="none" stroke="black"/> | |||
skipping to change at line 1805 ¶ | skipping to change at line 1933 ¶ | |||
| | | | | | | | |||
v v v | v v v | |||
/grp-rek /grp-rek /grp-rek /grp-rek | /grp-rek /grp-rek /grp-rek /grp-rek | |||
.--------. .--------. .--------. .--------. | .--------. .--------. .--------. .--------. | |||
| C1 | | C2 | | C3 | | C4 | | | C1 | | C2 | | C3 | | C4 | | |||
'--------' '--------' '--------' '--------' | '--------' '--------' '--------' '--------' | |||
[TO BE EVICTED] | [TO BE EVICTED] | |||
| | | | | | |||
\____________ Stored group keying material (num=5) _____________/ | \____________ Stored group keying material (num=5) _____________/ | |||
]]></artwork> | ]]></artwork> | |||
</artset> | </artset> | |||
</figure> | </figure> | |||
</section> | </section> | |||
<section anchor="one-to-many-rekeying"> | <section anchor="one-to-many-rekeying"> | |||
<name>One-to-Many Group Rekeying</name> | <name>One-to-Many Group Rekeying</name> | |||
<t>This section provides high-level recommendations on how the KDC can r | <t>This section provides high-level recommendations on how the KDC can r | |||
ekey a group by means of a more efficient and scalable group rekeying scheme, e. | ekey a group by means of a more efficient and scalable group rekeying scheme, e. | |||
g., <xref target="RFC2093"/><xref target="RFC2094"/><xref target="RFC2627"/>. Th | g., <xref target="RFC2093"/>, <xref target="RFC2094"/>, and <xref target="RFC262 | |||
at is, each rekeying message might be, and likely is, intended for multiple targ | 7"/>. That is, each rekeying message might be, and likely is, intended for multi | |||
et group members, and thus can be delivered to the whole group, although possibl | ple target group members, and thus can be delivered to the whole group, although | |||
e to decrypt only for the actual target group members.</t> | possible to decrypt only for the actual target group members.</t> | |||
<t>This yields an overall lower number of rekeying messages, thus potent | <t>This yields an overall lower number of rekeying messages, thus potent | |||
ially reducing the overall time required to rekey the group. On the other hand, | ially 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 | it requires the KDC to provide and use additional administrative keying material | |||
to protect the rekeying messages, and to additionally sign them to ensure sourc | to protect the rekeying messages and to additionally sign them to ensure source | |||
e authentication (see <xref target="one-to-many-rekeying-protection"/>).</t> | authentication (see <xref target="one-to-many-rekeying-protection"/>).</t> | |||
<t>Compared to a group rekeying performed in a point-to-point fashion (s | <t>Compared to a group rekeying performed in a point-to-point fashion (s | |||
ee <xref target="point-to-point-rekeying"/>), a one-to-many group rekeying typic | ee <xref target="point-to-point-rekeying"/>), a one-to-many group rekeying typic | |||
ally pays off in large-scale groups, due to the reduced time for completing the | ally pays off in large-scale groups due to the reduced time for completing the r | |||
rekeying, a more efficient utilization of network resources, and a reduced perfo | ekeying, a more efficient utilization of network resources, and a reduced perfor | |||
rmance overhead at the KDC. To different extents, it also requires individual gr | mance overhead at the KDC. To different extents, it also requires individual gro | |||
oup members to locally perform additional operations, in order to handle the adm | up members to locally perform additional operations in order to handle the admin | |||
inistrative keying material and verify source authentication of rekeying message | istrative keying material and verify source authentication of rekeying messages. | |||
s. Therefore, one-to-many group rekeying schemes and their employment ought to e | Therefore, one-to-many group rekeying schemes and their employment ought to ens | |||
nsure that the experienced performance overhead on the group members remains bea | ure that the experienced performance overhead on the group members also remains | |||
rable also for resource-constrained devices.</t> | bearable for resource-constrained devices.</t> | |||
<t>The exact set of rekeying messages to send, their content and format, | <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 o | the administrative keying material to use to protect them, as well as the set o | |||
f target group members depend on the specific group rekeying scheme, and are typ | f target group members depend on the specific group rekeying scheme and are typi | |||
ically affected by the reason that has triggered the group rekeying. Details abo | cally affected by the reason that has triggered the group rekeying. Details abou | |||
ut the data content and format of rekeying messages have to be defined by separa | t the data content and format of rekeying messages have to be defined by separat | |||
te documents profiling the use of the group rekeying scheme, in the context of t | e documents profiling the use of the group rekeying scheme in the context of the | |||
he used application profile of this specification.</t> | used application profile of this specification.</t> | |||
<t>When one of these group rekeying schemes is used, the KDC provides a | <t>When one of these group rekeying schemes is used, the KDC provides re | |||
number of related information to a Client joining the group in the Join Response | lated information to a Client joining the group in the Join Response message (se | |||
message (see <xref target="gid-post"/>). In particular, 'rekeying_scheme' ident | e <xref target="gid-post"/>). In particular, the 'rekeying_scheme' parameter ind | |||
ifies the rekeying scheme used in the group (if no default can be assumed); 'con | icates the rekeying scheme used in the group (if no default scheme can be assume | |||
trol_group_uri', if present, specifies a URI whose addressing information is, e. | d); the 'control_group_uri' parameter, if present, specifies a URI whose address | |||
g., a multicast IP address, and where the KDC will send the rekeying messages fo | ing information is, e.g., a multicast IP address where the KDC will send the rek | |||
r that group by reaching all the group members; 'mgt_key_material' specifies a s | eying messages for that group as intended to reach all the group members; and th | |||
ubset of the administrative keying material intended for that particular joining | e 'mgt_key_material' parameter specifies a subset of the administrative keying m | |||
Client to have, as used to protect the rekeying messages sent to the group when | aterial intended for that particular joining Client to have, as used to protect | |||
intended also to that joining Client.</t> | the rekeying messages sent to the group when also intended for that joining Clie | |||
<t>Rekeying messages can be protected at the application layer, by using | nt.</t> | |||
COSE and the administrative keying material as prescribed by the specific group | <t>Rekeying messages can be protected at the application layer by using | |||
rekeying scheme (see <xref target="one-to-many-rekeying-protection"/>). After t | COSE <xref target="RFC9052"/> and the administrative keying material as prescrib | |||
hat, the delivery of protected rekeying messages to the intended target group me | ed by the specific group rekeying scheme (see <xref target="one-to-many-rekeying | |||
mbers can occur in different ways, such as the following ones.</t> | -protection"/>). After that, the delivery of protected rekeying messages to the | |||
<ul spacing="normal"> | intended target group members can occur in different ways, such as the following | |||
<li> | ones.</t> | |||
<t>Over multicast - In this case, the KDC simply sends a rekeying me | <dl newline="false" spacing="normal"> | |||
ssage as a CoAP request addressed to the URI specified in the 'control_group_uri | <dt>Over multicast -</dt> | |||
' parameter of the Join Response (see <xref target="gid-post"/>). </t> | <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 t | ||||
he Join Response (see <xref target="gid-post"/>). </t> | ||||
<t> | <t> | |||
If a particular rekeying message is intended for a single target group member, t | If a particular rekeying message is intended for a single target group member, t | |||
he KDC may alternatively protect the message using the security association with | he KDC may alternatively protect the message using the secure communication asso | |||
that group member, and deliver the message like when using the "Point-to-Point" | ciation with that group member and deliver the message like when using the "Poin | |||
group rekeying scheme (see <xref target="point-to-point-rekeying"/>).</t> | t-to-Point" group rekeying scheme (see <xref target="point-to-point-rekeying"/>) | |||
</li> | .</t></dd> | |||
<li> | <dt>Through a pub-sub communication model -</dt> | |||
<t>Through a pub-sub communication model - In this case, the KDC act | <dd><t>In this case, the KDC acts as a publisher and publishes each rekeying mes | |||
s as a publisher and publishes each rekeying message to a specific "rekeying top | sage to a specific "rekeying topic", which is associated with the group and is h | |||
ic", which is associated with the group and is hosted at a broker server. Follow | osted at a Broker server. Following their group joining, the group members subsc | |||
ing their group joining, the group members subscribe to the rekeying topic at th | ribe to the rekeying topic at the Broker, thus receiving the group rekeying mess | |||
e broker, thus receiving the group rekeying messages as they are published by th | ages as they are published by the KDC. </t> | |||
e KDC. </t> | ||||
<t> | <t> | |||
In order to make such message delivery more efficient, the rekeying topic associ ated 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 membe rs during the rekeying process, as possibly aligned to a similar organization of the administrative keying material (e.g., a key hierarchy). </t> | In order to make such message delivery more efficient, the rekeying topic associ ated 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 membe rs during the rekeying process as possibly aligned to a similar organization of the administrative keying material (e.g., a key hierarchy). </t> | |||
<t> | <t> | |||
The setup of rekeying topics at the broker as well as the discovery of the topic | The setup of rekeying topics at the Broker as well as the discovery of the topic | |||
s at the broker for group members are application specific. A possible way is fo | s at the Broker for group members are application specific. A possible way is fo | |||
r the KDC to provide such information in the Join Response message (see <xref ta | r the KDC to provide such information in the Join Response message (see <xref ta | |||
rget="gid-post"/>), by means of a new parameter analogous to 'control_group_uri' | rget="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 s | and specifying the URI(s) of the rekeying topic(s) that a group member has to su | |||
ubscribe to at the broker.</t> | bscribe to at the Broker.</t></dd> | |||
</li> | </dl> | |||
</ul> | <t>Regardless of the specifically used delivery method, the group rekeyi | |||
<t>Regardless of the specifically used delivery method, the group rekeyi | ng scheme can perform a possible rollover of the administrative keying material | |||
ng scheme can perform a possible roll-over of the administrative keying material | through the same sent rekeying messages. Actually, such a rollover occurs every | |||
through the same sent rekeying messages. Actually, such a roll-over occurs ever | time a group rekeying is performed upon the leaving of group members, which have | |||
y time a group rekeying is performed upon the leaving of group members, which ha | to be excluded from future communications in the group.</t> | |||
ve to be excluded from future communications in the group.</t> | <t>From a high-level point of view, each group member stores only a subs | |||
<t>From a high level point of view, each group member stores only a subs | et of the overall administrative keying material, which is obtained upon joining | |||
et of the overall administrative keying material, obtained upon joining the grou | the group. Then, when a group rekeying occurs:</t> | |||
p. Then, when a group rekeying occurs:</t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>Each rekeying message is protected by using a (most convenient) ke | <li>Each rekeying message is protected by using a (most convenient) ke | |||
y from the administrative keying material such that: i) the used key is not stor | y from the administrative keying material such that: i) the used key is not stor | |||
ed by any node leaving the group, i.e., the key is safe to use and does not have | ed by any node leaving the group, i.e., the key is safe to use and does not have | |||
to be renewed; and ii) the used key is stored by all the target group members, | to be renewed; and ii) the used key is stored by all the target group members t | |||
that indeed have to be provided with new group keying material to protect commun | hat indeed have to be provided with new group keying material to protect communi | |||
ications in the group.</li> | cations in the group.</li> | |||
<li>Each rekeying message includes not only the new group keying mater | <li>Each rekeying message includes not only the new group keying mater | |||
ial intended for all the rekeyed group members, but also any new administrative | ial intended for all the rekeyed group members but also any new administrative k | |||
keys that: i) are pertaining to and supposed to be stored by the target group me | eys that: i) are pertaining to and supposed to be stored by the target group mem | |||
mbers; and ii) had to be updated since leaving group members store the previous | bers; and ii) had to be updated because leaving group members do store the previ | |||
version.</li> | ous version.</li> | |||
</ul> | </ul> | |||
<t>Further details depend on the specific rekeying scheme used in the gr oup.</t> | <t>Further details depend on the specific rekeying scheme used in the gr oup.</t> | |||
<t><xref target="fig-rekeying-example-2"/> provides an example of one-to -many group rekeying over multicast. In particular, the example makes the follow ing assumptions.</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 foll owing assumptions:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The group currently consists of four group members, namely C1, C2, C3, and C4.</li> | <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, with url-path "grp-rek".</li> | <li>Each group member, when joining the group, provided the KDC with a URI in the 'control_uri' 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>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 i n the group has version number num=5.</li> | <li>Before the group rekeying is performed, the keying material used i n the group has version number num=5.</li> | |||
<li>The KDC performs the group rekeying in such a way to evict the gro up member C3, which has been found to be compromised.</li> | <li>The KDC performs the group rekeying in such a way to evict the gro up member C3, which has been found to be compromised.</li> | |||
</ul> | </ul> | |||
<t>In the example, the KDC determines that the most convenient way to pe rform a group rekeying that evicts C3 is as follows.</t> | <t>In the example, the KDC determines that the most convenient way to pe rform a group rekeying that evicts C3 is as follows.</t> | |||
<t>First, the KDC sends one rekeying message over multicast, to the mult | <t>First, the KDC sends one rekeying message over multicast to the multi | |||
icast address MULT_ADDR and the url-path "grp-mrek". In the figure, the message | cast address MULT_ADDR and the url-path "grp-mrek". In the figure, the message i | |||
is denoted with dashed lines. The message is protected with a non-compromised ke | s denoted with solid arrows. The message is protected with a non-compromised key | |||
y from the administrative keying material that only C1 and C2 store. Therefore, | from the administrative keying material that only C1 and C2 store. Therefore, e | |||
even though all the group members receive this message, only C1 and C2 are able | ven though all the group members receive this message, only C1 and C2 are able t | |||
to decrypt it. The message includes: the new group keying material with version | o decrypt it. The message includes: the new group keying material with version n | |||
number num=6; and new keys from the administrative keying material to replace th | umber num=6 and new keys from the administrative keying material to replace thos | |||
ose stored by the group members C1, C2, and C3.</t> | e stored by the group members C1, C2, and C3.</t> | |||
<t>After that, the KDC sends one rekeying message addressed individually | <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 | 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 betwee | dotted arrow. The message is protected with the secure association shared betwe | |||
n C4 and the KDC. The message includes: the new group keying material with versi | en C4 and the KDC. The message includes: the new group keying material with vers | |||
on number num=6; and new keys from the administrative keying material to replace | ion number num=6 and new keys from the administrative keying material to replace | |||
those stored by both C4 and C3.</t> | those stored by both C4 and C3.</t> | |||
<figure anchor="fig-rekeying-example-2"> | <figure anchor="fig-rekeying-example-2"> | |||
<name>Example of Message Exchanges for a One-to-Many Group Rekeying</n ame> | <name>Example of Message Exchanges for a One-to-Many Group Rekeying</n ame> | |||
<artset> | <artset> | |||
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="400" width="576" viewBox="0 0 576 400" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px"> | <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" viewBox="0 0 700 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,32 L 8,64" fill="none" stroke="black"/> | |||
<path d="M 8,288 L 8,320" 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 56,192 L 56,240" fill="none" stroke="black"/> | |||
<path d="M 80,288 L 80,320" 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 112,288 L 112,320" fill="none" stroke="black"/> | |||
<path d="M 160,192 L 160,240" 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 184,288 L 184,320" fill="none" stroke="black"/> | |||
<path d="M 216,288 L 216,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 272,72 L 272,240" fill="none" stroke="black"/> | |||
<path d="M 312,288 L 312,320" fill="none" stroke="black"/> | <path d="M 312,288 L 312,320" fill="none" stroke="black"/> | |||
skipping to change at line 1971 ¶ | skipping to change at line 2096 ¶ | |||
| | | | : | | | | | : | |||
v v v v v | v v v v v | |||
/grp-mrek /grp-mrek /grp-mrek /grp-mrek /grp-rek | /grp-mrek /grp-mrek /grp-mrek /grp-mrek /grp-rek | |||
.--------. .--------. .-----------. .---------------------------. | .--------. .--------. .-----------. .---------------------------. | |||
| C1 | | C2 | | C3 | | C4 | | | C1 | | C2 | | C3 | | C4 | | |||
'--------' '--------' '-----------' '---------------------------' | '--------' '--------' '-----------' '---------------------------' | |||
[TO BE EVICTED] | [TO BE EVICTED] | |||
| | | | | | |||
\_______________ Stored group keying material (num=5) ________________/ | \_______________ Stored group keying material (num=5) ________________/ | |||
]]></artwork> | ]]></artwork> | |||
</artset> | </artset> | |||
</figure> | </figure> | |||
<section anchor="one-to-many-rekeying-protection"> | <section anchor="one-to-many-rekeying-protection"> | |||
<name>Protection of Rekeying Messages</name> | <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>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 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 Respon se (see <xref target="gid-post"/>).</t> | <t>The method assumes that the following holds for the administrative keying material specified in the 'mgt_key_material' parameter of the Join Respon se (see <xref target="gid-post"/>).</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The encryption algorithm SHOULD be the same one used to protect communications in the group.</li> | <li>The encryption algorithm <bcp14>SHOULD</bcp14> be the same one u sed to protect communications in the group.</li> | |||
<li>The included symmetric encryption keys are accompanied by a corr esponding and unique key identifier assigned by the KDC.</li> | <li>The included symmetric encryption keys are accompanied by a corr esponding and unique key identifier assigned by the KDC.</li> | |||
<li>A Base IV is also included, with the same size of the AEAD nonce considered by the encryption algorithm to use.</li> | <li>A Base IV is also included with the same size of the AEAD nonce considered by the encryption algorithm to use.</li> | |||
</ul> | </ul> | |||
<t>First, the KDC computes a COSE_Encrypt0 object as follows.</t> | <t>First, the KDC computes a COSE_Encrypt0 object as follows.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The encryption key to use is selected from the administrative ke ying material, as defined by the rekeying scheme used in the group.</li> | <li>The encryption key to use is selected from the administrative ke ying 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>The plaintext is the actual data content of the present rekeying | |||
.</li> | message.</li> | |||
<li>The Additional Authenticated Data (AAD) is empty, unless otherwi | <li>The Additional Authenticated Data (AAD) is empty unless otherwis | |||
se specified by separate documents profiling the use of the group rekeying schem | e specified by separate documents profiling the use of the group rekeying scheme | |||
e.</li> | .</li> | |||
<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 ma y define alternative ways to compute the AEAD nonce. </t> | <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 ma y define alternative ways to compute the AEAD nonce. </t> | |||
<t> | <t> | |||
The KDC considers the following values. </t> | The KDC considers the following values. </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>COUNT, as a 2-byte unsigned integer associated with the used | <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 reke | encryption key. Its value is set to 0 when starting to perform a new group reke | |||
ying instance, and is incremented after each use of the encryption key.</li> | ying instance and is incremented after each use of the encryption key.</li> | |||
<li>NEW_NUM, as the version number of the new group keying mater | <li>NEW_NUM: as the version number of the new group keying mater | |||
ial to distribute in this rekeying instance, left-padded with zeros to exactly N | ial to distribute in this rekeying instance, left-padded with zeros to exactly N | |||
ONCE_SIZE - 2 bytes.</li> | ONCE_SIZE - 2 bytes.</li> | |||
</ul> | </ul> | |||
<t> | <t> | |||
Then, the KDC computes a Partial IV as the byte string concatenation of COUNT an d NEW_NUM, in this order. Finally, the AEAD nonce is computed as the XOR between the Base IV and the Partial IV. </t> | Then, the KDC computes a Partial IV as the byte string concatenation of COUNT an d NEW_NUM in this order. Finally, the AEAD nonce is computed as the XOR between the Base IV and the Partial IV. </t> | |||
<t> | <t> | |||
In order to comply with the security requirements of AEAD encryption algorithms, the KDC MUST NOT reuse the same pair (AEAD encryption key, AEAD nonce). For exa mple, this includes not using the same encryption key from the administrative ke ying material more than 2^16 times during the same rekeying instance.</t> | In order to comply with the security requirements of AEAD encryption algorithms, the KDC <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 ad ministrative keying material more than 2<sup>16</sup> times during the same reke ying instance.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>The protected header of the COSE_Encrypt0 object MUST include t he following parameters. </t> | <t>The protected header of the COSE_Encrypt0 object <bcp14>MUST</b cp14> include the following parameters. </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'alg', specifying the used encryption algorithm.</li> | <li>'alg': specifying the used encryption algorithm.</li> | |||
<li>'kid', specifying the identifier of the encryption key from | <li>'kid': specifying the identifier of the encryption key from | |||
the administrative keying material used to protect this rekeying message.</li> | the administrative keying material used to protect the present rekeying message. | |||
</li> | ||||
</ul> | </ul> | |||
</li> | </li> | |||
<li>The unprotected header of the COSE_Encrypt0 object MUST include the 'Partial IV' parameter, with value the Partial IV computed above.</li> | <li>The unprotected header of the COSE_Encrypt0 object <bcp14>MUST</ bcp14> include the 'Partial IV' parameter with the value of the Partial IV compu ted above.</li> | |||
</ul> | </ul> | |||
<t>In order to ensure source authentication, each rekeying message pro tected with the administrative keying material MUST be signed by the KDC. To thi s end, the KDC computes a countersignature of the COSE_Encrypt0 object, as descr ibed in Sections <xref target="RFC9338" section="3.2" sectionFormat="bare"/> and <xref target="RFC9338" section="3.3" sectionFormat="bare"/> of <xref target="RF C9338"/>. In particular, the following applies when computing the countersignatu re.</t> | <t>In order to ensure source authentication, each rekeying message pro tected with the administrative keying material <bcp14>MUST</bcp14> be signed by the KDC. To this end, the KDC computes a countersignature of the COSE_Encrypt0 o bject, as described in Sections <xref target="RFC9338" section="3.2" sectionForm at="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"> | <ul spacing="normal"> | |||
<li>The Countersign_structure contains the context text string "Coun terSignature0".</li> | <li>The Countersign_structure contains the context text string "Coun terSignature0".</li> | |||
<li>The private key of the KDC is used as signing key.</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 payload is the ciphertext of the COSE_Encrypt0 object.</li> | |||
<li>The Additional Authenticated Data (AAD) is empty, unless otherwi se specified by separate documents profiling the use of a group rekeying scheme. </li> | <li>The Additional Authenticated Data (AAD) is empty, unless otherwi se specified by separate documents profiling the use of a group rekeying scheme. </li> | |||
<li>The protected header of the signing object MUST include the para meter 'alg', specifying the used signature algorithm.</li> | <li>The protected header of the signing object <bcp14>MUST</bcp14> i nclude the parameter 'alg', which specifies the used signature algorithm.</li> | |||
</ul> | </ul> | |||
<t>If source authentication of messages exchanged in the group is also | <t>If the source authentication of messages exchanged in the group is | |||
ensured by means of signatures, then rekeying messages MUST be signed using the | also ensured by means of signatures, then rekeying messages <bcp14>MUST</bcp14> | |||
same signature algorithm and related parameters. Also, the KDC's authentication | be signed using the same signature algorithm and related parameters. Also, the K | |||
credential including the public key to use for signature verification MUST be p | DC's authentication credential including the public key to use for signature ver | |||
rovided in the Join Response through the 'kdc_cred' parameter, together with the | ification <bcp14>MUST</bcp14> be provided in the Join Response through the 'kdc_ | |||
corresponding proof-of-possession (PoP) evidence in the 'kdc_cred_verify' param | cred' parameter, together with the corresponding proof-of-possession (PoP) evide | |||
eter.</t> | nce in the 'kdc_cred_verify' parameter.</t> | |||
<t>If source authentication of messages exchanged in the group is not | <t>If source authentication of messages exchanged in the group is not | |||
ensured by means of signatures, then the administrative keying material conveyed | 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 | in the 'mgt_key_material' parameter of the Join Response sent by KDC (see <xref | |||
target="gid-post"/>) MUST also comprise a KDC's authentication credential inclu | target="gid-post"/>) <bcp14>MUST</bcp14> also comprise a KDC's authentication c | |||
ding the public key to use for signature verification, together with a correspon | redential including the public key to use for signature verification, together w | |||
ding PoP evidence. Within the 'mgt_key_material' parameter, it is RECOMMENDED to | ith the corresponding PoP evidence. Within the 'mgt_key_material' parameter, it | |||
specify this information by using the same format and encoding used for the par | is <bcp14>RECOMMENDED</bcp14> to specify this information by using the same form | |||
ameters 'kdc_cred', 'kdc_nonce', and 'kdc_cred_verify' in the Join Response. It | at and encoding used for the parameters 'kdc_cred', 'kdc_nonce', and 'kdc_cred_v | |||
is up to separate documents profiling the use of the group rekeying scheme to sp | erify' in the Join Response. It is up to separate documents profiling the use of | |||
ecify such details.</t> | 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>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> | <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> | </section> | |||
<section anchor="sec-misalignment-keying-material"> | <section anchor="sec-misalignment-keying-material"> | |||
<name>Misalignment of Group Keying Material</name> | <name>Misalignment of Group Keying Material</name> | |||
<t>A group member can receive a message shortly after the group has been | <t>A group member can receive a message shortly after the group has been | |||
rekeyed, and new keying material has been distributed by the KDC. In the follow | rekeyed and new keying material has been distributed by the KDC. In the followi | |||
ing two cases, this may result in misaligned keying material between the group m | ng two cases, this may result in misaligned keying material between the group me | |||
embers.</t> | mbers.</t> | |||
<t>In the first case, the sender protects a message using the old group | <t>In the first case, the sender protects a message using the old group | |||
keying material. However, the recipient receives the message after having receiv | keying material. However, the recipient receives the message after having receiv | |||
ed the new group keying material, hence not being able to correctly process it. | ed the new group keying material, hence it is not able to correctly process the | |||
A possible way to limit the impact of this issue is to preserve the old, recent | message. A possible way to limit the impact of this issue is to preserve the old | |||
group keying material for a maximum amount of time defined by the application, d | , retained group keying material for a maximum amount of time defined by the app | |||
uring which it is used solely for processing incoming messages. By doing so, the | lication, during which such group keying material is used solely for processing | |||
recipient can still temporarily process received messages also by using the old | incoming messages. By doing so, the recipient can still temporarily process rece | |||
, retained group keying material. Note that a former (compromised) group member | ived messages also by using the old, retained group keying material. Note that a | |||
can take advantage of this by sending messages protected with the old, retained | former (compromised) group member can take advantage of this by sending message | |||
group keying material. Therefore, a conservative application policy should not a | s protected with the old, retained group keying material. Therefore, a conservat | |||
dmit the storage of old group keying material. Eventually, the sender will have | ive application policy should not admit the storage of old group keying material | |||
obtained the new group keying material too, and can possibly re-send the message | . Eventually, the sender will have obtained the new group keying material too an | |||
protected with such keying material.</t> | d can possibly resend the message protected with such keying material.</t> | |||
<t>In the second case, the sender protects a message using the new group | <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 | keying material, but the recipient receives that message before having received | |||
the new group keying material. Therefore, the recipient would not be able to co | the new group keying material. Therefore, the recipient will not be able to cor | |||
rrectly process the message and hence discards it. If the recipient receives the | rectly process the message and hence will discard it. If the recipient receives | |||
new group keying material shortly after that and the application at the sender | the new group keying material shortly after that and the application at the send | |||
endpoint performs retransmissions, the former will still be able to receive and | er endpoint performs retransmissions, the former will still be able to receive a | |||
correctly process the message. In any case, the recipient should actively ask th | nd correctly process the message. In any case, the recipient should actively ask | |||
e KDC for the latest group keying material according to an application-defined p | the KDC for the latest group keying material according to an application-define | |||
olicy, for instance after a given number of unsuccessfully decrypted incoming me | d policy, for instance, after a given number of unsuccessfully decrypted incomin | |||
ssages.</t> | g messages.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="sec-extended-scope"> | <section anchor="sec-extended-scope"> | |||
<name>Extended Scope Format</name> | <name>Extended Scope Format</name> | |||
<t>This section defines an extended format of binary encoded scope, which additionally specifies the semantics used to express the same access control inf ormation from the corresponding original scope.</t> | <t>This section defines an extended format of binary-encoded scope, which additionally specifies the semantics used to express the same access control inf ormation 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, als o in case the Resource Server runs multiple applications or application profiles that involve different scope semantics.</t> | <t>As also discussed in <xref target="ssec-authorization-response"/>, this enables a Resource Server to unambiguously process a received access token, als o 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 access to | <t>The extended format is intended only for the 'scope' claim of access to | |||
kens, for the cases where the claim takes as value a CBOR byte string. That is, | kens for the cases where the claim takes a CBOR byte string as the value. That i | |||
the extended format does not apply to the 'scope' parameter included in ACE mess | s, the extended format does not apply to the 'scope' parameter included in ACE m | |||
ages, i.e., the Authorization Request and Authorization Response exchanged betwe | essages, i.e., the Authorization Request and Authorization Response exchanged be | |||
en the Client and the Authorization Server (see Sections <xref target="RFC9200" | tween the Client and the Authorization Server (see Sections <xref target="RFC920 | |||
section="5.8.1" sectionFormat="bare"/> and <xref target="RFC9200" section="5.8.2 | 0" section="5.8.1" sectionFormat="bare"/> and <xref target="RFC9200" section="5. | |||
" sectionFormat="bare"/> of <xref target="RFC9200"/>), the AS Request Creation H | 8.2" sectionFormat="bare"/> of <xref target="RFC9200"/>), the AS Request Creatio | |||
ints message from the Resource Server (see <xref section="5.3" sectionFormat="of | n Hints message from the Resource Server (see <xref section="5.3" sectionFormat= | |||
" target="RFC9200"/>), and the Introspection Response from the Authorization Ser | "of" target="RFC9200"/>), and the Introspection Response from the Authorization | |||
ver (see <xref section="5.9.2" sectionFormat="of" target="RFC9200"/>).</t> | Server (see <xref section="5.9.2" sectionFormat="of" target="RFC9200"/>).</t> | |||
<t>The value of the 'scope' claim following the extended format is compose | <t>The value of the 'scope' claim following the extended format is compose | |||
d as follows. Given the original scope using a semantics SEM and encoded as a CB | d as follows. Given the original scope using semantics SEM and encoded as a CBOR | |||
OR byte string, the corresponding extended scope consists of the same CBOR byte | byte string, the corresponding extended scope consists of the same CBOR byte st | |||
string enclosed by a CBOR tag <xref target="RFC8949"/>, whose tag number identif | ring enclosed by a CBOR tag <xref target="RFC8949"/>, whose tag number identifie | |||
ies the semantics SEM.</t> | s the semantics SEM.</t> | |||
<t>The resulting tagged CBOR byte string is used as value of the 'scope' c | <t>The resulting tagged CBOR byte string is used as the value of the 'scop | |||
laim of the access token.</t> | e' claim of the access token.</t> | |||
<t><xref target="cddl-ex-0-ext"/> and <xref target="cddl-ex-ext"/> build o | <t>Figures <xref target="cddl-ex-0-ext" format="counter"/> and <xref targe | |||
n the examples in <xref target="ssec-authorization-response"/>, and show the cor | t="cddl-ex-ext" format="counter"/> build on the examples in <xref target="ssec-a | |||
responding extended scopes.</t> | uthorization-request"/> and show the corresponding extended scopes.</t> | |||
<figure anchor="cddl-ex-0-ext"> | <figure anchor="cddl-ex-0-ext"> | |||
<name>Example CDDL definition of scope, using the default Authorization Information Format</name> | <name>Example of Extended scope Using AIF</name> | |||
<sourcecode type="CDDL"><![CDATA[ | <sourcecode type="CDDL"><![CDATA[ | |||
;# include rfc9237 | ;# include rfc9237 | |||
gname = tstr | gname = tstr | |||
permissions = uint .bits roles | permissions = uint .bits roles | |||
roles = &( | roles = &( | |||
Requester: 1, | Requester: 1, | |||
Responder: 2, | Responder: 2, | |||
Monitor: 3, | Monitor: 3, | |||
Verifier: 4 | Verifier: 4 | |||
) | ) | |||
scope_entries = AIF-Generic<gname, permissions> | scope_entries = AIF-Generic<gname, permissions> | |||
scope = bstr .cbor scope_entries | scope = bstr .cbor scope_entries | |||
extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope) | extended_scope = #6.<TAG_FOR_THIS_SEMANTICS>(scope) | |||
TAG_FOR_THIS_SEMANTICS = uint | ||||
]]></sourcecode> | ]]></sourcecode> | |||
</figure> | </figure> | |||
<figure anchor="cddl-ex-ext"> | <figure anchor="cddl-ex-ext"> | |||
<name>CDDL definition of scope, using as example group name encoded as t str and role as tstr</name> | <name>Example of Extended scope Using the Textual Format, with the Role Identifiers Encoded as Text Strings</name> | |||
<sourcecode type="CDDL"><![CDATA[ | <sourcecode type="CDDL"><![CDATA[ | |||
gname = tstr | gname = tstr | |||
role = tstr | role = tstr | |||
scope_entry = [ gname , ? ( role / [ 2*role ] ) ] | scope_entry = [ gname , ? ( role / [ 2*role ] ) ] | |||
scope_entries = [ * scope_entry ] | scope_entries = [ * scope_entry ] | |||
scope = bstr .cbor scope_entries | scope = bstr .cbor scope_entries | |||
extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope) | extended_scope = #6.<TAG_FOR_THIS_SEMANTICS>(scope) | |||
TAG_FOR_THIS_SEMANTICS = uint | ||||
]]></sourcecode> | ]]></sourcecode> | |||
</figure> | </figure> | |||
<t>The usage of the extended scope format is not limited to application pr | <t>The usage of the extended scope format is not limited to application pr | |||
ofiles of this specification or to applications based on group communication. Ra | ofiles of this specification or to applications based on group communication. Ra | |||
ther, it is generally applicable to any application and application profile wher | ther, it is generally applicable to any application and application profile wher | |||
e access control information in the access token is expressed as a binary encode | e access control information in the access token is expressed as a binary-encode | |||
d scope.</t> | d scope.</t> | |||
<t>Applications and application profiles using the extended format of scop | <t>Applications and application profiles using the extended format of scop | |||
e have to specify which CBOR tag from <xref target="CBOR.Tags"/> is used for ide | e have to specify which CBOR tag from <xref target="CBOR.Tags"/> is used for ide | |||
ntifying the scope semantics, or to register a new CBOR tag if a suitable one do | ntifying the scope semantics or to register a new CBOR tag if a suitable one doe | |||
es not exist already (REQ28). In case there is an already existing, suitable CBO | s not exist already (<xref target="req28" format="none">REQ28</xref>). In case t | |||
R tag, a new CBOR tag should not be registered in order to avoid codepoint squat | here is an already existing, suitable CBOR tag, a new CBOR tag should not be reg | |||
ting.</t> | istered in order to avoid code point squatting.</t> | |||
<t>If the binary encoded scope uses a semantics associated with a register | <t>If the binary-encoded scope uses semantics associated with a registered | |||
ed CoAP Content-Format <xref target="RFC7252"/><xref target="CoAP.Content.Format | CoAP Content-Format <xref target="RFC7252"/> <xref target="CoAP.Content.Formats | |||
s"/>, then a suitable CBOR tag associated with that CoAP Content-Format would al | "/>, then a suitable CBOR tag associated with that CoAP Content-Format would alr | |||
ready be registered, as defined in <xref section="4.3" sectionFormat="of" target | eady be registered, as defined in <xref section="4.3" sectionFormat="of" target= | |||
="RFC9277"/>.</t> | "RFC9277"/>.</t> | |||
<t>This is especially relevant when the binary encoded scope uses the AIF | <t>This is especially relevant when the binary encoded scope uses AIF. Tha | |||
format. That is, it is expected that the definition of an AIF specific data mode | t is, it is expected that the definition of an AIF-specific data model comes tog | |||
l comes together with the registration of CoAP Content-Formats for the relevant | ether with the registration of CoAP Content-Formats for the relevant combination | |||
combinations of its Toid and Tperm values. As discussed above, this yields the a | s of its Toid and Tperm values. As discussed above, this yields the automatic re | |||
utomatic registration of the CBOR tags associated with those CoAP Content-Format | gistration of the CBOR tags associated with those CoAP Content-Formats.</t> | |||
s.</t> | ||||
</section> | </section> | |||
<section anchor="params"> | <section anchor="params"> | |||
<name>ACE Groupcomm Parameters</name> | <name>ACE Groupcomm Parameters</name> | |||
<t>This specification defines a number of parameters used during the secon | <t>This specification defines a number of parameters used during the secon | |||
d part of the message exchange, after the exchange of Token Transfer Request and | d phase of the key provisioning process, i.e., after the exchange after the exch | |||
Response. The table below summarizes them, and specifies the CBOR key to use in | ange of Token Transfer Request and Response. The table below summarizes them and | |||
stead of the full descriptive name.</t> | specifies the CBOR map keys to use instead of the full descriptive names.</t> | |||
<t>Note that the media type application/ace-groupcomm+cbor MUST be used wh | <t>Note that the media type "application/ace-groupcomm+cbor" <bcp14>MUST</ | |||
en these parameters are transported in the respective message fields.</t> | bcp14> be used when these parameters are transported in the respective CBOR map | |||
<figure anchor="fig-ACE-Groupcomm-Parameters"> | entries.</t> | |||
<table anchor="fig-ACE-Groupcomm-Parameters"> | ||||
<name>ACE Groupcomm Parameters</name> | <name>ACE Groupcomm Parameters</name> | |||
<artwork align="center"><![CDATA[ | <thead> | |||
+-----------------------+------+---------------------+------------+ | <tr> | |||
| Name | CBOR | CBOR Type | Reference | | <th>Name</th> | |||
| | Key | | | | <th>CBOR Key</th> | |||
+-----------------------+------+---------------------+------------+ | <th>CBOR Type</th> | |||
| gid | 0 | array | [RFC-XXXX] | | <th>Reference</th> | |||
+-----------------------+------+---------------------+------------+ | </tr> | |||
| gname | 1 | array of tstr | [RFC-XXXX] | | </thead> | |||
+-----------------------+------+---------------------+------------+ | <tbody> | |||
| guri | 2 | array of tstr | [RFC-XXXX] | | <tr> | |||
+-----------------------+------+---------------------+------------+ | ||||
| scope | 3 | bstr | [RFC-XXXX] | | <td>gid</td> | |||
+-----------------------+------+---------------------+------------+ | <td>0</td> | |||
| get_creds | 4 | array / | [RFC-XXXX] | | <td>array</td> | |||
| | | Simple value "null" | | | <td>RFC 9594</td> | |||
+-----------------------+------+---------------------+------------+ | </tr><tr> | |||
| client_cred | 5 | bstr | [RFC-XXXX] | | ||||
+-----------------------+------+---------------------+------------+ | <td>gname</td> | |||
| cnonce | 6 | bstr | [RFC-XXXX] | | <td>1</td> | |||
+-----------------------+------+---------------------+------------+ | <td>array of tstr</td> | |||
| client_cred_verify | 24 | bstr | [RFC-XXXX] | | <td>RFC 9594</td> | |||
+-----------------------+------+---------------------+------------+ | </tr><tr> | |||
| creds_repo | 25 | tstr | [RFC-XXXX] | | ||||
+-----------------------+------+---------------------+------------+ | <td>guri</td> | |||
| control_uri | 26 | tstr | [RFC-XXXX] | | <td>2</td> | |||
+-----------------------+------+---------------------+------------+ | <td>array of tstr</td> | |||
| gkty | 7 | int / tstr | [RFC-XXXX] | | <td>RFC 9594</td> | |||
+-----------------------+------+---------------------+------------+ | </tr><tr> | |||
| key | 8 | See the "ACE | [RFC-XXXX] | | ||||
| | | Groupcomm Key | | | <td>scope</td> | |||
| | | Types" registry | | | <td>3</td> | |||
+-----------------------+------+---------------------+------------+ | <td>bstr</td> | |||
| num | 9 | int | [RFC-XXXX] | | <td>RFC 9594</td> | |||
+-----------------------+------+---------------------+------------+ | </tr><tr> | |||
| ace_groupcomm_profile | 10 | int | [RFC-XXXX] | | ||||
+-----------------------+------+---------------------+------------+ | <td>get_creds</td> | |||
| exp | 11 | uint | [RFC-XXXX] | | <td>4</td> | |||
+-----------------------+------+---------------------+------------+ | <td>Null or array</td> | |||
| exi | 12 | uint | [RFC-XXXX] | | <td>RFC 9594</td> | |||
+-----------------------+------+---------------------+------------+ | </tr><tr> | |||
| creds | 13 | array | [RFC-XXXX] | | ||||
+-----------------------+------+---------------------+------------+ | <td>client_cred</td> | |||
| peer_roles | 14 | array | [RFC-XXXX] | | <td>5</td> | |||
+-----------------------+------+---------------------+------------+ | <td>bstr</td> | |||
| peer_identifiers | 15 | array | [RFC-XXXX] | | <td>RFC 9594</td> | |||
+-----------------------+------+---------------------+------------+ | </tr><tr> | |||
| group_policies | 16 | map | [RFC-XXXX] | | ||||
+-----------------------+------+---------------------+------------+ | <td>cnonce</td> | |||
| kdc_cred | 17 | bstr | [RFC-XXXX] | | <td>6</td> | |||
+-----------------------+------+---------------------+------------+ | <td>bstr</td> | |||
| kdc_nonce | 18 | bstr | [RFC-XXXX] | | <td>RFC 9594</td> | |||
+-----------------------+------+---------------------+------------+ | </tr><tr> | |||
| kdc_cred_verify | 19 | bstr | [RFC-XXXX] | | ||||
+-----------------------+------+---------------------+------------+ | <td>gkty</td> | |||
| rekeying_scheme | 20 | int | [RFC-XXXX] | | <td>7</td> | |||
+-----------------------+------+---------------------+------------+ | <td>int or tstr</td> | |||
| mgt_key_material | 27 | bstr | [RFC-XXXX] | | <td>RFC 9594</td> | |||
+-----------------------+------+---------------------+------------+ | </tr><tr> | |||
| control_group_uri | 28 | tstr | [RFC-XXXX] | | ||||
+-----------------------+------+---------------------+------------+ | <td>key</td> | |||
| sign_info | 29 | array / | [RFC-XXXX] | | <td>8</td> | |||
| | | Simple value "null" | | | <td>See the "ACE Groupcomm Key Types" registry</td> | |||
+-----------------------+------+---------------------+------------+ | <td>RFC 9594</td> | |||
| kdcchallenge | 30 | bstr | [RFC-XXXX] | | </tr><tr> | |||
+-----------------------+------+---------------------+------------+ | ||||
]]></artwork> | <td>num</td> | |||
</figure> | <td>9</td> | |||
<t>Note to RFC Editor: In <xref target="fig-ACE-Groupcomm-Parameters"/>, p | <td>int</td> | |||
lease replace all occurrences of "[RFC-XXXX]" with the RFC number of this specif | <td>RFC 9594</td> | |||
ication and delete this paragraph.</t> | </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>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>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>Null or array</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 Cli ent can support only a subset of such parameters, depending on the roles it expe cts to take in the joined groups or on other conditions defined in application p rofiles of this specification.</t> | <t>The KDC is expected to support all the parameters above. Instead, a Cli ent can support only a subset of such parameters, depending on the roles it expe cts to take in the joined groups or on other conditions defined in application p rofiles of this specification.</t> | |||
<t>In the following, the parameters are categorized according to the suppo rt expected by Clients. That is, a Client that supports a parameter is able to: i) use and specify it in a request message to the KDC; and ii) understand and pr ocess it if specified in a response message from the KDC. It is REQUIRED of appl ication profiles of this specification to sort their newly defined parameters ac cording to the same categorization (REQ29).</t> | <t>In the following, the parameters are categorized according to the suppo rt expected by Clients. That is, a Client that supports a parameter is able to: i) use and specify it in a request message to the KDC; and ii) understand and pr ocess it if specified in a response message from the KDC. It is <bcp14>REQUIRED< /bcp14> of application profiles of this specification to sort their newly define d parameters according to the same categorization (<xref target="req29" format=" none">REQ29</xref>).</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 wel l as what is defined in the used application profile of this specification.</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 wel l as what is defined in the used application profile of this specification.</t> | |||
<t>A Client MUST support the following parameters.</t> | ||||
<t>A Client <bcp14>MUST</bcp14> support the following parameters.</t> | ||||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'scope', 'cnonce', 'gkty', 'key', 'num', 'exp', 'exi', 'gid', 'gname | <li>'scope'</li> | |||
', 'guri', 'creds', 'peer_identifiers', 'ace_groupcomm_profile', 'control_uri', | <li>'cnonce'</li> | |||
'rekeying_scheme'.</li> | <li>'gkty'</li> | |||
<li>'key'</li> | ||||
<li>'num'</li> | ||||
<li>'exp'</li> | ||||
<li>'exi'</li> | ||||
<li>'gid'</li> | ||||
<li>'gname'</li> | ||||
<li>'guri'</li> | ||||
<li>'creds'</li> | ||||
<li>'peer_identifiers'</li> | ||||
<li>'ace_groupcomm_profile'</li> | ||||
<li>'control_uri'</li> | ||||
<li>'rekeying_scheme'</li> | ||||
</ul> | </ul> | |||
<t>A Client SHOULD support the following parameter.</t> | <t>A Client <bcp14>SHOULD</bcp14> support the following parameter.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<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 <xre f 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> | <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 <xre f 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> | </ul> | |||
<t>The following conditional parameters are relevant only if specific cond itions hold. It is REQUIRED of application profiles of this specification to def ine whether Clients must, should, or may support these parameters, and under whi ch circumstances (REQ30).</t> | <t>The following conditional parameters are relevant only if specific cond itions hold. It is <bcp14>REQUIRED</bcp14> of application profiles of this speci fication to define whether Clients must, should, or may support these parameters and under which circumstances (<xref target="req30" format="none">REQ30</xref>) .</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>'client_cred' and 'client_cred_verify'. These parameters are relevan | <li>'client_cred' and 'client_cred_verify': These parameters are relevan | |||
t for a Client that has an authentication credential to use in a joined group.</ | t for a Client that has an authentication credential to use in a joined group.</ | |||
li> | li> | |||
<li>'kdcchallenge'. This parameter is relevant for a Client that has an | <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 | 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" | token to the KDC through a Token Transfer Request (see <xref target="token-post" | |||
/>).</li> | />).</li> | |||
<li>'creds_repo'. This parameter is relevant for a Client that has an au | <li>'creds_repo': This parameter is relevant for a Client that has an au | |||
thentication credential to use in a joined group and that makes it available fro | thentication credential to use in a joined group and that makes it available fro | |||
m a key repository different than the KDC.</li> | m a key repository different than the KDC.</li> | |||
<li>'group_policies'. This parameter is relevant for a Client that is in | <li>'group_policies': This parameter is relevant for a Client that is in | |||
terested in the specific policies used in a group, but it does not know them or | terested 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> | cannot become aware of them before joining that group.</li> | |||
<li>'peer_roles'. This parameter is relevant for a Client that has to kn | <li>'peer_roles': This parameter is relevant for a Client that has to kn | |||
ow about the roles of other group members, especially when retrieving and handli | ow about the roles of other group members, especially when retrieving and handli | |||
ng their corresponding authentication credentials.</li> | ng their corresponding authentication credentials.</li> | |||
<li>'kdc_nonce', 'kdc_cred', 'kdc_cred_verify'. These parameters are rel | <li>'kdc_nonce', 'kdc_cred', and 'kdc_cred_verify': These parameters are | |||
evant for a Client that joins a group for which, as per the used application pro | relevant for a Client that joins a group for which, as per the used application | |||
file of this specification, the KDC has an associated authentication credential | profile of this specification, the KDC has an associated authentication credent | |||
and this is required for the correct group operation.</li> | ial and this is required for the correct group operation.</li> | |||
<li>'mgt_key_material'. This parameter is relevant for a Client that sup | <li>'mgt_key_material': This parameter is relevant for a Client that sup | |||
ports an advanced rekeying scheme possibly used in the group, such as based on o | ports an advanced rekeying scheme possibly used in the group, such as based on o | |||
ne-to-many rekeying messages sent over IP multicast.</li> | ne-to-many rekeying messages sent over IP multicast.</li> | |||
<li>'control_group_uri'. This parameter is relevant for a Client that su | <li>'control_group_uri': This parameter is relevant for a Client that al | |||
pports the hosting of local resources each associated with a group (hence acting | so acts as a CoAP server supporting: i) the hosting of a dedicated resource for | |||
as CoAP server) and the reception of one-to-many requests sent to those resourc | each group that the Client is interested to be a part of; and ii) the reception | |||
es by the KDC (e.g., over IP multicast), targeting multiple members of the corre | of one-to-many requests sent to those resources by the KDC (e.g., over IP multic | |||
sponding group. Examples of related management operations that the KDC can perfo | ast), as targeting multiple members of the corresponding group. Examples of rela | |||
rm by this means are the eviction of group members and the execution of a group | ted management operations that the KDC can perform by this means are the evictio | |||
rekeying process through an advanced rekeying scheme, such as based on one-to-ma | n of group members and the execution of a group rekeying process through an adva | |||
ny rekeying messages.</li> | nced rekeying scheme, such as based on one-to-many rekeying messages.</li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="error-types"> | <section anchor="error-types"> | |||
<name>ACE Groupcomm Error Identifiers</name> | <name>ACE Groupcomm Error Identifiers</name> | |||
<t>This specification defines a number of values that the KDC can use as e | <t>This specification defines a number of values that the KDC can use as e | |||
rror identifiers. These are used in error responses with Content-Format applicat | rror identifiers. These are used in error responses with Content-Format "applica | |||
ion/concise-problem-details+cbor, as values of the 'error-id' field within the C | tion/concise-problem-details+cbor", as values of the 'error-id' field within the | |||
ustom Problem Detail entry 'ace-groupcomm-error' (see <xref target="kdc-if-error | Custom Problem Detail entry 'ace-groupcomm-error' (see <xref target="kdc-if-err | |||
s"/>).</t> | ors"/>).</t> | |||
<figure anchor="fig-ACE-Groupcomm-Error-Identifiers"> | <table anchor="fig-ACE-Groupcomm-Error-Identifiers"> | |||
<name>ACE Groupcomm Error Identifiers</name> | <name>ACE Groupcomm Error Identifiers</name> | |||
<artwork align="center"><![CDATA[ | <thead> | |||
+-------+---------------------------------------------+ | <tr> | |||
| Value | Description | | <th>Value</th> | |||
+-------+---------------------------------------------+ | <th>Description</th> | |||
| 0 | Operation permitted only to group members | | </tr> | |||
+-------+---------------------------------------------+ | </thead> | |||
| 1 | Request inconsistent with the current roles | | <tbody> | |||
+-------+---------------------------------------------+ | <tr> | |||
| 2 | Authentication credential incompatible with | | ||||
| | the group configuration | | <td>0</td> | |||
+-------+---------------------------------------------+ | <td>Operation permitted only to group members</td> | |||
| 3 | Invalid proof-of-possession evidence | | </tr><tr> | |||
+-------+---------------------------------------------+ | ||||
| 4 | No available node identifiers | | <td>1</td> | |||
+-------+---------------------------------------------+ | <td>Request inconsistent with the current roles</td> | |||
| 5 | Group membership terminated | | </tr><tr> | |||
+-------+---------------------------------------------+ | ||||
| 6 | Group deleted | | <td>2</td> | |||
+-------+---------------------------------------------+ | <td>Authentication credential incompatible with the group configuration</t | |||
]]></artwork> | d> | |||
</figure> | </tr><tr> | |||
<t>If a Client supports the problem-details format <xref target="RFC9290"/ | ||||
> and the Custom Problem Detail entry 'ace-groupcomm-error' defined in <xref tar | <td>3</td> | |||
get="kdc-if-errors"/>, and is able to understand the error specified in the 'err | <td>Invalid proof-of-possession evidence</td> | |||
or-id' field therein, then the Client can use that information to determine what | </tr><tr> | |||
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 | <td>4</td> | |||
entry may provide additional context.</t> | <td>No available node identifiers</td> | |||
</tr><tr> | ||||
<td>5</td> | ||||
<td>Group membership 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 <xref tar | ||||
get="kdc-if-errors"/> of this document and is able to understand the error speci | ||||
fied in the 'error-id' field therein, then the Client can use that information t | ||||
o 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 suppo | ||||
rts 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 w hen learning that a specific error has occurred.</t> | <t>In particular, the following guidelines apply, and application profiles of this specification can define more detailed actions for the Client to take w hen learning that a specific error has occurred.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>In case of error 0, the Client should stop sending the request in qu estion to the KDC. Rather, the Client should first join the targeted group. If i t has not happened already, this first requires the Client to obtain an appropri ate access token authorizing access to the group and provide it to the KDC.</li> | <li>In case of error 0, the Client should stop sending the request in qu estion to the KDC. Rather, the Client should first join the targeted group. If i t has not happened already, this first requires the Client to obtain an appropri ate 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 should re-join the | <li>In case of error 1, the Client as a group member should rejoin the g | |||
group with all the roles needed to perform the operation in question. This might | roup 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 the KDC | require the Client to first obtain a new access token and provide it to the KDC, | |||
, if the current access token does not authorize it to take those roles in the g | if the current access token does not authorize the Client to take those roles i | |||
roup. For operations admitted to a Client which is not a group member (e.g., an | n the group. For operations admitted to a Client that is not a group member (e.g | |||
external signature verifier), the Client should first obtain a new access token | ., an external signature verifier), the Client should first obtain a new access | |||
authorizing to also have the missing roles.</li> | token authorizing to also have the missing roles.</li> | |||
<li>In case of error 2, the Client has to obtain or self-generate a diff | <li>In case of error 2, the Client has to obtain or self-generate a diff | |||
erent asymmetric key pair, as aligned to the public key algorithms and parameter | erent asymmetric key pair, as aligned to the public key algorithm and parameters | |||
s used in the targeted group. After that, the Client should provide the KDC with | used in the targeted group. After that, the Client should provide the KDC with | |||
its new authentication credential, consistent with the format used in the targe | its new authentication credential, which is consistent with the format used in t | |||
ted group and including the new public key.</li> | he targeted group and including the new public key.</li> | |||
<li>In case of error 3, the Client should ensure to be computing its pro | <li>In case of error 3, the Client should ensure to compute its proof-of | |||
of-of-possession evidence by correctly using the parameters and procedures defin | -possession evidence by correctly using the parameters and procedures defined in | |||
ed in the used application profile of this specification. In an unattended setup | the used application profile of this specification. In an unattended setup, it | |||
, it might be not possible for a Client to autonomously diagnose the error and t | might not be possible for a Client to autonomously diagnose the error and take a | |||
ake an effective next action to address it.</li> | n effective next action to address it.</li> | |||
<li>In case of error 4, the Client should wait for a certain (pre-config | <li>In case of error 4, the Client should wait for a certain (pre-config | |||
ured) amount of time, before trying re-sending its request to the KDC.</li> | ured) amount of time before trying to 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 t he KDC, e.g., if the current access token has expired.</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 t he 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 t he group, just like if it has left the group with no intention to re-join it.</l i> | <li>In case of error 6, the Client should clean up its state regarding t he group, just like if it has left the group with no intention to rejoin it.</li > | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="sec-cons"> | <section anchor="sec-cons"> | |||
<name>Security Considerations</name> | <name>Security Considerations</name> | |||
<t>Security considerations are inherited from the ACE framework <xref targ et="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>Security considerations are inherited from the ACE framework <xref targ et="RFC9200"/> and from the specific transport profile of ACE used between the C lients 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 Sectio ns <xref target="RFC9290" section="4" sectionFormat="bare"/> and <xref target="R FC9290" section="5" sectionFormat="bare"/> of <xref target="RFC9290"/> also appl y.</t> | <t>When using the problem-details format defined in <xref target="RFC9290" /> for error responses, then the privacy and security considerations from Sectio ns <xref target="RFC9290" section="4" sectionFormat="bare"/> and <xref target="R FC9290" section="5" sectionFormat="bare"/> of <xref target="RFC9290"/> also appl y.</t> | |||
<t>Furthermore, the following security considerations apply.</t> | <t>Furthermore, the following security considerations apply.</t> | |||
<section anchor="sec-cons-communication"> | <section anchor="sec-cons-communication"> | |||
<name>Secure Communication in the Group</name> | <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 avo id replayed messages and to assert their freshness, e.g., <xref section="B.1.2" sectionFormat="of" target="RFC8613"/> or <xref section="10" sectionFormat="of" t arget="I-D.ietf-core-oscore-groupcomm"/>. Such a mechanism aids the recipient gr oup member also in case it has rebooted and lost the security state used to prot ect previous group communications with that sender.</t> | <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 avo id 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" sect ionFormat="of" target="I-D.ietf-core-oscore-groupcomm"/>. Such a mechanism also aids the recipient group member in case it has rebooted and lost the security st ate used to protect previous group communications with that sender.</t> | |||
<t>By its nature, the KDC is invested with a large amount of trust, sinc e it acts as a generator and provider of the symmetric keying material used to p rotect communications in each of its groups. While details depend on the specifi c communication and security protocols used in the group, the KDC is in the posi tion 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>By its nature, the KDC is invested with a large amount of trust, sinc e it acts as a generator and provider of the symmetric keying material used to p rotect communications in each of its groups. While details depend on the specifi c communication and security protocols used in the group, the KDC is in the posi tion 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, w hich also means that:</t> | <t>A compromised KDC would thus put the attacker in the same position, w hich also means that:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>The attacker can generate and control new group keying material, h ence possibly rekeying the group and evicting certain group members as part of a broader attack.</li> | <li>The attacker can generate and control new group keying material, h ence 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 a group even without been authorized to join it, and can allow further unauthorized ent ities to do so.</li> | <li>The attacker can actively participate in communications in a group , even without having been authorized to join it, and can allow further unauthor ized entities to do so.</li> | |||
<li>The attacker can build erroneous associations between node identif iers and group members' authentication credentials.</li> | <li>The attacker can build erroneous associations between node identif iers and group members' authentication credentials.</li> | |||
</ul> | </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 K DC is not able to impersonate group members since it does not have their private keys.</t> | <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 K DC 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 pro tocols and complemented by the application profiles of this specification using them.</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 pro tocols and complemented by the application profiles of this specification using them.</t> | |||
</section> | </section> | |||
<section anchor="sec-cons-rekeying"> | <section anchor="sec-cons-rekeying"> | |||
<name>Update of Group Keying Material</name> | <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 discu ssed in <xref target="sec-group-rekeying"/>.</t> | <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 discu ssed in <xref target="sec-group-rekeying"/>.</t> | |||
<t>In particular, the KDC must renew the group keying material latest up | <t>In particular, the KDC must renew the latest group keying material up | |||
on its expiration. Before then, the KDC MAY also renew the group keying material | on its expiration. Before then, the KDC <bcp14>MAY</bcp14> also renew the group | |||
on a regular or periodical fashion.</t> | keying material on a regular or periodical fashion.</t> | |||
<t>Unless otherwise defined by an application profile of this specificat | <t>Unless otherwise defined by an application profile of this specificat | |||
ion, the KDC SHOULD renew the group keying material upon a group membership chan | ion, the KDC <bcp14>SHOULD</bcp14> renew the group keying material upon a group | |||
ge. As a possible exception, the KDC may not rekey the group upon the joining of | membership change. As a possible exception, the KDC may not rekey the group upon | |||
a new group member, if the application does not require backward security. As a | the joining of a new group member if the application does not require backward | |||
nother possible exception discussed more in detail later in this section, the KD | security. As another possible exception discussed more in detail later in this s | |||
C may rely on a rekeying policy that reasonably take into account the expected r | ection, the KDC may rely on a rekeying policy that reasonably takes into account | |||
ate of group membership changes and the duration of a group rekeying.</t> | the expected rate of group membership changes and the duration of a group rekey | |||
<t>Since the minimum number of group members is one, the KDC SHOULD prov | ing.</t> | |||
ide even a Client joining an empty group with new keying material never used bef | <t>Since the minimum number of group members is one, the KDC <bcp14>SHOU | |||
ore in that group. Similarly, the KDC SHOULD provide new group keying material a | LD</bcp14> provide even a Client joining an empty group with new keying material | |||
lso to a Client that remains the only member in the group after the leaving of o | never used before in that group. Similarly, the KDC <bcp14>SHOULD</bcp14> also | |||
ther group members.</t> | provide new group keying material to a Client that remains the only member in th | |||
<t>Note that the considerations in <xref target="sec-cons-communication" | e group after the leaving of other group members.</t> | |||
/> about dealing with replayed messages still hold, even in case the KDC rekeys | <t>Note that the considerations in <xref target="sec-cons-communication" | |||
the group upon every single joining of a new group member. However, if the KDC h | /> about dealing with replayed messages still hold, even in case the KDC rekeys | |||
as renewed the group keying material upon a group member's joining, and the time | the group upon every single joining of a new group member. However, if the KDC h | |||
interval between the end of the rekeying process and that member's joining is s | as renewed the group keying material upon a group member's joining and the time | |||
ufficiently small, then that group member is also on the safe side, since it wou | interval between the end of the rekeying process and that member's joining is su | |||
ld not accept replayed messages protected with the old group keying material pre | fficiently small, then that group member is also on the safe side, since it woul | |||
vious to its joining.</t> | d not accept replayed messages protected with the old group keying material prev | |||
ious to its joining.</t> | ||||
<t>Once a joining node has obtained the new, latest keying material thro ugh a Join Response from the KDC (see <xref target="ssec-key-distribution-exchan ge"/>), 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 p rovides the current group members with the new, latest keying material before co mpleting the joining procedure. However, the joining node is not able to read me ssages 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>Once a joining node has obtained the new, latest keying material thro ugh a Join Response from the KDC (see <xref target="ssec-key-distribution-exchan ge"/>), 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 p rovides the current group members with the new, latest keying material before co mpleting the joining procedure. However, the joining node is not able to read me ssages 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 | <t>A node that has left the group should not expect any of its outgoing | |||
messages to be successfully processed, if received by other nodes in the group a | messages to be successfully processed if received by other nodes in the group af | |||
fter its leaving, due to a possible group rekeying occurred before the message r | ter its leaving due to a possible group rekeying occurring before the message re | |||
eception.</t> | ception.</t> | |||
<t>The KDC may enforce a rekeying policy that takes into account the ove | <t>The KDC may enforce a rekeying policy that takes into account the ove | |||
rall time required to rekey the group, as well as the expected rate of changes i | rall time required to rekey the group, as well as the expected rate of changes i | |||
n the group membership. That is, the KDC may not rekey the group at each and eve | n the group membership. That is, the KDC may not rekey the group at each and eve | |||
ry group membership change, for instance if members' joining and leaving occur f | ry group membership change, for instance, if members' joining and leaving occur | |||
requently and performing a group rekeying takes too long. Instead, the KDC might | frequently and performing a group rekeying takes too long. Instead, the KDC migh | |||
rekey the group after a minimum number of group members have joined or left wit | t rekey the group after a minimum number of group members have joined or left wi | |||
hin a given time interval, or after a maximum amount of time since the last grou | thin a given time interval, after a maximum amount of time since the last group | |||
p rekeying was completed, or yet during predictable network inactivity periods.< | rekeying was completed, or yet during predictable network inactivity periods.</t | |||
/t> | > | |||
<t>However, this would result in the KDC not constantly preserving backw ard and forward security in the group. That is:</t> | <t>However, this would result in the KDC not constantly preserving backw ard and forward security in the group. That is:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>Newly joining group members would be able to access the keying mat erial used before their joining, and thus they could access past group communica tions if they have recorded old exchanged messages. This might still be acceptab le for some applications and in situations where the new group members are fresh ly deployed through strictly controlled procedures.</li> | <li>Newly joining group members would be able to access the keying mat erial used before their joining, and thus they could access past group communica tions if they have recorded old exchanged messages. This might still be acceptab le for some applications and in situations where the new group members are fresh ly deployed through strictly controlled procedures.</li> | |||
<li>The leaving group members would remain able to access upcoming gro up communications, as protected with the current keying material that has not be en updated. This is typically undesirable, especially if the leaving group membe r is compromised or suspected to be, and it might have an impact or compromise t he security properties of the protocols used in the group to protect messages ex changed among the group members.</li> | <li>The leaving group members would remain able to access upcoming gro up communications, as protected with the current keying material that has not be en updated. This is typically undesirable, especially if the leaving group membe r is compromised or suspected to be, and it might impact or compromise the secur ity properties of the protocols used in the group to protect messages exchanged among the group members.</li> | |||
</ul> | </ul> | |||
<t>The KDC should renew the group keying material in case it has reboote | <t>The KDC should renew the group keying material in case it has reboote | |||
d, even if it stores the whole group keying material in persistent storage. This | d, 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 | assumes that the secure communication associations with the current group membe | |||
any administrative keying material required to rekey the group are also stored i | rs as well as any administrative keying material required to rekey the group are | |||
n persistent storage.</t> | also stored in persistent storage.</t> | |||
<t>However, if the KDC relies on Observe notifications to distribute the | <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 Obse | new group keying material, the KDC would have lost all the current ongoing Obse | |||
rvations with the group members after rebooting, and the group members would con | rvations with the group members after rebooting, and the group members would con | |||
tinue using the old group keying material. Therefore, the KDC will rather rely o | tinue using the old group keying material. Therefore, the KDC will rely on each | |||
n each group member asking for the new group keying material (see <xref target=" | group member asking for the new group keying material (see Sections <xref target | |||
ssec-key-material-retrieval"/> and <xref target="update-keys"/>), or rather perf | ="ssec-key-material-retrieval" format="counter"/> and <xref target="update-keys" | |||
orm a group rekeying by actively sending rekeying messages to group members as d | format="counter"/>) or perform a group rekeying by actively sending rekeying me | |||
iscussed in <xref target="sec-group-rekeying"/>.</t> | ssages 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 | <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 a | nodes repeatedly performing actions that might trigger a group rekeying. Such a | |||
ctions can include leaving and/or re-joining the group at high rates, or often a | ctions can include leaving and/or rejoining the group at high rates or often ask | |||
sking the KDC for new individual keying material. Ultimately, the KDC can resort | ing the KDC for new individual keying material. Ultimately, the KDC can resort t | |||
to removing these nodes from the group and (temporarily) preventing them from j | o removing these nodes from the group and (temporarily) preventing them from joi | |||
oining the group again.</t> | ning the group again.</t> | |||
<t>The KDC also needs to have a congestion control mechanism in place, i | <t>The KDC also needs to have a congestion control mechanism in place in | |||
n order to avoid network congestion upon distributing new group keying material. | order to avoid network congestion upon distributing new group keying material. | |||
For example, CoAP and Observe give guidance on such mechanisms, see <xref secti | For example, CoAP and Observe give guidance on such mechanisms, see <xref sectio | |||
on="4.7" sectionFormat="of" target="RFC7252"/> and <xref section="4.5.1" section | n="4.7" sectionFormat="of" target="RFC7252"/> and <xref section="4.5.1" sectionF | |||
Format="of" target="RFC7641"/>.</t> | ormat="of" target="RFC7641"/>.</t> | |||
</section> | </section> | |||
<section anchor="block-wise-considerations"> | <section anchor="block-wise-considerations"> | |||
<name>Block-Wise Considerations</name> | <name>Block-Wise Considerations</name> | |||
<t>If the Block-Wise CoAP options <xref target="RFC7959"/> are used, and | <t>If the Block-Wise CoAP options <xref target="RFC7959"/> are used and | |||
the keying material is updated in the middle of a Block-Wise transfer, the send | the keying material is updated in the middle of a Block-Wise transfer, the sende | |||
er of the blocks just changes the group keying material to the updated one and c | r of the blocks just changes the group keying material to the updated one and co | |||
ontinues the transfer. As long as both sides get the new group keying material, | ntinues the transfer. As long as both sides get the new group keying material, u | |||
updating the group keying material in the middle of a transfer will not cause an | pdating the group keying material in the middle of a transfer will not cause any | |||
y issue. Otherwise, the sender will have to transmit the message again, when rec | issue. Otherwise, the sender will have to transmit the message again when recei | |||
eiving an error message from the recipient.</t> | ving an error message from the recipient.</t> | |||
<t>Compared to a scenario where the transfer does not use Block-Wise, de | <t>Compared to a scenario where the transfer does not use Block-Wise, an | |||
pending on how fast the group keying material is changed, the group members migh | d depending on how fast the group keying material is changed, the group members | |||
t consume a larger amount of the network bandwidth by repeatedly resending the s | might consume a larger amount of the network bandwidth by repeatedly resending t | |||
ame blocks, which might be problematic.</t> | he same blocks, which might be problematic.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="iana-considerations"> | <section anchor="iana-considerations"> | |||
<name>IANA Considerations</name> | <name>IANA Considerations</name> | |||
<t>This document has the following actions for IANA.</t> | <t>Per this document, IANA has completed the following actions.</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> | ||||
<section anchor="media-type"> | <section anchor="media-type"> | |||
<name>Media Type Registrations</name> | <name>Media Type Registrations</name> | |||
<t>This specification registers the 'application/ace-groupcomm+cbor' med | <t>This specification has registered the "application/ace-groupcomm+cbor | |||
ia type for messages of the protocols defined in this document following the ACE | " media type for messages of the protocols defined in this document following th | |||
exchange and carrying parameters encoded in CBOR. This registration follows the | e ACE exchange and carrying parameters encoded in CBOR. This registration follow | |||
procedures specified in <xref target="RFC6838"/>.</t> | s the procedures specified in <xref target="RFC6838"/>.</t> | |||
<t>Type name: application</t> | <dl newline="false"> | |||
<t>Subtype name: ace-groupcomm+cbor</t> | <dt>Type name:</dt><dd>application</dd> | |||
<t>Required parameters: N/A</t> | <dt>Subtype name:</dt><dd> ace-groupcomm+cbor</dd> | |||
<t>Optional parameters: N/A</t> | <dt>Required parameters:</dt><dd> N/A</dd> | |||
<t>Encoding considerations: Must be encoded as a CBOR map containing the | <dt>Optional parameters:</dt><dd> N/A</dd> | |||
parameters defined in [RFC-XXXX].</t> | <dt>Encoding considerations:</dt><dd> Must be encoded as a CBOR map cont | |||
<t>Security considerations: See <xref target="sec-cons"/> of [RFC-XXXX]. | aining the parameters defined in RFC 9594.</dd> | |||
</t> | <dt>Security considerations:</dt><dd> See <xref target="sec-cons"/> of R | |||
<t>Interoperability considerations: N/A</t> | FC 9594.</dd> | |||
<t>Published specification: [RFC-XXXX]</t> | <dt>Interoperability considerations:</dt><dd> N/A</dd> | |||
<t>Applications that use this media type: The type is used by Authorizat | <dt>Published specification:</dt><dd> RFC 9594</dd> | |||
ion Servers, Clients, and Resource Servers that support the ACE groupcomm framew | <dt>Applications that use this media type:</dt><dd> The type is used by | |||
ork as specified in [RFC-XXXX].</t> | Authorization Servers, Clients, and Resource Servers that support the ACE groupc | |||
<t>Fragment identifier considerations: N/A</t> | omm framework as specified in RFC 9594.</dd> | |||
<t>Additional information: N/A</t> | <dt>Fragment identifier considerations:</dt><dd> N/A</dd> | |||
<t>Person & email address to contact for further information: ACE WG | <dt>Additional information:</dt><dd> N/A</dd> | |||
mailing list (ace@ietf.org) or IETF Applications and Real-Time Area (art@ietf.o | <dt>Person & email address to contact for further information:</dt>< | |||
rg)</t> | dd> ACE WG mailing list (ace@ietf.org) or IETF Applications and Real-Time Area ( | |||
<t>Intended usage: COMMON</t> | art@ietf.org)</dd> | |||
<t>Restrictions on usage: None</t> | <dt>Intended usage:</dt><dd> COMMON</dd> | |||
<t>Author/Change controller: IETF</t> | <dt>Restrictions on usage:</dt><dd> None</dd> | |||
<t>Provisional registration: No</t> | <dt>Author/Change controller:</dt><dd> IETF</dd> | |||
<dt>Provisional registration:</dt><dd> No</dd> | ||||
</dl> | ||||
</section> | </section> | |||
<section anchor="content-type"> | <section anchor="content-type"> | |||
<name>CoAP Content-Formats</name> | <name>CoAP Content-Formats</name> | |||
<t>IANA is asked to register the following entry to the "CoAP Content-Fo | <t>IANA has registered the following entry in the "CoAP Content-Formats" | |||
rmats" registry within the "CoRE Parameters" registry group.</t> | registry within the "CoRE Parameters" registry group.</t> | |||
<t>Content Type: application/ace-groupcomm+cbor</t> | <dl newline="false" spacing="compact"> | |||
<t>Content Coding: -</t> | <dt>Content Type:</dt><dd> application/ace-groupcomm+cbor</dd> | |||
<t>ID: TBD</t> | <dt>Content Coding:</dt><dd> -</dd> | |||
<t>Reference: [RFC-XXXX]</t> | <dt>ID:</dt><dd> 261</dd> | |||
<dt>Reference:</dt><dd> RFC 9594</dd> | ||||
</dl> | ||||
</section> | </section> | |||
<section anchor="iana-kinfo"> | <section anchor="iana-kinfo"> | |||
<name>OAuth Parameters</name> | <name>OAuth Parameters</name> | |||
<t>IANA is asked to register the following entries in the "OAuth Paramet | <t>IANA has registered the following entries in the "OAuth Parameters" r | |||
ers" registry following the procedure specified in <xref section="11.2" sectionF | egistry, following the procedure specified in <xref section="11.2" sectionFormat | |||
ormat="of" target="RFC6749"/>.</t> | ="of" target="RFC6749"/>.</t> | |||
<ul spacing="normal"> | <dl spacing="compact"> | |||
<li>Parameter name: sign_info</li> | <dt>Parameter name:</dt><dd> sign_info</dd> | |||
<li>Parameter usage location: client-rs request, rs-client response</l | <dt>Parameter usage location:</dt><dd> client-rs request, rs-client re | |||
i> | sponse</dd> | |||
<li>Change Controller: IETF</li> | <dt>Change controller:</dt><dd> IETF</dd> | |||
<li>Specification Document(s): [RFC-XXXX]</li> | <dt>Specification document(s):</dt><dd> RFC 9594</dd> | |||
</ul> | </dl> | |||
<t> </t> | ||||
<ul spacing="normal"> | <dl spacing="compact"> | |||
<li>Parameter name: kdcchallenge</li> | <dt>Parameter name:</dt><dd> kdcchallenge</dd> | |||
<li>Parameter usage location: rs-client response</li> | <dt>Parameter usage location:</dt><dd> rs-client response</dd> | |||
<li>Change Controller: IETF</li> | <dt>Change controller:</dt><dd> IETF</dd> | |||
<li>Specification Document(s): [RFC-XXXX]</li> | <dt>Specification document(s):</dt><dd> RFC 9594</dd> | |||
</ul> | </dl> | |||
</section> | </section> | |||
<section anchor="iana-kinfo-map"> | <section anchor="iana-kinfo-map"> | |||
<name>OAuth Parameters CBOR Mappings</name> | <name>OAuth Parameters CBOR Mappings</name> | |||
<t>IANA is asked to register the following entries in the "OAuth Paramet | <t>IANA has registered the following entries in the "OAuth Parameters CB | |||
ers CBOR | OR | |||
Mappings" registry following the procedure specified in <xref section="8.10" sec | Mappings" registry, following the procedure specified in <xref section="8.10" se | |||
tionFormat="of" target="RFC9200"/>.</t> | ctionFormat="of" target="RFC9200"/>.</t> | |||
<ul spacing="normal"> | <dl spacing="compact"> | |||
<li>Name: sign_info</li> | <dt>Name:</dt><dd>sign_info</dd> | |||
<li>CBOR Key: TBD (range -256 to 255)</li> | <dt>CBOR Key:</dt><dd>45</dd> | |||
<li>Value Type: Simple value "null" / array</li> | <dt>Value Type:</dt><dd>Null or array</dd> | |||
<li>Reference: [RFC-XXXX]</li> | <dt>Reference:</dt><dd>RFC 9594</dd> | |||
</ul> | </dl> | |||
<t> </t> | ||||
<ul spacing="normal"> | <dl spacing="compact"> | |||
<li>Name: kdcchallenge</li> | <dt>Name:</dt><dd>kdcchallenge</dd> | |||
<li>CBOR Key: TBD (range -256 to 255)</li> | <dt>CBOR Key:</dt><dd>46</dd> | |||
<li>Value Type: Byte string</li> | <dt>Value Type:</dt><dd>byte string</dd> | |||
<li>Reference: [RFC-XXXX]</li> | <dt>Reference:</dt><dd>RFC 9594</dd> | |||
</ul> | </dl> | |||
</section> | </section> | |||
<section anchor="if-ace-group"> | <section anchor="if-ace-group"> | |||
<name>Interface Description (if=) Link Target Attribute Values</name> | <name>Interface Description (if=) Link Target Attribute Values</name> | |||
<t>IANA is asked to register the following entry in the "Interface Descr | <t>IANA has registered the following entry in the "Interface Description | |||
iption (if=) Link Target Attribute Values" registry within the "CoRE Parameters" | (if=) Link Target Attribute Values" registry within the "CoRE Parameters" regis | |||
registry group.</t> | try group.</t> | |||
<ul spacing="normal"> | <dl spacing="compact"> | |||
<li>Value: ace.groups</li> | <dt>Value:</dt><dd> ace.groups</dd> | |||
<li>Description: The KDC interface at the parent resource of group-mem | <dt>Description:</dt><dd> The KDC interface at the parent resource of | |||
bership resources is used to retrieve names of security groups using the ACE fra | group-membership resources is used to retrieve names of security groups using th | |||
mework.</li> | e ACE framework.</dd> | |||
<li>Reference: <xref target="kdc-if"/> of [RFC-XXXX]</li> | <dt>Reference:</dt><dd> <xref target="kdc-if"/> of RFC 9594</dd> | |||
</ul> | </dl> | |||
<t> </t> | ||||
<ul spacing="normal"> | <dl spacing="compact"> | |||
<li>Value: ace.group</li> | <dt>Value:</dt><dd> ace.group</dd> | |||
<li>Description: The KDC interface at a group-membership resource is u | <dt>Description:</dt><dd> The KDC interface at a group-membership reso | |||
sed to provision keying material and related information and policies to members | urce is used to provision keying material and related information and policies t | |||
of the corresponding security group using the ACE framework.</li> | o members of the corresponding security group using the ACE framework.</dd> | |||
<li>Reference: <xref target="kdc-if"/> of [RFC-XXXX]</li> | <dt>Reference:</dt><dd> <xref target="kdc-if"/> of RFC 9594</dd> | |||
</ul> | </dl> | |||
</section> | </section> | |||
<section anchor="iana-custom-problem-details"> | <section anchor="iana-custom-problem-details"> | |||
<name>Custom Problem Detail Keys Registry</name> | <name>Custom Problem Detail Keys Registry</name> | |||
<t>IANA is asked to register the following entry in the "Custom Problem | <t>IANA has registered the following entry in the "Custom Problem Detail | |||
Detail Keys" registry within the "CoRE Parameters" registry group.</t> | Keys" registry within the "CoRE Parameters" registry group.</t> | |||
<ul spacing="normal"> | <dl spacing="compact"> | |||
<li>Key Value: TBD</li> | <dt>Key Value:</dt><dd>0</dd> | |||
<li>Name: ace-groupcomm-error</li> | <dt>Name:</dt><dd> ace-groupcomm-error</dd> | |||
<li>Brief Description: Carry [RFC-XXXX] problem details in a Concise P | <dt>Brief Description:</dt><dd>Carry RFC 9594 problem details in a Con | |||
roblem Details data item.</li> | cise Problem Details data item.</dd> | |||
<li>Change Controller: IETF</li> | <dt>Change Controller:</dt><dd> IETF</dd> | |||
<li>Reference: <xref target="kdc-if-errors"/> of [RFC-XXXX]</li> | <dt>Reference:</dt><dd>RFC 9594, <xref target="kdc-if-errors"/></dd> | |||
</ul> | </dl> | |||
</section> | </section> | |||
<section anchor="iana-reg"> | <section anchor="iana-reg"> | |||
<name>ACE Groupcomm Parameters</name> | <name>ACE Groupcomm Parameters</name> | |||
<t>This specification establishes the "ACE Groupcomm Parameters" IANA re | <t>This specification has established the "ACE Groupcomm Parameters" IANA regist | |||
gistry within the "Authentication and Authorization for Constrained Environments | ry within the "Authentication and Authorization for Constrained Environments (AC | |||
(ACE)" registry group.</t> | E)" registry group.</t> | |||
<t>The registry has been created to use the "Expert Review" registration | <t>Values in this registry are covered by different registration policie | |||
procedure <xref target="RFC8126"/>. Expert review guidelines are provided in <x | s as indicated below. Some policies require Expert Review; guidelines are provid | |||
ref target="review"/>. Values in this registry are covered by different registra | ed in <xref target="review"/></t> | |||
tion policies as indicated. It should be noted that, in addition to the expert r | ||||
eview, some portions of the registry require a specification, potentially a Stan | ||||
dards Track RFC, to be supplied as well.</t> | ||||
<t>The columns of this registry are:</t> | <t>The columns of this registry are:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Name: This is a descriptive name that enables easier reference to | <dt>Name:</dt><dd> This is a descriptive name that enables easier refe | |||
the item. The name MUST be unique. It is not used in the encoding.</li> | rence to | |||
<li>CBOR Key: This is the value used as the CBOR key of the item. Thes | the item. The name <bcp14>MUST</bcp14> be unique. It is not used in the encoding | |||
e values MUST be unique. The value can be a positive integer, a negative integer | .</dd> | |||
, or a text string. Different ranges of values use different registration polici | <dt>CBOR Key:</dt><dd> This is the value used as the CBOR map key of t | |||
es <xref target="RFC8126"/>. Integer values from -256 to 255 as well as text str | he item. These values <bcp14>MUST</bcp14> be unique. The value can be a positive | |||
ings of length 1 are designated as "Standards Action With Expert Review". Intege | integer, a negative integer, or a text string. Different ranges of values use d | |||
r values from -65536 to -257 and from 256 to 65535, as well as text strings of l | ifferent registration policies <xref target="RFC8126"/>. Integer values from -25 | |||
ength 2 are designated as "Specification Required". Integer values greater than | 6 to 255 as well as text strings of length 1 are designated as "Standards Action | |||
65535 as well as text strings of length greater than 2 are designated as "Expert | With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 a | |||
Review". Integer values less than -65536 are marked as "Private Use".</li> | s well as text strings of length 2 are designated as "Specification Required". I | |||
<li>CBOR Type: This contains the CBOR type of the item, or a pointer t | nteger values greater than 65535 as well as text strings of length greater than | |||
o the registry that defines its type, when that depends on another item.</li> | 2 are designated as "Expert Review". Integer values less than -65536 are marked | |||
<li>Reference: This contains a pointer to the public specification for | as "Private Use".</dd> | |||
the item.</li> | <dt>CBOR Type:</dt><dd> This field contains the CBOR type of the item | |||
</ul> | or a pointer to the registry that defines its type when that depends on another | |||
item.</dd> | ||||
<dt>Reference:</dt><dd> This field contains a pointer to the public sp | ||||
ecification for the item.</dd> | ||||
</dl> | ||||
<t>This registry has been initially populated with the values in <xref t arget="fig-ACE-Groupcomm-Parameters"/>.</t> | <t>This registry has been initially populated with the values in <xref t arget="fig-ACE-Groupcomm-Parameters"/>.</t> | |||
</section> | </section> | |||
<section anchor="iana-key"> | <section anchor="iana-key"> | |||
<name>ACE Groupcomm Key Types</name> | <name>ACE Groupcomm Key Types</name> | |||
<t>This specification establishes the "ACE Groupcomm Key Types" IANA reg istry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.</t> | <t>This specification establishes the "ACE Groupcomm Key Types" IANA reg istry 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"/>. Expert review guidelines are provided in <x ref target="review"/>. Values in this registry are covered by different registra tion policies as indicated. It should be noted that, in addition to the expert r eview, some portions of the registry require a specification, potentially a Stan dards Track RFC, to be supplied as well.</t> | <t>Values in this registry are covered by different registration policie s as indicated below. Some policies require Expert Review; guidelines are provid ed in <xref target="review"/>.</t> | |||
<t>The columns of this registry are:</t> | <t>The columns of this registry are:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Name: This is a descriptive name that enables easier reference to | <dt>Name:</dt><dd> This is a descriptive name that enables easier refe | |||
the item. The name MUST be unique. It is not used in the encoding.</li> | rence to | |||
<li>Key Type Value: This is the value used to identify the keying mate | the item. The name <bcp14>MUST</bcp14> be unique. It is not used in the encoding | |||
rial. These values MUST be unique. The value can be a positive integer, a negati | .</dd> | |||
ve integer, or a text string. Different ranges of values use different registrat | <dt>Key Type Value:</dt><dd> This is the value used to identify the ke | |||
ion policies <xref target="RFC8126"/>. Integer values from -256 to 255 as well a | ying material. These values <bcp14>MUST</bcp14> be unique. The value can be a po | |||
s text strings of length 1 are designated as "Standards Action With Expert Revie | sitive integer, a negative integer, or a text string. Different ranges of values | |||
w". Integer values from -65536 to -257 and from 256 to 65535, as well as text st | use different registration policies <xref target="RFC8126"/>. Integer values fr | |||
rings of length 2 are designated as "Specification Required". Integer values gre | om -256 to 255 as well as text strings of length 1 are designated as "Standards | |||
ater than 65535 as well as text strings of length greater than 2 are designated | Action With Expert Review". Integer values from -65536 to -257 and from 256 to 6 | |||
as "Expert Review". Integer values less than -65536 are marked as "Private Use". | 5535 as well as text strings of length 2 are designated as "Specification Requir | |||
</li> | ed". Integer values greater than 65535 as well as text strings of length greater | |||
<li>Profile: This field may contain one or more descriptive strings of | than 2 are designated as "Expert Review". Integer values less than -65536 are m | |||
application profiles to be used with this item. The values should be taken from | arked as "Private Use".</dd> | |||
the Name column of the "ACE Groupcomm Profiles" registry.</li> | <dt>Profile:</dt><dd> This field may contain one or more descriptive s | |||
<li>Description: This field contains a brief description of the keying | trings of application profiles to be used with this item. The values should be t | |||
material.</li> | aken from the "Name" column of the "ACE Groupcomm Profiles" registry.</dd> | |||
<li>Reference: This contains a pointer to the public specification for | <dt>Description:</dt><dd> This field contains a brief description of t | |||
the format of the keying material, if one exists.</li> | he keying material.</dd> | |||
</ul> | <dt>Reference:</dt><dd> This field contains a pointer to the public sp | |||
ecification for the format of the keying material, if one exists.</dd> | ||||
</dl> | ||||
<t>This registry has been initially populated with the value in <xref ta rget="fig-gkty"/>.</t> | <t>This registry has been initially populated with the value in <xref ta rget="fig-gkty"/>.</t> | |||
</section> | </section> | |||
<section anchor="ace-groupcomm-profiles"> | <section anchor="ace-groupcomm-profiles"> | |||
<name>ACE Groupcomm Profiles</name> | <name>ACE Groupcomm Profiles</name> | |||
<t>This specification establishes the "ACE Groupcomm Profiles" IANA regi stry within the "Authentication and Authorization for Constrained Environments ( ACE)" registry group.</t> | <t>This specification establishes the "ACE Groupcomm Profiles" IANA regi stry 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"/>. Expert review guidelines are provided in <x ref target="review"/>. Values in this registry are covered by different registra tion policies as indicated. It should be noted that, in addition to the expert r eview, some portions of the registry require a specification, potentially a Stan dards Track RFC, to be supplied as well.</t> | <t>Values in this registry are covered by different registration policie s as indicated below. Some policies require Expert Review; guidelines are provid ed in <xref target="review"/>.</t> | |||
<t>The columns of this registry are:</t> | <t>The columns of this registry are:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Name: The name of the application profile, to be used as value of | <dt>Name:</dt><dd> The name of the application profile.</dd> | |||
the profile attribute.</li> | <dt>Description:</dt><dd> Text giving an overview of the application p | |||
<li>Description: Text giving an overview of the application profile an | rofile and the context it is developed for.</dd> | |||
d the context it is developed for.</li> | <dt>CBOR Value:</dt><dd> CBOR abbreviation for the name of this applic | |||
<li>CBOR Value: CBOR abbreviation for the name of this application pro | ation profile. These values <bcp14>MUST</bcp14> be unique. The value can be a po | |||
file. These values MUST be unique. The value can be a positive integer or a nega | sitive integer or a negative integer. Different ranges of values use different r | |||
tive integer. Different ranges of values use different registration policies <xr | egistration policies <xref target="RFC8126"/>. Integer values from -256 to 255 a | |||
ef target="RFC8126"/>. Integer values from -256 to 255 are designated as "Standa | re designated as "Standards Action With Expert Review". Integer values from -655 | |||
rds Action With Expert Review". Integer values from -65536 to -257 and from 256 | 36 to -257 and from 256 to 65535 are designated as "Specification Required". Int | |||
to 65535 are designated as "Specification Required". Integer values greater than | eger values greater than 65535 are designated as "Expert Review". Integer values | |||
65535 are designated as "Expert Review". Integer values less than -65536 are ma | less than -65536 are marked as "Private Use".</dd> | |||
rked as "Private Use".</li> | <dt>Reference:</dt><dd> This field contains a pointer to the public sp | |||
<li>Reference: This contains a pointer to the public specification of | ecification for this application profile, if one exists.</dd> | |||
the abbreviation for this application profile, if one exists.</li> | </dl> | |||
</ul> | ||||
<t>This registry has been initially populated with the value in <xref ta rget="ace-groupcomm-profile-0"/>.</t> | <t>This registry has been initially populated with the value in <xref ta rget="ace-groupcomm-profile-0"/>.</t> | |||
</section> | </section> | |||
<section anchor="ace-groupcomm-policies"> | <section anchor="ace-groupcomm-policies"> | |||
<name>ACE Groupcomm Policies</name> | <name>ACE Groupcomm Policies</name> | |||
<t>This specification establishes the "ACE Groupcomm Policies" IANA regi stry within the "Authentication and Authorization for Constrained Environments ( ACE)" registry group.</t> | <t>This specification establishes the "ACE Groupcomm Policies" IANA regi stry 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"/>. Expert review guidelines are provided in <x ref target="review"/>. Values in this registry are covered by different registra tion policies as indicated. It should be noted that, in addition to the expert r eview, some portions of the registry require a specification, potentially a Stan dards Track RFC, to be supplied as well.</t> | <t>Values in this registry are covered by different registration policie s as indicated below. Some policies require Expert Review; guidelines are provid ed in <xref target="review"/>.</t> | |||
<t>The columns of this registry are:</t> | <t>The columns of this registry are:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Name: The name of the group communication policy.</li> | <dt>Name:</dt><dd> The name of the group communication policy.</dd> | |||
<li>CBOR label: The value to be used to identify this group communicat | <dt>CBOR Label:</dt><dd> The value to be used to identify this group c | |||
ion policy. These values MUST be unique. The value can be a positive integer, a | ommunication policy. These values <bcp14>MUST</bcp14> be unique. The value can b | |||
negative integer, or a text string. Different ranges of values use different reg | e a positive integer, a negative integer, or a text string. Different ranges of | |||
istration policies <xref target="RFC8126"/>. Integer values from -256 to 255 as | values use different registration policies <xref target="RFC8126"/>. Integer val | |||
well as text strings of length 1 are designated as "Standards Action With Expert | ues from -256 to 255 as well as text strings of length 1 are designated as "Stan | |||
Review". Integer values from -65536 to -257 and from 256 to 65535, as well as t | dards Action With Expert Review". Integer values from -65536 to -257 and from 25 | |||
ext strings of length 2 are designated as "Specification Required". Integer valu | 6 to 65535 as well as text strings of length 2 are designated as "Specification | |||
es greater than 65535 as well as text strings of length greater than 2 are desig | Required". Integer values greater than 65535 as well as text strings of length g | |||
nated as "Expert Review". Integer values less than -65536 are marked as "Private | reater than 2 are designated as "Expert Review". Integer values less than -65536 | |||
Use".</li> | are marked as "Private Use".</dd> | |||
<li>CBOR type: the CBOR type used to encode the value of this group co | <dt>CBOR Type:</dt><dd> The CBOR type used to encode the value of this | |||
mmunication policy.</li> | group communication policy.</dd> | |||
<li>Description: This field contains a brief description for this grou | <dt>Description:</dt><dd> This field contains a brief description for | |||
p communication policy.</li> | this group communication policy.</dd> | |||
<li>Reference: This field contains a pointer to the public specificati | <dt>Reference:</dt><dd> This field contains a pointer to the public sp | |||
on providing the format of the group communication policy, if one exists.</li> | ecification for this group communication policy and its format, if one exists.</ | |||
</ul> | dd> | |||
</dl> | ||||
<t>This registry has been initially populated with the values in <xref t arget="fig-ACE-Groupcomm-Policies"/>.</t> | <t>This registry has been initially populated with the values in <xref t arget="fig-ACE-Groupcomm-Policies"/>.</t> | |||
</section> | </section> | |||
<section anchor="sequence-number-synchronization-methods"> | <section anchor="sequence-number-synchronization-methods"> | |||
<name>Sequence Number Synchronization Methods</name> | <name>Sequence Number Synchronization Methods</name> | |||
<t>This specification establishes the "Sequence Number Synchronization M ethods" IANA registry within the "Authentication and Authorization for Constrain ed Environments (ACE)" registry group.</t> | <t>This specification establishes the "Sequence Number Synchronization M ethods" IANA registry within the "Authentication and Authorization for Constrain ed Environments (ACE)" registry group.</t> | |||
<t>The registry has been created to use the "Expert Review" registration procedure <xref target="RFC8126"/>. Expert review guidelines are provided in <x ref target="review"/>. Values in this registry are covered by different registra tion policies as indicated. It should be noted that, in addition to the expert r eview, some portions of the registry require a specification, potentially a Stan dards Track RFC, to be supplied as well.</t> | <t>Values in this registry are covered by different registration policie s as indicated below. Some policies require Expert Review; guidelines are provid ed in <xref target="review"/>.</t> | |||
<t>The columns of this registry are:</t> | <t>The columns of this registry are:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Name: The name of the sequence number synchronization method.</li> | <dt>Name:</dt><dd> The name of the sequence number synchronization met | |||
<li>Value: The value to be used to identify this sequence number synch | hod.</dd> | |||
ronization method. These values MUST be unique. The value can be a positive inte | <dt>Value:</dt><dd> The value to be used to identify this sequence num | |||
ger, a negative integer, or a text string. Different ranges of values use differ | ber synchronization method. These values <bcp14>MUST</bcp14> be unique. The valu | |||
ent registration policies <xref target="RFC8126"/>. Integer values from -256 to | e can be a positive integer, a negative integer, or a text string. Different ran | |||
255 as well as text strings of length 1 are designated as "Standards Action With | ges of values use different registration policies <xref target="RFC8126"/>. Inte | |||
Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as we | ger values from -256 to 255 as well as text strings of length 1 are designated a | |||
ll as text strings of length 2 are designated as "Specification Required". Integ | s "Standards Action With Expert Review". Integer values from -65536 to -257 and | |||
er values greater than 65535 as well as text strings of length greater than 2 ar | from 256 to 65535 as well as text strings of length 2 are designated as "Specifi | |||
e designated as "Expert Review". Integer values less than -65536 are marked as " | cation Required". Integer values greater than 65535 as well as text strings of l | |||
Private Use".</li> | ength greater than 2 are designated as "Expert Review". Integer values less than | |||
<li>Description: This field contains a brief description for this sequ | -65536 are marked as "Private Use".</dd> | |||
ence number synchronization method.</li> | <dt>Description:</dt><dd> This field contains a brief description for | |||
<li>Reference: This field contains a pointer to the public specificati | this sequence number synchronization method.</dd> | |||
on describing the sequence number synchronization method.</li> | <dt>Reference:</dt><dd> This field contains a pointer to the public sp | |||
</ul> | ecification describing the sequence number synchronization method.</dd> | |||
</dl> | ||||
</section> | </section> | |||
<section anchor="iana-ace-groupcomm-errors"> | <section anchor="iana-ace-groupcomm-errors"> | |||
<name>ACE Groupcomm Errors</name> | <name>ACE Groupcomm Errors</name> | |||
<t>This specification establishes the "ACE Groupcomm Errors" IANA regist ry within the "Authentication and Authorization for Constrained Environments (AC E)" registry group.</t> | <t>This specification establishes the "ACE Groupcomm Errors" IANA regist ry within the "Authentication and Authorization for Constrained Environments (AC E)" registry group.</t> | |||
<t>The registry has been created to use the "Expert Review" registration procedure <xref target="RFC8126"/>. Expert review guidelines are provided in <x ref target="review"/>. Values in this registry are covered by different registra tion policies as indicated. It should be noted that, in addition to the expert r eview, some portions of the registry require a specification, potentially a Stan dards Track RFC, to be supplied as well.</t> | <t>Values in this registry are covered by different registration policie s as indicated below. Some policies require Expert Review; guidelines are provid ed in <xref target="review"/>.</t> | |||
<t>The columns of this registry are:</t> | <t>The columns of this registry are:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Value: The value to be used to identify the error. These values MU | <dt>Value:</dt><dd> The value to be used to identify the error. These | |||
ST be unique. The value can be a positive integer or a negative integer. Differe | values <bcp14>MUST</bcp14> be unique. The value can be a positive integer or a n | |||
nt ranges of values use different registration policies <xref target="RFC8126"/> | egative integer. Different ranges of values use different registration policies | |||
. Integer values from -256 to 255 are designated as "Standards Action With Exper | <xref target="RFC8126"/>. Integer values from -256 to 255 are designated as "Sta | |||
t Review". Integer values from -65536 to -257 and from 256 to 65535 are designat | ndards Action With Expert Review". Integer values from -65536 to -257 and from 2 | |||
ed as "Specification Required". Integer values greater than 65535 are designated | 56 to 65535 are designated as "Specification Required". Integer values greater t | |||
as "Expert Review". Integer values less than -65536 are marked as "Private Use" | han 65535 are designated as "Expert Review". Integer values less than -65536 are | |||
.</li> | marked as "Private Use".</dd> | |||
<li>Description: This field contains a brief description of the error. | <dt>Description:</dt><dd> This field contains a brief description of t | |||
</li> | he error.</dd> | |||
<li>Reference: This field contains a pointer to the public specificati | <dt>Reference:</dt><dd> This field contains a pointer to the public sp | |||
on defining the error, if one exists.</li> | ecification defining the error, if one exists.</dd> | |||
</ul> | </dl> | |||
<t>This registry has been initially populated with the values in <xref t | <t>This registry has been initially populated with the values in <xref t | |||
arget="fig-ACE-Groupcomm-Error-Identifiers"/>. The Reference column for all of t | arget="fig-ACE-Groupcomm-Error-Identifiers"/>. The "Reference" column for all of | |||
hese entries refers to this document.</t> | these entries refers to this document.</t> | |||
</section> | </section> | |||
<section anchor="iana-ace-groupcomm-rekeying-schemes"> | <section anchor="iana-ace-groupcomm-rekeying-schemes"> | |||
<name>ACE Groupcomm Rekeying Schemes</name> | <name>ACE Groupcomm Rekeying Schemes</name> | |||
<t>This specification establishes the "ACE Groupcomm Rekeying Schemes" I ANA registry within the "Authentication and Authorization for Constrained Enviro nments (ACE)" registry group.</t> | <t>This specification establishes the "ACE Groupcomm Rekeying Schemes" I ANA registry within the "Authentication and Authorization for Constrained Enviro nments (ACE)" registry group.</t> | |||
<t>The registry has been created to use the "Expert Review" registration procedure <xref target="RFC8126"/>. Expert review guidelines are provided in <x ref target="review"/>. Values in this registry are covered by different registra tion policies as indicated. It should be noted that, in addition to the expert r eview, some portions of the registry require a specification, potentially a Stan dards Track RFC, to be supplied as well.</t> | <t>Values in this registry are covered by different registration policie s as indicated below. Some policies require Expert Review; guidelines are provid ed in <xref target="review"/>.</t> | |||
<t>The columns of this registry are:</t> | <t>The columns of this registry are:</t> | |||
<ul spacing="normal"> | <dl spacing="normal"> | |||
<li>Value: The value to be used to identify the group rekeying scheme. | <dt>Value:</dt><dd> The value to be used to identify the group rekeyin | |||
These values MUST be unique. The value can be a positive integer or a negative | g scheme. These values <bcp14>MUST</bcp14> be unique. The value can be a positiv | |||
integer. Different ranges of values use different registration policies <xref ta | e integer or a negative integer. Different ranges of values use different regist | |||
rget="RFC8126"/>. Integer values from -256 to 255 are designated as "Standards A | ration policies <xref target="RFC8126"/>. Integer values from -256 to 255 are de | |||
ction With Expert Review". Integer values from -65536 to -257 and from 256 to 65 | signated as "Standards Action With Expert Review". Integer values from -65536 to | |||
535 are designated as "Specification Required". Integer values greater than 6553 | -257 and from 256 to 65535 are designated as "Specification Required". Integer | |||
5 are designated as "Expert Review". Integer values less than -65536 are marked | values greater than 65535 are designated as "Expert Review". Integer values less | |||
as "Private Use".</li> | than -65536 are marked as "Private Use".</dd> | |||
<li>Name: The name of the group rekeying scheme.</li> | <dt>Name:</dt><dd> The name of the group rekeying scheme.</dd> | |||
<li>Description: This field contains a brief description of the group | <dt>Description:</dt><dd> This field contains a brief description of t | |||
rekeying scheme.</li> | he group rekeying scheme.</dd> | |||
<li>Reference: This field contains a pointer to the public specificati | <dt>Reference:</dt><dd> This field contains a pointer to the public sp | |||
on defining the group rekeying scheme, if one exists.</li> | ecification defining the group rekeying scheme, if one exists.</dd> | |||
</ul> | </dl> | |||
<t>This registry has been initially populated with the value in <xref ta rget="rekeying-scheme-0"/>.</t> | <t>This registry has been initially populated with the value in <xref ta rget="rekeying-scheme-0"/>.</t> | |||
</section> | </section> | |||
<section anchor="review"> | <section anchor="review"> | |||
<name>Expert Review Instructions</name> | <name>Expert Review Instructions</name> | |||
<t>The IANA Registries established in this document are defined as exper t review. | <t>The IANA registries established in this document are defined as Exper t Review. | |||
This section gives some general guidelines for what the experts should be lookin g for, but they are being designated as experts for a reason so they should be g iven substantial latitude.</t> | This section gives some general guidelines for what the experts should be lookin g for, but they are being designated as experts for a reason so they should be g iven substantial latitude.</t> | |||
<t>Expert reviewers should take into consideration the following points: </t> | <t>Expert Reviewers should take into consideration the following points: </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li>Point squatting should be discouraged. Reviewers are encouraged to | <li>Point squatting should be discouraged. Reviewers are encouraged to | |||
get sufficient information for registration requests to ensure that the usage i | get sufficient information for registration requests to ensure that the usage i | |||
s not going to duplicate one that is already registered and that the point is li | s not going to duplicate one that is already registered and that the point is li | |||
kely to be used in deployments. The zones tagged as private use are intended for | kely to be used in deployments. The zones tagged as "Private Use" are intended f | |||
testing purposes and closed environments, code points in other ranges should no | or testing purposes and closed environments; code points in other ranges should | |||
t be assigned for testing.</li> | not be assigned for testing.</li> | |||
<li>Specifications are required for the standards track range of point | <li>Specifications are required for the Standards Track range of point | |||
assignment. Specifications should exist for specification required ranges, but | assignment. Specifications should exist for Specification Required ranges, but | |||
early assignment before a specification is available is considered to be permiss | early assignment before a specification is available is considered to be permiss | |||
ible. When specifications are not provided, the description provided needs to ha | ible. When specifications are not provided, the description provided needs to ha | |||
ve sufficient information to identify what the point is being used for.</li> | ve sufficient information to identify what the point is being used for.</li> | |||
<li>Experts should take into account the expected usage of fields when | <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 | 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 assi | documents does not mean that a Standards Track document cannot have points assi | |||
gned outside of that range. The length of the encoded value should be weighed ag | gned outside of that range. The length of the encoded value should be weighed ag | |||
ainst how many code points of that length are left, the size of device it will b | ainst how many code points of that length are left, the size of the device it wi | |||
e used on, and the number of code points left that encode to that size.</li> | ll be used on, and the number of code points left that encode to that size.</li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <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-DISCO | ||||
VERY"/> | ||||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references> | <references> | |||
<name>Normative References</name> | <name>Normative References</name> | |||
<reference anchor="RFC2119"> | ||||
<front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21 | |||
<title>Key words for use in RFCs to Indicate Requirement Levels</tit | 19.xml"/> | |||
le> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.36 | |||
<author fullname="S. Bradner" initials="S." surname="Bradner"/> | 29.xml"/> | |||
<date month="March" year="1997"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.66 | |||
<abstract> | 90.xml"/> | |||
<t>In many standards track documents several words are used to sig | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.67 | |||
nify the requirements in the specification. These words are often capitalized. T | 49.xml"/> | |||
his document defines these words as they should be interpreted in IETF documents | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.68 | |||
. This document specifies an Internet Best Current Practices for the Internet Co | 38.xml"/> | |||
mmunity, and requests discussion and suggestions for improvements.</t> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81 | |||
</abstract> | 26.xml"/> | |||
</front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81 | |||
<seriesInfo name="BCP" value="14"/> | 74.xml"/> | |||
<seriesInfo name="RFC" value="2119"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86 | |||
<seriesInfo name="DOI" value="10.17487/RFC2119"/> | 10.xml"/> | |||
</reference> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.72 | |||
<reference anchor="RFC3629"> | 52.xml"/> | |||
<front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79 | |||
<title>UTF-8, a transformation format of ISO 10646</title> | 67.xml"/> | |||
<author fullname="F. Yergeau" initials="F." surname="Yergeau"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87 | |||
<date month="November" year="2003"/> | 47.xml"/> | |||
<abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89 | |||
<t>ISO/IEC 10646-1 defines a large character set called the Univer | 49.xml"/> | |||
sal Character Set (UCS) which encompasses most of the world's writing systems. T | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90 | |||
he originally proposed encodings of the UCS, however, were not compatible with m | 52.xml"/> | |||
any current applications and protocols, and this has led to the development of U | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90 | |||
TF-8, the object of this memo. UTF-8 has the characteristic of preserving the fu | 53.xml"/> | |||
ll US-ASCII range, providing compatibility with file systems, parsers and other | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92 | |||
software that rely on US-ASCII values but are transparent to other values. This | 00.xml"/> | |||
memo obsoletes and replaces RFC 2279.</t> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92 | |||
</abstract> | 37.xml"/> | |||
</front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92 | |||
<seriesInfo name="STD" value="63"/> | 90.xml"/> | |||
<seriesInfo name="RFC" value="3629"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93 | |||
<seriesInfo name="DOI" value="10.17487/RFC3629"/> | 38.xml"/> | |||
</reference> | ||||
<reference anchor="RFC6690"> | <reference anchor="COSE.Algorithms" target="https://www.iana.org/assignm | |||
<front> | ents/cose/"> | |||
<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, a | ||||
nd other relationships between links. Based on the HTTP Link Header field define | ||||
d in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carrie | ||||
d as a payload and is assigned an Internet media type. "RESTful" refers to the R | ||||
epresentational 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="Har | ||||
dt"/> | ||||
<date month="October" year="2012"/> | ||||
<abstract> | ||||
<t>The OAuth 2.0 authorization framework enables a third-party app | ||||
lication to obtain limited access to an HTTP service, either on behalf of a reso | ||||
urce owner by orchestrating an approval interaction between the resource owner a | ||||
nd 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 prot | ||||
ocol 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 regi | ||||
stration of media types for use in HTTP, MIME, and other Internet protocols. Thi | ||||
s 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 con | ||||
stants to identify various protocol parameters. To ensure that the values in the | ||||
se fields do not have conflicting uses and to promote interoperability, their al | ||||
locations 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 des | ||||
cribing the conditions under which new values should be assigned, as well as whe | ||||
n 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 Consideratio | ||||
ns 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 52 | ||||
26.</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</ti | ||||
tle> | ||||
<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 protoco | ||||
l 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 Convent | ||||
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu | ||||
res</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 Conci | ||||
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal | ||||
is to provide an easy and unambiguous way to express structures for protocol me | ||||
ssages 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 we | ||||
b transfer protocol for use with constrained nodes and constrained (e.g., low-po | ||||
wer, lossy) networks. The nodes often have 8-bit microcontrollers with small amo | ||||
unts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wire | ||||
less 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-ma | ||||
chine (M2M) applications such as smart energy and building automation.</t> | ||||
<t>CoAP provides a request/response interaction model between appl | ||||
ication endpoints, supports built-in discovery of services and resources, and in | ||||
cludes key concepts of the Web such as URIs and Internet media types. CoAP is de | ||||
signed to easily interface with HTTP for integration with the Web while meeting | ||||
specialized requirements such as multicast support, very low overhead, and simpl | ||||
icity 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="Bhattacha | ||||
ryya"/> | ||||
<author fullname="S. Bandyopadhyay" initials="S." surname="Bandyopad | ||||
hyay"/> | ||||
<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 re | ||||
sponses 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 resou | ||||
rce consumption in constrained systems while updating many resources simultaneou | ||||
sly 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 indica | ||||
ting "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 disint | ||||
erest in all responses against the particular request. This option also provides | ||||
granular control to enable expression of disinterest to a particular response c | ||||
lass 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 th | ||||
e No-Response option in the request. This option may be effective for both unica | ||||
st and multicast requests. This document also discusses a few examples of applic | ||||
ations 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 a | ||||
lso sometimes described as being the holder-of-key. This specification provides | ||||
equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Toke | ||||
ns (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 forma | ||||
t whose design goals include the possibility of extremely small code size, fairl | ||||
y small message size, and extensibility without the need for version negotiation | ||||
. These design goals make it different from earlier binary serializations such a | ||||
s ASN.1 and MessagePack.</t> | ||||
<t>This document obsoletes RFC 7049, providing editorial improveme | ||||
nts, new details, and errata fixes while keeping full compatibility with the int | ||||
erchange 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 Pro | ||||
cess</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 de | ||||
signed 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 encrypt | ||||
ion 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 de | ||||
signed 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 se | ||||
t of algorithms that can be used with the CBOR Object Signing and Encryption (CO | ||||
SE) 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 a | ||||
uthorization in Internet of Things (IoT) environments called ACE-OAuth. The fram | ||||
ework is based on a set of building blocks including OAuth 2.0 and the Constrain | ||||
ed Application Protocol (CoAP), thus transforming a well-known and widely used a | ||||
uthorization solution into a form suitable for IoT devices. Existing specificati | ||||
ons are used where possible, but extensions are added and profiles are defined t | ||||
o 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 pr | ||||
oducing an overall system that is secure. Conveying precise authorization inform | ||||
ation is especially critical in highly automated systems with large numbers of e | ||||
ntities, such as the Internet of Things.</t> | ||||
<t>This specification provides a generic information model and for | ||||
mat for representing such authorization information, as well as two variants of | ||||
a specific instantiation of that format for use with Representational State Tran | ||||
sfer (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 ca | ||||
rry machine-readable details of errors in a Representational State Transfer (RES | ||||
T) 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 mor | ||||
e 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 de | ||||
signed for small code size and small message size. CBOR Object Signing and Encry | ||||
ption (COSE) defines a set of security services for CBOR. This document defines | ||||
a countersignature algorithm along with the needed header parameters and CBOR ta | ||||
gs 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> | ||||
<reference anchor="COSE.Algorithms" target="https://www.iana.org/assignm | ||||
ents/cose/cose.xhtml#algorithms"> | ||||
<front> | <front> | |||
<title>COSE Algorithms</title> | <title>COSE Algorithms</title> | |||
<author> | <author> | |||
<organization>IANA</organization> | <organization>IANA</organization> | |||
</author> | </author> | |||
<date/> | ||||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="COSE.Header.Parameters" target="https://www.iana.org/ | ||||
assignments/cose/cose.xhtml#header-parameters"> | <reference anchor="COSE.Header.Parameters" target="https://www.iana.org/ | |||
assignments/cose/"> | ||||
<front> | <front> | |||
<title>COSE Header Parameters</title> | <title>COSE Header Parameters</title> | |||
<author> | <author> | |||
<organization>IANA</organization> | <organization>IANA</organization> | |||
</author> | </author> | |||
<date/> | ||||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="COSE.Key.Types" target="https://www.iana.org/assignme | ||||
nts/cose/cose.xhtml#key-type"> | <reference anchor="COSE.Key.Types" target="https://www.iana.org/assignme | |||
nts/cose/"> | ||||
<front> | <front> | |||
<title>COSE key Types</title> | <title>COSE Key Types</title> | |||
<author> | <author> | |||
<organization>IANA</organization> | <organization>IANA</organization> | |||
</author> | </author> | |||
<date/> | ||||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="CBOR.Tags" target="https://www.iana.org/assignments/c | ||||
bor-tags/cbor-tags.xhtml"> | <reference anchor="CBOR.Tags" target="https://www.iana.org/assignments/c | |||
bor-tags/"> | ||||
<front> | <front> | |||
<title>Concise Binary Object Representation (CBOR) Tags</title> | <title>Concise Binary Object Representation (CBOR) Tags</title> | |||
<author> | <author> | |||
<organization>IANA</organization> | <organization>IANA</organization> | |||
</author> | </author> | |||
<date/> | ||||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="CoAP.Content.Formats" target="https://www.iana.org/as | ||||
signments/core-parameters/core-parameters.xhtml#content-formats"> | <reference anchor="CoAP.Content.Formats" target="https://www.iana.org/as | |||
signments/core-parameters/"> | ||||
<front> | <front> | |||
<title>CoAP Content-Formats</title> | <title>CoAP Content-Formats</title> | |||
<author> | <author> | |||
<organization>IANA</organization> | <organization>IANA</organization> | |||
</author> | </author> | |||
<date/> | ||||
</front> | </front> | |||
</reference> | </reference> | |||
</references> | </references> | |||
<references> | <references> | |||
<name>Informative References</name> | <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 symmet | ||||
ric keys and distribute them amongst communicating peers. This memo defines an E | ||||
xperimental 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 symmet | ||||
ric keys and distribute them amongst communicating peers. This memo defines an E | ||||
xperimental 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 k | ||||
ey management for multicast communication sessions. It focuses on two main areas | ||||
of concern with respect to key management, which are, initializing the multicas | ||||
t group with a common net key and rekeying the multicast group. This memo provid | ||||
es 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 ch | ||||
aracters that identifies an abstract or physical resource. This specification de | ||||
fines the generic URI syntax and a process for resolving URI references that mig | ||||
ht be in relative form, along with guidelines and security considerations for th | ||||
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers | ||||
et of all valid URIs, allowing an implementation to parse the common components | ||||
of a URI reference without knowing the scheme-specific requirements of every pos | ||||
sible identifier. This specification does not define a generative grammar for UR | ||||
Is; 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 Cert | ||||
ificate 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 certif | ||||
icate revocation list (CRL) for use in the Internet. An overview of this approac | ||||
h and model is provided as an introduction. The X.509 v3 certificate format is d | ||||
escribed in detail, with additional information regarding the format and semanti | ||||
cs of Internet name forms. Standard certificate extensions are described and two | ||||
Internet-specific extensions are defined. A set of required certificate extensi | ||||
ons is specified. The X.509 v2 CRL format is described in detail along with stan | ||||
dard and Internet-specific extensions. An algorithm for X.509 certification path | ||||
validation is described. An ASN.1 module and examples are provided in the appen | ||||
dices. [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 representi | ||||
ng 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) stru | ||||
cture or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the | ||||
claims to be digitally signed or integrity protected with a Message Authenticat | ||||
ion 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 applic | ||||
ation 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 exte | ||||
nsion for CoAP that enables CoAP clients to "observe" resources, i.e., to retrie | ||||
ve a representation of a resource and keep this representation updated by the se | ||||
rver over a period of time. The protocol follows a best-effort approach for send | ||||
ing 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="Sh | ||||
elby"/> | ||||
<date month="August" year="2016"/> | ||||
<abstract> | ||||
<t>The Constrained Application Protocol (CoAP) is a RESTful transf | ||||
er protocol for constrained nodes and networks. Basic CoAP messages work well fo | ||||
r 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 work of segmenting and resequencing, | ||||
CoAP is based on datagram transports such as UDP or Datagram Transport Layer Sec | ||||
urity (DTLS). These transports only offer fragmentation, which is even more prob | ||||
lematic 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 exte | ||||
nds basic CoAP with a pair of "Block" options for transferring multiple blocks o | ||||
f information from a resource representation in multiple request-response pairs. | ||||
In many important cases, the Block options enable a server to be truly stateles | ||||
s: the server can handle each block transfer separately, with no need for a conn | ||||
ection setup or other server-side memory of previous block transfers. Essentiall | ||||
y, the Block options provide a minimal way to transfer larger representations in | ||||
a block-wise fashion.</t> | ||||
<t>A CoAP implementation that does not support these options gener | ||||
ally is limited in the size of the representations that can be exchanged, so the | ||||
re is an expectation that the Block options will be widely used in CoAP implemen | ||||
tations. 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 ECMAScrip | ||||
t Programming Language Standard. JSON defines a small set of formatting rules fo | ||||
r the portable representation of structured data.</t> | ||||
<t>This document removes inconsistencies with other specifications | ||||
of JSON, repairs specification errors, and offers experience-based interoperabi | ||||
lity 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 Co | ||||
ncise Binary Object Representation (CBOR), and CBOR Object Signing and Encryptio | ||||
n (COSE) is used for added application-layer security protection. A claim is a p | ||||
iece 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 E | ||||
nvironments (OSCORE), a method for application-layer protection of the Constrain | ||||
ed Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). | ||||
OSCORE provides end-to-end protection between endpoints communicating using CoA | ||||
P or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks s | ||||
upporting a range of proxy operations, including translation between different t | ||||
ransport protocols.</t> | ||||
<t>Although an optional functionality of CoAP, OSCORE alters CoAP | ||||
options processing and IANA registration. Therefore, this document updates RFC 7 | ||||
252.</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 Authenti | ||||
cation 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 constrain | ||||
ed servers to delegate client authentication and authorization. The protocol rel | ||||
ies 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 resourc | ||||
e-constrained server can use this protocol to delegate management of authorizati | ||||
on information to a trusted host with less-severe limitations regarding processi | ||||
ng 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 (OSC | ||||
ORE) Profile of the Authentication and Authorization for Constrained Environment | ||||
s (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 Au | ||||
thorization for Constrained Environments (ACE) framework. It utilizes Object Sec | ||||
urity for Constrained RESTful Environments (OSCORE) to provide communication sec | ||||
urity and proof-of-possession for a key owned by the client and bound to an OAut | ||||
h 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 Represen | ||||
tation (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 Bina | ||||
ry Object Representation (CBOR) data items that is friendly to common systems th | ||||
at 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 Laye | ||||
r Security (TLS) Profile of Authentication and Authorization for Constrained Env | ||||
ironments (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 Au | ||||
thorization for Constrained Environments (ACE) framework to enable authorization | ||||
in a publish-subscribe messaging system based on Message Queuing Telemetry Tran | ||||
sport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are us | ||||
ed to authenticate and authorize MQTT Clients. The protocol relies on TLS for co | ||||
nfidentiality and MQTT server (Broker) authentication.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9431"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9431"/> | ||||
</reference> | ||||
<reference anchor="I-D.ietf-core-groupcomm-bis"> | ||||
<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 Applicati | ||||
on | ||||
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 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> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 | |||
</abstract> | 093.xml"/> | |||
</front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-core-groupcomm-bis | 094.xml"/> | |||
-10"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 | |||
</reference> | 627.xml"/> | |||
<reference anchor="I-D.ietf-core-oscore-groupcomm"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 | |||
<front> | 986.xml"/> | |||
<title>Group Object Security for Constrained RESTful Environments (G | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 | |||
roup OSCORE)</title> | 280.xml"/> | |||
<author fullname="Marco Tiloca" initials="M." surname="Tiloca"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | |||
<organization>RISE AB</organization> | 519.xml"/> | |||
</author> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | |||
<author fullname="Göran Selander" initials="G." surname="Selander"> | 641.xml"/> | |||
<organization>Ericsson AB</organization> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | |||
</author> | 959.xml"/> | |||
<author fullname="Francesca Palombini" initials="F." surname="Palomb | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | |||
ini"> | 259.xml"/> | |||
<organization>Ericsson AB</organization> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | |||
</author> | 392.xml"/> | |||
<author fullname="John Preuß Mattsson" initials="J. P." surname="Mat | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | |||
tsson"> | 613.xml"/> | |||
<organization>Ericsson AB</organization> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | |||
</author> | 202.xml"/> | |||
<author fullname="Jiye Park" initials="J." surname="Park"> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | |||
<organization>Universitaet Duisburg-Essen</organization> | 203.xml"/> | |||
</author> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | |||
<date day="2" month="September" year="2023"/> | 277.xml"/> | |||
<abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | |||
<t> This document defines the security protocol Group Object Sec | 431.xml"/> | |||
urity 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> | <!-- [I-D.ietf-core-groupcomm-bis] IESG state: I-D Exists as of 02/26/24 --> | |||
</abstract> | <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-co | |||
</front> | re-groupcomm-bis.xml"/> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-core-oscore-groupc | ||||
omm-20"/> | ||||
</reference> | ||||
<reference anchor="I-D.ietf-core-coap-pubsub"> | ||||
<front> | ||||
<title>A publish-subscribe architecture for the Constrained Applicat | ||||
ion 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 | ||||
of CoAP 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 acting | ||||
as broker. | ||||
</t> | <!-- [I-D.ietf-core-oscore-groupcomm] IESG state: I-D Exists as of 02/26/24 | |||
</abstract> | Long way used to fix "Mattsson, J. P."--> | |||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-core-coap-pubsub-1 | ||||
3"/> | ||||
</reference> | ||||
<reference anchor="I-D.ietf-cose-cbor-encoded-cert"> | ||||
<front> | ||||
<title>CBOR Encoded X.509 Certificates (C509 Certificates)</title> | ||||
<author fullname="John Preuß Mattsson" initials="J. P." surname="Mat | ||||
tsson"> | ||||
<organization>Ericsson AB</organization> | ||||
</author> | ||||
<author fullname="Göran Selander" initials="G." surname="Selander"> | ||||
<organization>Ericsson AB</organization> | ||||
</author> | ||||
<author fullname="Shahid Raza" initials="S." surname="Raza"> | ||||
<organization>RISE AB</organization> | ||||
</author> | ||||
<author fullname="Joel Höglund" initials="J." surname="Höglund"> | ||||
<organization>RISE AB</organization> | ||||
</author> | ||||
<author fullname="Martin Furuhed" initials="M." surname="Furuhed"> | ||||
<organization>Nexus Group</organization> | ||||
</author> | ||||
<date day="20" month="October" year="2023"/> | ||||
<abstract> | ||||
<t> This document specifies a CBOR encoding of X.509 certificate | ||||
s. 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> | <reference anchor="I-D.ietf-core-oscore-groupcomm" target="https://datatracker.i | |||
</abstract> | etf.org/doc/html/draft-ietf-core-oscore-groupcomm-21"> | |||
</front> | <front> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-cose-cbor-encoded- | <title> | |||
cert-07"/> | Group Object Security for Constrained RESTful Environments (Group OSCORE) | |||
</reference> | </title> | |||
<reference anchor="I-D.tiloca-core-oscore-discovery"> | <author initials="M." surname="Tiloca" fullname="Marco Tiloca"> | |||
<front> | <organization>RISE AB</organization> | |||
<title>Discovery of OSCORE Groups with the CoRE Resource Directory</ | </author> | |||
title> | <author initials="G." surname="Selander" fullname="Göran Selander"> | |||
<author fullname="Marco Tiloca" initials="M." surname="Tiloca"> | <organization>Ericsson AB</organization> | |||
<organization>RISE AB</organization> | </author> | |||
</author> | <author initials="F." surname="Palombini" fullname="Francesca Palombini"> | |||
<author fullname="Christian Amsüss" initials="C." surname="Amsüss"> | <organization>Ericsson AB</organization> | |||
</author> | </author> | |||
<author fullname="Peter Van der Stok" initials="P." surname="Van der | <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson"> | |||
Stok"> | <organization>Ericsson AB</organization> | |||
<organization>Consultant</organization> | </author> | |||
</author> | <author initials="R." surname="Höglund" fullname="Rikard Höglund"> | |||
<date day="8" month="September" year="2023"/> | <organization>RISE AB</organization> | |||
<abstract> | </author> | |||
<t> Group communication over the Constrained Application Protoco | <date month="March" day="4" year="2024"/> | |||
l (CoAP) | </front> | |||
can be secured by means of Group Object Security for Constrained | <seriesInfo name="Internet-Draft" value="draft-ietf-core-oscore-groupcomm-21"/> | |||
RESTful Environments (Group OSCORE). At deployment time, devices may | </reference> | |||
not know the exact security groups to join, the respective Group | ||||
Manager, or other information required to perform the joining | <!-- [I-D.ietf-core-coap-pubsub] IESG state: I-D Exists as of 02/26/24 --> | |||
process. This document describes how a CoAP endpoint can use | <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-co | |||
descriptions and links of resources registered at the CoRE Resource | re-coap-pubsub.xml"/> | |||
Directory to discover security groups and to acquire information for | ||||
joining them through the respective Group Manager. A given security | <!-- [I-D.ietf-cose-cbor-encoded-cert] IESG state: I-D Exists as of 7/7/24 | |||
group may protect multiple application groups, which are separately | Long way used to fix "Mattsson, J. P."--> | |||
announced in the Resource Directory as sets of endpoints sharing a | <reference anchor="I-D.ietf-cose-cbor-encoded-cert" target="https://datatracker. | |||
pool of resources. This approach is consistent with, but not limited | ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-11"> | |||
to, the joining of security groups based on the ACE framework for | <front> | |||
Authentication and Authorization in constrained environments. | <title> | |||
CBOR Encoded X.509 Certificates (C509 Certificates) | ||||
</title> | ||||
<author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson"> | ||||
<organization>Ericsson AB</organization> | ||||
</author> | ||||
<author initials="G." surname="Selander" fullname="Göran Selander"> | ||||
<organization>Ericsson AB</organization> | ||||
</author> | ||||
<author initials="S." surname="Raza" fullname="Shahid Raza"> | ||||
<organization>RISE AB</organization> | ||||
</author> | ||||
<author initials="J." surname="Höglund" fullname="Joel Höglund"> | ||||
<organization>RISE AB</organization> | ||||
</author> | ||||
<author initials="M." surname="Furuhed" fullname="Martin Furuhed"> | ||||
<organization>Nexus Group</organization> | ||||
</author> | ||||
<date month="July" day="8" year="2024"/> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-ietf-cose-cbor-encoded-cert-11"/> | ||||
</reference> | ||||
<!-- [I-D.tiloca-core-oscore-discovery] IESG state: I-D Exists as of 02/26/24 -- | ||||
> | ||||
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-tiloca- | ||||
core-oscore-discovery.xml"/> | ||||
</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="Internet-Draft" value="draft-tiloca-core-oscore-disc | ||||
overy-14"/> | ||||
</reference> | ||||
</references> | </references> | |||
</references> | </references> | |||
<section anchor="req"> | <section anchor="req"> | |||
<name>Requirements for Application Profiles</name> | <name>Requirements for Application Profiles</name> | |||
<t>This section lists the requirements for application profiles of this sp ecification, for the convenience of application profile designers.</t> | <t>This section lists the requirements for application profiles of this sp ecification for the convenience of application profile designers.</t> | |||
<section anchor="req-mandatory"> | <section anchor="req-mandatory"> | |||
<name>Mandatory-to-Address Requirements</name> | <name>Mandatory-to-Address Requirements</name> | |||
<ul spacing="normal"> | <ol type="REQ%d:"> | |||
<li>REQ1: Specify the format and encoding of 'scope'. This includes de | <li anchor="req1">Specify the format and encoding of scope. This inclu | |||
fining the set of possible roles and their identifiers, as well as the correspon | des defining the set of possible roles and their identifiers, as well as the cor | |||
ding encoding to use in the scope entries according to the used scope format (se | responding encoding to use in the scope entries according to the used scope form | |||
e <xref target="ssec-authorization-request"/>).</li> | at (see <xref target="ssec-authorization-request"/>).</li> | |||
<li>REQ2: If the AIF format of 'scope' is used, register its specific | <li anchor="req2">If scope uses AIF, register its specific instance of | |||
instance of "Toid" and "Tperm" as Media Type parameters and a corresponding Cont | "Toid" and "Tperm" as media type parameters and a corresponding Content-Format, | |||
ent-Format, as per the guidelines in <xref target="RFC9237"/>.</li> | as per the guidelines in <xref target="RFC9237"/>.</li> | |||
<li>REQ3: If used, specify the acceptable values for 'sign_alg' (see < | <li anchor="req3">If used, specify the acceptable values for the 'sign | |||
xref target="token-post"/>).</li> | _alg' parameter (see <xref target="token-post"/>).</li> | |||
<li>REQ4: If used, specify the acceptable values for 'sign_parameters' | <li anchor="req4">If used, specify the acceptable values and structure | |||
(see <xref target="token-post"/>).</li> | s for the 'sign_parameters' parameter (see <xref target="token-post"/>).</li> | |||
<li>REQ5: If used, specify the acceptable values for 'sign_key_paramet | <li anchor="req5">If used, specify the acceptable values and structure | |||
ers' (see <xref target="token-post"/>).</li> | s for the 'sign_key_parameters' parameter (see <xref target="token-post"/>).</li | |||
<li>REQ6: Specify the acceptable formats for authentication credential | > | |||
s and, if used, the acceptable values for 'cred_fmt' (see <xref target="token-po | <li anchor="req6">Specify the acceptable formats for authentication cr | |||
st"/>).</li> | edentials and, if applicable, the acceptable values for the 'cred_fmt' parameter | |||
<li>REQ7: If the value of the GROUPNAME URI path and the group name in | (see <xref target="token-post"/>).</li> | |||
the access token scope (gname in <xref target="ssec-authorization-response"/>) | <li anchor="req7">If the value of the GROUPNAME URI path and the group | |||
are not required to coincide, specify the mechanism to map the GROUPNAME value i | name in the access token scope ('gname' in <xref target="ssec-authorization-req | |||
n the URI to the group name (see <xref target="kdc-if"/>).</li> | uest"/>) are not required to coincide, specify the mechanism to map the GROUPNAM | |||
<li>REQ8: Define whether the KDC has an authentication credential and | E value in the URI to the group name (see <xref target="kdc-if"/>).</li> | |||
if this has to be provided through the 'kdc_cred' parameter, see <xref target="g | <li anchor="req8">Define whether the KDC has an authentication credent | |||
id-post"/>.</li> | ial as required for the correct group operation and if this has to be provided t | |||
<li>REQ9: Specify if any part of the KDC interface as defined in this | hrough the 'kdc_cred' parameter (see <xref target="gid-post"/>).</li> | |||
document is not supported by the KDC (see <xref target="kdc-if"/>).</li> | <li anchor="req9">Specify if any part of the KDC interface as defined | |||
<li>REQ10: Register a Resource Type for the group-membership resource, | in this document is not supported by the KDC (see <xref target="kdc-if"/>).</li> | |||
which is used to discover the correct URL for sending a Join Request to the KDC | <li anchor="req10">Register a Resource Type for the group-membership r | |||
(see <xref target="kdc-if"/>).</li> | esources, which is used to discover the correct URL for sending a Join Request t | |||
<li>REQ11: Define what specific actions (e.g., CoAP methods) are allow | o the KDC (see <xref target="kdc-if"/>).</li> | |||
ed on each resource provided by the KDC interface, depending on whether the Clie | <li anchor="req11">Define what specific actions (e.g., CoAP methods) a | |||
nt is a current group member; the roles that a Client is authorized to take as p | re allowed on each resource that are accessible through the KDC interface, depen | |||
er the obtained access token (see <xref target="ssec-authorization-request"/>); | ding on: whether the Client is a current group member; the roles that a Client i | |||
and the roles that the Client has as current group member.</li> | s authorized to take as per the obtained access token (see <xref target="ssec-au | |||
<li>REQ12: Categorize possible newly defined operations for Clients in | thorization-request"/>); and the roles that the Client has as a current group me | |||
to primary operations expected to be minimally supported and secondary operation | mber.</li> | |||
s, and provide accompanying considerations (see <xref target="client-operations" | <li anchor="req12">Categorize possible newly defined operations for Cl | |||
/>).</li> | ients into primary operations expected to be minimally supported and secondary o | |||
<li>REQ13: Specify the encoding of group identifier (see <xref target= | perations, and provide accompanying considerations (see <xref target="client-ope | |||
"ace-group-fetch"/>).</li> | rations"/>).</li> | |||
<li>REQ14: Specify the approaches used to compute and verify the PoP e | <li anchor="req13">Specify the encoding of group identifiers (see <xre | |||
vidence to include in 'client_cred_verify', and which of those approaches is use | f target="ace-group-fetch"/>).</li> | |||
d in which case (see <xref target="gid-post"/>).</li> | <li anchor="req14">Specify the approaches used to compute and verify t | |||
<li>REQ15: Specify how the nonce N_S is generated, if the token is not | he PoP evidence to include in the 'client_cred_verify' parameter and which of th | |||
provided to the KDC through the Token Transfer Request to the authz-info endpoi | ose approaches is used in which case (see <xref target="gid-post"/>).</li> | |||
nt (e.g., if it is used directly to validate TLS instead).</li> | <li anchor="req15">Specify how the nonce N_S is generated, if the acce | |||
<li>REQ16 Define the initial value of the 'num' parameter (see <xref t | ss token is not provided to the KDC through the Token Transfer Request sent to t | |||
arget="gid-post"/>).</li> | he /authz-info endpoint (e.g., the access token is instead transferred during th | |||
<li>REQ17: Specify the format of the 'key' parameter and register a co | e establishment of a secure communication association).</li> | |||
rresponding entry in the "ACE Groupcomm Key Types" IANA registry (see <xref targ | <li anchor="req16">Define the initial value of the version number for | |||
et="gid-post"/>).</li> | the group keying material (see <xref target="gid-post"/>).</li> | |||
<li>REQ18: Specify the acceptable values of the 'gkty' parameter (see | <li anchor="req17">Specify the format of the group keying material tha | |||
<xref target="gid-post"/>).</li> | t is conveyed in the 'key' parameter (see <xref target="gid-post"/>).</li> | |||
<li>REQ19: Specify and register the application profile identifier (se | <li anchor="req18">Specify the acceptable values of the 'gkty' paramet | |||
e <xref target="gid-post"/>).</li> | er (see <xref target="gid-post"/>). For each of them, register a corresponding e | |||
<li>REQ20: If used, specify the format and content of 'group_policies' | ntry in the "ACE Groupcomm Key Types" IANA registry if such an entry does not ex | |||
and its entries. Specify the policies default values (see <xref target="gid-pos | ist already.</li> | |||
t"/>).</li> | <li anchor="req19">Specify and register the application profile identi | |||
<li>REQ21: Specify the approaches used to compute and verify the PoP e | fier (see <xref target="gid-post"/>).</li> | |||
vidence to include in 'kdc_cred_verify', and which of those approaches is used i | <li anchor="req20">If used, specify the format, content, and default v | |||
n which case (see <xref target="gid-post"/> and <xref target="kdc-pub-key-get"/> | alues of the entries of the CBOR map to include in the 'group_policies' paramete | |||
). If external signature verifiers are supported, specify how those provide a no | r (see <xref target="gid-post"/>).</li> | |||
nce to the KDC to be used for computing the PoP evidence (see <xref target="kdc- | <li anchor="req21">Specify the approaches used to compute and verify t | |||
pub-key-get"/>).</li> | he PoP evidence to include in the 'kdc_cred_verify' parameter and which of those | |||
<li>REQ22: Specify the communication protocol that the members of the | approaches is used in which case (see Sections <xref target="gid-post" format=" | |||
group must use (e.g., CoAP for group communication).</li> | counter"/> and <xref target="kdc-pub-key-get" format="counter"/>). If external s | |||
<li>REQ23: Specify the security protocol the group members must use to | ignature verifiers are supported, specify how those provide a nonce to the KDC t | |||
protect their communication (e.g., group OSCORE). This must provide encryption, | o be used for computing the PoP evidence (see <xref target="kdc-pub-key-get"/>). | |||
integrity, and replay protection.</li> | </li> | |||
<li>REQ24: Specify how the communication is secured between Client and | <li anchor="req22">Specify the communication protocol that members of | |||
KDC. Optionally, specify a transport profile of ACE <xref target="RFC9200"/> to | the group use to communicate with each other (e.g., CoAP for group communication | |||
use between Client and KDC (see <xref target="ssec-key-distribution-exchange"/> | ).</li> | |||
).</li> | <li anchor="req23">Specify the security protocol that members of the g | |||
<li>REQ25: Specify the format of the identifiers of group members (see | roup use to protect the group communication (e.g., Group OSCORE). This must prov | |||
<xref target="gid-post"/> and <xref target="pubkey-fetch"/>).</li> | ide encryption, integrity, and replay protection.</li> | |||
<li>REQ26: Specify policies at the KDC to handle ids that are not incl | <li anchor="req24">Specify how the communication is secured between th | |||
uded in 'get_creds' (see <xref target="pubkey-fetch"/>).</li> | e Client and the KDC. Optionally, specify a transport profile of ACE <xref targe | |||
<li>REQ27: Specify the format of newly-generated individual keying mat | t="RFC9200"/> to use between the Client and the KDC (see <xref target="ssec-key- | |||
erial for group members, or of the information to derive it, and corresponding C | distribution-exchange"/>).</li> | |||
BOR label (see <xref target="node-get"/>).</li> | <li anchor="req25">Specify the format of the node identifiers of group | |||
<li>REQ28: Specify which CBOR tag is used for identifying the semantic | members (see Sections <xref target="gid-post" format="counter"/> and <xref targ | |||
s of binary scopes, or register a new CBOR tag if a suitable one does not exist | et="pubkey-fetch" format="counter"/>).</li> | |||
already (see <xref target="sec-extended-scope"/>).</li> | <li anchor="req26">Specify policies at the KDC to handle node identifi | |||
<li>REQ29: Categorize newly defined parameters according to the same c | ers that are included in the 'get_creds' parameter but are not associated with a | |||
riteria of <xref target="params"/>.</li> | ny current group member (see <xref target="pubkey-fetch"/>).</li> | |||
<li>REQ30: Define whether Clients must, should, or may support the con | <li anchor="req27">Specify the format of (newly generated) individual | |||
ditional parameters defined in <xref target="params"/>, and under which circumst | keying material for group members or of the information to derive such keying ma | |||
ances.</li> | terial, as well as the corresponding CBOR map key that has to be registered in t | |||
</ul> | he "ACE Groupcomm Parameters" registry (see Sections <xref target="node-get" for | |||
mat="counter"/> and <xref target="node-put" format="counter"/>).</li> | ||||
<li anchor="req28">Specify which CBOR tag is used for identifying the | ||||
semantics of binary scopes, or register a new CBOR tag if a suitable one does no | ||||
t exist already (see <xref target="sec-extended-scope"/>).</li> | ||||
<li anchor="req29">Categorize newly defined parameters according to th | ||||
e same criteria of <xref target="params"/>.</li> | ||||
<li anchor="req30">Define whether Clients must, should, or may support | ||||
the conditional parameters defined in <xref target="params"/> and under which c | ||||
ircumstances.</li> | ||||
</ol> | ||||
</section> | </section> | |||
<section anchor="req-optional"> | <section anchor="req-optional"> | |||
<name>Optional-to-Address Requirements</name> | <name>Optional-to-Address Requirements</name> | |||
<ul spacing="normal"> | <ol type="OPT%d:"> | |||
<li>OPT1: Optionally, if the textual format of 'scope' is used, specif | <li anchor="opt1">Optionally, if the textual format of scope is used, | |||
y CBOR values to use for abbreviating the role identifiers in the group (see <xr | specify CBOR values to use for abbreviating the role identifiers in the group (s | |||
ef target="ssec-authorization-request"/>).</li> | ee <xref target="ssec-authorization-request"/>).</li> | |||
<li>OPT2: Optionally, specify the additional parameters used in the ex | <li anchor="opt2">Optionally, specify the additional parameters used i | |||
change of Token Transfer Request and Response (see <xref target="token-post"/>). | n the exchange of Token Transfer Request and Response (see <xref target="token-p | |||
</li> | ost"/>).</li> | |||
<li>OPT3: Optionally, specify the negotiation of parameter values for | <li anchor="opt3">Optionally, specify the negotiation of parameter val | |||
signature algorithm and signature keys, if 'sign_info' is not used (see <xref ta | ues for signature algorithm and signature keys, if the 'sign_info' parameter is | |||
rget="token-post"/>).</li> | not used (see <xref target="token-post"/>).</li> | |||
<li>OPT4: Optionally, specify possible or required payload formats for | <li anchor="opt4">Optionally, specify possible or required payload for | |||
specific error cases.</li> | mats for specific error cases (see <xref target="kdc-if-errors"/>).</li> | |||
<li>OPT5: Optionally, specify additional identifiers of error types, a | <li anchor="opt5">Optionally, specify additional identifiers of error | |||
s values of the 'error-id' field within the Custom Problem Detail entry 'ace-gro | types as values of the 'error-id' field within the Custom Problem Detail entry ' | |||
upcomm-error' (see <xref target="kdc-if-errors"/>).</li> | ace-groupcomm-error' (see <xref target="kdc-if-errors"/>).</li> | |||
<li>OPT6: Optionally, specify the encoding of 'creds_repo' if the defa | <li anchor="opt6">Optionally, specify the encoding of the 'creds_repo' | |||
ult is not used (see <xref target="gid-post"/>).</li> | parameter if the default one is not used (see <xref target="gid-post"/>).</li> | |||
<li>OPT7: Optionally, specify the functionalities implemented at the ' | <li anchor="opt7">Optionally, specify the functionalities implemented | |||
control_uri' resource hosted at the Client, including message exchange encoding | at the resource hosted by the Client at the URI indicated in the 'control_uri' p | |||
and other details (see <xref target="gid-post"/>).</li> | arameter, including the encoding of exchanged messages and other details (see <x | |||
<li>OPT8: Optionally, specify the behavior of the handler in case of f | ref target="gid-post"/>).</li> | |||
ailure to retrieve an authentication credential for the specific node (see <xref | <li anchor="opt8">Optionally, specify the behavior of the POST handler | |||
target="gid-post"/>).</li> | of group-membership resources, for the case when it fails to retrieve an authen | |||
<li>OPT9: Optionally, define a default group rekeying scheme, to refer | tication credential for the specific Client (see <xref target="gid-post"/>).</li | |||
to in case the 'rekeying_scheme' parameter is not included in the Join Response | > | |||
(see <xref target="gid-post"/>).</li> | <li anchor="opt9">Optionally, define a default group rekeying scheme t | |||
<li>OPT10: Optionally, specify the functionalities implemented at the | o refer to in case the 'rekeying_scheme' parameter is not included in the Join R | |||
'control_group_uri' resource hosted at the Client, including message exchange en | esponse (see <xref target="gid-post"/>).</li> | |||
coding and other details (see <xref target="gid-post"/>).</li> | <li anchor="opt10">Optionally, specify the functionalities implemented | |||
<li>OPT11: Optionally, specify policies that instruct Clients to retai | at the resource hosted by the Client at the URI indicated in the 'control_group | |||
n messages and for how long, if they are unsuccessfully decrypted (see <xref tar | _uri' parameter, including the encoding of exchanged messages and other details | |||
get="update-keys"/>). This makes it possible to decrypt such messages after gett | (see <xref target="gid-post"/>).</li> | |||
ing updated keying material.</li> | <li anchor="opt11">Optionally, specify policies that instruct Clients | |||
<li>OPT12: Optionally, specify for the KDC to perform group rekeying ( | to retain messages and for how long, if those are unsuccessfully decrypted (see | |||
together or instead of renewing individual keying material) when receiving a Key | <xref target="update-keys"/>). This makes it possible for Clients to decrypt suc | |||
Renewal Request (see <xref target="new-keys"/>).</li> | h messages after obtaining updated keying material.</li> | |||
<li>OPT13: Optionally, specify how the identifier of a group member's | <li anchor="opt12">Optionally, specify for the KDC to perform a group | |||
authentication credential is included in requests sent to other group members (s | rekeying when receiving a Key Renewal Request, together with or instead of renew | |||
ee <xref target="update-pub-key"/>).</li> | ing individual keying material (see <xref target="new-keys"/>).</li> | |||
<li>OPT14: Optionally, specify additional information to include in re | <li anchor="opt13">Optionally, specify how the identifier of a group m | |||
keying messages for the "Point-to-Point" group rekeying scheme (see <xref target | ember's authentication credential is included in requests sent to other group me | |||
="sec-group-rekeying"/>).</li> | mbers (see <xref target="update-pub-key"/>).</li> | |||
</ul> | <li anchor="opt14">Optionally, specify additional information to inclu | |||
de in rekeying messages for the "Point-to-Point" group rekeying scheme (see <xre | ||||
f target="sec-group-rekeying"/>).</li> | ||||
</ol> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="sec-future-cose-algs"> | <section anchor="sec-future-cose-algs"> | |||
<name>Extensibility for Future COSE Algorithms</name> | <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 ta rget="COSE.Algorithms"/> as specifying none or multiple COSE capabilities.</t> | <t>As defined in <xref section="8.1" sectionFormat="of" target="RFC9053"/> , future algorithms can be registered in the "COSE Algorithms" registry <xref ta rget="COSE.Algorithms"/> as specifying none or multiple COSE capabilities.</t> | |||
<t>To enable the seamless use of such future registered algorithms, this s | <t>To enable the seamless use of such future registered algorithms, this s | |||
ection defines a general, agile format for each 'sign_info_entry' of the 'sign_i | ection defines a general, agile format for each 'sign_info_entry' of the 'sign_i | |||
nfo' parameter in the Token Transfer Response, see <xref target="sign-info"/>.</ | nfo' parameter in the Token Transfer Response; see <xref target="sign-info"/>.</ | |||
t> | t> | |||
<t>If any of the currently registered COSE algorithms is considered, using | <t>If any of the currently registered COSE algorithms are considered, usin | |||
this general format yields the same structure of 'sign_info_entry' defined in t | g this general format yields the same structure of 'sign_info_entry' defined in | |||
his document, thus ensuring backward compatibility.</t> | this document, thus ensuring backward compatibility.</t> | |||
<section anchor="sec-future-cose-algs-sign-info-entry"> | <section anchor="sec-future-cose-algs-sign-info-entry"> | |||
<name>Format of 'sign_info_entry'</name> | <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> | <t>The format of each 'sign_info_entry' (see <xref target="sign-info"/>) is generalized as follows.</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <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>'sign_parameters' includes N >= 0 elements, each of which is a COSE capability of the signature algorithm indicated in 'sign_alg'. </t> | |||
<t> | <t> | |||
In particular, 'sign_parameters' has the same format and value of the COSE capab ilities array for the signature algorithm indicated in 'sign_alg', as specified for that algorithm in the 'Capabilities' column of the "COSE Algorithms" registr y <xref target="COSE.Algorithms"/>.</t> | In particular, 'sign_parameters' has the same format and value of the COSE capab ilities array for the signature algorithm indicated in 'sign_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registr y <xref target="COSE.Algorithms"/>.</t> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>'sign_key_parameters' is replaced by N elements 'sign_capab', eac h of which is a CBOR array. </t> | <t>'sign_key_parameters' is replaced by N elements 'sign_capab', eac h of which is a CBOR array. </t> | |||
<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> | 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> | <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> | 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> | <t> | |||
Such a COSE capabilities array is currently defined for the algorithm capability COSE key type, in the "Capabilities" column of the "COSE Key Types" registry <x ref target="COSE.Key.Types"/>.</t> | Such a COSE capabilities array is currently defined for the algorithm capability COSE key type in the "Capabilities" column of the "COSE Key Types" registry <xr ef target="COSE.Key.Types"/>.</t> | |||
</li> | </li> | |||
</ul> | </ul> | |||
<figure anchor="fig-sign-info-entry-general"> | <figure anchor="fig-sign-info-entry-general"> | |||
<name>'sign_info_entry' with general format</name> | <name>'sign_info_entry' with a General Format</name> | |||
<sourcecode type="CDDL"><![CDATA[ | <sourcecode type="CDDL"><![CDATA[ | |||
sign_info_entry = | sign_info_entry = | |||
[ | [ | |||
id : gname / [ + gname ], | id : gname / [ + gname ], | |||
sign_alg : int / tstr, | sign_alg : int / tstr, | |||
sign_parameters : [ * alg_capab : any ], | sign_parameters : [ * alg_capab : any ], | |||
* sign_capab : [ * capab : any ], | * sign_capab : [ * capab : any ], | |||
cred_fmt : int / null | cred_fmt : int / null | |||
] | ] | |||
gname = tstr | gname = tstr | |||
]]></sourcecode> | ]]></sourcecode> | |||
</figure> | </figure> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="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" a | ||||
nd "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 9290 is used 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 have to store the 'cnonce' from a | ||||
Join Request.</li> | ||||
<li>Consistency fix: Clients always support the 'cnonce' parameter.</l | ||||
i> | ||||
<li>Added new parameter 'exi' providing the residual lifetime of the c | ||||
urrent 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 rekeyin | ||||
g.</li> | ||||
<li>Mentioned explicit exceptions to a group rekeying at each group me | ||||
mbership change.</li> | ||||
<li>Explained reasons for delaying a rekeying and halting communicatio | ||||
ns.</li> | ||||
<li>Fixes in current IANA registrations.</li> | ||||
<li>Added integer abbreviation values for registrations in new IANA re | ||||
gistries.</li> | ||||
<li>IANA registration of two CoRE if= values: "ace.group" and "ace.gro | ||||
ups".</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 terminolog | ||||
y.</li> | ||||
<li>Early definition of "backward security" and "forward security".</l | ||||
i> | ||||
<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 resou | ||||
rces.</li> | ||||
<li>Relaxed rule about including the 'peer_roles' parameter.</li> | ||||
<li>Ensured that the KDC always has a Client-side challenge for comput | ||||
ing a proof-of-possession evidence.</li> | ||||
<li>More guidelines for group members that fail to decrypt messages.</ | ||||
li> | ||||
<li>Fetching the latest keying material can happen before the old, sto | ||||
red one expires.</li> | ||||
<li>Renewing the current keying material can happen before it expires. | ||||
</li> | ||||
<li>Moved up the discussion on misalignment of group keying material.< | ||||
/li> | ||||
<li>Expanded security considerations on group rekeying for joining nod | ||||
es.</li> | ||||
<li>Revised size of integer for building AEAD nonces for group rekeyin | ||||
g.</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.</l | ||||
i> | ||||
<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 introduct | ||||
ion.</li> | ||||
<li>Overall clarifications on semantics of operations and parameters.< | ||||
/li> | ||||
<li>Major restructuring in the presentation 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 fr | ||||
om draft-ietf-ace-key-groupcomm-oscore.</li> | ||||
<li>New parameters 'group_rekeying_scheme' and 'control_group_uri'.</l | ||||
i> | ||||
<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/optio | ||||
nal to support for ACE Clients.</li> | ||||
<li>Guidelines on enhanced error responses using 'error' and 'error_de | ||||
scription'.</li> | ||||
<li>New section on 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 sig | ||||
nature keys.</li> | ||||
<li>Node identifiers always indicated with 'peer_identifiers'.</li> | ||||
<li>Format of public keys changed from raw COSE Keys to be certificate | ||||
s, CWTs or CWT Claims Set (CCS). Adapted parameter 'pub_key_enc'.</li> | ||||
<li>Parameters and functionalities imported from draft-ietf-key-groupc | ||||
omm-oscore where early defined.</li> | ||||
<li>Possible provisioning of the KDC's Diffie-Hellman public key in re | ||||
sponse 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 an | ||||
d/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.</l | ||||
i> | ||||
<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/responder | ||||
s.</li> | ||||
<li>Clarification on stopping using owned keying material.</li> | ||||
<li>Clarification on different reasons for processing failures, relate | ||||
d 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 Reques | ||||
t.</li> | ||||
<li>Clarified meaning of requirement REQ3; added requirement OPT12.</l | ||||
i> | ||||
<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 publ | ||||
ic keys.</li> | ||||
<li>Revised and extended profile requirements.</li> | ||||
<li>Clarified specific usage of parameters related to signature algori | ||||
thms/keys.</li> | ||||
<li>Included general content previously in draft-ietf-ace-key-groupcom | ||||
m-oscore</li> | ||||
<li>Registration of media type and content format application/ace-grou | ||||
p+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 par | ||||
ameters, 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 (Sec | ||||
tion 1.1).</li> | ||||
<li>New parameters 'sign_info' and 'pub_key_enc' to negotiate paramete | ||||
r values for signature algorithm and signature keys (Section 3.3).</li> | ||||
<li>New parameter 'type' to distinguish different Key Distribution Req | ||||
uest 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 materia | ||||
l (Section 6).</li> | ||||
<li>Encoding of 'get_pub_keys' in Public Key Request (Section 7.1).</l | ||||
i> | ||||
<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), popul | ||||
ated with the entries in Section 8.</li> | ||||
<li>New "Ace Groupcomm Request Type" IANA registry (Section 11.4), pop | ||||
ulated 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 Reque | ||||
st (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 (Sectio | ||||
n 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 (Secti | ||||
on 5.2).</li> | ||||
<li>Renewal of individual keying material and methods for group rekeyi | ||||
ng initiated by the KDC (Section 6).</li> | ||||
<li>CBOR type for node identifiers in 'get_pub_keys' (Section 7.1).</l | ||||
i> | ||||
<li>Added section on parameter identifiers and their CBOR keys (Sectio | ||||
n 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 P | ||||
rofile registry", "ACE Groupcomm Policy registry" and "Sequence Number Synchroni | ||||
zation 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"> | <section numbered="false" anchor="acknowledgments"> | |||
<name>Acknowledgments</name> | <name>Acknowledgments</name> | |||
<t>The following individuals were helpful in shaping this document: <conta | <t>The following individuals were helpful in shaping this document: <conta | |||
ct fullname="Christian Amsüss"/>, <contact fullname="Carsten Bormann"/>, <contac | ct fullname="Christian Amsüss"/>, <contact fullname="Carsten Bormann"/>, <contac | |||
t fullname="Roman Danyliw"/>, <contact fullname="Martin Duke"/>, <contact fullna | t fullname="Roman Danyliw"/>, <contact fullname="Martin Duke"/>, <contact fullna | |||
me="Thomas Fossati"/>, <contact fullname="Vidhi Goel"/>, <contact fullname="Rika | me="Thomas Fossati"/>, <contact fullname="Vidhi Goel"/>, <contact fullname="Rika | |||
rd Höglund"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Erik Kline"/> | rd Höglund"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Erik Kline"/> | |||
, <contact fullname="Warren Kumari"/>, <contact fullname="Watson Ladd"/>, <conta | , <contact fullname="Warren Kumari"/>, <contact fullname="Watson Ladd"/>, <conta | |||
ct fullname="John Preuß Mattsson"/>, <contact fullname="Daniel Migault"/>, <cont | ct fullname="Daniel Migault"/>, <contact fullname="John Preuß Mattsson"/>, <cont | |||
act fullname="Zaheduzzaman Sarker"/>, <contact fullname="Jim Schaad"/>, <contact | act fullname="Zaheduzzaman Sarker"/>, <contact fullname="Jim Schaad"/>, <contact | |||
fullname="Ludwig Seitz"/>, <contact fullname="Göran Selander"/>, <contact fulln | fullname="Ludwig Seitz"/>, <contact fullname="Göran Selander"/>, <contact fulln | |||
ame="Cigdem Sengul"/>, <contact fullname="Dave Thaler"/>, <contact fullname="Hen | ame="Cigdem Sengul"/>, <contact fullname="Dave Thaler"/>, <contact fullname="Hen | |||
ry Thompson"/>, <contact fullname="Peter van der Stok"/>, and <contact fullname= | ry Thompson"/>, <contact fullname="Peter van der Stok"/>, and <contact fullname= | |||
"Paul Wouters"/>.</t> | "Paul Wouters"/>.</t> | |||
<t>The work on this document has been partly supported by VINNOVA and the | <t>The work on this document has been partly supported by the Sweden's Inn | |||
Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home (Grant agreement 9 | ovation Agency VINNOVA and the Celtic-Next project CRITISEC, by the H2020 projec | |||
52652); and by the EIT-Digital High Impact Initiative ACTIVE.</t> | t SIFIS-Home (Grant agreement 952652), and by the EIT-Digital High Impact Initia | |||
tive ACTIVE.</t> | ||||
</section> | </section> | |||
</back> | </back> | |||
<!-- ##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= | ||||
</rfc> | </rfc> | |||
End of changes. 380 change blocks. | ||||
4719 lines changed or deleted | 2894 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |