spec server-initiated sign-in with ssb

[staltz]

@keks @cryptix Would appreciate your feedback! :pray:

---

Context: I met cryptix and we figured that Sign-in with SSB has a missing feature.

Problem: The spec was assuming that the dance is initiated by the client SSB peer which generates a challenge and then opens a page in the browser, but there are often cases where you'd like to begin with the browser, such as inputting your SSB ID or alias. The spec didn't account for that and assumed that we always had to begin it in the client SSB peer.

Other problem as I digged deeper: if we want both sides (server and client) to verify each other's solutions, we need to send messages 3 times (A-->B generates challenge, B-->A sends solution, A-->B sends solution), and this can't be done with 1 muxrpc calls, it needs 2 muxrpc calls, and that sounds too much. I started questioning whether we need to do "mutual authentication" given that secret-handshake assures us that both sides are mutually authenticated.

Solution: I slimmed down the sign-in protocol a bit, so that there is only cc (client nonce), sc (server nonce), cr (client solution). This means that we would only need 1 muxrpc call. The idea is that cc and sc act like session IDs, and all that needs to be done is the client "acknowledge" these by creating a signature cr that certifies those session IDs. We don't need to authenticate the peers themselves, we just need the client to certify those nonces.

See these UML diagrams (that omit the error handling cases, just to make it smaller and easier to grok the dance):

Client-initiated sign-in protocol

Server-initiated sign-in protocol

PDF: rev2021-02-10.pdf

[keks]

Hey Andre, sorry for the late response. In general I'd say that as long as you don't change what is signed and all the signatures are adequately verified, we are still good. As far as I can see, this holds in the two sequence diagrams you posted.

Regarding the question on whether we actually do need signatures because we already have a secure, authenticated channel: you are right, we don't need them. One approach we could take is that the client, through muxrpc, asks the room server for a token. This token is then presented to the user, so they can enter it in their browser to log in, once, for a short time period. The ssb client could present it in the form of a URI, such that it can be clicked and the browser just opens. The token could expire after the first login or 30 sec, whichever comes first, in order to reduce the attack surface

[staltz]

Thanks @keks, I think I'll merge this then, but I'm open to changes and discussions (up until the point we start implementing it in https://github.com/ssb-ngi-pointer/go-ssb-room/, which isn't quite yet).