Bring Your Own IDentity
2022-07-22, 20:40–21:30, Battery 🔋

Thanks to DNSSEC and DANE, it is possible to automatically verify identities by checking with servers. The real problem however, is integration with existing protocols, instead of inventing something completely new and perhaps web-only. The purpose of our work on Realm Crossover mechanisms has been to design generic solutions that extend many different application protocols, without changing their protocol specs.

For clients, being able to control an online identity is not just a cool matter of adding their domain name at the end. It also means that they control how long the identity exists, if it is an alias, if it can be a group account with members that they control. (We made identity and access control libraries to support all that, along with identities that are only usable until a timeout, from a certain remote domain, under a particular communication topic, and so on.)

For servers, being able to authenticate users from any domain is an answer to many questions that otherwise stagnate:

  • Why does every HTTP server want us to create an account under its domain, instead of letting us use our own?
  • Why do we constantly need to confirm our email address by clicking links?
  • Why not authenticate SMTP senders and subject others to the most stringent spam filtering?
  • Why not publish a mailing list archive in IMAP, available only to subscribers and searchable with their own tooling?
  • Why not use AMQP as an automation-friendly document push protocol with authenticated senders for form submission, bill processing, blog publications, document archiving, ...
  • Why not share your MQTT dataflow with external parties, so they don't need to keep a web page open to be notified about, say, a newly posted document?
  • Why not share your PGP keys and contact information in your own LDAP directory but with access control to decide who may see what?

All these questions stagnate on problems like You would need to have accounts for all users in the World. So that is what we solved in this project.

This project expands the usefulness of many protocols by changing the way their implementations handle authentication; instead of local accounts, they follow a backlink to the client's domain. We designed and built the extensions needed for the backend, and made a few first implementations. We are hoping to show the usefulness of adopting these ideas in your own tooling.

We present a number of generic mechanisms for Realm Crossover:

  1. SASL tokens can be relayed to a Diameter server under the;
  2. Kerberos supports Realm Crossover, and a keying handshake can do this on-demand;
  3. X.509 certificates and PGP keys can be assured with DANE-akin structures for clients or by a lookup in an LDAP server for

For each, some form of domain-owned identity provider is run to assert identity when an external service needs it. The level of security is a matter of the user and their; an external service should not have to force down the security level of the client's domain.

These three Realm Crossover mechanisms cover the majority of application protocols, the notable exceptions being the oldest ones, like Telnet, FTP and HTTP. Specifically for HTTP, we have defined an authentication mechanism that adds SASL; this means that new security mechanisms can be defined in SASL, where it benefits many protocols; it also means that authentication shifts from the HTTP application to the server, where the coding environment is better suited for such responsibilities.

We end with a demo, showcasing a useful authentication flow:

  • Client desktop, with FireFox and a HTTP-SASL plugin
  • Server domain, running Apache with HTTP-SASL module under an independent domain
  • Server identity client, using Diameter to relay SASL to the Client Domain
  • Client Domain, running an identity provider with SASL over Diameter
See also:

Rick is the architect behind the open source project, and one of its developers. The project draws on years of his experience analysing open protocols and their authentication and privacy. The project has now matured to a stage where IETF draft standards are stable-ish and their implementations demonstrate that they work.

The overall goal of the project is to facilitate domain owners with maximum control over their online presence (and that of their users) and the most dire need for that seems to be an ability to authenticate as a user of the domain.

Rick has studied elektrotechnical engineering for 4 years, electronics for 3 years (both at a practical level) and after a year of mixed education completed an academic degree in computer science. He then worked as a teacher for a full year, and returned to the university for promotional work.

After acquiring a PhD, Rick founded, aimed at security and privacy, mostly in networking systems, and always aiming at strong cryptography with the easiest user experience. Five years later, Rick also founded, which aims to research/develop technology for sustainable purposes. Perfect technology solves many problems in one stroke, so these two approaches are combined where possible.

This speaker also appears in:

I have been programming since high school in the seventies when computers were still very small and expensive. Since internet and version control systems I have been contributing to open source projects which I am interested in.
I have been involved in ARPA2 for serveral years no.