This blog reports about software design for the InternetWide Architecture.
Something that we might easily forget however, is what is the
true nature of the InternetWide project. In the end, it's not
about software -- instead, it is all about protocols.
Open source software is a wonderful mechanism of sharing software improvements that someone wanted as a feature to enhance their resilience; even for people who do not program themselves, there are great benefits of using devices and software that are actually extended and maintained rather than shipped as soon as it looks good enough to sell. Just think of your alarm clock, television, desktop phone or printer and their unchanging software bugs and missing features. Interestingly, manufacturers can benefit too; they need not reinvent the wheel, or spend a fair amount of time debugging their locally re-invented mistakes. Sharing is economically sane, it's that simple.
For the InternetWide project, we start with open source software, and extend it where we need. Much of our work comes down to connective tissue, such as a backbone for the microservice components that we need for the InternetWide Architecture. The main purpose however, is not software but protocols.
Connecting Realms
Our main purpose is to free online identity from individual providers over whom end-users have no control. Nobody should have to be a member of one of the three or four largest players in the Internet, and have an identity that they could take away at a whim. Generally, users are better off with a provider within base-ball bat range :) So, instead of being someone under the realm of Facebook, Google or Microsoft you should prefer to flexibly manage identities under your own realm. In terms of the Internet, the simplest and strongest control over identity is possible under your own domain name, which you can then host for a small sum or perhaps deploy on your own hardware. Paying for this simple kind of service means that the terms of your hosting contract will benefit you, not the hosting provider, also because you can pack your bags and go to another provider without a change to your online identity.
To make this possible, we need mechanisms to Bring Your Own IDentity (BYOID) to external services that you may want to use. In a later phase named ServiceHub we want to enable plugin services under your domain name so that you may also offer services internally or, if you want, externally. Those services then support BYOID from local or foreign users alike.
The most important aspect of BYOID is remote authentication. We tend to refer to that by the name realm crossover and we design protocols with care to support just that.
Kerberos Realm Crossover
For our most advanced users, or more accurately for the most complete hosting providers, we assume that Kerberos will be available. Kerberos has support for links between domains or realms, but there must be a way to initiate connections between pairs of realms, which is currently assumed to be arranged manually by administrators. This is not going to scale up to a solution for the entire Internet, so we needed a fix.
Present-day DNS has been protected with DNSSEC, and it is possible to post certificates for a server using DANE, so we have a strong mechanism to allow realms to connect when they need to. Indeed, such a solution can be built around the realm controller for Kerberos, the so-called KDC.
The mechanism we propose is Kerberos Realm Crossover, or KXOVER for short. It consists of a handshaking protocol with discovery:
- Impromptu Realm Crossover between KDCs is the mechanism that we propose;
- Declaring Kerberos Realm Names in DNS is a simple mechanism to allow KDCs to learn about this.
As a very powerful enabler, we are working on an integration of Kerberos in TLS. This is the first Quantum Proof mechanism that we have seen up to now! (Note however, the design of KXOVER only supports Quantum Proofing when a suitable key exchange mechanism is used.)
- TLS-KDH introduces Kerberos authentication in TLS 1.3 and backports it to the 1.2 version.
SASL Realm Crossover
For those that are currently bogged down by password mechanisms it is good to realise that Quantum Computers will discover all those credentials in hindsight. We really must get away from passwords.
Unfortunately, it takes two to tango. Both client-side and server-side need to be involved in a better mechanism. Clients tend to be unaware of the problems they are facing, and servers tend to assume that clients cannot be taught. Or, more accurately, servers do not want to be the first to trouble clients, because they might be considered "difficult". This even includes banks!
Well, when it comes to security, InternetWide is willing to take the lead. And technology to do this is readily available, in the form of SASL. SASL is a pluggable authentication mechanism that is built into all serious protocols. It allows client and server to negotiate how authentication takes place. Given a sufficiently flexible server, the client can automatically pick the strongest mechanism that it can handle. Passwords are still among the available mechanisms, but there are much stronger mechanisms too, including Kerberos and SCRAM.
What SASL cannot do yet, is securely crossover to other realms. It is used internally, for such protocols as email and directory access, but it is not customary for these protocols to welcome foreign users. As soon as SASL can work with realm crossover, these might however offer interesting new opportunities...
The reason why SASL traffic does not offer realm crossover is a matter of security. The information passed is not generally safe from middle men, and so it cannot be passed from a client, to an external server, and back to the client's realm for authentication confirmation. Our design for SXOVER is meant to offer precisely that:
- Diameter SASL defines how SASL messages may be sent back to a client's realm over Diameter. Diameter is like RADIUS, but it is more suitable for pooled connections between realms, and connections are always authenticated as connecting to the client's realm, so any statements about client identity under such realms can be trusted. The specification includes a definition of SXOVER, a mechanism for SASL that wraps a "normal" SASL exchange in an end-to-end encryption layer. Among the "normal" mechanisms could even be passwords, but there is room for growth.
This means that any server that accepts SASL authentication can now
welcome foreign users. There is no need for having setup an account
in the past. Access control can be tied to a user@domain.name kind
of identity, so local accounts are simply not needed anymore. And,
because the client is involved in authentication, there is no way of
silently picking up the identity and tracing the client unless it
agrees to present its identity through login.
This covers a very large number of protocols. There is only one protocol that persists in trying to reinvent the wheels, but this is highly ineffective and a simple solution is to add SASL to HTTP as part of its general authentication framework. It is precisely the pluggable nature of SASL that frees the web programmer and the web client from needing to be actively involved in authentication. The frustrations about authentication in the web have led to all sorts of user-interactive mechanisms that, simply put, do not work and only extend the reign of the long-overdue password mechanism. So we defined:
- HTTP Authentication with SASL embeds SASL as one of the the standard HTTP Auth mechanisms.
Client Certificates
An older model for realm crossover was based on X.509 certificates, that all clients could hold. Alternatively, one might think of OpenPGP keys. These mechanisms never got popular, on account of the complexity of certificate management and the logic this expected from clients, but it is still something we support.
Both X.509 and OpenPGP assume an LDAP directory running under a domain, allowing queries of credentials under these domains. We support this as part of the InternetWide Architecture, and more specifically, as part of our IdentityHub software. This means that software can validate even locally spul certificates and keys using nothing but the domain name. The additional securities of DNSSEC and DANE work to validate a TLS certificate for the LDAP server, so a completely secure chain links this form of validation to the domain in real time.
In addition, we work to avoid the management difficulties for client certificates. Instead of asking the client to jump through hoops for key generation and certificate installation with regular rollover, and to do this on each and every device, we provide a Remote PKCS #11 system with standardisation-friendly data formatting for remote access to a token service. The token service is part of the identity management solution IdentityHub for our InternetWide Architecture. You still get to decide if you want your hosting provider to run it for you or, if you are really good with this or if you have another trusted provider, to run it elsewhere. All your devices gain access to the same token service, and certificate rollover is handled transparently.
This is not the most likely path for future development of online authentication, but at least we make it possible. For encryption however, this framework is a vital extension to what we have today.
Web-only Authentication
Anyone who knows about our work will see the difference with most other single-signon mechanisms out there. Virtually anything else is web-only. Bogging everyone down to web interfaces with their one-sided automation support is too strong a limitation according to the InternetWide Architecture.
It is however important to be compatible with web-only authentication and this is usually what we look into when encountering any such mechanisms. Up till now, we have found that our approach is more general, and welcomes the extensions with these mechanisms.
As examples, you can think of OpenID Connect or OAuth2 mechanisms. These generally have a so-called resource (or visited services) and a (possibly separate) authorisation server which authenticates the client and passes a token to them. We can easily construct software that work on either side of these protocols, based on the primitives of authentication under the InternetWide Architecture.
Go Top