RFC: Authentication OCTOI services

Retronetworking ISDN
#1

A number of cool services (like BBS, Linux shells, Fediverse/Mastodon clients, E-Mail(-ish), etc.) could be offered over OCTOI, but some form of authentication would be required.

We’re living in the virtual 90s here, so our options for encryption, etc. are a bit limited :grin:

I’m thinking of options for centralized user account management for low security applications, which would also be viable for terminals.

Personally, I’d love to have some sort of central user account management (Keycloak, LDAP, etc.).
A little web interface could be used to configure the account, manage access, etc.

TOTP Authentication

One possible mechanism would be using TOTP as the “password”.
The user would create an account at the central registry, get a TOTP token (QR code, etc.) like normal.

The user could then connect to a (3rd party) service, types in their username and the current TOTP token. This token is validated against the (central) OCTOI authentication API.

This would have the benefit of limited impact in case of a logged/stolen/etc. token. 6 digits are also easy to type on any device.

BBSes like Synchronet could be easily adapted to this mechanism (exec/login.js).

URL/QR Authentication

The service would display a special URL for login, which the user could then access on a modern PC/phone/etc. and would then be logged in for the current session.

ASCII art QR codes could be used on platforms which support this.

This is actually pretty secure (in contrast to the TOTP mechanism), but also much more inconvenient.

Writing these mechanism is a bit of work, but I think it’s useful anyway.
This would also enable features like central accounting and logging.
Having a way to see call logs, connection logs, maybe even PCAPs/B-channel recordings could be really useful.

Comments? Ideas for other authentication schemes?

#2

I second the idea of using Keycloak :slight_smile:
In my opinion, Keycloak would provide more out of the box and/or one could benefit from extensions offered by the community.
LDAP would require some more work around it, and, at least considering me personally, I never really got familiar with the concepts and syntax.

Regarding your second suggestion I think I did not fully understand how the process would actually look like. So, for example, how would it look like when a user wants to use his trusty Netscape Navigator e-mail-client?

#3

I like the idea of using TOTP as password. It is a neat work-around for the plaintext password transmssion in virtually all of the retronetworking use cases that we’re looking at, specifically BBSs.

Talking about centralized user account management, I’m all for LDAP. It’s trusted and old enough that most people (especially intetested in retronetworking) should know its basics… We’re using it at sysmocom, and even for modern stuff you can store your ssh public key in your ldap user record and services like gitea/forgejo can pick it up automatically.

2 Likes
#4

I also like TOTP (maybe even password + TOTP?) since you could also offer App Passwords for places where changing the password is very inconvenient (think: PPP, or POP3/SMTP if you were to offer this). I did mention this privately, but I think as long as the server has a longer timeframe of acceptance - like 60s instead of 30s expiry - it’d be a lot easier on even slower lines.

I’ll be honest, I haven’t looked much at LDAP yet, but I’m sure it would be a good fit and not too difficult to pick up (which means anyone can integrate with it!).

My main concern with the QR code setup is the requirement of another Internet-connected device; there are projects bringing TOTP even to J2ME featurephones (remind me to test it on my Nokia when it arrives…), so you could still use it on slightly more appropriate hardware :slight_smile:

1 Like
#5

+1 for TOTP - It’s always struck me as a nice idea for amateur radio applications (Some countries don’t permit encryption on amateur radio). It would also be a good fit for retro applications.

1 Like