Add register-and-verify extension #276

Open
wants to merge 11 commits into
from

Projects

None yet

8 participants

@DanielOaks
Member
DanielOaks commented Nov 7, 2016 edited

The REG command framework provides a unified, standardized interface for account creation and validation to the network's authentication layer. This allows for a network to provide a common interface regardless of what authentication layer they have chosen for their network to operate.

This allows clients to develop tailored interfaces for registering accounts.

This is the same spec as in #152 but cleaned up and with some bugs fixed. Asked kaniini if I could submit some fixes a while back and he said I should just throw a new PR in.

edit: I think the last thing missing here is the ability to know whether the net uses your nickname as the account name or not. I'll take a look at that and get something worked out there

+| --- | ------------------------------- | ------------------------------------------------------------------------------------------------------------ |
+| 927 | `RPL_REG_VERIFICATION_REQUIRED` | `:<server> 927 <user_nickname> <accountname> <callback_namespace:><callback> :A verification token was sent` |
+
+Upon error, the IRC server MUST send an error code that is relevant. We suggest these numerics:
@ProgVal
ProgVal Nov 15, 2016 Contributor

Could you add the requirement for the error code to be in a given list?
Otherwise, servers may send something a bot does not expect to be a reply to this, and the bot will not know what to do with it.

extensions/reg-core-3.3.md
+
+The `REG VERIFY` command signals the intent of a client to submit a verification token for their
+account to the authentication layer. The verification token MUST be sent to a valid callback
+resource as specified by the client in the `REG CREATE` command.
@ProgVal
ProgVal Nov 15, 2016 Contributor

If a verification token is required by the server, it MUST be sent by the IRC network to a valid callback resource [...]”

+account that has been successfully verified.
+
+Upon error, the IRC server MUST send an error code that is relevant. We suggest these
+numerics:
@ProgVal
ProgVal Nov 15, 2016 Contributor

Could you add the requirement for the error code to be in a given list?
Otherwise, servers may send something a bot does not expect to be a reply to this, and the bot will not know what to do with it.

extensions/reg-core-3.3.md
+ * `certfp`: the client certificate fingerprint as determined by the server if available.
+ The client MAY provide an empty credential (`*`) in this case. The server SHOULD calculate
+ the credential using the client certificate fingerprint, if available. If no client certificate
+ is presented, the server SHOULD NOT advertise the availability of this credential type.
@ProgVal
ProgVal Nov 15, 2016 Contributor

What hash algorithm should be used to give a fingerprint other than *? And what format?

@DanielOaks
DanielOaks Nov 17, 2016 Member

Yeah the language here is a bit iffy, thanks for pointing it out. I'll clean this up a bit.

extensions/reg-core-3.3.md
+ :irc.example.com 005 kaniini REGCREDTYPES=passphrase,certfp :are supported by this server
+
+The first credential type SHOULD be the implementation-defined default if default credential types
+are supported.
@ProgVal
ProgVal Nov 15, 2016 Contributor

I did not understand this line at first.
Do you mean this? “The order credential type SHOULD be the implementation-defined default if both credential types are supported.

@DanielOaks
Member

@ProgVal I'll look at making sure the error codes are in the given list, but how do those changes look to you? Should clean up the language in those sections a fair bit

@DanielOaks DanielOaks Add REGNICK token, allow * for accountname = nick.
These changes allow REG to be better used on networks that explicitly link accounts to nicknames.
cba7bb1
@ProgVal
Contributor
ProgVal commented Nov 18, 2016

Why do you want to prevent the client from setting a fingerprint that is not the one of its current certificate?
We will have to allow that at some point if we want to allow users to change certificates or use more than one.

@DanielOaks
Member
DanielOaks commented Nov 18, 2016 edited

Different networks can use whatever fingerprint methods they want for certs. In addition, allowing clients to register with fingerprints other than one that they explicitly control sounds a bit dodgy in terms of spoofing other users. Say that you know the fingerprint of my cert – you register an account with the fingerprint in the certfp's cred field and now I can't register an account linked to my cert because one already exists for it.

Because of that and the difficulty of conveying which algorithm is being used. Does certificate fingerprinting use standardised algorithms like SHA1/SHA256 always or are there cases where people can do whatever special stuff they want, say using both SHA1 and SHA256 to better protect against dodgy collisions? Is there a 100% solid way that we know to convey exactly which method is being used to generate the fingerprint, or should we instead also define a numeric that dumps what your certfp is on connection, so that clients can then use that later in the REG CREATE command?

