From 73e400d9944f6314e1fe38d218c3f9dfeb622dfb Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Sun, 6 Jun 2021 08:23:52 -0400 Subject: [PATCH] ProtoXEP: pre-auth key generation --- inbox/preauth-ibr.xml | 194 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 194 insertions(+) create mode 100644 inbox/preauth-ibr.xml diff --git a/inbox/preauth-ibr.xml b/inbox/preauth-ibr.xml new file mode 100644 index 00000000..20af34d9 --- /dev/null +++ b/inbox/preauth-ibr.xml @@ -0,0 +1,194 @@ + + +%ents; +]> + + +
+ Pre-auth Registration Key Generation and Validation + + This specification updates XEP-0401 and XEP-0445 by specifying a shared + format for the pre-authenticated registration token. + + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0401 + XEP-0445 + + + + preauth-token + &sam; + + 0.0.1 + 2021-06-06 + ssw +

First draft.

 + +
+ +

+ Both &xep0401; and &xep0445; specify a mechanism for requesting a token from + a server that can be exchanged for registration at a later date. + However, neither XEP defines the format of this token, or a recommended + algorithm for generating it. + This means that each server may choose a unique format and that any token + issuing entity must either only support a specific servers token format, or + must connect to the server with an admin account so that it can ask the + server for tokens. +

+

+ This specification rectifies this by specifying a server-agnostic format for + pre-auth tokens and an algorithm for generating them. + This enables third-party trusted services that share a private key to + sign a token that can later be verified by the server to register a user. +

+ + +
    +
  • + Tokens issued by a third-party authorization server MUST be verifiable by + any authentication server supporting this specification. +
    • +
  • + Generated tokens MUST be URL safe. +
    • +
  • +

    + The algorithm for generating tokens SHOULD allow verification of the + following inputs: +

    +
      +
    • an optional username,
      • +
    • a list of hostnames for which the user can register,
      • +
    • and an optional expiration time.
      • +
    +
    • +
+ + +
+ +
Authentication server
+
+ The server authenticating the user using IBR or SASL, normally the XMPP + server. +
+ + +
Authorization server
+
+ A server issuing a token authorizing the user to register. + This may be the XMPP server, or another entity that shares its private + key. +
+ + +
IBR
+
+ In-band Registration, as defined by either &xep0077; or &xep0389; +
+ + +
Key
+
+ A shared secret that is used to sign and validate tokens. +
+ +
+ + +
    +
  • + As the admin of a social media network I want to allow my users to + self-provision accounts on our instant messaging platform without + involving the XMPP admin or requiring that the provisioning service speak + with the XMPP server. +
    • +
  • + As the admin of an XMPP server I want to generate tokens that can be + redeemed for an account at a later date even though the XMPP server is + temporarily down for maintenance. +
    • +
  • + As the representative of a chat network attending a conference, I want to + be able to print invitations to sign up for an account at our server even + though the conference WiFi is spotty and I may not be able to remain + connected to the server. + Furthermore, I want to use a different private key than the one used by + user invites so that I can see how many users from the conference + registered. +
    • +
+ + +

+ The following algorithm is used to generate tokens where "," is a separator + and not part of any actual input and $key is the shared secret key. + All uses of base64 are the Raw URL encoding (with no padding characters) + defined in &rfc4648; + HMAC-SHA256 is a Keyed-Hash Message Authentication Code (see &nistfips198a;) + using the SHA256 hashing algorithm (see &nistfips180-2;). +

+ +// Current time rounded up and converted to milliseconds. +expiration = ($currentTime + 1e6 -1) / 1e6 +jids = { + JID1, ':', + JID2, ':', + JID3, ':', + … + JIDFinal + } +signature = HMAC-SHA256 + ( + $key, + $jids, ':', + $expiration + ) +token = { + base64-raw-url($signature), ':', + base64-raw-url($jids), ':', + $expiration, + } + + + +

+ If the shared key is longer than the block size it will be hashed by some + HMAC implementations, otherwise it is left unhashed. + This is not represented in the algorithm above, but if it is not done the + user must determine whether the input key needs hashing themselves. + Input keys shorter than the block size are not hashed. +

+ + +

+ The secret key SHOULD be at least half the length of the SHA256 output (ie. + 16 bytes). + No key stretching is performed by this algorithm, so the user should take + care to pick a long key. +

+

+ Creation of the secret key MUST NOT require communication between the + authentication server, the authorization server, or a third party such as a + database. +

+ + +

This document requires no interaction with &IANA;

+ + +

This document requires no action from the ®ISTRAR;

+ + +

This document does not define an XML namespace requiring a schema.

+ +