commit 0282b071b064bd1d73bcff35ab3f69ccd4e47386
parent ff5479db2f1a3cb735c296494b8908148d15e954
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 8 Apr 2024 15:28:27 +0200
Start updating and improving reclaimID protocol.
Diffstat:
1 file changed, 78 insertions(+), 52 deletions(-)
diff --git a/draft-schanzen-reclaimid.xml b/draft-schanzen-reclaimid.xml
@@ -247,67 +247,59 @@
issued by a user for an identity to a relying party.
The Ticket may then be used by the relying party to retrieve the
shared attributes from the name system.
- The record wire format of a Ticket is as follows:
</t>
- <figure anchor="figure_ticket">
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ <t>
+ A ticket is a GNS name that points to information pertaining to
+ the authorization given to the relying party.
+ The ticket has the format:
+ </t>
+ <figure>
+ <artwork type="abnf"><![CDATA[
+ticket = "TID.IDENTITY.zkey"
+TID = *gnslabel
+IDENTITY = *gnslabel
+]]>
+ </artwork>
+ </figure>
+ <t>
+ The TID essentially serves as a shared secret between user and
+ relying party. knowledge of the IDENTITY key and the TID allows
+ the relying party to iteratively query attribute data in GNS.
+ The record set under the TID label contains references to the shared attributes as
+ well as any credential presentations which attest attribute values.
+ The record set also includes the AUDIENCE key.
+ </t>
+ <section anchor="rp_rr" numbered="true" toc="default">
+ <name>Relying party reference</name>
+ <t>
+ A RP resource record is stored in GNS under records
+ of type "RECLAIM_RP". An RP reference
+ is stored in GNS under the TID.
+ The record format of a RECLAIM_RP is as follows:
+ </t>
+ <figure anchor="figure_gnsrp">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
-| IDENTITY TYPE | IDENTITY |
-+-----------------------+ |
-| +-----------------------|
-| | AUDIENCE TYPE |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| AUDIENCE |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| TID |
+| AUDIENCE KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>
- where:
- </t>
- <dl>
- <dt>IDENTITY TYPE</dt>
- <dd>
- Is the 32 bit identity type as defined in GANA for GNS
- identity zone types (e.g. PKEY).
- </dd>
- <dt>IDENTITY</dt>
- <dd>
- Is the 256 bit identity public zone key of the user.
- </dd>
- <dt>AUDIENCE TYPE</dt>
- <dd>
- Is the 32 bit audience type as defined in GANA for GNS
- identity zone types (e.g. PKEY).
- </dd>
- <dt>AUDIENCE</dt>
- <dd>
- Is the 256 bit audience public zone key of the relying party.
- </dd>
- <dt>TID</dt>
- <dd>
- Is a 256 bit ticket identifier.
- </dd>
- </dl>
- <t>
- The TID essentially serves as a shared secret between user and
- relying party. knowledge of the IDENTITY key and the TID allows
- the relying party to iteratively query attribute data in GNS.
- Tickets are stored as RECLAIM_TICKET records under a label derived
- from the TID by applying a Base64-encoding. In addition to the ticket,
- the record set also contains references to the shared attributes as
- well as any credential presentations which attest attribute values.
- </t>
- <section anchor="attrrefs" numbered="true" toc="default">
+ </figure>
+ <t>
+ where:
+ </t>
+ <dl>
+ <dt>AUDIENCE KEY</dt>
+ <dd>
+ Is the audience zone key.
+ </dd>
+ </dl>
+ </section>
+ <section anchor="attrrefs" numbered="true" toc="default">
<name>Attribute References</name>
<t>
An attribute reference is stored in GNS under records
@@ -440,6 +432,40 @@
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
+ <section anchor="tickets_generation" numbered="true" toc="default">
+ <name>Ticket generation</name>
+ <t>
+ The TID in a Ticket <bcp14>SHOULD</bcp14> have at least 256 bits of entropy.
+ The TID could be generated by simply sampling 32 bytes of random data and
+ encoding it using a suitable text encoding compatible with GNS labels such as
+ Base64.
+ </t>
+ <t>
+ The TID <bcp14>MAY</bcp14> be derived using more sophisticated means in order to
+ be able to relax security requirements on the exchange or storage of authorization metadata.
+ One option is to derive the TID using ephemeral Diffie-Hellman.
+ The user would first create an ephemeral key pair and calculate the TID in order to
+ populate the GNS resource records:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+CreateTid(AUDIENCE_PK):
+ x := rand()
+ ETK := X25519 (x, AUDIENCE_PK)
+ dhs := X25519 (x, G)
+ TID := Base64 (SHA-512 (dhs))
+ return (TID,ETK)
+ ]]></artwork>
+ <t>
+ This allows to the user to only transfer the ETK which can in turn be
+ used by the relying party to calculate the ticket identifier (TID)
+ using its private key:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+CalculateTid(AUDIENCE_SK,ETK):
+ dhs := X25519 (AUDIENCE_SK, G)
+ return TID := Base64 (SHA-512 (dhs))
+ ]]></artwork>
+ </section>
</section>
<section anchor="gana" numbered="true" toc="default">
<name>GANA Considerations</name>