Just using the client's current cert makes the most sense to me, though if there are answers for all these then I'm open to investigating it further.

@grawity
Contributor
grawity commented Nov 18, 2016

Existing services already allow "claiming" any fingerprint anyway. But I like the restriction because it can reduce accidents – if you're only allowed to use your current cert, then registering implies you can successfully connect with it and won't end up with an unusable account.

@DanielOaks
Member
DanielOaks commented Nov 18, 2016 edited

Updating your cert would be handled separately, if appropriate could be through another REG command we describe later (similar to updating your email address perhaps).

@ProgVal
Contributor
ProgVal commented Nov 18, 2016

But to update the cert, you have to be able to give a fingerprint at some point. Unless you find a way of connecting with the old and the new cert at the same time (IRC in TLS in TLS?), but that may be hard to implement in some/most clients.

@DanielOaks
Member

I think restricting registration to the certificate you currently have makes sense, for reasons @grawity put above. For updating the cert on an existing account that could definitely make sense, but I think looking at that is the job of another spec (which may also look at updating passphrase/etc for the account as well).

@ProgVal
Contributor
ProgVal commented Nov 19, 2016

Ok

+types may or may not allow spaces inside `credential`.
+
+The `callback` field designates an opaque value which indicates where a verification code, if any,
+will be sent. The callback field is implementation-specific, with namespaces being listed using the
@M2Ys4U
M2Ys4U Nov 19, 2016 Contributor

If we're using IANA-registered scheme names for the callback namespace, does it make sense that the callback field is implementation-specific? Why not just use a proper URI here?

@DanielOaks
DanielOaks Jan 7, 2017 Member

Makes sense, thanks for the suggestion. I'll look at this.

@jwheare jwheare added the accounts label Jan 7, 2017
@jwheare jwheare modified the milestone: Roadmap Jan 7, 2017
+
+A `REG VERIFY` command consists of the following format:
+
+ REG VERIFY <accountname> <auth_code>
@Zarthus
Zarthus Jan 7, 2017 edited

I think this should include the (optional?) password if we're going to immediately log the user in [L111]. Or indicate that this command is only available while already logged in (how do you log in?) (in which case the sentence below "the irc server should also send an rpl_loggedin ..." would no longer be valid)

There are many users who accidentally paste their authentication code in chat.

@Zarthus
Zarthus commented Jan 7, 2017

Seems to be missing a way to drop the existing nickname. What if I misspell my email?

@DanielOaks
Member

That's handled by a separate spec. This is just about registering your account

@prawnsalad

C: REG CREATE * mailto:dan@example.com passphrase :testpassphrase123
S: 920 dan- dan- :Account registered
S: 927 dan- dan- dan@example.com :A verification code was sent

From the client dev perspective, receiving the 920 when verification is still required can cause issues in the UI.

  • User attempts to register, UI shows a loading sign
  • Client receives the 920, UI shows "congrats" screen
  • Client must wait for an arbitrary length of time incase it receives a 927, UI must now change to "Sorry, you're not actually finished. verify now".

Two possible ways to improve this would be to either send 927 before 920, or to send one or the other but never both. The latter would be cleaner IMO.

@DanielOaks
Member

920's sent when it's successful, so if they do mailto: then it'd send that after they send the REG VERIFY command, not after REG CREATE. If they REG CREATE with skipping verification, they wouldn't get 927 since it requires no verification code to be sent/etc.

+| --- | ------------------- | ------------------------------------------------------------------------------ |
+| 923 | `RPL_VERIFYSUCCESS` | `:<server> 923 <user_nickname> <accountname> :Account verification successful` |
+
+The IRC server SHOULD also send an `RPL_LOGGEDIN` (900) numeric and consider the client to be logged in to the
@Zarthus
Zarthus Jan 7, 2017

Sounds better defined as a MUST.

@prawnsalad

@DanielOaks In that case then the examples need updating to reflect that. They currently show verification mailto: being sent and then a 920 being received before 927.

@DanielOaks
Member

@prawnsalad oh, weird. yeah I'll def go over that and make sure it's made clearer and all, thanks for pointing that out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment