Pre-auth Registration Key Generation and Validation

%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.