InternetWide.org

Identity 17: Future Warfare may be about Identity

2022-05-05T00:00:00+02:00

This is an opinion article in a mostly technical article series on identity.

Today, the Netherlands celebrates Liberation Day, marking the end of a Nazi occupation of our contry between 1940 and 1945. Fear and violence were the instruments used to oppress our people, but it gave rise to underground resistence. I have often wondered if I would have the courage to stand up and fight the enemy in such a war, but the work in the InternetWide project and its delivery as ARPA2 software may in fact be preparing for future warfare.

The current Ukraine war shows a more prominent role for information. Propaganda and control over resources are nothing new, Hitler did that too, but it does take on new forms. But another general pattern may be to introduce new technology with propagandistic messaging (marketing) but use it as a strategic advantage later on.

Adolf Hitler manifested himself through beer garden lectures with populist themes, his popularity grew and he promised prosperity through technical advancement with highways and a Volkswagen. The highways turned out to be infrastructure for fast tank movement operations.

Technical and economic advances can be convincing arguments while wheeling in instruments of oppression. When people have individual freedom of choice but no ideal or information to guide their choices, they fall back on economic optimisation. This includes making choices that turn out to have been short-sighted with more information. But these processes are difficult to stop; it is even the mechanism by which whole societies collapse, even when everybody sees it coming; individuals continue to fend for themselves when they feel they cannot do anything else. What could I do, I am only one. But no, many like-minded individuals can easily make a difference if they act as a mass.

This article is not predicting any concrete future war, but I am showing you some instruments that could be used and how we can all make smarter choices to evade them. And I am bringing forward the point that Liberation Day is there to remember that freedom is not a given, and that we should be mindful enough to not let it slip away.

Sovereignty

A strong motivation underpinning the Internet is to create as many bubbles of sovereign control as feel a need to exist. These bubbles of control can be as small or large as desired. The people who work on Internet standards, who implement them and develop central infrastructure are highly concerned about this level of fundamental freedom. This plane of society is rife with open source contributors and open protocol adherents, both vital ingredients of online sovereignty.

This attitude has brought us domain names, which anyone can register for a humble fee and completely control. It has given us email, under full control of a domain owner (if they decide to go that extra mile, instead of selling out to a large provider outside their control). And it has brought us strong cryptographic mechanisms so we can prove who we are, or to be as concealed as we like. Bitcoin and Ethereum are recent examples which, in spite of their devastating energy expenditure, take a first step towards freedom in the monetary area.

Freedom is one concern out of many. It is more common to look at expenses and treat freedoms (such as privacy and sovereignty) as afterthoughts. This usually means that we give up on those aspects of our lives, because they are not expressed in our spreadsheets. In addition, computer services scale very well (cloning a general mechanism is almost free) and if these services make their earnings from jeopardising these freedoms, then we are bound to make silly choices. And indeed, that has become mainstream practice. We store our data, even our identity, at a few very large silos who crack away at it to analyse how to squeeze earnings out of us indirectly. The use of patterns with the intent of marketing suggestions is a direct insult to our freedom of choice.

Every one of those silos is operated under a jurisdiction, with major ramifications for your sovereignty. In practical terms, your online presence is subjected to inspection and eradication under not only the commercial motivations of your service provider, but also the policital motivations of the country in control. Privacy has no visible price tag, so is easily forgotten in the interest of economic saving.

Selling out 101: University of Twente

I studied at the Unversity of Twente in the early 90's, and still come there every once in a while. It saddens me to showcase this wonderful institution as one that is giving away all control in such a systematic manner that it reeks of conspiracy. But honestly, I believe it to be penny-pinching that makes the university make silly choices.

Aside from thrift there must also be a lack of clear thinking, because many UT members must have read Orwell's book 1984, and still they let it happen. I use the university as an example of a common trend, because it is the last place where you would expect money to be more powerful than knowledge. So while reading this, keep in mind that many people are making similar choices, and giving up their freedom and sovereignty for a few measly euros. There is no such thing as "economic rationalisation", it is an excuse for penny-pinching at the expense of human values.

Students have almost abandoned email and are only practically available via chat. They collectively make the populist choice, namely WhatsApp. It is amazing that something as trivial as passing around small texts in virtual realtime would call for such an invasion of privacy, but since it is an enclosed environment, it's a black-or-white, either you're with us or you're against us choice.

Students are young, and have an age that allows them to make mistakes and learn from them. But it is surprising that a trivial chat service is not made available as an open protocol to the many thousands of students and staff that are active on this (technical?) university. All student organisations want similar facilities, and it would be quite possible to provide these in bulk. It is a missed opportunity to teach students that they can control technology; instead it teaches them to run off to Google and be mindless consumers if they want to do things online. It makes them impose privacy regulations of Mailchimps because that is the only realistic choice available to a sports club.

When I studied, the driving idea was to empower students as makers, rather than prepare us for a life as click bait. The university's sell-out started by not taking responsibility, the first mistake of my university. It got worse from there on.
With vague marketing notions of one shared image the complete control over all websites of the university were centralised on one server. The prior existence of subdomains for faculties and their research groups has all been redirected into one glowing image. With more colour and far less information about the work of the various groups.

What nobody seems to notice in such a change is that complete control over a very large organisation can now be had in one stroke. Content becomes political when you centralise it. It is subjected to black-hat as well as white-collar abuses. Someone might break in to do much more harm; or one might sell out the underlying data and surrender much more individual liberty than any research group might individually have wanted to let happen.
During Corona, teaching was streamed with Big Blue Button, a piece of open source software that worked effortlessly. It has now been replaced by a business solution, with the excuse that one vital function was lacking, in reality just a small control.

Yes, we are talking about a (technical?) university that invades privacy rather than making a fix to open source code, which they could then donate back to the benefit of everyone else. Rather than this one-time investment they choose to surrender either money on a reguary basis, or some aspect of their sovereignty (or their students').

Passing core information services over to external providers means that their privacy conditions will have to be accepted. External staff will get to see a lot of data passing by, including private information (student identity) and when used for research discussions it may leak business-critical information that may be passed on to 3rd parties down a chain of responsibility. If any link along that chain leaks, or is subjected to the laws of another jurisdiction, then it may be problematic to the organisation and its core business, even for a university where research is considered private/internal up to the point of publication.

These external providers do not write their privacy regulations to protect you, but merely to defend themselves against laws that intend to protect the online freedoms that are so easily lost when externalising hosting. The usual sign of this is lengthy privacy regulations.

Note that universities have no shortage of young intelligent people, eager to pickup such chores for a modest fee. It should be completely trivial to modify open source systems from time to time, and it has been a normal practice before universities started to centralise control over information technology, and treat it as an expense rather than a vital part of their organisation.
Email was another one of those scattered things that gave way to sovereignty of research groups. It has now been collected under one domain, and central control. As part of this process, many identities of the entire university got @exchange.utwente.nl as their domain because, yes indeed, the control over email has been handed out to an American company.

It is a common Dutch management style to separate those with decisive power from those who know what would be clever. You would hope that universities were smarter than that, but mine clearly is not. Had the decision been well-informed, than a technician would have explained that MX records can be hung under any (sub)domain to point to any hostname, so a service provider never needs to dictate the email domain, not even when they ask for a hostname under the domain the receives email (and even that is not necessary). I would really like to know why email addresses posted on top of articles in scientific journals can no longer be reached. I doubt there is anything scientifically relevant, though.

Also, if I can run my own email server, why could a university not do the same? The only work is to add and remove users from time to time, something that can easily be automated, and software upgrades, which a Linux distribution handles. On the other hand, given that the exchange. prefix is (part of) a trademark of Microsoft, would it be possible to move that email domain to another service provider in the future, without facing lawsuits? If anything, then trademarks are about product naming, and I can imagine Microsoft winning a lawsuit over it, causing the entire UT staff to face yet another change of email addresses and all journal article addresses to be rendered invalid once more. In practice, the university may now be stuck with their current email provider. Who can now demand anything they want from them.

The university has jeopardised its online freedom.
Telephony is another such thing. It has been moved over completely to the same provider as for email. Email and telephony together represent incredible control over what goes on at a university.

Maybe you consider telephony as a remnant of the past, overtaken by mobile telephony. But consider that a modern phone runs on software that needs to connect to the Internet; it is a microphone with remote control. It is the last place where you should want to run automated updates with closed-source software from a company under another jurisdiction. Doing so strikes at the heart of what a university is about: research and development and, to some degree, having a competitive edge based on not-yet-published research.
Login to most services, including knowledge (in the library) is subject to access control. It has been mandated that this is two-factor authentication for everything. (Interestingly, this is even the case for temporary accounts that are casually handed out to visitors and alumni, and that last a few days.)

Access to knowledge in the form of books and scientific papers in my university is now subject to approval by an external party from another jurisdiction.

Should we expect them to also offer search facilities and start controlling what is shown to faculty members?
Control is now closing in on the edges. If you want to engage in sports, you always needed a card that grants access to facilities. This makes sense, as it helps to maintain those facilities at the expense of its users. Recently, an announcement was made that access control gates are to be used, so you basically need to surrender your identity before you can pee or take a shower.

The system adds no value at all, except for more control and data processing, which is likely to be placed in the hands of an information giant in time to come.

This development is happening in many places at the same time. Gradually, we are giving away control over our online presence, and in part even our everyday livelihood. But it happens so slowly that journalists barely report on it. And it is so abstract that only well-informed people draw a line in the sand that they will not have crossed. Most people just let it happen. How long was the uproar over the last change in privacy regulations of Facebook? And how many have closed their account? How do you boil a frog? One degree at a time; going slowly so it does not notice the change.

Future Warfare over Identity

I have been surprised by the effectiveness of taking Russia out of international payment systems. A response to require ruble payment for gas payments makes sense from their perspective. But in general, warfare never makes sense to me, because it is all destructive. It has a disruptive effect on many people, without any gain for anyone. (In my PhD thesis "stellingen" I stated Oorlog betekent dat iemand met een te groot ego op een te hoge post zit. and that still seems valid to me.)

When disruption of every day life is a goal, any form of dependency becomes a strategic advantage. Today it is gas versus banking, but I predict that there will be a growing role for dependency on online services.

I predict that future warfare will move towards control over online identity and online data.

Imagine a war in which WhatsApp blocks messaging, where Gmail forgets your email history or Microsoft refuses to acknowledge your second factor authentication. Many of us have given up their sovereignty as if it was a tradeable service like the supply of electricity. Except that these online services are not anonymous; they encapsulate your identity, that is the names by which you are known to others, to the servers to which you logon, and so on. They may even be the place where your contact list is stored. Without access to these, you would be paralysed for a large part of your life.

In case of a war, you do not want to have given up sovereignty over your information. You want to own your mailbox. You want to control authentication choices at services run by others, so you want to control your online identity. You want to communicate effortlessly. And you want to have prepared your privacy so you can speak freely. Not just you, but your nation ought to be free of information leaks.

Our World is facing serious resource problems, and these are likely triggers for war. But even if that does not happen, there already is a slow-paced battle going on. The control over identity, data and social networks is migrating into the hands of a few large silos that use it for their own good — and may be required by their governments to make it available to them too. This poses a serious strategic disadvantage. The more data and control you land with a large site, the more likely it is that they will increase demands. It will be a gradual process; increasing expenses or, more likely, increased control over how they may interfere with your online conduct. This is taking place today. It is not as obvious as a war with guns and tanks, but it is nonetheless a fight for individual freedom.

A war is blunt and direct. Creeping erosion of online freedom is much more subtle, but it can cause similarly high levels of devestation.

I can no longer exchange email with members of the University of Twente without Microsoft watching over my shoulders. I cannot access its library books and academic research papers without Microsoft controlling my acces. I cannot freely discuss matters of academic or personal nature at a university office without a risk of being overheard through a Microsoft phone (if not by a Amazon Alexa or Google Assistent).

Communication involves more than one party. If the other sells out on their own privacy, they also sacrifice that of their communication peers. This is anti-social behaviour and may interfere with the willingness of others to communicate.

The university has adopted a no-smoking policy for its campus, but I can think of more useful forms of personal hygien: Just like you don't want to poison others with second-hand smoke, it is a professional practice to not poison others with the information leaking out from your services.

InternetWide Sovereignty is up for grabs

Humans can do wonderful things when they collaborate. Competition is said to bring out the best in people, but in my own humble experience, innovation is more often the result of people tinkering from intrinsic motivation than under economic pressure, at least in technology. And it is this individual tinkering that needs freedom to move, to publish and exchange ideas with like-minded individuals. Ideas flourish under an open and free network of people. Not under central control, nor under marketing strategies. This is why I used the University of Twente as an example; it is an ultimate place where these freedoms and forms of individuality are a requisite for the primary productive process.

But the Internet is there, and can still remedy these problems. This applies to a university as well as to individuals and commercial companies. And the price level is completely affordable.

Open source software is licensed in such a way that you have end control. Even if you don't actively participate in its development, you can make a quick fork to make a small improvement and suggest its integration in future versions. It is this easy to exercise control over software, and is a light process in comparison to getting it done by a commercial service provider, precisely because you can do it yourself. Or, as a result of the openness, find one of many people willing and able to help you out for a modest one-time payment.
Open protocols are standardised in such a way that compliance can be verified by technicians. There is no need for lawyers or lawsuits to get compatibility problems sorted out. More importantly, technicians can fix problems and are glad to do so if it improves compatibility. But note well; this only works if a party is not "too big to fail". Large parties tend to have an "embrace and kill" strategy that starts off with a standard and adds proprietary extensions that can make them functionally incompatble. Be weary of such extensions, especially if they are not documented or if other obstructions block others from moving along.

Most of us are no fan of Jehova's teachings and its ideas of expelling members from their communities when they break with their religion. And yet, we seem to accept closed protocols and services that only talk to those who use the same domain — a domain that thereby gains full control over online identities and their ability to communicate.
Domain names give you full control over online identities. You want to own your domain name and be in control of its DNS servers. If you cannot do this, be willing to pay a service provider under a fair contract.

Subdomains provide a way of passing control down to a department without giving up the power to retract that control. For a subdomain manager, the benefit of a subdomain is to have an identity that is verifiably part of a larger whole.
Mail and web under a domain name are stock items for most hosting providers, and you can choose one that meets your criteria for privacy and storage resilience. By all means, avoid the slightly cheaper silos that are so large-scaled that you can only control them up to their level of desire. You get what you paid for. The unbalance of power at large silos is going to be costly at some point.

At the very least, plan an escape route with any hosting provider; control identity and do not use their domain (or one with their trademark), have downloads of all data (or the contractual right to get it when you close down) and make sure you can redirect traffic elsewhere.
Chat is completely trivial to setup and run as an open protocol under your domain, and it can easily be offered for free. A good choice is XMPP, which is wonderfully and openly standardised, is heavily used, has many open source implementations and can even integrate with less-open chat solutions.

End-user applications are often liked for a slick user interface; with an open protocol and open source you it would be simple to have a slick mobile app produced just for you. You might gradually expand the app to deliver other bits of data over its authenticated channels. XMPP at least has a generous tradition of extensions.

Why are we using so many chat applications? Because they are cheap to run and simple to offer; it passes terse data that is fit for statistical analysis, and if it is a closed protocol a full overview of users and their connectivity can be seen, and that data is exclusively available to the chat service. In short, it helps to sell advertisements.

These "benefits" disappear with open protocols, which would allow users to connect to anyone and everywhere. Open protocols serve users, rather than service providers.
Identity is a typical service to not lay in the hands of a data-hungry party. This is the right to enter your account and look around, after all! Even if current agreements do not do not use this technical ability, it might happen in a future "upgrade" of service conditions. Will your corporate lawyer detect such issues? Is your technical staff capable of changing providers in such an event? How costly will such a change be? Where do you draw the line, and how economical is that choice?

This article series discusses options for having control over your online identity and staying in control. We used intentional extension facilities in protocols to make this possible, wrote open protocol specifications that we aim to standardise via the Internet Engineering Task Force, and we see many ways of integrating it into most of the protocols we use today. Not just the (eroding) web environment, but also email, chat, telephony, database access and much more.

In short, we developed software that you can use to run an openly accessible identity provider under your domain name. This takes in standard protocol exchanges such as SASL or Kerberos and on the basis of this exchange it authenticates a user under its domain. The domain is validated by an identity-depending party using standard Internet mechanisms (DNSSEC, DANE) so that it knows that it is talking to an identity provider whose prerogative it is to decide on user identities underneath the domain.
Telephony, and especially the potential to listen in to microphones on desks everywhere, is probably an underestimated risk for information leaks. This means that you want control over the phone switches that connect to such microphones. Although VoIP can be a bit of a nuisance to setup, there are many commercial providers who are quite capable of helping out, usually with the open protocol SIP, possibly with open source PBX software, and facilitating your existing phone numbers. Home users often find such functionality in their routers, either as part of a package deal or as an easily configured link to telephony. There really is no need to leak your commercial or academic advances, nor to be subject to listening in on private conversations.
GDPR Compliance can be a nuisance, but it gives the same privacy guidance to many organisations that make a united requirement of fair privacy from services that control their information. Do not struggle with the GDPR, but use it to select your service providers. You may end up in your own jurisdiction, which makes (economic) sense, certainly when you are publicly funded.

Instead of listing all the faults that follow from the poverty of a thrifty sell-out, wipe the slate clean by choosing one who subscribes to the privacy of your users. Do not lightly decide to sacrifice your user's privacy, by treating them as cheap labour subject to cost optimisation, but consider them human resources.

It is a sign of poverty if money makes you do things that you would not have done if it hadn't played a role.
Confront your organisation about any point where they sacrifice freedom or sovereignty, for the company or its "human resources". If the work force is indeed considered a resource, then they should treat it respectfully.

Make sure that choices always include ethic variants, find the price difference with the cheapest and conclude from this what the price (per head) for these values is, if the choice for the cheapest form is made.

Make sure to verify whether an escape mechanism exists. No choice is made for ever, and it should not be costly to leave, because that will be used as an excuse for not taking a turn for the good.

Be sure to introduce these issues in the advisary board of your organisation. Make your board aware of the future implications of today's choices.
As a company, consider that the best workers have more freedom to move, and are more likely to feel a burden from these sacrifices. Given other options, they might leave. You would be left with less opinionated workers, which may well be the less motivated ones.

Liberation Day is worthy of Celebration

Let's commemorate past wars, and avoid future ones, by realising the great value of individual freedom in a democracy. Let us repeat that it is not an automatic given, and needs our ongoing attention. And that our freedom is a valuable human asset, worth fighting for (says a pacifist) because it is in no way destructive; it actually provides an alternative for the delusive paths that move us towards desolation.

The University of Twente is cited above as a mere example of a global trend. Many organisations make the same silly choices for the same silly reasons. They are penny-wise but pound-foolish. They are selling out because they are only staring at numbers. Numbers that have no meaning because they ignore human values. Numbers that do not express the anti-social devestation on the privacy and sovereignty of your communication peers. Numbers that are dangerously one-dimensional, and could never represent the splendour of a diverse and multi-cultural society.

Let's start to break free on this Liberation Day. Not just this year, but in all the ones following. Our project is here to guide you, and is glad to integrate your contribitions for general good. Because the silo of open source and open protocols is just as capable as any silo. All it takes is collaboration — which is a more powerful force than competition (let alone warfare) could ever be.

And we are all but alone; many open source projects are part of this ongoing battle, and they need your support in so many easy ways; be it through donations or project acquisition, through documentation or bugfixes and new feature additions.

But, more than anything, these open source projects are waiting for you to start using their software.

Liberation Day is a good day to free yourself, and move away from the ongoing commercial battle of control over your online presence.

This article was published under a CC BY-SA 4.0 license.

Access 5: Juggling Keys in the Rules DB

2021-06-24T21:49:18+02:00

This article is part of a series on access control and is related to another series on identity.

The worst thing that can happen to a service hosting provider is if their databases are tapped, and the information of many users is published to people of debious repute. The ARPA2 Rules DB is designed to not be an interesting catch for such people.

Cryptographers are funny people. Given a pile of useful information, we turn it into unreadable gibberish. And we pride ourselves on the fact that you will not recognise back your original information. Plus, when presented with the same information, we guarantee delivering the same gibberish... well, that might actually be useful!

Hierarchy of Keys

As explained in Dialing into Access Control, the access of a database gradually approaches the targeted field. We use the Access Domain and an optional Database Secret as a first level, much like a country code in telephony. Then comes an Access Type like comm or docu or group, which compares to an area code. Finally, the (Remote) Selector and a resource-description string called the Access Name finds is like the actual phone that we want to ring.

Keys are derived at each of these levels. They are called the Domain Key, Service Key and Selector Key. And they all look like long hexadecimal sequence, devoid of content for anyone but the odd folk known as cryptographers.

We introduced the a2rule utility and innovated it heavily since then (yes, in just two days). We added the desirable support for Document Access, a generic Ruleset Access interface.

Do not just read the empty words below; do try them, playing around with a2rule and checking your suspicions. The quick feedback will be instructive. When you stick to get actions you should not cause any damage while playing around.

Rule DB and Password

An addition that we first made for debugging, but realised as incredibly potent for users, was the dumping of the keys at various levels,

shell# a2rule comm get local john@example.org remote mary@example.com
Domain Key not in $ARPA2_DOMAINKEY_example_org
Database Secret: 
Trunk number: 0
Domain   Key: f6559b947113d42b0a6ae4542a4f8c8e77178a1935858f6d2b8e1a712899c35e
Service  Key: 3ced5fc5b2aaa1c45acc71230f267886cb97fdc9ac95505b6e0373e221eac665
Selector Key: 165426bc7ba66c93e2872d9fcc1c6060954c70605a5d99686687af09c64faaf0
DBrule: #a2xs %W

What you can see here, are the three levels of keys from the "dial plan" just described. If we change the Access Name or Remote Selector we should get another Selector Key, and indeed:

shell# a2rule comm get local john@example.org remote sweetsister@example.com
Domain Key not in $ARPA2_DOMAINKEY_example_org
Database Secret: 
Trunk number: 0
Domain   Key: f6559b947113d42b0a6ae4542a4f8c8e77178a1935858f6d2b8e1a712899c35e
Service  Key: 3ced5fc5b2aaa1c45acc71230f267886cb97fdc9ac95505b6e0373e221eac665
Selector Key: 2da13bd48746e6450b56f0c8abb4211aae29a8f61d28356ba51bfa289e2e97d7
No rules found in the database

The Domain Key and Service Key do not care for the Remote Selector, but the Selector Key does, so that hex code is different. Unrecognisably different, and flipped an average of half the bits, a cryptographer would proudly add. Also note that no rule was found this time, due to the changed Selector Key.

So let's change the Service Key and see that the Selector Key changes along with it, but not the Domain Key:

shell# a2rule group get member cooks+vegan@example.org        
Domain Key not in $ARPA2_DOMAINKEY_example_org
Database Secret: 
Trunk number: 0
Domain   Key: f6559b947113d42b0a6ae4542a4f8c8e77178a1935858f6d2b8e1a712899c35e
Service  Key: f9bbc0890a3328855ea9a7cf2e0dd75d67a958db547bae75c1833a23b8e1b13b
Selector Key: 817823302bfd2cce699636108317601e00f44e9ec4c15fb86f93b3f305829ef9
DBrule: #a2xs %RWA ^vegan@john@example.com

This does indeed change the Service Key and logically also the Selector Key; and although it finds a DBrule it is a different one. But as expected it does not alter the Domain Key. For that, we really not change the local domain:

shell# a2rule group get member cooks+vegan@example.net
Domain Key not in $ARPA2_DOMAINKEY_example_net
Database Secret: 
Trunk number: 0
Domain   Key: 83b448a3e4d0e14088a92f2fbc2f0cda69e11829b16282ba574bd64972f18b13
Service  Key: 861c9784f465912689bc8dabbda83b8965bf9d29e1434b33f17bf27d891992a5
Selector Key: 551056495b2ee675fdbe49e1b1850e4cc67ebd9071addb9e87c081d5d10e1f0a
No rules found in the database

As might be expected, all three Keys change as the result of a different domain name, and any DBrule should be located in the changed location of the Selector Key. Generally, this is the idea, that changes at any of the levels perturb the process of database lookups, or relocate it to other codes. The codes are too large to guess, of course. It's one of those things that cryptographers pride themselves for.

Database Secrets

In the examples above, we simply pressed Enter when prompted with Database Secret:, which is the good-old password prompt from getpass(). If you entered an actual string you would hit a fourth level of perturbation:

shell# a2rule group get member cooks+vegan@example.net
Domain Key not in $ARPA2_DOMAINKEY_example_net
Database Secret: 
Trunk number: 0
Domain   Key: ceff8176af41a983433086210ab54db33971f02220d68675f4e3dd7adef7782a
Service  Key: d61d4d67acb92bf1f003a63288cf30cc9cb5052fa0b1196dd9dda7591f1f2d52
Selector Key: 24d7924681f27797c5ede91152d0dbec0bff8d1278db24b10b6b0dbc6a5b0eb5
No rules found in the database

That's for typing a mere x after the prompt. As if you planted your Tree of Keys in completely different soil. And that's the idea; you can have as many trees as you like, as long as you protect them each with their own password.

Now, passwords are a nuisance; they may add a useful daytime regime to the life of a system administrator, but not "normal" users. So now let's divert the password prompt!

Lower Secrets

The top-level entry to Access Control will always be protected by a password, but the lower-level keys can be spread more easily to administrators who control only a portion of the tree.

The Domain Key may be handed over to the owner of a domain, or their administrator. As you can see in the dumps above, an environment variable is tried to load it. When this is found, it effectively bypasses the Database Secret prompt, because en entrance point lower in the key tree is available. Note how a mangled domain name is part of the variable name, so you can have variables for each domain if you own many.
The Service Key is usually handed over to a service provider. Given a hosted service, the domain name and Access Type ought to be fixated, and crossing over to other domains and/or types is not a good idea without explicitly providing them with the corresponding Service Key material. That's how cryptographers can actually be a bit useful, by assuring that to be safe. We are experimenting with an environment variable for this too, but have to see if it works out in practice.
The Selector Key is derived through iteration, usually as part of a database access process. For instance, the calls access_comm() and access_document() can be handed a Service Key, and they may iterate from concrete to abstract on a Remote Selector to derive the various Selector Keys locally.

And yes, users matter:

Perhaps User Keys would make sense too, if a domain has users that may control aspects of hosting. In fact, the code used for derivation is a sequence of rules_dbkey_domain(), rules_dbkey_service() and rules_dbkey_selector() and the first takes in something called a domain, but not really checked to be just a fully qualified domain name; we may formalise support for a user@ prefix but already have "accidental" support for this useful idea.

Juggling Keys is What We Do

In the end, souvereign use of the Internet involves handling privacy and securty, and that always ends up as a game of juggling keys. The scheme presented here is designed to gradually dissiminate control, following the path considered the authoritative scheme behind systems such as DNS and URL notations.

Most of the time, you should not notice these games. You simply have the key you are supposed to know, and can do your work, running a2rule and never entering any password. The only exceptions are when you control the tree of rights from the top, handing out datbase keys to those below your realm of control.

Access 4: ARPA2 Access Control for Mail

2021-06-24T20:01:22+02:00

This article is part of a series on access control and is related to another series on identity.

As previously shown we have made tools for easily managing Access Control, which is setup in a system-central database. Now we demonstrate how you can apply these rules in an application. We demonstrate it for email, but there is nothing special about SMTP/email; the same ideas could be applied to XMPP/chat, SIP/telephony and so on.

Email usually passes through a number of stages of filtering and scrubbing. Even if we leave out the virus scanners and spam filters it may look a bit daunting. We'll talk you through though.

On the left, you can see email coming in. Lots of terrible things are being tried at that point, so a fair degree of effort goes into fencing off the most blatant attackers. This is what a program like postscreen, part of the Postfix MTA, does nicely.
Soon after, we enter a program axesmtp-in that employs ARPA2 Access Control to learn about the communication rights for the sender to the intended recipient. Email classified as black listed gets bounced, and white listed email may pass.
Grey listed email should be challenged a little, which fights spam quite effectively and programs like postgrey do this well. Note how convenient it is that explicitly white listed contacts can pass through immediately, while those unknown are filtered with a bit more backpressure (by incurring a delay).
Email that is marked as honeypotted may be treated like they were on the black list or, if you want to discover more about it, sent astray into a honeypot where they hopefully tell us all the tricks that spammers might think of.
White listed email normally passes into the mail queue, which is central to mail servers, and the cornerstone of their solid delivery. From the mail queue, delivery to local users via their mailboxes is among the options. Users who send mail may also send it out, but the habit of doing this for incoming mail is considered offensive, if no further processing takes place.
One form of processing that may be useful is that of group iteration. Since the ARPA2 Rules DB also stores group members and allows their iteration, this has been built into the axesmtp-group program. Mail is directed here when ARPA2 Access Control told us that the sender address should be changed into a so-called Actor Identity. This new identity is often a group member, and is triggered by a Rule when it permits sending to a group address. Group iteration then completes the task by iterating over the members in the group that should receive an email. It delivers to their registered email address (or identity).
Finally, mail that is not group mail may be sent out through the axesmtp-out program, which makes an ARPA2 Signed Identity when it seens a "recipe" for such a signature pass through. The idea is that a reply to such an email address will be recognised by the axesmtp-in program. Normal email replies should not notice any changes, but there may be exceptions for unintended uses that you pinned down with the signature as improper conduct. Sending you email a month after you ordered something in a webshop, for example, could be rejected due to an expiration of the email address.

About AxeSMTP

The AxeSMPT programs are ours. They are built on top of an efficient, event-driven program that passes email as a kind of SMTP pass-through server. It may intervene anywhere, chop up the traffic and paste the chips back together in another form.

The program as shown below is very young, and certainly needs to mature. The simplicity of the current code does however make it a perfect example of the simple ideas. So, the links below point at a fixed, young code version for explanatory reasons.

You are more than welcome to apply these ideas to your own programs, and we love to hear about such work!

Filtering Incoming Communication

Blocks similar to axesmtp-in in the diagram can be imagined for other application protocols, but email serves as a good example. The purpose here is to recognise the things we consider proper communication, and weed out anything else.

The program code processes callbacks when the commands MAIL FROM (with a sender address) and RCPT TO (with an intended recipient address) are sent.

During MAIL FROM, the sender address is parsed with a2id_parse_remote() to know that it has at least somewhat reasonable grammar. The form does not assume that the sender uses an ARPA2 Identity, which makes this check more lenient than it would be for local users.
During RCPT TO, the local recipient address is provided. Since this is a local address, it is possible to more stringently parse the recipient address with a2id_parse() that does require proper ARPA2 Identity forms.
Once parsed, the recipient address is subjected to Signed Identity testing with a2id_verify(). If it has a signature that does not pass, for instance because it has expired or because it does not permit the sender address, then it will lead to the refusal of the email. A fine point to note is that email without a signature always passes; it is up to the next phase to put up any minimum requirements through signature flags.
What now follows is a check of Communication Access with access_comm() which returns a level that allows diversified actions further down. Not all the ideas of the schema above are already implemented here, but the structures are clearly shown. Also note the actor output and the check if it was not set with a2act_isempty(). This is how the two whitelisted paths can be distinguished; whether to delivery the email to the queue or to group iteration.
Only after all this scrutiny will the email get passed to the backend for further handling. The level and whether or not an Actor Identity was returned provide timely information to distribute the email to various possible backends.

As you can see, all this logic fits into 174 lines of code, not counting generic SMTP support code in the directory above it. We believe that the ideas for ARPA2 Access Control are very powerful, but at the same time really simple to embed into any bit of software, for any protocol.

Processing Outgoing Communication

The only task currently handled in the program code for outgoing traffic is to add signatures into ARPA2 Identity forms that ask for it. This applies to sender addresses whose username part ends in + but not as the end of a complete signature.

This work cannot be done during the MAIL FROM command, because some of the data hashed into the signature may depend on the recipient address. So all that is done here is to check the ARPA2 Identity grammer with a2id_parse() and store the result.
When the destination address arrives during RCPT TO, the first thing being done is avoid trouble with basic parsing as a remote, non-ARPA2 address, using lenient parsing with a2id_parse_remote().
Next up, the email is signed with a2id_sign() if it holds a recipe; otherwise, the function returns success without having done a thing. As with a2id_verify() this choice was made to allow a consistent flow without separate checks and code paths for signing.
As with the input filter, the backend delivery is started for the recipient.

This all in just 169 lines, of which quite a bit is patched out. You should feel no hesitation in adding this to your own software, as far as we're concerned. Offering your users control over their own identity may help them escape from the cognitive dissonance of being a second-class citizen in a world that controls their online behaviour.

Delivering to Group Members

The last bit to cover is group iteration, and the delivery of mail to multiple members. This takes only slightly more code than the foregoing bits.

During MAIL FROM, the sender address is assumed to be an Actor Identity, which in the case of a Group Member means that it has a local domain and a username that consists of at least two parts separated by a + symbol. The part after the last + is considered a Member Alias and the part before is the address of the ARPA2 Group. This explains the parsing as an Actor Identity with a2act_parse() with 1 level of + being stripped off.
The recipient address provided during RCPT TO is also assumed to be a Group Address, though it may have any number of Member Aliases added; none would deliver to the group and any higher number would only deliver to the named members. This explains parsing as an Actor Identity with a2act_parse() with 0 levels of + stripped off, followed by a manual check that the group matches the group from the MAIL FROM phase.
This filter is larger because it also has a callback for DATA, and distributes the actual email to multiple backends. Also, it stores all recipient addresses for one call to member iteration in group_iterate() to avoid double delivery to Group Members.
Group Iteration will repeatedly start a callback procedure for Group Members to start backends for each. Further content is then forked to all these backends.

Well, that was a lot of logic in only 312 line, once more a sign of careful design and an API that wants to be easy to use and allow you to benefit from it.

Now go and grind your own Axe!

Access 3: ARPA2 Access Control and Groups for Admins

2021-06-22T14:01:33+02:00

This article is part of a series on access control and is related to another series on identity.

Our software library ARPA2 Common does general tasks for all our projects, and it is designed to easily integrate into the protocols and software made by others.

First, let's briefly explain what our libraries do; then we turn to the way an admin would manage these rights.

The identity library makes it easy to work with ARPA2 Identity, including its pattern form ARPA2 Selector. It involves parsers that dissect a string into its components, it can iterate over its parts, compare if one is more special than another, and so on.
A special feature if the identity library is that it can make identities valid only in a specific context. For example, an email address could be setup to only accept email from a particular sender (or sender domain).
The access library can be asked if Communication Access from a remote ruser@rdomain.com to our own user@domain.org is granted. The answer will be that it is on the white, black or grey list -- or perhaps that it should be subjected to a honeypot! It is up to the software calling the access library how these results are put into effect.
The same access library handles Document Access, where a local or remote user@domain.com wants to read write or otherwise work on a document. The access library presents a series of flags that indicate the rights that apply.
The group library can be used to iterate group members. Again, this is a generic mechanism that is not specific for, say, email. Some fancy tricks are possible to address one or more specific members, or perhaps all but a few, in a way that conceals their actual address to anyone but an admin looking for an abusive group member.

Rules Database

ARPA2 Common uses an efficient memory-mapped database that we call the Rules DB. It takes great care to do this efficiently. The database is normally stored in the /var/lib/arpa2/rules/ directory, but an environment variable ARPA2_RULES_DIR can be set to override that.

The libraries mentioned above use this database. They usually need to do only a few lookups, so they are extremely fast. On top of that, the Rules DB is built on LMDB which is extremely fast.

The a2rule utility is used to manually write into the database. A second utility that automatically extracts configuration data from LDAP is being developed. The design of the database allows future exchange of data from an identity hoster to a service hoster, with protection against iteration of the database by any party.

Communication Access

To manually update Communication Access in the Rules DB, the admin can post commands like

a2rule comm add \
   local  john@example.org \
   remote mary@example.com \
   list   white

This white lists, so grants access, from Mary to John. This setting is agnostic of protocols or software, so it would apply to any email, chat, voice or other forms of communication that you might think of. As long as it uses ARPA2 Common to look into the database.

Pass in too little, and you will receive feedback about the command syntax. The general form is an action on a class of objects, with additional parameters after a keyword name. The order of the <keyword> <value> pairs is arbitrary.

a2rule <class> <action> [<keyword> <value>]...

The contents of the database can subsequently be queried with

a2rule comm get \
   local  john@example.org \
   remote mary@example.com

The output is (currently) the contained Rule, which reads

#a2xs %W

You might be surprised how little information this produces, but this is the actual stored data. The local and remote values are hashed into the database key, but not stored in it. This means that the database can be an oracle for questions, but it cannot be brutally iterated for communication data.

The part %W flags the entry as white-listed. The part #a2xs does not even mean anything, it is merely a (comment) marker for the a2rule tool. This helps to keep the tools from interfering with each other's data.

What you can get, you can also delete,

a2rule comm del \
   local  john@example.org \
   remote mary@example.com

You cannot add what is already there, and you cannot delete what is not there. This can raise errors. To remedy that, there is a variation that assures that the new content is set to a desired value,

a2rule comm set \
   local  john@example.org \
   remote mary@example.com \
   list   white

This works like add after an optional del. A good use is to assure that Communication Access maps to a certain list.

The remote is an ARPA2 Selector, and a full ARPA2 Identity is just one possible form it may take. On the other end is the most general form @. which covers everything. Since Communication Access looks for the most concrete match to the Remote Identity, it is possible to set a default treatment with something like

a2rule comm set \
   local  john@example.org \
   remote @. \
   list grey

You have now enabled grey listing for all undefined Remote Identities. Grey listing defaults to refusal of communication, but it may pose a challenge to the remote. When the challenge is satisfied, a white list entry may be set for that Remote Identity.

Document Access

This is actually not implemented yet in ARPA2 Common v2.2.6, but the pattern will be similar. Thelocal user@domain.name identity would be replaced by a name for a document or directory, and the list selection would be replaced by flags that grant particular kinds of access.

Group Members

A rather different application of the Rules DB is group membership. The underlying engine is the same however, and so the a2rule tool is used for this too.

a2rule group add \
   member   cook+vegan@example.org \
   identity john@example.org \
   marks RW

This already shows the magic of ARPA2 Groups; although john@example.org signs up for the cook@example.org group, he does so under a member alias vegan. Within the group, he will therefore be known as cook+vegan@example.org.

How well this abstraction works depends on the software and protocol; for example, an email mentioning John's underlying identity john@example.org would still leak that information, but email headers might be rewritten by a privacy-aware piece of software.

The mapping from the member alias to the underlying identity is still used for delivery, of course. To that end, software iterates over the group with the ARPA2 Common group library.

To track down abusers, there is also commandline support for looking up the identity for a member,

a2rule group get \
   member cook+vegan@example.org

This would list the Rule in the database,

#a2xs %RW ^vegan@john@example.org

The comment #a2xs marks this as the work of the a2rule tool, %RW marks read/write privileges to group resources, and ^vegan@john@example.org is a trigger that indicates the member alias vegan as bound to an underlying identity john@example.org.

As before, there are also a2rule group del and a2rule group set commands with similar meaning. In the end, a2rule manages Rule Sets, and so set operations are used for individual Rules.

Demonstration Code

An early bit of code to demonstrate the ideas of ARPA2 Common is AxeSMTP. This performs a few tasks:

Destination addresses are subjected to Communication Access. This not only involves the recipient address but also the sender.
Destination addresses with signatures are compared against their context. The address might have expired, or be a misfit with the communication context, in which case it is rejected.
Rules in Communication Access may spell out aspects that ought to be checked through a signature. This would be where unsigned destination addresses fail, or ones with too little constraints built in.
Actor Identities are applied when they are encountered during Communication Access.
Group Member Iteration is performed for group identities. (The current Group Iterator fails on non-group identities; in Postfix, you can remedy that with a transport for group identities.)
Source addresses with an incomplete signature (flags and optional expiration, but no actual signature) are signed on the way out. Do not apply this to group mail.

This can already do more than the few simple examples given above. Please interact with a2rule to see syntax suggestions, and do read the manual page.

Think Globally, Act Locally

2020-12-25T00:00:00+01:00

There are many situations in the World that nobody wants to maintain, but most of us assume that individuals cannot make a change. In our project, we obviously think otherwise; open source is perhaps the most obvious example of the difference that our individual choices can make.

Being human, we need to make make our day-to-day choices based on partial knowledge. This is unsolvable, because we have only a limited processing bandwidth [Mihaly]. And so, our brains evolved to fill in any gaps; this ensures that we don't freeze when faced with a choice, but that we can at least act. Run away, fight, whatever. Brain researchers [Swaaij] will tell you that we habitually think up reasons for our actions as an afterthought; police investigators and magicians will tell you that this makes a human's account of a scene unreliable. Simply because we cannot process all the information around us.

To help us make the best decisions we make them more local; we focus on the things that concern us. We usually consider information directly around us, such as the current place, the current time, and the (current) family. We basically prioritise our choices with this mechanism. Observe animals and you will understand how well this works. The phrase think globally, act locally basically calls out to use our intelligence to prioritise global concerns while making decisions; to develop a pattern of choice that focusses on things that serve humanity as a whole, rather than acting on impulse and evolve beyond the individual interests that animals are subjected to.

There are good reasons for calling out on this. We often assume that individuals should be empowered to make their own personal decisions, and may be making a mistake when we extend that to commercial organisations, especially those who defend shareholder value. Freedom of choice combined with a financial motivation creates situations in which parties may act against their conscience. When faced with the consequences, they tend to argue that they have no other choice. People sometimes do that too. Anyone saying this is basically saying that they understand and reject the ethics involved in their decision, presumable because something else is an overruling concern. What could that be?

Money gives us an abstract form of trading; every transaction is complete and neutral. This sounds nice, until you realise that anthropologists [Lietaer] have found that friendships arise when people help one another; many things are simple to give but feel great to receive. This causes people to feel a wish to continually help each nother; it is a sound basis with mutual benefits, even motivated by personal interests. This aspect of friendship vanishes when money is handed over to neutralise the help provided.

Ethics is abstracted out from transactions that are neutralised with money. We can see this in the financial industry which would rather gamble on prices of staple foods like rice and wheat than financing enterprises. The enterprises could help build a better World, whereas staple food prices rise due to the trading; the latter is however less risky, so an understandable choice when seen from an individual angle; it is of course a misfit for banks that have been empowered to create money if they do not act with fitting societal responsibilty. Poverty in general would be unbearable if we could not abstract from it, and allow people to just thrive [Yunus]. Industrial animal keeping can only exist in its current form as long as we can use money's abstract properties to distantiate ourselves from from its brutal treatment of animals.

Growth has a natural ceiling in nature; a lion hunts to survive, but will not prey on more than it needs. Although greed is sometimes excused as "survival of the fittest", any comparison with nature is actually a misfit. But unbounded growth tends to be unstoppable and lead to the destruction of civilisations [Diamond]. It would be a different matter if regulation was effective in providing a ceiling to the creation of differences between wealth and poverty. Interest is a main driver in the broadening of this gap [Lietaer] and Inflation creates growth of money, but not of wealth; what does create are instability and insecurity by subjecting the financial system to phases of growth and recession [deSoto].

Freedom is about your ability to make choices. If you only incorporate the lowest price in your choices, just like many companies do, then you are not really free; you are not imposing your personality on your actions. Instead, you have fallen prey to marketeers who think on your behalf. They will tell you what you need, they decide when your "old" stuff is out of fashion. And they are so good at it [Barber] and are even designing for addiction [Lustig] that it is surprising that not all advertisements have been banned entirely. Personally, I consider advertising an insult to my intelligence and I always block it from entering my head.

Think Globally is a mantra that asks you to be aware of the World around you. To realise what the global impact is of choices made by individuals like you. And how you may be part of a system that you do not approve of. This sounds uncomfortable, but it is mostly a motivator that pushes you to liberate yourself.

Act Locally is a mantra to empower you in exercising your personal freedom, and make choices founded on your own feelings of what is ethical and what is not. This can be a process of constant personal development, and much more rewarding than mere enslavement to marketing, to fashion, and to the feeling that you don't matter. Because you do. It's your ideals that make you human.

Accept Imperfection when it comes to ideals; it is often easy to do 90% but getting to 100% is likely to bring a lot of anxiety. Ideals can liberate you, but being too forceful may end up impairing you, and giving up. You will probably find that you need to approach your ideals one step at a time, and can then incorporate more and more habits to get closer to. Personal example: I cook vegan meals because I care for my health, the environment, poverty and animals; however, to avoid stressing out friends I ask them to treat me as a vegetarian. I show less leniency in restaurants.

Concrete Examples

Personal freedom forbids that you would be forced into someone else's ideals... and still, a few examples, however personal, may be interesting.

Express yourself! As long as you don't block others from being themselves, why would you hold back in being the best you can be? There is a reverse side to this coin - judging others about matters that don't concern you would restrict their personal freedom.
Innovate the World towards something you love. Find others to work with. You actions count, especially if you end up motivating others.
Use open source software because it expresses that copying code is cheap. In return, companies should consider funding improvements, and individuals can donate their quality by working on it. There is certainly room for non-coders; there is a lot of work for writers, graphical artists, translaters, project managers. Not employed? Gain some experience for free!
Use open protocols and frown on services that can only work with their own "very special" software. This includes all Apps and JavaScript requirements on websites. The web is basically open, but quickly moving into a closed and locked-in mechanism. How many chat applications do you need in a World where such trivial functionality ends up in non-integrated islands? And there are many protocols that are more specialised, and better when not forced over the web; telephony, chat, data transfer, and plenty more [IETF].
Be sceptic about "free" offers because they are usually made with a purpose. Do you agree with that purpose? If it is an assault to privacy, does it only affect yours or are you pulling others along in a ride that they don't want?
Be sceptic about "social" networks because they tend to individualism, but not to society. By sheer language definitions, this makes them populist networks.
Think. Don't let algorithms turn you from someone exploring an opinion into someone caught into a bubble that confirms this. Lookup authoritative sources before you form an opinion. Bring strong viewpoints into balance by also reading about the opposite views.
Vote. Many countries are currently experimenting with populism; most of it ends up being destructive for the well-being in a country. Question your politicians before you vote for them.
Be energy-neutral or at least work towards it. It is an undeniable need of the World that we all move in this direction. The older you are, the more you benefited from the CO2 that is now hurting the World, and the more reasons you have to make up to younger generations. Elderly people who can afford solar panels may want to balance an isolated cost/benefit calculation with this ethical consideration.
Money talks as soon as you take it away from things you don't approve of, and put it into things you care for. The lowest price can be a really cheap choice to make; it is an enrichment of your life to be part of a solution, than part of a problem.
Industrial animal farming is a questionable system to fund. You know the reasons, although most people are not aware that it is a breeding ground for new diseases [Greger]. Luckily, you can get as far away from it as you like; your taste adopts a new pattern of eating after 3 week and the human body only needs animal food to offset extremely one-sided diets; to most of us, animal food quickly becomes an overdose and culminates in cancer, diabetes and heart disease. It also drives climate change. ([Lancet]*.

Sources. Mostly popular words from authorities in their fields.

[Mihaly] Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience.

[Swaaij] Dick Swaaij, Wij zijn ons brein: van baarmoeder tot alzheimer. (in Dutch)

[Lietaer] Bernard Lietaer, The Future of Money.

[deSoto] Jesús Huerta de Soto, Money, Bank Credit, and Economic Cycles.

[Yunus] Muhammad Yunus, Banker to the Poor.

[Diamond] Jared Diamond, Collapse: How Societies Choose to Fail or Succeed.

[Barber] Benjamin R. Barber, Consumed: How Markets Corrupt Children, Infantilize Adults, and Swallow Citizens Whole.

[Lustig] Robert Lustig, The Hacking of the American Mind, interview.

[IETF] Internet Engineering Task Force, About, online.

[Greger] Michael Greger, Pandemics: History and Prevention. online.

[Lancet] EAT-Lancet Commission, summary report, Food in The Anthropocene: the EAT-Lancet Commission on Healthy Diets From Sustainable Food Systems, online.

Access 2: Shaped like a Matrix

2020-12-22T00:00:00+01:00

This article is part of a series on access control and is related to another series on identity.

In this article, a few examples of Access Control in the InternetWide Architecture will be explained. They will be part of the ARPA2 common support library that we develop alongside.

Access Control in Rows and Columns

In the above diagram, we have drawn yellow hexagonal cells, each expressing some access control information.

%R is the Access Right of reading, %RW for reading and writing, and %CRWD adds creation and deletion rights.
=aadmin is a variable definition supplied along with the Access Rights. What variables mean depends on the Access Type (application area). Here, it might mean only when using an admin alias.
^log triggers an action in the evaluating software. It too is defined by the Access Type, and it may or may not be meaningful to the application evaluating access rights.

Variables and triggers are rather luxureous features to add, but they are almost zero-cost and can greatly leverage expressiveness, so we added them. The heart of the matter lies in the %rights indications, of course.

The cells express the rights where the coordinates in the blue boxes on top and the green trapeziums on the left meet.

The blue boxes on the top are what we call the Access Name; in general terms these are UTF-8 Strings with generic handling rules. The actual string is specific to the Access Type being used; for document access the string holds a volume/path format; for communication it holds the userid of the local user.

The green trapeziums on the left are Remote Selectors; at the base, they start as a full-blown Remote Identity, but gradual abstraction steps turns them into a pattern that could match if the more specific forms did not. Access Control will start at the base and iterate upwards to try to gain access.

The fish is the last to discover water, because it is all around him. Similarly, this entire image is considered to apply to an local domain being accessed (the Access Domain), and to an Access Type (such as document access).

Resource-Centric view on the ACL

Access Control makes most sense in relation to resources, even if this does not yield the most scalable implementation. Under any object that we want to protect, we can iterate who may access it and who may not. In the diagram above, this is looking at one column at a time.

Let's write the hdd/photo column in a computer-sciency ACL notation.

dn: ...,accessDomain=example.org,...
object: labeledURIObject
object: accessControl
accessType: 3c2291f6-fc11-3d83-9908-f79b2d2f4ced
accessName: hdd/photo
accessRule: ^log %R ~@example.com %CRWD ~john@example.com
cn: Collection of Photos on Bugs, Beetles and Beatles
labeledURI: https://photo.example.com/john/bugs
...

This defines two Access Rules consisting of a sequence of code words. We use % before rights, ^ before triggers and, not shown here, = to set any of 26 variables and # to comment out (or disable) a word.

This example notation defines a single object with all the information we need for Access Control:

Access Domain from the dn: line
Access Type from the accessType line
Access Name from the accessName line
Access Rights and a few extra facilities in the accessRule line.
Remote Selectors at various levels in the accessRule line.

All this information is packed tightly together, and can be requested with a single query. This is the common approach for LDAP, of which this is an example. It works quite well, as long as not too many users approach any single object.

A problem with this model is that all the information is out in the open, making it is easy to iterate the data. This can be a problem to security and to privacy, and an interesting target for data theft. This makes the form less suitable for sharing with service providers, especially when these are third parties and certainly when these are large-scale operations.

Example Service using the ACL

Imagine a service like an Apache web server, configured with HTTP-SASL authentication and entry-level Access Control:

<VirtualHost ...>
   DocumentRoot ...
   ServerName photo.example.com
   <Location /john/bugs>
      AuthType SASL
      Require valid user
      ...
      AccessRule ^log %R ~@example.com %CRWD ~john@example.com
      ...
   </Location>
   ...
</VirtualHost>

Note how simple this is. The Access Domain, Access Type and Access Name are implicit in the webserver configuration, but they are there. But they are not really used; Apache can just evaluate the AccessRule directive against the authenticated %REMOTE_USER variable.

This is lovely for personally run servers. But it also has a few problems that would block its adoption with massive domain hosting providers:

Very long AccessRule lists would slow down the web server, so this model scales poorly;
Editing configuration files is unworkable for hosting providers, except perhaps for static entries.

So, we shift our focus to a model with an external database that can be queried more efficiently, and that does not to search linearly through the AccessRule. Using the key derivation diagram of the previous post, replicated below, we can collapse quite a bit of information into one Type Key, and this could include a Database Secret which makes the entire action irreversible:

<VirtualHost ...>
   DocumentRoot ...
   ServerName photo.example.com
   <Location /john/bugs>
      AuthType SASL
      Require valid user
      ...
      AccessTypeKey ebf036285570769e0359b24cdceb7dd56c1558436ec7ceffa9f251e8916ae6bf
      AccessName "hdd/photo"
      ...
   </Location>
   ...
</VirtualHost>

This setup is static for any given Access Domain, Access Type and of course the database secret. The only variable part that remains is the Access Name, which happens to be static in this particular example, but which may in general vary.

The Access Name is a formatted string, and when setup as a regular expression it may extract information from the current query, including its path and query parameters. Not explicitly visible but still dynamic is the authenticated value in %REMOTE_USER that would be incorporated into the ACL process.

We have now arrived at the other perspective on the ACL; we shift our focus from columns to rows of the matrix of cells!

Remote-Centric view on the ACL

Consider once more the diagram at the top of this posting. The remote selector goes through an upward iteration process, and for each of the strings found we land on a different row of the matrix with each a different selection of cells.

The information to select the right column is also present, so we have the actual cell coordinate in the matrix diagram. Now all we need to do is to look for it efficiently (not linearly). We can look in a simple key-value database for each iteration output string. The most concrete one wins, so we start at the Remote Selector at the bottom of the left column and work our way up until we find a hit. The cases for @. therefore serve as default settings.

This is how the second Apache webserver configuration above works. It uses the AccessTypeKey with the AccessName to derive most of the lookup key, and then extends it one by one with the Remote Selector obtained through iteration.

The contents of the cells are simpler than those in LDAP,

accessRule: ^log %R ~@example.com %CRWD ~john@example.com

The model for the key-value database turns this inside-out and delivers separate key-value mappings:

( ebf0...bf, "hdd/photo",     "@example.com" ) --> "^log %R"
( ebf0...bf, "hdd/photo", "john@example.com" ) --> "%CRWD"

If we start looking for john@example.com we would hit the rule for %CRWD immediately. When mary@example.com takes a look she would fail but retrying with @example.com should would find ^log %R for read access and being logged. She might run into some beautiful Coccinellidae magnifica images, but she won't be able to squash them (the images, of course).

The distribution of long list simplifies the Access Rule, and they could be found in log(N) steps. There are a few nitty-gritty optimisations to get even more out of this scheme, but these may be a topic for a separate post.

Access 1: Dialing into Access Control

2020-12-21T00:00:00+01:00

This article is part of a series on access control and is related to another series on identity.

In this article, the general concepts of Access Control in the InternetWide Architecture will be explained. They will be part of the ARPA2 common support library that we develop alongside.

If you prefer to read about examples before you read about these general ideas, look for later contributions in this series of articles.

Barring access

Have you ever wanted to block calls to your phone from marketeers? Have you ever felt the wish to pull protective rubber sheathing around your email address, so it cannot be intruded by virusses? Welcome to the topic of Access Control.

These examples are concerned with the area of communication, but there could be other application areas, such as access to documents, to the source code of software or computation models that you are developing, or even for physical access to your home.

We shall use the analogy of the phone system to explain the abstract concepts that we designed to let you express your wishes for Access Control. The mechanisms are general and therefore a bit complex, but the result is a highly practical outcome -- like the phone system.

Country Codes are like dialing Hosted Domains

If you know the country of your callee, you should lookup the corresponding country code and enter it after the international prefix. For instance, dial +31 to reach the Netherlands.

Countries are the start of authority; they are sovereign entities. On the Internet, authority to reign starts with a domain name. Once you registered your own name, you are the sovereign over that domain. To take away your domain from you would take nothing short of a war.

Countries are just a name; to come alive they need territory, a soccer team and railways. In short, you need a kingdom. Compare this to hosting a domain name and erecting services for it. You might do this on your own if you are technically inclined, or you could outsource it to an external hosting provider.

ARPA2 Access Control involves mixing your domain name with a database secret for the hosting provider. This results in a "Domain Key" to predial your online kingdom. The Domain Key is not meaningful on its own; it merely routes access attempts to your online territory.

After dialing a country code, you can no longer choose to connect to other countries.

Domain Keys are derived using a secure hash. This is a forward-only computation, meaning that this code cannot be dissected to learn about the database secret for the hosting provider, or even the domain name. This means that it is not possible to derive the Domain Key for another domain from the Domain Key for yours.

Area Codes for dialing Application Types

Once you accessed the country, you continue dialing the area code for your callee. The country's switches use this to route your call to an area in the called country.

Metropolitan Areas represent communities that live and work together, and usually have tightly entangled communications. There is less talk between areas than within, and such connections take an explicit choice.

On the Internet, we can distinguish application types, and it makes sense to keep these separate by default. Your settings for access control of communication are simply different from your settings of who can view the photos on your website, who may access your documents, and so on.

ARPA2 Access Control derives a Type Key that can be configured into software that services a particular application area for your domain. For instance, communication may not only be available over email or chat, but parts like teleconferencing may be disclosed through a web server. All these bits of software can use the same Area Code that identifies an application area for your domain.

The area code is local to the country you just dialed. For instance, +3123 would be the area Haarlem (023) in the Netherlands (+31). But in the UK (+44), the area code +4423 would land you in Portsmouth (023) or Southampton.

Your hosting provider derives the Type Key by mixing your Domain Key with an "Access Type" code that covers the application area. This Access Type can be shared by all domains, but the resulting Type Key will be different for each domain. ARPA2 Access Control uses the 128-bit binary code of a well-known UUID for this purpose. The nice thing of the UUID system is that it is easy to create your own UUID for a new Access Type, so even if some applications are registered, this is not being enforced.

The purpose of well-known UUID values is that they can span across many pieces of software and allow integration and collaboration of many individual parties. You might have a lovely cloud storage tool, but it may be just one of many ways in which you access your documents, and you would like to have one place to control document accessibility.

To use communication once more as an application: It has an UUID of b4f0fc38-d4d7-3bb9-ad69-5bf75efc46dd derived in a standard computation from the DNS name communication.uuid.arpa2.org that falls under our control. This Access Type can be mixed with any Domain Key to form a unique Access Type that will not clash when they are looked up.

After dialing a area code, you can no longer choose to connect to other areas.

The area codes are derived using a secure hash. This is a forward-only computation, meaning that the area code cannot be dissected to learn about the country code, not even if the applicaton type is known. This implies that it is not possible to derive another domain's area code from your domain's area code, not even for the same application.

Residential Numbers for dialing Individual Resources

Once you accessed the area, you continue dialing the residential number for your callee. The area's switches use this to route your call to the phone jack in your callee's home. For example dial +3123456789 to reach John in Haarlem, the Netherlands.

Pfew, you finally reached your target. Now the phone can start ringing, at least when John's phone is not configured to block your Caller ID, or even all calls from your country/area codes with no exception for your Caller ID.

In Access Control, we want to specify access to a diversity of online resources; for communication it would be specific to users and for document access it may be specific to file folders. This may apply to pretty much anything, but a classification is possible when we consider the application type.

ARPA2 Access Control speaks of Access Names and represents them in general terms as a UTF-8 String. This general definition allows software to provide general support for this pinning-down of resources.

The string format of this Access Name is specified by the Access Type. For communication, it is the local userid. For document access control, it defines a path construct used to reach the document.

Application code usually finds this information in a query. Email would find it the Access Name as the beginning of an email address; document management systems find it as a path starting from a given document root and in the last part of a URL.

Access Control can now be reduced to a database lookup, which involves following elements (shown in the picture below):

Your Type Key, representing an application under your domain
The Access Name for the resource being accessed
The Remote Selector (or "Caller ID") trying to gain access

Just like you may want to block all calls from an entire country or area, you can specify similar things for the Remote Selector. This is the topic of a full Identity or a Selector that matches many, to be discussed soon in another blog post. The software for ARPA2 Access Control looks for a few more things than just the concrete remote identity, but in general the most concrete one found decides on the Access Rights granted to the remote. This allows you to block an entire domain but then let certain users in that domain back in.

The Key to Access Control

Since we are intent on distributing our online presence to third-party service providers with access control centralised at an identity host, we need some complexity in terms of this key derivation as sketched before. It is highly efficient and hardly takes an effort while accessing services, but the structure helps to keep better control over your online presence.

The picture below shows the structure of key derivation for ARPA2 Access Control; as you can see, the service software is configured with a Type Key and needs to format application data into an Access Name. It then iterates over the remote user to evaluate access from several levels --beyond just john@example.com this would be willing to fallback to @example.com, @.com and @.-- with a simple lookup in a key-value database. We use a highly efficient memory-mapped database for doing this in our software.

Technicalities of Trunking

The phone system consists of switched circuits, connected by trunks. A trunk may carry multiple calls at the same time. When one trunk breaks down, the call is routed over another trunk. These technicalities are concealed from the users of the system.

Type Keys are general enough that they could get distributed over multiple providers. This explains why we employed forward-only computations. But it also implies that Access Control information should be shared between providers.

This is possible by inserting an extra number with every entry in the database. By default, it is set to 32 bits. This extra number is like a trunk code; it is concealed from the user, but very important in routing information.

The extra number allows us to dissect an Access Control database. Different sections may have come from different providers or, if we are the source of information, may be targeted at different providers. In general, the idea is to be able to have one large database, using one efficient access mechanism to serve a bulk of customer domains, but still be able to manage sections of the data in a generic manner. For instance, when resyncing to the access control information from another provider it is helpful to cull old data; all data in a section can be safely removed before it is replaced. Transactional boundaries help to shield user processes from ever observing it.

This is just an example; a few more uses can be imagined. It is not of importance to users, but hosting providers can rest assured: we got you covered.

Metaphorically Speaking

We hope that this informal introduction will help your understand the general concepts that we shall introduce next in this series.

Identity 16: Support Levels for Realm Crossover

2020-09-16T00:00:00+02:00

This article explains the approach for support of BYOID to this article series on identity.

We design solutions for hosting providers. This means that what we design would scale to large customer bases. That does not mean that it cannot be run on individual services, however. Inasfar as the diagrams below seem complicated, this is mostly due to our recognition of more concepts than usual; the actual software that needs to run is modest enough. It just has a few more hinges, with great client freedom as a major benefit.

We discuss SASL at length, and briefly turn to the simpler models for Kerberos and GSS-API near the end. We also touch upon pseudonymity near the end of this article.

Level 0: Plain SASL Authentication

Basic authentication assumes that a client is local to the realm that also operates a service. The client does have a unique client userid, but not a client realm because the realm is provided by the service. The result is an identity userid@service.realm where userid is authenticated by SASL under the service realm.

As an example of this, you might think of a typical email server, which requires login with an account on that server. This model works well for email, because our mail server makes global connections on our behalf, and at the other end email pickup is once again a local process. At most, the model sacrifices some flexibility for shared mailing lists.

For web services, the same model is problematic. Having accounts on each and every web service is a common problem these days, and because most bog down to the most stupid model that they know, namely password authentication, security is downright bad. No surprise then that we are designing a way out.

Level ½: Plugin Services or "Static" Realm Crossover

Plugin Services assume a hosting provider, specialised on a service that domain owners can plugin through a references in DNS. The business model for the hosting provider is massive hosting with specialisation on the service. You certainly could do worse but you also might do better with a more integrated approach to identity. This is what we propose here. We still derive userid@service.realm identities.

This approach uses a simple backend API and protocol that we called diasasl. This is a TCP/IP connection on the local network, over which SASL requests can be passed to a central authentication backend. The protocol and API are really simple and integrate with blocking processes or threads as well as modern event-looping service architectures. We have made it as easy as we can imagine to integrate diasasl as the umbilical cord to your locally trusted identity node.

The local identity node is setup to relay requests to the serviced realm if one is requested that is not locally defined. This is made possible with Diameter, which shines in just this kind of realm-crossing authentication connections; it mutually authenticates over TLS and pools connections, so it is quite efficient in connecting to other realms and securely exchange SASL mechanisms. We defined an embedding of SASL into Diameter for this purpose.

This setup allows a client to run their own identity provider as a SASL-over-Diameter service, announce it in DNS with the proper protections with DNSSEC/DANE/TLS. Any party willing to host a service for the realm would use diasasl from a service to reach their central identity node, which then connects to the hosting client's own realm for login.

The realm of a Plugin Service is, strictly speaking, a realm configured for the service. This is why we call it "static" realm crossover. It is possible that the realm is derived from a protocol element, such as a host name or a path. This gives some form of flexibility, but the client still ends up under the service-configured realm.

A concern with this setup is that it is not safe to use with any login method. The service provider sees the SASL traffic flowing by, and not all methods are secure in that form. Some are, but one has to be cautious. The next level offers a better alternative.

Level 1: Realm Crossover with SXOVER

Public Services are even more open than Plugin Services, in that anyone may use them. In this case, the solution should even work without server configuration. Furthermore, it is not usually reasonable to trust a public service to see the authentication details passing through, especially when no service contract can be negotiated. Being the most flexible, this mechanism can also be used for the previous levels.

The pivotal point for allowing any client to use a public service is to facilitate Bring Your Own IDentity by granting clients to provide their own domain, with their own identity provider using a straightforward standard for realm-crossing authentication. The public service would use diasasl to connect to their local identity node, which knows just enough about SASL to detect the desired client realm, connect to it over Diameter, and relay SASL traffic.

SASL can be flexibly extended with new mechanisms; we designed one named SXOVER, specifically for use with Realm Crossover. This mechanism starts off by stating a client realm, under which a client userid can be obtained. SXOVER is like an end-to-end encrypted tunnel between the client and the identity provider in their realm. The additional use of channel binding information allows the client to ensure that they are authenticating to a particular public server and not any backend other than the identity provider.

The client realm is authenticated over Diameter, which means that it can be trusted by the public service; routing is however completely dynamic and no prior knowledge of the client realm is required for client login. Based on the trusted connection to the identity provider for the client realm is trusted, its claims of user identity underneath can be trusted too. We can therefore derive userid@client.realm identities; clients BYOID!

Pseudonymity

The best point to switch a client identity to an alias is during Realm Crossover, and SASL can provide this through authorisation identities; the first step is authentication under a primary identity and an optional second step is to switch to another identity, as specified by the client. Validation of this switch is required, for which we developed the identity inheritance idea.

Next to the use of an identity without active email account or simply a fresh one to thwart tracking across sites, a good use of identity switching is to access a service under a group account, for instance purchase when accessing a sales service without necessarily acting as an individual.

Mixing Support Levels

There is no issue with the mixed support of these levels. The inquiry for supported SASL mechanisms is always answered by the service realm, in all scenarios. Only when the SXOVER is offered and chosen by the client will level 1 commence. This will be offered when dynamic realm crossover is available for that service. Our diasasl protocol has a standard realm, namely the empty string, to allow quick provision of SXOVER and nothing else.

A setup for level 1 can be resolved locally if the sending and receiving ends of Diameter are on the same node. The connection will be made locally and more efficiently.

Realms that are available locally can be redirected to a normal SASL library with underlying account databases. If this is the only option, such as at level 0, then the link can be directly made from the application service. Note that nothing stops this direct connection to be made in a diasasl implementation, in which case maximum flexibility can be offered.

Kerberos and GSS-API

The examples above detail how Realm Crossover for SASL works, but we also have a mechanism in development for Kerberos. This is perhaps a more advanced model; both in terms of the knowledge needed and the quality and functionality.

Kerberos and GSS-API authentication carry a realm as part of the client identity, and so it can easily express all three levels. The question is how it maps to infrastructure.

At level 0, the client identities are part of a local ACL and this is the common usage pattern. Level ½ compares to "classical" Realm Crossover for Kerberos, based on manually configured crossover keys; in Microsoft terms, this is the formation of a forest. Level 1 is our full-blown setup with the KXOVER protocol that we designed for Impromptu Realm Crossover; again, the full dynamicity that allows any client to approach any (public) service.

Quantum Proofing your VPN

2020-08-06T00:00:00+02:00

As explained before, it is not a question if Quantum Computers will be made, but when. Compare it to industrial farming/marketing of meat if you like; we knew that a pandemic would come but not when; humans are surprisingly weak in battling such situations.

But when Quantum Computers arrive, it will be like Corona, and certificate authentication will need to be locked down everywhere. Those who neglected encryption will be beyond help at that time; encryption should already be your concern today, because traffic captured now can be decrypted in the future and is likely to still be a potent source of abuse and hindsight responsibility. Perhaps surprisingly, this includes almost all VPNs. This survey of techniques can help you weigh their risks.

Perfect Forward Secrecy

A valuable technology for deriving encryption keys is Diffie-Hellman (in either its modular-exponentiation or elliptic-curve form) where each party generates a public key and mixes their private key with the other party's public key. The result is a shared secret that both can use, but no interceptor of the intermediate result can derive that same shared secret.

Briefly put, the intermediate is always one step behind the proper parties that each have a private key. This principle even scales up to more than two participants in a key exchange, and the capturing middle man is always just not clever enough to do what the proper parties can do.

The best schemes are those where a private key (with a matching public key) is generated on the fly. This produces a scheme with Perfect Forward Secrecy, that is, no ability to derive one session key from a past (or future) one. This is a great improvement over something like RSA-based encryption, where a fixed public key is used and once its private key is derived all past and future work done with it can be reverse-engineered.

Unfortunately, under Quantum Computers, it will be possible to reverse a Diffie-Hellman public key (in either its modular-exponentiation or elliptic-curve form) and so, any derived secrecy can be reversed.

Craving for Entropy

The obvious solution is to add entropy, that is, a bunch of random bits that are somehow exchanged out-of-band. One way of doing this is Kerberos, and it is precisely that principle that we employed in our TLS-KDH. This happens to work because Kerberos is a key-derivation scheme that starts off as a shared secret between a user and the realm controller or KDC.

Another solution is to not send the public key in plain sight. This is also difficult in general, because you either need to magically know it (which will not work in the first-contact situations for which public-key crypto is most useful) or you need to have some way of encrypting the public key... which is introduces a loop in our reasoning. The only way to do this might be with Kerberos, for reasons of its pre-established encryption keys.

In general, it is difficult to find good sources of entropy, especially when they are to be kept out-of-band. The value of Perfect Forward Secrecy is so great that it is nonetheless used, but the Internet needs sources for entropy sharing. Either that or a Quantum Proof form of Diffie-Hellman, but there are currently no hopes for that.

Protocol Structures

Most encryption protocols use Diffie-Hellman to derive a session key, and use it without mixing in entropy (because there usually is nothing that could add this). This applies to OpenSSH, TLS and IKEv2 -- the driving protocols for Secure Shells and Secure File Transfer, for the most common Internet protocols like web and mail, and for the most common VPN technology IPsec. Oops!

Since Diffie-Hellman alone is not secure enough, its exchanges are often used for authentication. This means that the session key is somehow hashed in with credentials in a non-reversible manner, and it is verified that both derive the same result.

The nice aspect of this structure is that the protocol first encrypts, and only then starts sending identities. The observation of these identities would be possible for a party that actively intervenes in the traffic flow, but then authentication would not work, so this tapping party would be noticed during authentication.

The step that is not taken next, but that might be useful, is to merge the credentials used for authentication with the session key to form a new encryption key for the session. That way, the protocol would:

Setup a session key through Diffie-Hellman
Authenticate (and detect active intervention by tappers)
Update the session key with credential entropy
Exchange the actual data

Not much is needed to do this securely. Pretty much anything that cannot be computed back, or that allows isolation of the credentials or old session key would work. For instance, one might derive a session key from a secure hash over

If the session key can vary in size, include its size
The session key
A secure hash of the credential

Another approach could be to use the CRAM-xxx(key,input) method with the credential as the key and the session key as the input to sCRAMble. For xxx same hash can be used in other parts of the protocol.

This could easily be integrated into SASL or GSS-API exchanges, as well as the session key incorporated into each Kerberos ticket and made available to both ends.

Survey of VPN Systems

How do the various VPN systems hold up in practice?

OpenVPN with TLS is a proprietary but popular, somewhat documented protocol that uses TLS to derive a key. Since TLS is not Quantum Proof, this solution is not either.

IPsec with IKEv2 is used in a broad category of VPNs, usually over L2TP or directly over IP or UDP/IP. The offerings include interesting open source variants such as StrongSWAN with Charon as its IKEv2 driver. The standard key exchange mechanism is IKEv2, where session keys are solely based on Diffie-Hellman. When certificates are used, there is no extra entropy (private keys are not known on both ends and are not Quantum Proof anyway). And when a PSK is used, it only serves to authenticate the Diffie-Hellman exchange, rather than used for added entropy as suggested above. This solution is not Quantum Proof but at least the PSK-variant could be fixed as explained above.

IPsec with KINK is a solution that virtually nobody knows, and it only seems to be implemented in Racoon2. KINK leverages Kerberos for key derivation and is in that form Quantum Proof. It has an option for adding Perfect Forward Secrecy, where the public keys are sent in Kerberos-encrypted form and so they are Quantum Proof (and at the same time have Perfect Forward Secrecy).

Since storage of today's encrypted traffic mostly suffices for decryption once we have Quantum Computers, it is best to switch to a VPN that works today to thwart this future doom scenario. It may save you from abusive practices and give you ample time to update any credential that may ever have crossed a wire that was assumed safe on account of a VPN. The solution for today is IPsec with KINK; future extensions to IPsec with IKEv2 are possible, as well as for SASL and GSS-API mechanisms, but it remains to be seen how long that will take to standardise.

Update 2020-09-01: There are a few other ways to make IPsec a Quantum Proof protocol. First, the latest IKEv2 update specifies a "Kerberos Token" as a certificate payload. It does not specify what this means, but it is worth noting that the Kerberos spec uses distinct [APPLICAITON n] tagging for the various chunks of data that make sense in protocols. Basically, there is some room and it could get standardised, but it is not clear yet.

A recent extension well worth mentioning is the mixing of pre-shared keys with the Diffie-Hellman exchange that puts plain IPsec at jeapourdy of Quantum Computers. Pretty much any mix-in of such additional entropy solves matters but the price is high -- there is a need for somehow establishing this key up front. One way of doing this, once again, is to use the session key incorporated into every Kerberos ticket, or possibly the subkey incorporated into the Authenticator ("signature") for a session. Beyond this, it's preconfiguration of shared secrets that are then stored on the machines that serve as IPsec endpoints.

Networking #2: Reliable Peering over 6bed4

2020-06-26T00:00:00+02:00

This article is part of a series on networking.

There are a few tunnels for IPv6, and most are difficult to use. The 6bed4 tunnel is relatively easy to use; it installs as a bit of software and behaves somewhat like a VPN client, though its main purpose is routing over IPv6.

Applications can assume native IPv6 routing (but may impose any form of firewalling they like) and specifically that they can reach ports without NAT getting in the way as with IPv4. If any protocol flourishes on IPv6 it is going to be peer-to-peer protocols. The omnipresence of IPv4 however, lets designs of peer-to-peer protocols use that "for the time being" and lands them in the terrible problems of NAT traversal. For which there is never a perfect solution. By being generic, 6bed4 can solve these problems once, and have all the applications benefit.

The design of 6bed4 attempts direct connections between peers, but hides the details in the tunnel, which runs over UDP/IPv4 and does all the things that are otherwise loaded onto the designer of a peer-to-peer protocol. The places where 6bed4 can be used are:

As a tunnel serving a single host; this runs as a 6bed4peer process that connects to a 6bed4router that runs on a server; this could be your server or the default one, run at 146.136.0.1 by SURFnet.
As a tunnel on a router, serving a LAN; this also runs a 6bed4peer, but can offer a range of 65534 IPv6 addresses through DHCPv6 software (like DNSmasq) to a local network. The 6bed4router is around 35 kB and 6bed4peer is about 50 kB; they only depend on a C library.
As part of an application; we have this as a currently open issue but we are closing in on it fast. The protocol is quite open so nobody depends on our software anyway.

How Addresses Look in 6bed4

The traffic routes in 6bed4 depend on prefixes. There are three kinds of interest:

fc64::/16 is a local range, completed to fc64:<netid>:<ipv4>::/64 where the <netid> can be used to distinguish network segments and <ipv4> is the address of the 6bed4router serving it.
TBD1::/32 is intended to be globally routable, but we need to formally file for such a prefix assignment. The intention is to make it recognisable that the address is a 6bed4-routed address. The range is completed to TBD1:<ipv4>::/64 with <ipv4> referencing the address of the 6bed4router, as for the previous form.
Native /64 prefixes can be used. These do not convey an IPv4 address, so they are considered local to the 6bed4router address.

The former two kinds of address are supportive of direct peering connections. All forms have the peer's UDP port and IPv4 address in the lower part of the address, but not all prefixes let us recognise that this information is there. The fc64::/16 prefix will be assumed to have this meaning on a 6bed4 network; the TBD1::/32 prefix will be assumed to have this meaning everywhere on the Internet and the native /64 prefixes can only be assumed to have this meaning on the 6bed4 network, and only if it is a prefix under which the peer configured its own address.

How Routing Works in 6bed4

The destination address determines where traffic is forwarded. In 6bed4, the source address must match the sending peer; it is vital that the UDP port and IPv4 address of a sender match the lower half of its source IPv6 address, to avoid tampering with traffic to make it look like it's coming from somewhere else.

The green parts of this diagram form "your" network, the yellow node is another user of "your" upstream 6bed4router and the red parts are considered remote parts, either residing under another 6bed4router or none at all. The thick lines are the 6bed4peer and 6bed4router that you have setup for yourself, the rest comes for free.

Note that 6bed4peer processes may connect directly, at least if the destination prefix is recognised by the sender as one whose UDP port and IPv4 address can be derived from the lower half of the IPv6 address. It is this direct peering that is so beneficial. Your 6bed4peer process works with the other side to make reliable direct connections when it can, but goes through the 6bed4router if it cannot do so reliability.

Your 6bed4router may recognise its own /64 prefix, regardless of the form it takes, and relay the traffic to the 6bed4peer that uses that same 6bed4router service. It is the task of each 6bed4peer to always keep a link open to its 6bed4router, so this is a reliable fallback route in any case.

Something else your 6bed4router may do is pass the traffic to another 6bed4router for delivery to a 6bed4peer that keeps a reliable link open to it. This is called trapezium routing, and its use is to keep everything in the 6bed4 network and allow for bypasses to be made. At present, the only considered bypass is direct peering. This kind of routing is only possible when your 6bed4router can know the the prefix is a 6bed4 prefix, with the right information for delivery to a 6bed4peer in the lower half. This is why native traffic is not delivered in this manner.

Native traffic however, can be delivered if your 6bed4router offers it. This may involve specific routes or a default route, which just looks like ::/0 in IPv6. Delivery can be to local interfaces sitting behind the 6bed4router, or it may pass traffic on to external routers that care for the delivery.

As a special case, the IPv6 address of the 6bed4router may be connected to backend addresses and ports. In this case, a service at that address is contacted. It is even possible to map to another address, which is actually a form of NAT and awkward in IPv6; this hack is called masquerading and may disappear from future versions.

Return Traffic over 6bed4

When you send something, you normally want a response. This is why the UDP port and IPv4 address of your 6bed4peer occur in the lower half of its assigned IPv6 address; through this, the 6bed4router can always reach you and, if they are lucky, so can other 6bed4peer nodes. In relation to non-6bed4 nodes, the concern is mostly if traffic can route back to the 6bed4router.

The first case is also the most difficult; return traffic to fc64::/16 sources is only possible for local nodes, because the addresses are locally defined only. It is a concern when setting up the 6bed4router process; read the man page!

The second case is possible as soon as we have the TBD1::/32 prefix assigned to 6bed4, because it allows the traffic to be passed to any 6bed4router for the first 32 bits, and then the traffic is relayed to the IPv4 address that follows after the prefix. Note how this is a matter of routing rules, but otherwise already encompassed in this diagram.

Finally, if your 6bed4peer was setup with a native prefix, as is the case for our default router as provided by SURFnet on 145.136.0.1, your 6bed4router will receive the return traffic through normal IPv6 routing and relay it based on the knowledge it happens to have about the lower part of the address.

Note that all this is derived from the addresses themselves. There is no need to keep state. This means that there is no reason to log anything, especially because complaints about abuse of an IPv6 address can be translated into complaints of an IPv4 address and a UDP port.

Reliable Peering in 6bed4

A protocol similar to 6bed4 has been tried before, by the name of TEREDO. It is built into Windows machines, and is the cause why Windows users tend to switch off IPv6. The tunnel is flawed, because it makes assumptions about its NAT traversal possibilities. Most peer-to-peer systems suffer from the same fate, and occassionally missroute traffic as a result. You may have had single-sided media connections and this is where it comes from: assumptions based on classification of NAT traversal.

Instead of this inductive appraoch, 6bed4 is deductive. It simply tries if NAT traversal works, and chooses to go through the 6bed4router if this is not possible.

When communicating with a potential direct peer, your 6bed4peer will send empty Probe messages to the direct address. It will not do this for every packet you send, but try a few times and slow down the pace when no response comes in. It never fully gives up, so when the remote peer comes online later it will be discovered.

When traffic returns from the remote peer, it can set a "Seen" flag to indicate that traffic got through. This may have been a Probe or actual traffic. The "Seen" flag is sent on all return traffic for 2 seconds after it was seen, and it permits 27 seconds of direct peering after reception. This assumes that NAT holes stay open for at least 30 seconds, a common assumption but one that can be changed on the remote peer if its NAT works differently; this impacts the "Seen" timing.

This process happens independently in both directions. The returned attempt is usually even simpler, because your 6bed4peer already sent a Probe. And it will try again after 1 second and after 2 seconds, so under normal protocols this quickly leads to bidirectional direct peering. As long as your NAT allows direct peering at the same IPv4 address and UDP port, then 6bed4 should discover this rather quickly.

There is a method to guaranteer that your NAT supports direct peering. This is done with port forwarding. As described before, a 6bed4router can be run in a router box, and this combines perfectly with port forwarding. If the standard port for 6bed4 is used, this even means that the IPv4 address in the top half fc64:<netid>:<ipv4>::/64 or TBD1:<ipv4>::/64 can be the public IPv4 address of this router. This may explain why trapezium routing can be beneficial.

Traffic Classes in 6bed4

The IPv6 header "Traffic Class" is used to give a clue about routing preferences for a single packet. Applications can use this to request a bulk and eventually reliable delivery, or fast but possibly dropped treatment.

We use the Traffic Class to distinguish whether the traffic may, must, or must not pass through your 6bed4router. This being the only reliable route, excluding it reduces the chances of contact, but you may prefer that for some applications.

We define the following Traffic Classes:

proper-peering(0) is the default treatment, going through the 6bed4router for reliability, but passing to a direct peer when this is a reliable alternative.
prohibited-peering(1) is the mode where all traffic flows through your 6bed4router.
presumptious-peering(2) tries for a few seconds to setup direct peering, but when this fails it falls back on your 6bed4router.
persistent-peering(3) goes even further, and will never route through your 6bed4router; it would rather drop traffic and send errors about it.

These choices are made for individual packets. This means that different kinds of traffic can be treated differently (SIP versus RTP versus MSRP for example). You might even try out one approach and switch to an alternative if you have to.

The relation to a given remote peer is managed while traffic flows, so the state of reliability is known when a later packet hits, and any delays of a few seconds learning time are shared. You might pass a few seconds of meaningless traffic and then add a secret stream as soon as it is safe.

The "Seen" flag is passed in this field too. You cannot set it in the application and should send its value as 0 for future extensibility, but you can learn its value from received traffic. This can help you make decisions about routing policies with this peer, or whether to turn on the green light that indicates safe mode, whether to start a secret flow, and so on.

Networking #1: Backward Compatible with IPv4

2020-05-31T00:00:00+02:00

This article is part of a series on networking.

IPv4 is a very old protocol, and it has survived surprisingly well. The addition of Network Address Translation (NAT) allows sharing of addresses with a larger group, although at the risk that port numbers may have to be changed while also changing the address. This port change reduces the reliability of peer-to-peer exchanges, and it means that the worst case scenario's require a server to bounce off traffic. When your online conversation is only one-sided (you can hear the other but they cannot hear you, for instance) it is very likely caused by this problem.

Advantages of IPv6 over IPv4

Port changes by NAT are not a real problem with client-server protocols, so as long as we do not need peering, we can continue to use IPv4. In a peer-to-peer protocol, traffic passes directly between the end points. In media traffic, this is usually the goal, both for reasons of privacy and to offload servers. Using IPv4 generally means that "NAT traversal" techniques are needed, and that may involve bouncing traffic through a remote server. A salient example is Skype, which is said to be bounced by the NSA.

The addresses in IPv6 are much larger, so everyone can have their own, and NAT is no longer needed. Firewalls still are used, but they are much easier to pass through when both ends want to connect. This is known as transparent addressing.

In IPv4, virtually all addresses behind a NAT router are so-called internal numbers. There is a range 10.x.y.z, one at 192.168.y.z and another that runs from 172.16.y.z to 172.31.y.z. These offer enough room for in-house networks, but when designing a network with a few bits of information in the address, these quickly fill up. Random numbers of 24 bits run into 50% clashes around 5000 hosts, for example. IPv6 not only offers a broader range of addresses, but it also defines many practical address allocation policies by way of a prefix. This means that most software can behave smartly around these addresses, whereas the IPv4 ranges given above remain open to interpretation because they serve all those purposes at the same time.

As a bonus, there are several prefixes that incorporate an IPv4 address into the much longer space of an IPv6 address. For example, a given /96 prefix before the 32 bits of an IPv4 address may give a routable IPv6 address at 128 bits. In other words, an IPv6 address can express any IPv4 addresses, while the opposite is impossible. This makes that IPv6 is more general.

IPv6-only Internal Networking

These reasons make it interesting to look into IPv6 for internal networking. A common practice is doing both IPv4 and IPv6, but then the addressing problems, peering trouble all end up on the plate of the network designer, and not everything will work well. Plus, firewalls and routing must be setup, tested and maintained twice, which is costly and can be downright confusing.

An internal network can be IPv6-only, as long as it has a way of expressing IPv4 addresses as well. Given that, a generic layer of processing on the perimeter of a network may handle the mapping to the IPv4 world. This is how we will arrange the hosting stack for the InternetWide Architecture.

As a general approach, we consider a public interface iwo0pub that faces the Internet and translate it to a DeMilitarised Zone interface iwo0dmz that has been filtered; this includes the translation.

The translation from iwo0pub to iwo0dmz is almost direct, with just a firewall to stop undesired traffic patterns before they hit the internal services. It is generally transparent, and is most conductive to peer-to-peer protocols.

Mapping IPv4 to IPv6: Incoming Traffic

When a client accesses an IPv4 address, it needs to map to the internal IPv6 addresses. We do this in a number of steps, all targeted towards maximum use of the spares address and port space in IPv4. We do keep that mapping static inasfar as possible, because that reduces the need to keep state and work with timeouts and the resulting network-driven disconnects.

NAT46 is a technique to map IPv4 addresses to IPv6 addresses, and it can be part of a NAT64 technique doing just the opposite; when a mapping is static, this is easy to understand because traffic passes through in both directions.

Basically, every IPv4 address can be explicitly mapped to an IPv6 address,

172.16.0.1 <--> 2001:db8:172:16::1

You would not notice being relayed through IPv6, except when you were to ask the server for your IP address:

myclient$ ssh 172.16.0.1
Welcome on myserver.

myserver$ echo $SSH_CONNECTION
2001:db8:172:30::7012 60447 2001:db8:172:16::1 23

This allows the translation of a targeted address, but what to do with the IPv4 address of the sender? Simple enough, we can add any /96 prefix, but there actually is a standard namely 64:ff9b::/96, that can be used for any public IPv4 addresses. So this means that an arbitrary address is mapped with

w.x.y.z <--> 64:ff9b::w.x.y.z

These internal addresses do not have to be known to our internal network; we may setup firewall rules to further map the 2001:db8:172:16::, along with protocol and port information, as it can be directly reached over IPv6. To the service running on that IPv6 address and protocol port combination, the client now has a funny address, but it can respond to it -- as long as the return traffic passes back into NAT64. That is easily achieved, with routing tables that redirect the 64:ff9b::/96 prefix to NAT64.

It is also possible to treat TLS connections in a special manner; since these start announcing the server name that they are connecting to, it is possible to use that to further split incoming connections and thus multiplex more incoming channels on one external port. This is useful for IPv4 but the slight overhead it brings can be avoided with transparant addressing under IPv6.

Mapping IPv6 to IPv4: Outgoing Traffic

The question now rises how an IPv6-only service may connect to an IPv4-address. The answer is simply to use the same stateless NAT64 service, so we should use the 64:ff9b::/96 prefix for any such remote addresses.

Again, this can be solved in a generic manner, using DNS64. This is an extension that name servers can have, and that may be applied directly after any DNSSEC validation. The effect of DNS64 is to lookup IPv6 addresses with an AAAA query but, failing to find any, lookup IPv4 addresses with an A query and add a prefix to map the output into IPv6 addresses.

DNS64 is the perfect companion for NAT64, and allows your internal network to make client connections to any IPv4 address from an IPv6-only network.

Such connections however, are made from a local address and protocol/port which also needs to be mapped to IPv4. If the local address/port matches a published service this is trivial, but otherwise we need to resort to NAT to squeeze many IPv6-only clients into a small external IPv4 space.

This can be done in an IPv6 firewall by using NAT in that realm, and directing the output into NAT64 by using the prefix 64:ff9b::/96. This would be a dynamic translation, for the same reasons as in a home router for IPv4: to be able to squeeze many possible internal addresses into a few external addresses. The same disadvantages apply as with those NAT boxes, of course.

The NAT approach would be applied for any outward IPv6 traffic that is sent to NAT64, and only when no static mapping for published services can be used. This is very much like any NAT setup with port mapping for explicitly configured service forwarding rules. It just happens to be easier to do in IPv6 space. The result is an address that maps into the NAT64 statically mapped address space, so the local address too can be mapped to IPv4, even if this was originally not possible.

Given that we have NAT available, we may even use the privacy-friendly private IPv6 addresses that can be automatically generated under a routable /64 prefix. These addresses rotate regularly, and make it difficult for attackers to guess them; the NAT setup with port mapping would end up spreading the allocated external address/port combination too.

Full-Strength IPv6 for IPv4 users

The use of a NAT mapping will not be problematic in all cases, but it certainly devestates the reliability of peer-to-peer connections. Users who continue to put up with STUN guesses about NAT behaviour, or who are unconcerned about bouncing all media through external parties on a data-hungry Internet may continue to use this.

The NAT64 solution with DNS64 and IPv6 NAT will keep the Internet usable for IPv4 users, though with some added processing for their backward compatibility. Future patterns of peering may however be out of reach, simply because IPv4 with NAT is an incomplete solution to those goals.

For IPv4 users who cannot obtain their own IPv6 range, there is an option to run IPv6 locally and run it over a tunnel. We shall use the 6bed4 tunnel for this purpose, and set it up on a server in such a manner that it works directly. Only when two IPv4 users connect through 6bed4 and their networks cannot support it, would the traffic pass through a bouncing proxy -- but that would be the proxy selected by one of the participants, which can be held under own control, as part of a domain name solution.

The principle of 6bed4 is simply to wrap IPv6 packets into UDP/IPv4 packets. The IPv6 address is constructed from the IPv4 address and UDP port on each end point. There is a routing mechanism, and most importantly, active trying of direct connections between peers, and switching to that mode whenever possible.

Though it is possible to implement 6bed4 as a generic uplink to IPv6, it depends on the IPv6 routing policies of the network around the 6bed4 server whether this is possible. When this surrounding network is not setup to manage the specially formed addresses for 6bed4 then it cannot do this. This, however, is an extension that is not required for direct use of a service on a hosting platform that supports 6bed4 for local use.

Knowing your Priorities

The three schemes of reachability are, in slightly declining order of efficiency and user experience:

Native IPv6 traffic is the best option;
Tunneling over 6bed4 is the second option, but only available where a tunnel is installed;
Mappings to IPv4 addresses are the last resort because they provide incomplete functionality and may block peer-to-peer applications, or make them less reliable.

Services that use records with priorities, such as SRV or MX records, should probably takes this order into account, yet specify all these addresses to reach the best connectivity that can be achieved.

Though it is possible to improve the peering behaviour of IPv4 with STUN or TURN, this still leaves the disadvantages of a more problematic internal stack. Choose wisely, and plan for the future; with a single IPv6 stack you should not have the overhead that dual-stack solutions brought you. If you still have IPv4-only devices however, you may need to patch around them; you know, things like 6bed4proxy for SIP/RTP crossover; these tools are mildly obtuse, but actually drive the message that your network can still be improved. Peering is getting more and more important in a centrally-tapped World, which trumps such local networking inconveniences. Furthermore, these transitions can be yet another way to centralise IPv4 users into a tapping point. We should choose wisely, and roll out IPv6 everywhere.

Conclusion

It is certainly possible to design network internals as simple IPv6-only applications, and it enhances the freedom and possibilities of such applications.

The translation of IPv4 traffic to IPv6 is then taken care of by generic components, and IPv4 users get the user experience that they get elsewhere too, just with a bit more processing to make it possible.

The limitations of IPv4 with NAT do show, especially for peer-to-peer applications. This is always the case in such setups, and it is important enough to communicate that the fault lies with NAT, and so with IPv4.

Anyone interested in full-blown IPv6 access but unable to do this on their own end can lift up their service level explicitly by adding 6bed4peer software.

The approach sketched here should make it painless to be up to date, and guide evermore IPv6 into your network, and to be supportive of peer-to-peer protocols and their ongoing development, while retaining IPv4 functionality for classic client-server use cases.

Identity 15: Entering Security Codes

2020-04-17T12:50:51+02:00

The best passwords have a lot of entropy, meaning surprising bits. While English proze has a density of 1 bit per character, because of its structure. A number has about 3 bits per digit, hexidecimal comes in at precisely 4 and BASE32 and BASE64 bring 5 and 6 bits into the game. The lack of structure in these formats are terrible for human users.

This is a somewhat fundamental article.

Helm Keys are Long Codes

As explained before we need fallback codes to bootstrap our online identity. A very simple system for that is the HAAN Service, for which both user name and password are represented as long codes. Normally, you would not enter those manually, but let's say did, and registered a fallback identity with a typo. Whoops!

As an example, these are fallback credentials that a HAAN Service could provide:

Haan Key: 5XICN3JA3FJ7IILMWNNGHQLH3FZIXYPU@unicorn.demo.arpa2.org
Password: 6P5ED4TDH4S7ZQHKM3FUDF4SZDNXROAU

(I can simply post these actual credentials here; they have no value because they will not be registered anywhere.)

It is easy to make a mistake when you would enter these by hand. In the web world, the "solution" might be to let you enter the same address twice, or to authenticate just to be sure. We prefer to squash that need because it involves typing long codes, and because the passwords are reserved for fallback/recovery uses.

The solution is then to make those long codes, that you only enter in exceptions, just a little longer (as has already been done in the above). This gives a security level of more bits than strictly required, and if we find a way to ensure that the security does not drop below the intended level, we may allow corrections.

Counting Entropy

When we speak of 128 bits or 256 bits of information, we speak of the entropy, or the amount of pure information, without any structure, so completely surprising with every bit. Contrast that with somewhat predictable codes that are known as redundant. Practical codes are a mixture; English proze has some surprises (otherwise there would be no use reading it) but not too much (allowing us to recognise structure).

The term entropy dates back to Shannon's information theory, which considers noisy channels and the amount of entropy they could transport reliably. If 30% of the channel's content gets distorted by noise or clicks, then only 70% of the bits sent will arrive properly. If you add redundant bits you might detect and perhaps even correct errors. (You might even like to read up on this 1948 technology.)

This is pretty much the approach that we have in mind; we need to match a registered identity, but may remove some of its entropy to correct for mistakes. To do so, we allow for some operations on the text and count the number of bits to encode them. Subtracting all the necessary changes should not bring the security level below the desired level of 128 or 256 bits.

Entropy Lost due to Typos

People make a few common mistakes when they type information:

Add a character
Change a character
Drop a character
Swapping two adjecent characters

Again, we can go back to very old computer science theory to find algorithms doing this. The combination of these four aspects is resolved in the Damerau-Levenshtein algorithm. Normally, these algorithms count the number of editing operations, but a weight may be assigned to each of them. The weight we coose is the number of bits to encode operations:

Exact matches: 0 bits lost
Switches between upper/lower case: 0 bits lost
Switches between I and 1 or between O and 0 in BASE32 codes: 0 bits lost
Adding a character: 11 bits lost
Changing a character: 11 bits lost
Changing a character to a keyboard neighboir: 7 bits lost
Dropping a character: 7 bits lost
Swapping two characters: 7 bits lost

Now you wonder how we got to these bit losses, of course. It is really straightforward; we devised an encoding:

Equivalent changes consume no entropy
Operation choices consume 2 or 3 bits of entropy
Positions consume an estimated 4 bits (there will be ~4 of them in up to 64 characters)
Character data consumes 5 bits of entropy (for BASE32)
Adding a character: 00<pos><data>
Changing a character: 01<pos><data>
Changing to keyboard left: 100<pos>
Changing to keyboard right: 101<pos>
Drop a character: 110<pos>
Swap adjacent characters: 111<pos>

Note how this encoding would be parseable, there are no overlapping operations. The codes would be completely surprising, so they take away entropy. If we start with 160 or 320 bits of entropy, we can loose 32 or 64 bits of entropy and still have 128 or 256 bits left.

We also don't need to do anything special with these codes; we can just generate more random bits to include; this is effectively the entropy from which we shall subtract.

Examples

We shall look at a few small codes and see how much changes in them. The input code is vertical and the output is horizontal, and each matric node shows the entropy lost up to that point in the two codes. The output is in the bottom right position.

Going from ABBA to ABBA, we find no cost because we simply run along the diagonal:

 0/base 11/add  22/add  33/base
 7/del   0/base 11/base 22/add
14/del   7/base  0/base 11/add
21/base 14/del   7/del   0/base

The code base is a choice for plain copy or substitution; add and del and swap mean what you think they mean.

Now let's swap the last two characters and go from ABBA to ABAB:

 0/base 11/add  22/base 33/add
 7/del   0/base 11/add  22/base
14/del   7/base 11/base 11/base
21/base 14/del   7/base  7/swap

Finally, let's see what happens when adding characters from ABBA to ABBBA:

 0/base 11/add  22/add  33/add  44/base
 7/del   0/base 11/base 22/base 33/add
14/del   7/base  0/base 11/base 22/add
21/base 14/del   7/del  11/base 11/base

As you can see, you can make about 3-4 mistakes when 160 bits are supplied for the 128 bit security level and 6-8 when 320 bits are supplied for the 256 bit security level. The redundancy really pays off.

We believe it is useful to have a way to allow gradual decay of security levels. This allows control over the achieved level, and makes it measurable.

Extensions to SASL

This mechanism can be implemented in SASL, when it goes from an authenticated/logged-in username to an authorisation/access-control username. Many of the mechanisms, including even the trivial PLAIN mechanism, support such changes. Any implementation of SASL therefore needs code to see if such changes are permitted.

It would be typical of a HAAN Service (Helm Arbitracy Access Node) to facilitate these corrective measures and help people to help themselves.

It should be clear from this that the 128-bit and 256-bit forms must have distinct computations; one must not be a prefix or otherwise modified form of the other. It should not be supported that a 256-bit identity could be used to facilitate (a lot) more editing to get to a 128-bit identity!

Extensions to ARPA2 Helm

The ARPA2 Helm can use SASL with Realm Crossover. When a user wants to login, they can choose to relay to a HAAN Service, which responds with the authorisation identifier. In normal circumstances this would match the identity stored in the ARPA2 Helm, which may look it up without distinguishing upper/lower case. If a typo was made in the registered identity, the HAAN Service must be asked to derive and count the editing operations, to see if sufficient entropy remains. If so, the authorisation identifier that passes can be the mistyped one known at the ARPA2 Helm.

To the ARPA2 Helm, this means that hints must be given when a login fails. It too could use this comparison to see if an entered correct identifier matches one that was registered with sufficient entropy left; if so, it might present that as an option. Note that this is not an information leak; it assumes that a user already logged in with their correct identity, which just not happens to match the one registered in the ARPA2 Helm.

There will be a wish to correct wrongly registered identities, of course. To the ARPA2 Helm, that kind of action is within normal operational parameters.

Identity 14: Bootstrapping Online Identity

2020-04-13T18:22:49+02:00

The central problem in all this is that your online presence builds on something else, as it needs to start somewhere. In our project we tend to think of this as bootstrapping your online presence, starting with a form of authentication that you want to continue to exist. And to be honest, going back in time is not helpful to get back control. The systems were less secure and your memory about the credentials likely gets foggier.

Related to this is the problem that people fall off the net for a variety of reasons, and their presence may need to be changed by others. This applies to people are deceased, to employees who loose their jobs and to companies that are sold or go bankrupt.

Placing you at the Helm

Every entry point to online resources (like email addresses and domain names) is an important point to regulate your continued access. And doing this properly clearly needs more fantasy than the current password-with-email-fallback.

We developed the idea of ARPA2 Helm, and want to place you at that Helm. Since it makes sense at any point where you take control over a resource, it should be used for domains but also for delegated subdomains, for email addresses of individual members (but not their personal aliases), and within groups each member counts as an access point to guard. There are many places where users hop into online resources and could make good use of an ARPA2 Helm to stay in control.

In essence, an ARPA2 Helm just lists online resources and provides buttons to control them (add new ones, remove current ones and so on). And ways of using the resources as normal users, of course. You only need to login, and the authenticated identity that this yields allows the ARPA2 Helm to locate all the items that you can control.

Flying in from Different Angles

The trick of the ARPA2 Helm is that it allows you to connect more than one login identity to an online resource. And each of these identities is a separate possibility to authenticated. So instead of winding back time, you can have parallel options. The underlying identities are only used for authentication to the ARPA2 Helm; they are not shown to the outside world. They would rather be rewritten to a canonical identity for the online resource, for example an admin@ address for a domain name.

This means that really any identity will do, so the concept of Realm Crossover can be used to allow remote identities to authenticate for accessing the Helm. This gives you many angles of flight to get on board, and they can be completely independent.

Among the actions you can do in the Helm is the management of other identities that can be used to access the online resources. Forgot one? Remove it. And add another to replace it. As long as you have at least one entry point you stay in control.

Finding a Wingman

You should consider printing a few of the identities (and their matching credentials) on paper, and store them in a sealed envelope. Put them in book covers or vaults, whichever suits your requirements.

Another useful idea is handing over identity/credential pairs to friends, collegues or, for the most stringent requirements, an acting lawyer or notary official. In all cases the purpose is the same, namely to serve as a backup in situations of take-over/bankrupty or disease/death. And remember, if you and your friend fall in disgrace you can easily remove their access and substitute another; much simpler than getting back your home key from them.

Unlimited Boarding Passes

You still need a way to authenticate. But you only need to authenticate; there is no communication requirement. Indeed, with Realm Crossover this is possible, as we designed for SASL as well as Kerberos.

Because only authentication is required, and because the identity is not pubished, a long random code suffices as a user identity. Mix that with a long-term key in a server to compute a password. Reconstructing the password is easy, and requires no storage but for the key. Plus, sufficient netropy can be used to achieve a much better security level than for human-made passwords; 128 bit and 256 bit security levels are achievable. The one design constraint that is required for this setup is that nothing allows a username-to-password lookup for outsiders. With a randomly generated user identity and further only login attempts this does not happen.

Creation of such light-weight identities is trivial, because they have no value. It's like opening an empty bank account; authentication to such an account is not an issue. The moment you tell people to pay you into it there is a value, but not before. Likewise, a fresh authenticated identity is of no value, but that changes as soon as the identity is attached to online resources, as it is done in the ARPA2 Helm.

So, a fresh identity can be produced and provided to any requester without any concern. The password will protect a value, but only after the recipient allows it.

This means that we can construct something that we call Helm Arbitrary Access Node, or HAAN for short. It is incredibly light-weight to run a HAAN Service on a dedicated (sub)domain, and the most reliable service providers can be very small organisations that are simply careful about longevity and key management. A few of these suffice to give you a maximum of control over your online service through the Helm.

SASL Extensions

SASL mechanisms habitually lookup passwords for authenticating users; instead of accessing a database, passwords might be derived with a key computation that incorporates that entropy of a username. The result is usable with any SASL mechanism that requests a password for a given username, which gives a good range of choice. Making this available under Realm Crossover for SASL allows anyone to return to the key that can validate the username/password combination.

One SASL mechanism is useful to add. We call it GS2-HAAN-GENERATE and its task is to produce a fresh pair of username and password. As explained above, the username is random and the password is derived from it. Together with the domain name of the originating HAAN Service, the username forms a Helm Key that can be registered for any Online Resource.

The SASL exchange starts with a server-offered list of mechanisms, from which the client selects one. If normal login mechanisms are offered along with a GS2-HAAN-GENERATE fallback, then a well-known pattern emerges, namely the equivalent of a website login with an extra button to register if you have no account yet.

LDAP Extensions

Some systems are administered in LDAP, others in SQL or yet other formats. Since only LDAP has a generic schema language, this is the best way of expressing the extensions in support of the ARPA2 Helm, and have an easy-to-translate example for other contexts.

Adding a class helmOnlineResource to an LDAP object makes it subject to control over the ARPA2 Helm. A search for instances can start by looking for such objects.

Each of these can list any number of helmIdentity attributes. After authenticated login, presumably with Realm Crossover for SASL, a simple filter can be used to match these entries. The helmIdentity is either the exact identity or it may add a space and a label; that can be formulated in an LDAP search filter.

A few more things can be useful. When the object classes provide insufficient detail, a helmType may add value. And when an application independent name to present for the object is useful, then helmCanonical may be used. But that's it, really.

These simple additions to LDAP objects suffice to search for those that match a login; to add and remove Helm Keys, and so on.

True Independency is a Choice

The use of a HAAN Service implies trust in such a provider, and that may not be easy in all situations. Having seen how simple this service is to run, it should be possible to run your own and even multiple of them, either distributed among friends or among locations of your organisation. Spreading control is the trick, so that instances cannot fail together due to the same reason. Variation is key.

There are bound to be ideologically pure providers. The trick is then to find the ones that share your ideology.

Identity 13: Be Your Own IDentity Provider

2020-03-18T06:03:18+01:00

The idea of BYOID is that you can use your own domain's user@domain.name identity, along with a plethora of forms to login to foreign servers. This means that you need protocols to help you, for which we have two forms in the making:

KXOVER can serve organisations already using Kerberos today. We expect users of the InternetWide Architecture to migrate to this technology because of its single-signon properties;
SXOVER, described below, is easier-to-get-going, because it uses SASL that can be as clever as Kerberos with KXOVER but also as dumb as password authentication (until your admin understands why he should disable that). SASL with SXOVER is a perfect transition technology.

We shall now explain what SXOVER is about. If the technical details are overwhelming, be sure to skip ahead to the short final section for a smashing conclusion.

Your own Identity Provider (IdP)

To be able to make statements about identity, you need to run an identity provider of some kind, and let foreign servers find it to authenticate you. Some magic with TLS, DNSSEC and DANE would help those foreign servers to trust the statement of the domain (or "secure realm") as the owner of user names under the realm. In specifications, it is common to use ASCII art to draw that:

   +--------+    SASL     +--------+    SASL    +---------+
   | Client |-----------> | Server | ---------> |  Realm  |
   +--------+  AppProto   +--------+  Diameter  +---------+
       ||                     ||                    ||
john@example.com        find SRV, TLSA          example.com
  & credential            relay SASL           authentication

The path between the client and (foreign) server runs over SASL in any application protocol, for example HTTP, and the backend simply relays the SASL communication to the identity provider for the client's own realm.

There are several similar designs, but these are typically web-specific, and may require manual intervention and/or constrain the client's choices. The design proposed above embraces virtually all protocols; this happens to include the popular web protocol, but not exclusively. It is difficult to expand a web-specific design to include other protocols, but it tends to be easy to add web-specific frails to a system that is designed to be generic.

Diameter to carry SASL

Diameter is the sequel to RADIUS, a very old protocol that was invented in the times of dial-in modems that ran PPP and had to check username/password combinations. Using RADIUS, that question was transported from the modem pool to an identity provider that would check the password and either send back success or failure to the modem pool, which then allowed client access or withhold it.

RADIUS was designed to run on a confined, internal network where nothing bad was happening. It has since been patched to run over TLS, but in a way that scales poorly, and certainly is no good basis for trust. Diameter on the other hand, is a re-design that can hold up in the questionable context of the Internet and, when combined with DNSSEC and DANE, can provide strong guarantees about a remote peer being authoritative for a domain. Furthermore, connections are pooled and can easily be setup or torn down, it runs over SCTP to avoid technicalities about request ordering and it is designed for applications of authentication (proof of identity) and authorisation (access control).

SASL is used in many-many-many protocols for the authentication part, and we have our efficient ACL technology even including group facilitation for authorisation immediately afterwards, so SASL over Diameter sounds like a useful idea.

Diameter however, has no profile for carrying SASL. So that's what we are adding now. The protocol is easily flexible enough to carry it, nobody just thought of its usefulness! But with it, you could have a foreign server (like a web server) that is blissfully unaware of any client identities but knows where to turn to have them checked. It simply turns to your domain's Diameter server and relays any SASL inquiries that it gets. Cracking the web server won't reveal any credentials of such clients!

Diameter/SASL flow for Anonymous Access

The information in Diameter is packaged into attributes, formally known as AVPs. These have a name and intended use; we are merely adding a few for use with SASL.

Let's start simple, and assume the foreign server has no clue about the presence of SASL. It might send a Diameter message with the command AA-Request, which means that it wants to do authentication and authorisation. The server would send a response command AA-Answer, holding in it a challenge with the following attribute:

SASL-Mechanism set to the string ANONYMOUS SCRAM-SHA-256
No State has been builtup

This is an invitation to use one of the named SASL mechanisms. The mentioned State attribute is used to avoid the need to store any state in a Diameter server, so it is passed back and must be repeated in the following request. This is not yet done here.

The client now chooses a mechanism and starts it with:

SASL-Mechanism set to ANONYMOUS
According to the ANONYMOUS spec, the client may include a "trace identity" for debugging purposes; this would go in a SASL-Token attribute.
No State needs to be passed

If the server accepts this, it will respond with an AA-Answer command indicating success.

This being the ANONYMOUS mechanism, it does not actually authenticatate a user, but it may be used to (explicitly) grant guest access. An added use is that the AA-Request and AA-Answer may carry access control information, detailing what access rights are provided. Any rights would be minimal for ANONYMOUS but should allow more after serious authentication.

Diameter/SASL in a Complete Example

After this simple, but still somewhat useful example, let's now turn to a more realistic flow, using the SXOVER mechanism GS2-SXOVER-PLUS as defined below. We shall skip the first step which is not always necessary anyway.

The client initiates an AA-Request holding:

SASL-Mechanism set to GS2-SXOVER-PLUS
SASL-Token set to the initial message, which is named C2S-Init in the SXOVER spec
at least one SASL-Channel-Binding attribute (explained further below)
No State can be passed

The server sees no State, so this initiates a new exchange. Since there is no SASL-Mechanism, it knows it does not need to list possible mechanisms as described before.

The mechanisms that an identity provider supports may vary:

If it is used behind internal services like an IMAP mail server, it might welcome many SASL mechanisms, such as SCRAM-SHA-256 and GSSAPI.
If it relays ACL information, it may be useful to have an ANONYMOUS option sharing that.
In support of Realm Crossover with SASL, it must support GS2-SXOVER-PLUS and it may also support GS2-KRB5-PLUS.

We will assume that the SASL mechanism GS2-SXOVER-PLUS is supported, as our identity provider intends to support realm crossover. So, the server now starts the corresponding SASL mechanism and passes it the SASL-Token attribute value (if one was given, otherwise it passes no token).

Now it starts to loop around...

The SASL mechanism responds with either accept or reject, or the need to continue. Furthermore, it may yield a token. After making the step, the SASL state would be exported. Now, the Diameter server constructs an AA-Answer response:

If SASL decided to reject or accept, this will be reflected in the response; if it decided to continue, this will lead to a challenge response.
If SASL provided a token, then a SASL-Token attribute is filled with its value; note that it is possible to receive no token, which means that this attribute is not sent.
If SASL made a decision, the server may include extra attributes, such as the User-Name that was authenticated (the part before the @domain.name).
If SASL made no decision, its exportes state is signed/encrypted and stored in a State attribute. The client will be expected to return this in follow-up requests.

When the client receives this AA-Answer with a challenge and a State, it knows it should continue. It passes the SASL-Token into its local SASL client process and may harvest another token to send. This is then sent to the server in another AA-Request:

If a token was produced, it is stored in a SASL-Token attribute.
The State from the previous AA-Answer is cloned in this follow-up request.

The server sees a State attribute and knows it has to continue. After decryption and signature checking, it imports the state into SASL to reconstruct the server state and mechanism choice, and then it makes another step, passing it the value in the SASL-Token attribute if it is provided.

...and then it loops back!

At some point, the client receives an AA-Answer that either rejects or accepts the request. At this point, it can harvest any responses, which may include the User-Name attribute. The client, which may be in need of this value, appends @domain.name where the domain.name is the Diameter-verified realm of the Diameter server, and now has the full user@domain.name form that forms the client's globally unique BYOID form of identity.

Plus, while doing this, the client has used its own realm which enabled it to slip in an alias or pseudonym, which is best done when leaving the identity perimeter as is the job of the Diameter identity provider.

In all this, the server (which is stateless thanks to the State attribute) is really simple to define:

IF   have a State attribute
THEN process_next_sasl_step()
ELSE IF   have a SASL-Mechanism attribute
     THEN process_first_sasl_step()
     ELSE send_sasl_mechanism_list()

Security: Encryption

We mentioned that State attributes must be signed and encrypted. The reason for having this attribute is to offload state from the server, so it can be small and reactive. Clients will drop the state when they loose interest, but servers might not know and keep it around for far too long. Passing the State through the client who must send it back on the next round helps, but is also a security hazard. To avoid abuse by the client, this state is signed and encrypted.

Precautions against the client (and perhaps the foreign server acting on its interest) are not the only concern. SASL is not in general designed for this kind of passing through potentially hazardous foreign servers. It is designed for local use, directly between a client and its client realm. The foreign server should not be allowed to inspect the SASL traffic, which precisely what the purpose for GS2-SXOVER-PLUS is; it is an encrypted tunnel in which another SASL mechanism flows. As far as the foreign server is concerned, the only data in this stream is the realm, which it needs to find out the Diameter server to connect to and to learn the @domain.name part of the client identity. The rest is random bits that it simply passes back and forth.

The inner SASL mechanism can now be as stupid as a password authentication, as that will not be seen by to the foreign server. This means, among other things, that you can pick one strong password to use with all servers. For a password mechanis, that is not entirely bad. But SASL allows you to choose, and to migrate to better mechanisms such as Kerberos.

Security: Channel Binding

Not mentioned above, there is an attribute called SASL-Channel-Binding. This helps with yet another form of security, and it is obliged for all SASL mechanisms ending in -PLUS, including the one we described here.

It is really simple to take a SASL exchange from one protocol and forward it into another. The value of Diameter as a server for GS2-SXOVER-PLUS is that it will not offer any actual resource access, but merely decides between accept or reject. There is no value to be had from that.

Now imagine that we allowed GS2-SXOVER-PLUS to end in another server. Perhaps an IMAP server, or an LDAP server, both examples that may store information considered sensitive. Don't call us mad; similar things have happened. Doing this means that any foreign server might put on a nice face (or a sexy face, which is supposed to be the common lure) and pass the client's SASL tokens to this IMAP or LDAP backend server. The client enters its token, all the way until acceptance, and the foreign server either serves the client or falsely shows a rejection, while extracting all your sensitive data from the backend IMAP or LDAP server -- to which you just authenticated.

This nightmare scenario looks like this:

   +--------+    SASL     +--------+    SASL    +---------+    SASL    +---------+
   | Client |-----------> | Server | ---------> |Mail/Data| ---------> |  Realm  |
   +--------+  AppProto   +--------+ IMAP/LDAP  +---------+  Diameter  +---------+
       ||                     ||                    ||
john@example.com        find SRV, TLSA          example.com            example.com
  & credential            relay SASL           under attack           authentication

This is the big challenge of Realm Crossover; to balance the flexibility against stringent security. In this case, the solution is quite simple; the backend should verify that it is talking to a server seen by the client. This is established with channel binding.

Channel binding includes bits of the TLS session in which the SASL-enabled protocol runs, in such a way that it cannot possibly be forged. This would be the expected addition when passing SASL into Diameter, but no IMAP or LDAP server would expect or tolerate it. There is not even a mechanism in any mechanism but for Diameter to express this! So the scenario above is completely impossible.

Channel binding is cryptographically bound into the SASL mechanism used. Not every mechanism supports it, but GS2-SXOVER-PLUS does, and its end-to-end encrypting tunnel will fail to work without it. The server needs the channel binding information to be available, because it does not see the TLS connection between the client and foreign server, but it is not in the interest of the foreign server to lie -- nor could it, because the client will be certain to include the channel binding information and require its inclusion from the server as well.

Returning to Diameter, and its possible provisioning of ACL data, this too might be considered a valuable resource to try to tap. Attacks can easily be stopped however, by only returning ACL data to Diameter servers that have been listed as trustworty. It is completely useless passing ACL data to an audience that is not listening, so there will be an assumed relationship anyway. This is precisely what we are thinking of when we speak of plugin services as part of our next phase ServiceHub. To be continued!

And yet... it is Simple to Use

In spite of all this technical complexity, the interaction of SASL for access to a foreign server is straightforward; you cannot use all SASL mechanisms on any foreign server, but it should always be safe to use GS2-SXOVER-PLUS to login anywhere, so it can be a default/anywhere mechanism.

Reservoir: Your Data reaching out to You

2020-02-16T16:29:34+01:00

This is a story to explain the work that we are putting into ARPA2 Reservoir, a system for bulk data management that develops under the freedom-provoking mindset of the InternetWide Architecture.

Human Habits

On your computer, you have files that you can open in the right applications with some help of your operating system. You sort these files into folders, using a structure that makes sense to you. Unfortunately, the computer has more difficulty in making sense of these human habits, and you often end up wading through your folders, looking for that one file... you are so lacking in metadata that even a brute-force word search is helpful.

On the web, you can upload and download pictures and music and enjoy them within a browser environment. But not everything works as you like it to. Web environments were designed to access data resources, but they rarely do just that; they come with code that controls what you can do with the data, be it as JavaScript or in a mobile App. The general result of this is one-sided automation; it is completely automatic for the server side of things, but you may have to do a lot more manual work. You get to do it when you want, but that's about as far as client-friendliness goes.

Agile Automation

Reservoir can be used over a web interface, but it does not force you and offers additional channels to control your data to facilitate much better automation. These extra channels are based on standard protocols, and their more refined semantics make them more specific to an application, but also more informative to tools, and so friendlier to automation. The web is nice if you want to browse around; but it quickly grows into a nuisance if you have to.

A major part of data storage is its protection; not everyone should be able to access all data, but there is a lot of value in sharing, for instance within a group. Groups may include a set of collegues, a family or your choir. All this is expressed in our identity model.

Minimal Mechanics

At the mechanistic level, ARPA2 Reservoir is really simple. It orders data in three levels: (user at) domain, folder and perhaps a file. Or, as we call it: authority, collection and perhaps a resource,

//domain/collection/
//domain/collection/resource

This looks a bit like a web location, but it also looks like other locations. This is a bare form for URIs, the Internet's standard way of describing data/resources.

The domain is something like orvelte.nep to represent the data owner.
Collection is like a folder; it is a container for bits of data.
Resource is like a file; it is something you can upload or download.

The structure of this path is, along with any other URI, a gradual delegation of authority, or of the right to publish. The domain is the starting point of authority for Internet users, and is designed by a system that gradually delegates to the domain owner. The Collection than adds a delegation to a group of objects, and down to a specific Resource. Just like you should never look for your bank's name on a web search engine and click the first one to come along, you should not directly address a resource. Because yes, your bank would show up, but not, you are not certain that only your bank shows up in the search results; anyone could be found when they merely mention the bank's name!

Now, Collections and Resources look awful in this format, each being a UUID, so the form 15dbe45d-d636-41a9-94a5-0d16a8dbe09b -- they are not meant for human consumption. They are however useful: Long enough codes to avoid clashes and the form is nice and consistent, ideal for use in computer programs. Simplicity is key in all this. They provide relatively short links, yet these would be unique, so the benefits outweigh the ugly form -- for technical uses.

Lovely Looks

As a user, you will want to access your resources differently. You may want to have folders for companies and people named after domain names and email addresses, for instance. And below that you may want to split things into projects, or into separate years. But the URI format of Reservoir does not support arbitrary names, or even just two layers of Collection above a Resource!

The trick is that a Collection doubles as an Index, holding named references to other Collections. So when you want to proceed to photo/holiday/2014 from some initial Collection, the name photo is looked up in the index of that initial Collection, which yields another Collection. In that, you look for holiday to find a third; and in that you lookup 2014 to find the Collection you were after.

You have now located the Collection of Resources that you were looking for. Depending on your tooling it may have replaced your path with the standard format above, but that would be useful to share with others, who you might not necessarily want to show your path, especially if you are about to revise its structure.

Hospitable Homes

What you don't have yet, is the initial Collection for your search. You could bookmark it, but a nice starting point would be very useful.

For this reason, a Home Index is assigned to every domain and to every domain user. So, if the authority section is orvelte.nep you will access the home index with shared resources for the village's domain; in general this form can also accept the form bakker@orvelte.nep to locate the home index for the bakker user at the orvelte.nep domain.

Others might use this too; they might send information to an address like this, using a protocol like AMQP or, for small things like photos, email attachments. You would still receive the textual part of an email, but attachments might be stripped off and uploaded to the ARPA2 Reservoir for better integration with your browser. The email would replace the attachment with a link to the web location.

Apprehensive Applications

Useful as it may be to have a Home Index, it gets cluttered if all kinds of information are piled up in it. You probably want to keep your music and photos separate "views" on your data, and although it is important that a backup tool uploads their regular batches you are less likely to want to see it between your letters.

This is where an apphint, short for application hint, comes into play. Various types of application can use this to indicate a preference for a separate storage area. There are plenty of general-purpose names to use: music, photo, movie, book, article, contact, agenda, shopping, backup, ...

Such an apphint is sent by applications when they access your Home Index. Thans lands them another Collection that the default/unnnamed one. You can link in this other one as part of your Home Index, or anywhere underneath, or only use it over tools.

Note how it is meaningful to have apphint words for kinds of data, rather than for applications per se. There is no reason why multiple applications could not access the same music set, if they address different sides to it -- playing, tagging, musical analysis, track editing, and so on.

Luring Links

Thanks to the apphint mechanism, it is possible to create interfaces that focus on a part of your data. Access control may limit access to the data so these interfaces do not gain access to anything else; they simply get their own private view on your online presence and need not have any relation with what others see or what you do.

Given that services are available to you, how do you know where they are? The trick is to define those links clearly. We do this for a given domain authority, like orvelte.nep, with links in their top descriptive node. This covers just the //authority part, not /collection/ and certainly not /collection/resource, so the definition is for all to enjoy.

A good example might be https://music.orvelte.nep/superblast/player?apphint=music which would be a basic link to address a music server. If so desired, the /collection/ or /collection/resource could be added (in this URI it would go before the ? for technical reasons) and the server, recognising the host name music.orvelte.nep, would know to address the Reservoir for orvelte.nep and its local setup makes it recognise any added Collection and Resource references.

In this example, the ?apphint=music is likely interpreted by this service to mean that this application references your collection with the apphint set to music -- but that is something considered while this link was being added, and not a concern to its users because it is merely a suggestive local convention of the service. For using it, just reproduce and optionally insert a targeted Collection and perhaps a Resource and open it in any suitable application -- click and go!

Smart Security

Although Reservoir is about sharing data, it is also recultant to do this to anyone. Collections have an Access Control List defined on them, so only designated parties may access the data. This may include you, a group you are a member of, your friends or customers in other domains, and even applications that send an apphint that was setup for them.

Users who first start using an apphint will silently clone the access control setup from their domain, which presumably was put in place by their administrator. This ensures that the apphint mechanism automatically restricts access to the intended service.

Individual Resources do not have their own access rights; that would be confusing to most of us, and tedious to the rest. The concept is really simple, that you can create a separate Collection to group different access patterns.

Since access is determined for the //domain/colluuid/ prefix form alone, the path that leads to it is not shared as part of the canonical URI, nor is the user name. This is helpful by not providing information that is not strictly required. Imagine Reservoir as a mechanism for exchanging sales information; the other party does not see your username, and so cannot bother you over email.

Magical Metadata

All this, and we did not even explain the vital improvement of metadata. The data itself is boring to store on any disk, but metadata describing it can be very useful in many applications, for instance to present titles, sort out older information, add a lock item if someone has placed it under one, and so on.

Metadata is stored in LDAP, a directory that can be queried through a standard algorithm. If you want manual labour, you can stick to HTTP, which we happily supply with a wrapper for metadata. But if you want true automation, where you can run an agent to do things for you, you should use LDAP instead. It assigns so much more meaning to the literal bytes exchanged that it can be automatically processed with a rather deep understanding of what the various words and fields mean; no need for a user's gazing eyeballs and manual mousing.

You no longer have to plough through your files and open any that looks like it might be the one you misplaced. Instead, you can search for titles, descriptions, references, cross-links with other documents, document identifiers and so on.

Pungent Protocols

HTTP and LDAP need not be the only protocols involved in ARPA2 Reservoir, and indeed they are not.

Attachments may be uploaded over LMTP, for instance. And between domains operated by different parties, we use AMQP 1.0, which is ultimately suited for distributing automation-friendly formats. It is a bit like email, except that it bypasses the human eyeballs and instead is subjected to access control, possibly to spam/virus scanning and then on to automated processing.

And there might be possible uses for XMPP chat, SIP telephony, BEEP peering, SFTP for file transfers, RMT for remote "tape" backups, and so on. There are so many protocols that can serve you and make your life more automated than mere HTTP that it could leave you dizzy. ARPA2 Reservoir is such a different approach to data storage that it can make them all flourish.

You should expect protocol-specific URIs to look similar to the //authority/collection/resource format, and possibly support the human-friendly paths to get to data as well. The format is like a URI for good reason; often, you only need to stick a protocol and a colon in front.

The idea is that all protocols are named in the home index for the domain. A few notes about that:

Links with descriptions (URI-space-text format) are used to present to used; the addition of /collection/ or /collection/resource can be easily automated.
Links without descriptions (URI only) are used for automation purposes. In those, the scheme (such as https: or ldap:) will be a useful selection criterium.

Protocols may also be mentioned in DNS, using SRV records. This has not yet materialised.

Ushering Users

Most of these wonderful protocols have a notion of users, but not all of them do. For HTTP, there is no standard manner of identifying users. We specified a User header to do just that. This is not related to authentication, as that is about client-side users; it is an indication of the user we want to reach on the server, so in this case, the home index of the Reservoir.

Not all tools support this User extension to HTTP yet. Until they do, you can work around it by using the ugly alternative format that represents the user's UUID in a longer string. Did we already mention that HTTP is not optimal in saving you work? Or, your administrator may setup links to your Collection in the home index for the domain, and you need to click once more than under better circumstances (because this is one of those non-standard things that require your eyeballs and manual intervention).

Similar things apply to the Collection and Resource values; protocols that cannot express the hierarchy of Reservoir would be receiving additional headers. Think of SMTP and SIP as examples of this; both have a URI format that can easily be extended with headers. We have not tried to define those yet.

It's All about Protocols!

2019-11-26T00:00:00+01:00

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.

ARPA2 All Hands June 2019 talks

2019-08-01T00:00:00+02:00

On 25 June 2019 we had another great 'All Hands' meeting of the ARPA2 project. Again with SURFnet as wonderful host, providing us with a nice conference room and good coffee.

This was the agenda of the day, with links to slides where available:

Thanks to the national research and educational network SURFnet for kindly providing the venue for this event, and to NLnet and the National Cyber Security Center for their continued support to the ARPA2-project.

Why TLS 1.3 is NOT born dead

2019-07-14T00:00:00+02:00

We are facing a grim future. In a few years, the now-active development of Quantum Computers will break our backs and bones and this is why the ARPA2 project has a road map for getting over Quantum Computers which, incidentally, assumes the TLS will solve this problem in an integral manner for the entire Internet.

Pros and Cons of TLS 1.3

TLS 1.3 is a great improvement over TLS 1.2 in most other regions. As TLS 1.2 grew, many pathways were added that complicate the design of implementations. Some code portions are then barely tested, and unprecedented combinations of such code portions have no purpose in proper use cases, but may still help to abuse the protocol. The redesign of TLS 1.3 solves many such problems by being much more simple. This is an incredible benefit to the security world.

TLS 1.3 does not prevent attacks by Quantum Computers. In fact, it might be said that it plays Quantum Computers in the hands by always using ECDH key establishment and using mechanisms to sign for the keys. Note that this is also the advised use for TLS 1.2, so it merely establishes a commonly advised practice. The problem however, is that it is now enforced, even though ECDH is known crackable with Quantum Computers.

One might say that a new TLS 1.4 is needed to avoid that, and that TLS 1.3 is born dead. The trick however, is that so-called cipher suites can be added to to protect from Quantum Computers. We developed such a cipher suite for TLS 1.2 and TLS 1.3, so that no upgrade to TLS 1.4 is needed. There is no Quantum Proof replacement for ECDH yet. As soon as one is found and established as secure, there is a very good reason for TLS 1.4, but not until that. Until then ECDH is very useful, we should just use it well.

Explaining ECDH

Let's say we can multiply by 3, but we have no way of reversing that. That is not really true of course, but it is a simple model of the kind of things that more complex cryptographic algorithms do; they work one way but have no reverse. The danger of Quantum Computers is that they break assumptions about the operation of computers, and this means that the reverse operations (division by 3 in our model) are available to those who have such a device.

This is how ECDH works:

The client and server picks long random numbers, let's call them C and S respectively.
They each make the irreversible multiplication by 3. They keep hold of the original random number, but consider it secret.
They pass the multiplication result to the other, so the client and server receive 3*S en 3*C, respectively.
Each now combines the received value with the secret random number. The client finds C*(3*S) and the server finds S*(3*C). When the actual operation, which is not multiplication, has the properties of changing the order and brackets (commutativity and associativity), then both are equal to 3*C*S. In short, they have the same value. A master key can be derived for that, and can be used in TLS.
The trick of ECDH lies in the fact that the end points are ahead of the game, knowing information with one less multiplication-by-3. Adversaries that observe the traffic see 3*C and 3*S and end up with 3*3*C*S which has one irreversible multiplication by 3 more than is needed to construct the master key.
Note that TLS does more than this; most importantly, it authenticates the key exchange to thwart man-in-the-middle attacks. It also explains how to continue with the master key, and protect further traffic so it is private and authentic.

A very important feature of this setup is that it uses fresh random data on every new connection. As a result, if someone were to crack one TLS connection it would not be able to crack another. Another valuable asset is that the party providing the credentials for authentication of parties cannot decrypt the value 3*C*S if it sees the flow of traffic.

Using ECDH Safely

The "only" problem left in ECDH is the Quantum Computer. They will be able to crack and infer 3*C*S from 3*3*C*S. And this is a big problem, because TLS connections may be stored today with the intention of deciphering them in the future. Your credit card numbers and passwords that were assumed to be safe under the cloak of TLS suddenly lay barren to the eyes of those with the funds to own a Quantum Computer. This is not only an assault to the privacy of individual users, but it also creates immense inequality.

The trick, then, is to incorporate further secret information that cannot be known to such forceful parties. This is difficult in itself, because it needs to come from a source that is preferrably controlled by the end points in the game, not some central party that may be coerced into cooperation with those who own Quantum Computers.

The additional secret means that the client and server have a shared key K on top of their local secrets C and S. They send 3*C and 3*S and each can compute 3*C*S*K -- observers would still see 3*C and 3*S but they can reduce 3*3*C*S to 3*C*S because Quantum Computers would allow them the division by 3. They still have no access to K though, if it is passed in a manner out of reach of a Quantum Computer. (Note that an alternative scheme might pass 3*C*K and 3*S*K over the wire, and the adversary would have 3*3*C*S*K*K and, not knowing K, they should not be able to divide it out of 3*C*S*K*K either. It is questionable if this is in any way better though.)

Certificates are no help when it comes to this, as all current-day public-key crypto is bound to fail. Thankfully, some solutions exist there too. But for now, all we have is symmetric crypto, which is considered safe from Quantum Computers. And if you need an infrastructure for symmetric crypto then there is one obvious source: Kerberos.

Kerberos is very old and yet, has withstood the pressure of time. It has its problems, but none as devastating as the threat of Quantum Computers. Very useful is that it logs on to all systems, both web and non-web, with a single login each day. It has a place in virtually all the protocols, it is flexible and very easy to use. In fact, single-signon systems are constantly being proposed for the web (which in itself means it is not at all single-signon; there is more to the Internet than just the web and some are more user-friendly than you might think).

Enter TLS-KDH

Our integration of Kerberos with TLS is general in nature, and happens to also solve another problem, namely the lukewarm security of Kerberos for HTTP. The TLS-KDH cipher suite uses Kerberos for authentication of the ECDH exchange, and it uses ECDH for key agreement. By incorporating a session key from Kerberos as K in the ECDH exchange, we establish a stronger security level, namely one in which the Kerberos administrator must be part of the game of cracking the security of the connection with a Quantum Computer. And the Kerberos administrator is usually local and trusted to protect the interest of the domain it identifies.

The protection starts as soon as TLS-KDH is introduced. It does require the authentication of a client, but there are forms of anonymous identity in Kerberos, and at least the form that releases the domain but not the user identity is implemented.

There are two forms of TLS-KDH:

KDH-only uses nothing but Kerberos credentials and ECDH to construct the master key for TLS. The server may provide no key, or it may allow user-to-user (or peer-to-peer) TLS connections if it passes an opaque handle to its own Kerberos session.
KDH-enhanced uses common certificates but the client continues the connection by providing Kerberos authentication. In this case, the certificate-based security is enhanced with K too, causing the same benefits as with KDH-only, just after starting the TLS connection in a more generally accepted manner. We believe this can be useful to offer a mixed service that allows both TLS-KDH and traditional session protection.

Where to get TLS-KDH

We are offering TLS-KDH in a number of manners:

We built it into GnuTLS. There it is one of the mechanisms available for TLS 1.2 as well as TLS 1.3. See the advise above about our strong recommendations to upgrade to TLS 1.3 and not consider it born dead. You may however want to trim the list of cipher suites if you are concerned about current-day tapping of TLS connections for upcoming-future cracks with Quantum Computers.
We are building it into mbedTLS.
We have incorporated GnuTLS with TLS-KDH into our TLS Pool product, and may in future releases add support for mbedTLS as an alternative TLS driver underlying the TLS Pool. The intent of the TLS Pool is to separate the concerns of TLS and keys from the applications, and offer it a simple API over which it only needs to be concerned with the identity of peers.

If you use and like these products, please support it in your applications and be loud about it. We should not panic about Quantum Computers, but we should realise their devastating impact on today's security and even its risk of creating inequality and, as with any other problem, solve it with better technology.

This is work from early phases of the InternetWide project. If you like where we are heading, then please read more about our work, and think about adopting that too. We are in the game for an Internet that is much more distributed, self-controlled and certainly more private and secure than what we have today.

ARPA2 All Hands - 25 June 2019

2019-06-25T00:00:00+02:00

The location is at walking distance from Utrecht Central Station. Do you want to attend? Please RSVP by sending an e-mail to allhands@arpa2.org. We will then send you the exact location.

We start at 10:00h and will finish around 16:00h, after which we will make sure there are some drinks and finger food to continue the discussion and brainstorming.

The programme is under development and we will leave room for some topics added on the spot (also by you!), but expect amongst others talks and discussions about:

Keyful Identity Protocol (KIP): a fundamentally new approach to encryption and signing of email and documents.
ARPA2 Shells: for connecting ARPA2 microservice components, which the potential to open up to the world for third party services as well.
Raspbian: building ARPA2 components for Raspbian is surprisingly easy, what are the implications relating to MDS Attacks and Zombie Load Attacks?
CI/CD: how can we benefit using CI/CD and how to set it up?
Docker and Kubernetes: how can we use these tools in our projects?
Windows: introduction to the portability checklist.

If you have an interest in the ARPA2 project, or one of the various subprojects, do consider attending!

We are looking for students and other young open source programmers. They can work on the ARPA2 Mail & Reservoir system, involving such things as identities for groups and roles, aliases and pseudonyms.

Participants will get an overall introduction to the architecture and thinking behind ARPA2 and an update on the status of the various sub projects. Importantly (and the main reason for an all-hands) you will meet the other people that are active elsewhere in the project, and brainstorm about the future direction of the project.

Limited space available! We only room for 6 more attendees, so be quick!

RSVP: Send an e-mail to allhands@arpa2.org if you want to attend. We will then add you to the list of attendees and send you the exact location (address).

If you have any questions, don't hesitate to contact me as well.

ARPA2 All Hands March 2019 talks

2019-03-28T00:00:00+01:00

The first ARPA2 All Hands meeting took place on December 9^th 2015 in Utrecht.

On 12 March 2019 we had another great 'All Hands' meeting of the ARPA2 project. Again with SURFnet as wonderful host, providing us with a nice conference room and good coffee.

This was the agenda that evolved during the day:

10:00-10:30	Arriving, settling down, getting coffee
10:30-11:15	Keyful Identity Protocol (KIP) (Rick van Rein)
11:15-12:00	Docker, Kubernetes and CI/CD (Tom Vrancken)
12:00-12:15	Optimization vs. Memory Zeroing (Tim Kuijsten)
12:15-12:30	Who is working on what?
12:30-13:30	"Broodje Mario" lunch
13:30-14:00	ARPA2 Shells (Rick van Rein)
14:00-14:30	Building for Raspbian (Henri Manson)
14:30-15:00	Portability Checklist (Henri Manson)
15:00-15:15	Code Indentation (Tom Vrancken)
15:15-15:30	Rounding up: next appointments
15:30-16:00	Dialogue about "How to better collaborate?"
16:00-17:00	Drinks!

Getting over Quantum Computers

2019-02-11T00:00:00+01:00

To quickly recap the threats that Quantum Computing imposes:

Secure authentication may be impossible in 10 years;
Digital signatures on digital content may not be trustworthy in 10 years;
Things we encrypt today may be decrypted in 10 years from now.

The reason we say “may” is just because it may take 15 years instead of 10 before Quantum Computers hit us; but the funding is there, and it is no longer fundamental research but rather in a phase of technology being refined.

Take special note of the third point; this impacts our current and past actions and indicates that we should get moving as soon as possible, not in 10 years from now.

One major concern that hits everyone, if we look at today's practices, is that any password and any credit card number that we send to a "secure" web server will become readable under the regime of quantum computers. Both practices, the "authorisation to enter" and the "license to withdraw" are cryptographically poor, as they are founded on fixed "secret" words, and their technology has expired; they may still be practical in serving the masses, but they are lingering traces of a naive past and need to be replaced.

What Crypto Algorithms are hurting?

Most cryptographic algorithms that we use all the time will be carried to the cryptographic graveyard: RSA, DSA, Diffie-Hellman. Not just the modular-exponentiation forms, but also the elliptic-curve varieties. Algorithms have been devised that can crack the fundamental assumption underlying these algorithms given a quantum computer to run it on.

The algorithms are not poorly designed; they have just been designed for the “normal” approach to computing. Quantum Computers change the game completely, by effortlessly performing a very large number of computations at the same time, weeding out impossible solutions as they go. This is not unlike a string on a guitar, which produces the most idiotic vibrations when it is plucked, but quickly stabilises on just those wavelengths that fit in the string.

What Crypto Algorithms will replace them?

There are several other algorithms that would resist quantum computers. They are less efficient than the popular ones, however. Or they lack properties that we desire.

For one, message digests and symmetric encryption are thought to remain being secure. They use the same key on both ends, however, so they lack the property of public-key crypto, where anyone can learn about a public key and only one person has access to the opposite private key. Perfect algorithms where they can be used, but use-cases that cross over realm boundaries (such as opening a secure website) is not covered yet.

Secondly, there are (sometimes very old) algorithms such as those based on lattices or other primitives but not modular exponentiation. These sometimes require long keys, long message formats or they are founded on state being stored, which has made them less popular than the algorithms now under attack. But these are at least public-key algorithms.

Intermediate forms also exist; public-key signatures based on hashes, for instance. Some of these can be small, but they may need a storage space to keep revolving the keys. That can be unpractical, for instance when the key is used in different locations.

What we have not seen yet, is a Quantum Computer proof replacement for Diffie-Hellman or its Elliptic-Curve counterpart. These algorithms are important in current-day cryptography because they let us have Perfect Forward Secrecy, a property that isolates the keys used in different sessions.

Work is being done in cryptographic circles and standards bodies to select algorithms that should replace the old ones. These bodies are well aware of the danger to current-day encryption.

TLS to Encrypt the Internet

Most protocols use TLS as their basic encryption mechanism. It is safe to assume that this protocol will be among the first to be updated. This protocol secures websites, email and many other protocols, so at least the basic use cases will be remedied at some point.

As indicated, the most pressing concern is encryption. This may not be clear to all service providers, making some wait with upgrades until Quantum Computers arrive. These providers will be too late, and you are warned to leave them to the benefit of those that do upgrade quickly. Such transitions may be forced somewhat with upgrades in client software that invalidate such running-behind services.

SASL for Authentication

Authentication is a second-level concern, but it is still a concern. Most protocols use SASL authentication which, if implemented well, is a pluggable interface to a plethora of authentication options. Most SASL mechanisms are hash-based, including the strongest ones today (the SCRAM-*-PLUS mechanisms).

Hopeless HTTP

The web is the only protocol who thinks they are too clever to be standardised. What makes it simple to develop on, namely its lack of semantics, is also what makes it difficult to do well. That is, if the web is to remain open.

The lack of semantics has led to a trend of vendors providing both client and server side of the connection, also known as “complete control” and generally not in the user’s interest. Think of “download our App now” for mobile platforms and “use our online application” for desktop usage. In general, it is a lock-in paradigm. Nice for providers, not so nice for users with the exception of superficial aspects such as ease-of-use.

Unfortunately, these lock-in paradigms are the only ones capable of change these days. There is absolutely no tendency in the web world to migrate towards an integral solution for proper authentication or other form of security. Running over TLS does some good, but certaintly not enough. Passwords embedded into websites have always been a bad idea, and they will probably be among the first aspects being cracked.

The web has us worried. It may die under Quantum Computers.

InternetWide Vision on Kerberos

We use Kerberos as the foundation for our security. This is for various reasons.

Kerberos is well-integrated and easy to use. Once a day, each user logs on and for the remainder of the day they can access anything that they are eligable for. The user will not notice Kerberos during his day of work.
Kerberos is secure from Quantum Computers, simply as a result of its choice of algorithms, which are symmetric.
Kerberos is very efficient. Not just because symmetric algorithms are much faster than public-key credentials, but also because there are caches at clever places, allowing the reuse of gained credentials for the duration of a (day-long) session.
We have found mechanisms that enable the use of Kerberos across realms, even to a level that can connect the Internet as a whole. There is sufficient room for pseudonymity in our identity model that can be mapped onto Kerberos as well, so as to control one’s privacy when hitting upon remote services.

InternetWide Vision on TLS

We believe TLS should be as light as can be, so it is easy to use everywhere. Security is great when it is automatic and unnoticed. Our strategy towards TLS comes in a few choices:

We prefer to isolate TLS aspects in a daemon that is isolated from the actual clients or services using them. This is what inspired us to develop a TLS Pool that can be updated without turning to a plethora of applications.
We prefer to fill a TLS Pool from a cenral infrastructure, that can be upgraded to new crypto algorithms with on quick swoop. This is our IdentityHub approach.
We aim to add options to support Quantum Computing in the TLS Pool, and aim to switch the defaults from off to on as soon as this is possible with existing software. We defined three levels at which this could be done (authentication, encryption, handshake privacy) to allow us to do this with maximum control, rather than all at once. We shall add options to the validation expressions to allow more dynamic checks of this nature on a TLS connection that has already been setup, so administrators can exercise fine-grained control over their peers.
We prefer to provide any keys to users from a managed/central location. This underpins our Remote PKCS #11 mechanism, with a key repository hosted under personal control.
We have developed a cipher suite for TLS that caught us by surprise as being protected from Quantum Computers! The reason is that we integrate Diffie-Hellman with Kerberos, and we hash the session key from the Kerberos ticket into the key agreement with Diffie-Hellman.
We are working on a mechanism named KXOVER that allows Kerberos tickets to be agreed between independent realms. As recently decided upon, this will run over TLS and thus depend on to-be-selected Post Quantum algorithms. These algorithms can demand very large messages, as far as we are concerned; the exchanges are going to be rare and will only take places once in a number of weeks for a pair of realms that wish to be connected. Individual client-to-service connections will benefit from the much higher speeds of Kerberos exchanges, when they pass through TLS-KDH. Crypto does not have to hurt!

InternetWide Vision on SASL

We think of SASL as a vital mechanism for today’s authentication. It is virtually everywhere, and can be easily expanded.

SASL should be used whenever possible. One way we like it is with GSS-API running Kerberos, so as a mechanism to integrate with our security foundation of Kerberos. Alternatively, SASL EXTERNAL can be used to look at the protocol context, which usually means TLS. A client certificate (possibly from a managed repository over Remote PKCS #11) or Kerberos ticket (passed over TLS-KDH with or without psuedonymity) can be used quickly at this point.
Modern SASL mechanisms allow an authenticated user to step down to an authorisation identity. That is, instead of using your full name you might use an alias or a role, or perhaps talk on behalf of a group. This can help with privacy, especially when users can see each other’s identity. Pseudonymity shines here; users are identified but not necessarily by their primary (login) identity and not necessarily related to a communication identity or other identities that they may be using.
We believe HTTP should adopt SASL. It has been accepting individual mechanisms, but this is not helpful because it is not reaching the right people. Authentication of HTTP applications should move out of applications and into the HTTP layer. We also believe that channel binding, that is linking the surrounding TLS connection in with the authentication, should at least be available as an option.
We believe that SASL can arrive on a remote service and be passed back to a home realm for validation. All the remote service would need to know is that it is indeed talking to the home realm (a domain name, basically) and that this agrees to an acclaimed user identity. This requires specifying a domain name, which is easiest when using email-style user names like bakker@orvelte.nep that spell out the domain that should validate the user. This is not trivial, but it is expected to be possible and useful. Most importantly, it turns SASL into a realm-crossover technology for BYOID.
We believe it may be helpful to have mechanisms that can pass safely through an intermediate service, through the Diameter relay system. SASL was not designed for this, so either encryption should be added, or one of the few systems that can safely pass through an intermediate should be used. At present, only GSS-API comes to mind, as well as SRP which is expected to fail under quantum computing. The addition of public-key crypto which is resilient to quantum computers may be a helpful extension to the SASL portfolio of algorithms.

InternetWide Vision on Document and Email Security

Not everybody uses digital signatures on their email, or encryption to conceal the content from others than the intended recipient. These usage patterns do serve important uses to some, however, and they are an intrinsic part of the liberal openness of the free Internet. (Some might say that the technology could be abused, but for those of bad intention this is probably more than they need; there are plenty of clever tricks that can easily conceal online behaviour, with or without cryptography.)

The technology for securing documents and emails comes in two variants: The X.509 public-key system and OpenPGP. The former tends to be part of government attempts to provide civilians with certificates, the latter is what is actually being used by people involved in security and privacy. Both of these technologies can be modified with "plugin" algorithms that would be protected from Quantum Computing. It is reasonable to expect these mechanisms to develop in that direction.

The InternetWide Architecture uses open technology precisely because it has this healthy tendency to develop. We do not believe we can outsmart these algorithms, and will simply abide our time, and integrate them soon after they arrive.

This technology is more in demand than people realise. It is common for identities to be stolen; especially monetary institutions and governments are under constant attack. Consumer programs make it a habit of telling people what hints may indicate possible intrusions, but this always comes after the fact, because intruders develop to overcome such "challenges". The one challenge they could not overcome is to send email that can be authenticated as coming from the claimed sender; that is, by using a signature with a key that the consumer can trace back to the expected sender. As soon as the online behaviour of banks and governments signs their email, consumers can finally start validating their email and the assaults should stop instantly. Signatures with old algorithms can be relied upon until the first realistic Quantum Computers arrive, so their future announcement is no excuse to defer this introduction of digital professionality.

Building This Vision

This set of measures ought to get our projects beyond the problems that we need to face due to the rise of Quantum Computers. With the given adoptions these would offer generic support. This is why we embrace open protocols and open frameworks, instead of inventing it to shield off our own niche; we would not want to have to defend something with the vague "we know what we are doing" or "you can trust us" references that invariably follow from closed solutions that proclaim to be secure.

Our project currently focusses mostly on the protocols and identity systems. For those, we are building the vision above as we speak. We have a small team, but are always interested in hearing from you if you would like to connect your software to our setup. Talk to us if you want to know if and how this would be possible!

KXOVER, the design of a protocol

2019-02-07T00:00:00+01:00

Although we are supportive of everyday protocols, the basis of our security is Kerberos. We have good reasons for that:

Highly suitable for central identiy management
Single sign-on makes proper security simple for its users
Integrated in much modern software, directly or via SASL
Extremely efficient integration with TLS possible

Users under a Kerberos realm need to login once a day, and after this security is not even noticed. It works for all applications using all protocols, and tickets for use of services are quietly arranged when needed, based on the daily login. This kind of system makes it doable to have one very difficult password for all work done. What we plan to do with KXOVER is to make this mechanism usable across the entire Internet.

Kerberos is normally used within an enclosed security realm. All users and all machines are assumed to exist in that same realm. This alone would make it unfit for use on the Internet at large, but there are a few extensions that can help a client in one realm to use services in another.

Kerberos can link independently managed realms (for instance, in the commercial product Active Directory this forms a forest) but it is currently based on manual agreement of keys between operators. To simplify matters, it is possible to link through intermediate realms, but these would then be able to decode and intervene in all Kerberos traffic.

This is not secure as a mechanism for the Internet, where middle men are unknown and so they cannot always be trusted. Even more importantly, what is still missing is a mechanism for impromptu crossover between realms, namely when a client in one realm wants to contact a server anywhere on the Internet.

We believe that the linkage between realms can be made automatically without endangering security. What we need is a facility for public key crypto, and validation of keys from hitherto unknown realms, which is precisely what DANE can do.

First stab: PKINIT

There is a mechanism for public-key crypto already embedded in Kerberos, and it is called PKINIT. It is also known as Smart Card Login on Windows systems. The smart card on one and, and the Active Directory server on the other, engage in a public-key based exchange during which they establish a secret for the duration of a Kerberos session, which usually grants access to services for one day.

PKINIT cannot be used literally as a KXOVER protocol. For one, we had to be more stringent because the original definition is too loose to be completely secure and sufficiently modern. But we also needed a few changes that would be incompatible.

Second attempt: KX-OFFER with Tailored Crypto

We therefore designed our own Kerberos messages, clearly distinguishable from any existing ones, and used those to send a KX-OFFER (Kerberos Crossover Offer) from the client's realm controller to the service's, and another KX-OFFER is sent back. The composition of the two KX-OFFER messages allows the derivation of a shared key that can be used as the basis for the crossover. Again, DANE is used to confirm the certificate used by a remote realm, even if it is formally not described for our protocol.

Clients do not need any changes. There is a widely implemented form for server referrals that hints the client to switch to another realm, and contact its realm controller for a service that could not be resolved in the client's own realm. Only the realm controller needs to be updated, which is a great advantage to the KX-OFFER mechanism.

Third charm: KX-OFFER over TLS

We ended up designing the cryptography for KX-OFFER, and were deeply involved in the precise structures when we analysed that TLS-KDH is a Post Quantum mechanism and KXOVER is not. The move to a Post Quantum mechanism is still difficult, and not just a matter of changing an algorithm; not all structures will move over; specifically Diffie-Hellman style key agreement may be different, if it exists at all. Were we going to preview all that in our design?

This was when we started looking into TLS, even if it may be quite a pull on resources, as a basic layer over which to exchange the two KX-OFFER messages, but without the tailor-made cryptographic facilities. TLS will be maintained and will certainly be updated with Post Quantum technology at some point.

As it turns out, a little-used specification exists for Kerberos over TLS which requests STARTTLS through a TCP extension mechanism. It may be designed for reasons for privacy, but can be used as a protected mechanism between realms too. What's more, a standardised label in DNS can be used to inquire if TLS is an option at all for a realm.

The idea of running simpler KX-OFFER messages over a TLS connection between realms clearly integrates quite naturally with existing standards, which is always a good sign. Also useful is that DANE is formally defined for TLS, and our previous attempts sort-of freely used it for other uses.

Our realms will now setup a TLS connection initiated by the client realm, and both client and server will present a certificate. This is still close to the PKIX certificate with just two small changes:

The certificate's Subject field is now defined, and must hold a commonName set to the host name of the realm controller; this is commonly used in TLS solutions to validate a remote peer's name.
The Subject Alternative Name lists krbtgt/REALM@REALM identities. We shall insist on the name-type NT-SRV-INST and the actual occurrence of the realm that we expect to be our remote peer.

Interestingly, TLS solutions that integrate DANE can do a lot of the work of this new approach to KXOVER. All we need to add is securely link from the realm name to the server names of the realm controllers. We will indeed use our own TLS Pool to separate the realm's private key from the KXOVER code.

Finally, the reliance on TLS means that we need not be concerned about the key exchange to derive the shared key between the client and service realms anymore; there is a facility built into TLS that exports the same shared key material from a pseudo-random number generator seeded with the master secret and some other things that we include. The master secret is the pivot of TLS security, and any cipher suite worth its salt will fight for it to be highly unpredictable for outsiders — yet have the same value for the TLS endpoints.

Simplicity is almost always a sign of a good design :)

KXOVER as a Bump in the Wire

The new design can be used as a front-end to a realm controller. When TCP/TLS and UDP pass through it to the actual realm controller, an answer stating that a name was not found can be intervened on, by looking up a server host name's realm with a _kerberos TXT query and then performing realm crossover with the remote realm. Once a key is setup, it is stored in a database with crossover keys that the realm controller can use, and the request is again sent to the KDC.

The only behaviour required inside the KDC to make this work is that it can see that it should use a crossover key. One way is through the same _kerberos TXT queries to detect an unknown realm and to conclude that a crossover key from the client's realm to the service's should be looked up in a database written by the KXOVER service.

Again, simplicity is a good sign!

Conclusion

Protocol design is hard labour! It is often needed to tear up ideas that we defended with vigour in an earlier phase, and start from scratch. The iterations that this goes through tends to be useful, and it has brought us closer to the goal of KXOVER, which has always been the same:

Single sign-on with a local identity to the entire Internet.

This, we are making happen. And we are not cheating by making it web-only — we can simply step down from Kerberos to any web-only mechanism. And as with our TLS cipher suite, the work is extremely efficient, because an established crossover key between realms can be recycled at a very slow pace, but intermediately put to good use by all clients and services in the respective realms. The only (slow) public-key crypto involved would be for the crossover key, whereas the day-to-day uses by clients and services is founded on the (fast) key management mechanisms of Kerberos.

Backbone Innovations in the IdentityHub

2018-11-22T00:00:00+01:00

It is common these days to develop software in terms of microservices. These relatively small components have a well-defined task and communicate with other components over a queueing backbone.

The queues help to resolve downtime of independent components, and help with operational control and fast recovery of complex systems.

The separation of a complex system into well-defined tasks also helps to focus while developing one task, and to avoid entanglement of code.

A run through our Microservices

We are developing microservices for a number of tasks. Some of the development takes place in the form of Docker containers, so we make it easy for others to test out the ideas while they are still in progress.

IdentityHub is the central site for coordination of identities and their relationships, including the rights set in access control lists. Identities include domains and their users, for which we defined a variety of forms.
KeyMaster will be the place where we manage private keys and their use in services, as well as in user view.
Kerberos will be the place where Kerberos accounts are created, from which users obtain service tickets and that participates in realm crossover.
Global Directory will be a publicly searchable LDAP repository that allows searching for user keys by remote parties. It's standardised location under a domain gives that the desired authority and interoperability. By using LDAP, we can filter who may see what, in the interest of privacy. We aim to only show identities when they are explicitly requested.
DNS is the module that outputs host IP addresses, as well as keying material for such things as DANE or ACME.
Reservoir is a storage facility for documents. Their metadata ends up in LDAP and the actual data is stored in an object store. This integrates with the IdentityHub because it would be a core service when used to collect backups from various plugin services.

Let's take an example by looking at the IdentityHub. Internally, this can be operated by a shell, which may give a good idea of the things done. Here is a list of self-explanatory commands that one might enter into the IdentityHub:

Shell to the ARPA2 IdentityHub.  You can add, del, mov
identities for users, groups, roles and so on.
arpa2id> domain add orvelte.nep Orvelte, Incorporated
arpa2id> user add orvelte.nep bakker Hij die bakt
arpa2id> user add orvelte.nep smid Hij die hakt
arpa2id> user del orvelte.nep bakker
arpa2id> user del orvelte.nep smid
arpa2id> domain del orvelte.nep

Shells with JSON backdoors

Shell-based control is perfect for operators and other power users. It will always be useful to have this, even if just as a last resort. If we took a classic approach to system management, we would add an SSH connection to run these shells remotely, and end up fixing problems with quotes for a long while before our code became secure enough for automation.

Instead, we prefer to unleash these facilities over a queueing mechanism. To do this, we introduce a second interface to the existing shell interface, more in line with queueing and automation, namely a JSON interface. We can do this because the shell already interprets and validates data and assigns names for each part. By way of example, the syntax of the user statement is

arpa2id> ?user
user add <domain> <uid> <descr...> |
user del <domain> <uid>

The assignment of <domain>, <uid> and <descr> made here is useful for the implementation code, that can retrieve those fields at will. Other than that, the literal tokens user and add help to select the variation of the code to use. All this is incorporated into the shell parser. In fact, the names are not just assigned, but may even be subject to shell-specific checks.

The feature set of these shells is very useful, but the local formatting rules of shells are not perfect to glue microservices together. So what we added, strictly through generic code, is a JSON interface with the names defined in the syntax:

 {
   "do_":    [ "user", "add" ],
   "domain":   "orvelte.nep",
   "uid":      "bakker",
   "descr":    "Hij die bakt"
 }

As you can probably tell, this matches the second commmand line example given above. Each form has its own use; shells are useful for people when they come with command line completion and online help, and JSON is more suitable for automation, and also more common. And so we do both in our microservices.

Normally, JSON structures tend to be loosely structured, not to speak of the literal values passed in it. But the alignment with a validating shell is perfect: the shells can be quite restrictive in the JSON input that is deemed acceptable. And it will make sure that the request fields are completely "used up" while parsing the structure. This sort of thing is not noticeable during proper use, but it quickly gets in the way of abusive patterns.

End-to-end Security and Access Control

Most microservices are used internally, and a front-end is the only way to get in. The front-end handles encryption, authentication and access control (authorisation). We intend to open up our infrastructure to plugin services in the upcoming ServiceHub phase, so this model will not work for us.

What we end up doing could make sense in many more situations. We use end-to-end security for our backbone, and apply an efficient ACL mechanism at the serving side.

This means that access control is built right into the shells, and from there it automatically carries over to JSON. The interesting result is that we can accept shell commands from anyone, as long as they establish their identity and we will look it up using our efficient ACL mechanism.

Is this model too refined or too dynamic? Probably not. Instead of having to know what access to constrain in a front-end, we now put it right where the actions are about to launch, and this is going to be simpler in any case. There is bound to be a high degree of dynamicity, because every domain is going to have its own administrator. It can only be helpful to have the lookup of these rights related directly to the place where they are exercised.

End-to-end security means that a JSON fragment can be dropped on an AMQP endpoint, to have it routed to the responsible microservice, where it can decide on access control. Our microservice interconnect is open to InternetWide Access! Of course, there will be the usual concerns about attempts to overload these services, but it is quite normal to use SASL authentication before granting AMQP access; even if this is just coarse-grained authentication for an entire bulk provider, then this is still helpful to sort out any massive-sending abuse without needing to confine access to only a set of static IP addresses (which would disable roaming access by users).

The shells are not omnipotent, not even for root users. They will only grant actions according to access control lists; the same rules that apply to remote users also apply to local shell users. As a result, shell access can be open to anyone, and what each user can do is still controlled. No special user accounts are needed, so administration of the systems can be fairly relaxed and root access is only needed for hardware and software management, but not for configuration management.

The mechanism for end-to-end security cannot be TLS, of course. TLS only provides hop-to-hop protection. Instead, we use GSS-API for encryption and mutual authentication. Though mostly known as the way to embed Kerberos5, other GSS-API mechanisms exist. Specifically Kerberos is based on symmetric-key cryptography, making the mechanism highly efficient and yet it protects from attacks with Quantum Computers — we have got your backs covered!

Is this difficult? Not at all. To the microservice programmer, GSS-API is a function through which a network packet passes to add protection, and another on the other end to verify and remove the protection. Or more likely, it is part of the backbone communication library. To the operator, GSS-API is even simpler, because it is baked right into SSH as an authentication mechanism. Just connect to the right server, let single sign-on take care of silent login and start a shell. You can immediately start to enter the desired commands. Access control is not visible during permitted actions, making it easy to have it everywhere. This actually means that anyone, not just hosting system operators but also domain owners and even users, can safely be granted operator shell access!

Something's Cooking #4: Web Auth with SASL

2018-11-15T00:00:00+01:00

You have heard us complain about the lack of security and identity support on websites. The reason has perhaps been gradual progress without a clear direction. This is why projects like our InternetWide Architecture, with explicit design, can make a leap forward.

Authentication at the TLS or HTTP levels is the best option, because it eliminates the context of JavaScript, that also runs code from arbitrary sources. Also, application developers are not necessarily security experts.

HTTP however, is still recovering from the original authentication with weak methods. Some have overruled it in JavaScript, where some aspects of the weakness of passwords could be compensated by guiding users towards slightly better passwords. But once in JavaScript, the chances of stronger security mechanisms (like SCRAM) is gone.

We can complain all we like, but the InternetWide Architecture intends to untie such knots. So here we go.

SASL can Connect Everything

We propose to introduce SASL into HTTP. SASL is already part of many everyday protocols, such as IMAP, SMTP, POP3, LDAP, XMPP, AMQP and countless other -- even low-profile chat with IRC uses SASL!

SASL is a little more difficult to get into than a simple password, but that is due to its strengths:

SASL can be built into any protocol
SASL can carry any authentication algorithm

The specification shows this in the following ASCII-art drawing:

    SMTP    LDAP    XMPP   Other protocols ...
       \       |    |      /
        \      |    |     /
       SASL abstraction layer
        /      |    |     \
       /       |    |      \
EXTERNAL   GSSAPI  PLAIN   Other mechanisms ...

Think of SASL as standardised piping; the protocol side defines what hooks and bolts are needed to mount it, and the mechanism side defines an inner lining for the piping to which mechanisms can be matched for easy passing.

Genericity towards protocols means that not every protocol developer needs to invent a mechanism for user names and passwords; instead he can grab on SASL library and pass the messages through his protocols. For web applications this is evey simpler; web applications run on top of a protocol, and the SASL can be implemented at the HTTP and TLS layers and served to the application through environment variables.

Genericity towards authentication mechanisms means that new ones can be incorporated silently, without knowledge to the application programmer. The plethora of independently developed applications have been holding back the deployment of better schemes, which is why the web is still rife with password authentication, in spite of all security advise discrediting it.

Today, every application programmer starts off with a simple system based on passwords "just to get started" but never finds the time to move away from it -- there are always more pressing concerns in the application. This is precisely why it is a good reason to separate the concerns and simply follow the security offered by the HTTP and TLS layers.

SASL mechanisms are identified by standardised names. The requirements of a corporation might call for GS2-KRB5-PLUS or SAML20, but these are difficult and it is a hard call convincing application developers to support it. When authentication is handled at the HTTP and TLS layers, the dependency on a wide variety of application developers is gone; it is more realistic to convince parties producing generic software, such as web servers and web middleware.

Towards mechanisms, SASL defines how they can pass messages back and forth. This is not of influence on a design of HTTP SASL.

Towards protocols, SASL defines what kind of messages they should pass. It is up to the protocol how to fit this into the rest of the protocol flow. This is what needs to be handled by an HTTP embedding of SASL.

Introducing SASL for HTTP

Given these properties, we though it would be a good idea to introduce HTTP SASL in the most general manner possible, that is, as a specification for the Internet Engineering Task Force.

We are currently trying out these ideas by coding them into a proof of concept, and supporting it in other software:

A browser plugin that answers to HTTP SASL challenges, cleverly incorporating a desktop application to enable controlled access to local authentication infrastructure such as Kerberos;
An Apache module that will implement not just HTTP SASL, but also the other aspects of our identity model;
A demo servlet that runs its demonstration as part of a Java Tomcat webserver and that responds with HTTP SASL authentication requests;
WSGI middleware that demonstrates how HTTP SASL can be a layer that can mount on any WSGI service;
Docker demos for these components will likely follow too; for now, FireFox with SASL can be tried; the Apache modules also aim to incorporate SASL.

Not all this work is done, and there is certainly a lot more that can be done. This is an open source project, and you are welcome to join our ranks if you would like to see this evolve!

The pleasant thing is that it all works in HTTP headers, so:

No mixing of credentials and dynamically loaded extensions and advertisements in the same name space;
Application programmers need not concern themselves with authentication;
Authentication mechanisms can be configured by website administrators;
A growth path for ever-improving security has been plotted.

Diving In: Message Flows

For those who are interested in seeing the technology working, this section gives an example of the message flow of HTTP SASL. Others are welcome to skip ahead for a last surprise.

When a website is asked for a protected page, it will ask for authentication with a special status code 401 (for proxy access that would be 407, same story but different names). Stripped down to the bare essentials, we get

HTTP/1.1 401 Unauthorized
WWW-Authenticate: SASL
    realm="members only"
    mech="SCRAM-SHA-256 SCRAM-SHA-256-PLUS
          SCRAM-SHA-1 SCRAM-SHA-1-PLUS
          GS2-KRB5-PLUS GS2-KRB5"

(This post adds spacing and line breaks for readability)

From the looks of it, this is a very secure server! And why not, given that the SASL mechanisms are available and all behave the same? And so, this server offers SCRAM-* mechanisms, a tick-tock pattern where both client and server prove knowledge of the password, and GS2-KRB5 which is a very pleasant Kerberos single-signon authentication. The variants with -PLUS provide additional channel binding, to ensure that authentication is specific to the current HTTPS connection.

The client sees this and decides it has a few options to choose from. Since the mechanism names are standard, it can recognise them and pick out the ones it supports. Perhaps the user also added constraints.

Let's say the user has no setup with single sign-on, so it will have to be a password. SCRAM is a pretty good way of doing that if you have to, so that is selected. There are variants based on the SHA-1 and SHA-256 hashes, of which the latter is more secure. And if the browser gives access to TLS information, it is even possible to incorporate that; the browser therefore selects SCRAM-SHA-256-PLUS.

This mechanism is initiated by the client, so the first message already does something active:

Authorization: SASL
    realm="members only"
    mech="SCRAM-SHA-256-PLUS"
    c2s=[n,,n=user,r=rOprNGfwEbeRWgbNEkqO]

(Square brackets denote base64-encoded content)

We can see the choice of authentication being made with SASL, we can see the mech having been reduced to a single option, and the realm being repeated for the server's reference. Then there is the client-to-server parameter named c2s holding things specific to the mechanism. It doesn't matter what that means exactly; the general idea is that it is taken care of by the SASL mechanism and not a concern to HTTP SASL.

The server checks with its SCRAM mechanism implementation, which decideds to go for another round and so the server sends an update:

HTTP/1.1 401 Unauthorized
WWW-Authentication: SASL
    s2c=[r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxF
         Ilj)hNlF$k0,s=W22ZaJ0SNY7soEsUEjb6gQ==,
         i=4096]
    s2s=[xxxxx]

The parameter s2c, as you probably guessed, means server-to-client. The other parameter s2s may be a bit of a surprise; it contains server state that must be replicated by the client in continued messages. This is a requirement for all HTTP authentication mechanisms, and it helps to keep the server lenient.

The client makes an effort to continue the computation. The fact that it takes a few tick-tocks is precisely what the SCRAM mechanism prescribes, and it is necessary in all SASL protocols to allow the number of exchanges needed before the mechanism can come to a conclusion. So the client scratches its head, thinks hard about its password and decides

Authorization: SASL
    c2s=[c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2Ra
         TCAfuxFIlj)hNlF$k0,p=dHzbZapWIk4jUhN+Ute9
         ytag9zjfMHgsqmmiz7AndVQ=]
    s2s=[xxxxx]

The c2s is funny as always; in a PLAIN mechanism this sort of message would hold a readable password, but such replayable credentials are what we hope to avoid by using SCRAM instead. The s2s bounces back the literal text had from the server, as required. This seems to put the server in a good mood, and it finally decides on

HTTP/1.1 200 OK
WWW-Authentication: SASL
    s2c=[v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsj
         l95G4=]
    s2s=[zzz]

A redirect would also be an option, allowing client judgement.

The server is happy, and the s2c part is the final step to also make the client happy. If that is the case, the positive response can be used for client access to the website.

The fact that an s2s parameter is included in the positive response may come unexpected, but it is very useful. This s2s parameter is the client's hold on future access to the members only realm. For the remainder of our session, or if ever the server wants us to authenticate to the members only realm, we can respond by simply including the following header in the request:

Authorization: SASL
    realm="members only"
    s2s=[zzz]

The server still has an option to refuse this and forcing us into a new authentication round. One reason for this could be that a session timed out. If that happens, another round of SCRAM would be started. Or perhaps the users understands that it need not type passwords all the time, and better setup Kerberos.

Microsoft Friendly

We don't talk about Microsoft a lot in the world of open source and open protocols. Still, it is good to know that the HTTP SASL mechanism is very useful to that group of users.

Corporate domains often use Active Directory which is a fixed combination of Kerberos with LDAP and a few other protocols. Users in those domains have tickets that they can use in all Kerberos applications. (There are independent Kerberos stacks for Windows too, of course.)

The HTTP SASL mechanism allows better integration of Kerberos with the web than the current option, HTTP Negotiate. This option is considered only moderately secure. Specifically the option GS2-KRB5-PLUS can help to improve the security of access to web sites based on single sign-on. This is an often-heard requirement.

We probably will not develop dedicated plugins for the Windows platforms, but others might. The best economic model is sharing work once it has been done, so we hope to find one or two back on open source platforms, as a sign of gratitude to solving this big problem.

Passwords are back?!?

SASL supports password authentication. But don't take our support for SASL the wrong way -- passwords are detrimental to online security and must go as soon as possible. But this will not be an instant change, and a transition path that can support old and good habits at the same time allows each user to change at their own pace. HTTP SASL offers precisely that option, and precisely where it hurts most.

Current HTTP authentication is beyond hope: It has always been poor, the responsibility is dispersed over many incompatible home-grown code pieces, and so it is unmanageable -- and it is not changing a bit. Or have you encountered the HTTP headers for SCRAM authentication in the wild? It was published in 2010, so by now it should be commonplace, right? But we are waiting for application developers to pick it up. And every application that does move to a better mechanism is outcrowded by ten new applications that begin all over and re-invent the worst mechanism way "for now" and get away with it -- because everyone is still doing it so poorly.

Separation of authentication from application can free us from waiting for application developers to introduce better security. And it is in everybody's interest because it assigns the most suitable programmers to each task. And what we really need to move forward is an authentication approach that can grow with time and the individual maturity of their users.

Gold and Silver Paths

We consider the use of SASL as the "silver path" towards the InternetWide Mission and that certainly includes its use in HTTP. The use of a browser extension makes it possible for any user to step up to the system. In addition, native messaging allows for access to credentials on the desktop, such as password managers and today's Kerberos session.

We believe that the "golden path" for the InternetWide Architecture continues to be TLS-KDH with SASL mechanism EXTERNAL to fetch identities. The addition of KXOVER allows connections everywhere. The reason that we say this path is better is manyfold:

TLS-KDH protects against Quantum Computers;
Kerberos is a single sign-on system; the user will benefit with simpler security;
Kerberos is an promising combination with mobile platforms, such as smart phones;
The TLS-KDH protocol authenticates hundreds to tens of thousands times faster than public-key based TLS;
once established, realm crossover (KXOVER) can hold for weeks, effectively caching the crossover connection;
Kerberos tickets can cache information for improved efficiency.

We do still have work to do; TLS-KDH is not a formal specification yet, and still underway in TLS stacks; KXOVER is being implemented to make it more scalable than the proof of concept; KXOVER waits for consensus about public-key algorithms for key agreement that protect against Quanum Computing.

Identity 12: User Names in URLs

2018-10-26T22:23:24+02:00

In the InternetWide Architecture, we have many forms of identity with tight relations to service end users' control over their online presence. After tending to privacy during realm crossover, we want you to Bring Your Own IDentity (BYOID) so that you need not setup local user names and passwords with every service you might want to use.

A long time ago, we accessed "secure" portions of websites with a user name and password, as in

http://john:sekreet@www.example.com

These habits have died out. Passwords in URLs are considered a bad idea, but the use of accounts has been dropped along with it, making HTTP a rare protocols with non-standard notations in the path of a URL to encode users,

http://www.example.com/~john/his/path
http://www.example.com/#!/john/his/path
http://www.example.com/his/path?user=john
http://www.example.com/.well-known/webfinger?resource=acct%3Ajohn%40example.com

These being local standards for the visited domain, they are not as good as the proper use

http://john@example.com/his/path

So, is this last form such a bad idea, or is it just the use of passwords? It seems to be, as non-standard naming mechanisms cannot possibly be integrated with authentication in the browser, leading us to enter passwords in websites and surrendering it to the application layer where it is tightly knit with (adverse) advertisements.

What do the standards say exactly?

Clarity from RFC 3986

The formal definition of the URI syntax is RFC 3986 and it is quite clear about user names which it considers part of the authority section of the URI:

The userinfo subcomponent may consist of a user name and, optionally,
scheme-specific information about how to gain authorization to access
the resource.  The user information, if present, is followed by a
commercial at-sign ("@") that delimits it from the host.

In other words, the user name is meant to guide the visitor to the information about the user; it is authoritative in that it determines the origin of the information being presented. The common feeling that a user name would be related to a login name of a website is not what the specification say!

Many URI schemes include a hierarchical element for a naming
authority so that governance of the name space defined by the
remainder of the URI is delegated to that authority (which may, in
turn, delegate it further).  The generic syntax provides a common
means for distinguishing an authority based on a registered name or
server address, along with optional port and user information.

Just like the host name is part of the authority, dictating where the information comes from, the optional user name is such a thing too. This is just what those non-standard representations of user names want to do! They are not about login of that user, but about the scoping of the data presented. The login process is an independent concern.

An important implication of this is that the user name must never be stripped from the URI. When it is treated as a login, this might be done, but that would remove part of the authority, and thus represent potentially different data. We do see vastly different reactions in browsers, indeed, and most of them are plain wrong.

Even when user names ought to be rendered, the advise is to do this in a way that distinguishes them from a domain name through something like a separete colour, or in RFC terms:

Applications that render a URI for the sake of user feedback, such as
in graphical hypertext browsing, should render userinfo in a way that
is distinguished from the rest of a URI, when feasible.  Such
rendering will assist the user in cases where the userinfo has been
misleadingly crafted to look like a trusted domain name
(Section 7.6).

It is absolutely no problem to talk to a server with a user name but without ever logging in. This is actually a service to privacy, as long as the user name has not been guessed. It allows you to have a server up without showing all its contents to anyone, robot or human. Leave the part of a website without user name to robots, but do not invite them in the parts with a user name.

A problem for HTTP is how to deliver a user name. This is not trivial, but it can be done with a simple use of Basic authentication: simply sending it without a password can only be interpreted as a signal that no password is provided (the authentication content would be username, colon, and a gaping hole where the password would otherwise be). HTTP servers can simply take in this user name and require no password or other form of authentication, until the user happens to hit upon a protected part of the data; at that time, the usual 401/407 exchange would be started, but even then the Basic header could be provided.

In general, authentication should take place in a place away from the JavaScript application, to improve security as well as to empower the browser to take control and help with automation. Authentication should be part of the HTTP protocol or even run below it, in TLS. No amount of reasoning about JavaScript code guiding the user can make up for what they are consistently guiding with, the use of passwords. And as a result of this crummy mechanism, needing to enter it over and over again. And forgetting it. Doing badly at picking them. Keeping them static for longer than is wise.

Stuffit, those Password Requirements

One reason that JavaScript "needs" to interact with the password is to "help" the user choose a "strong" one. You know, add a digit, mix capitals and lowercase, that sort of wonnabe-security. The official viewpoint is that this sort of oppression is a bad idea, even from a security standpoint. One more reason for access to password from the JavaScript/advertising space gone.

Verifiers SHOULD NOT impose other composition rules (e.g.,
requiring mixtures of different character types or prohibiting
consecutively repeated characters) for memorized secrets.
Verifiers SHOULD NOT require memorized secrets to be changed
arbitrarily (e.g., periodically). However, verifiers SHALL
force a change if there is evidence of compromise of the
authenticator.

Leave it to standards authors to make up their own terminology for passwords; but otherwise this should be crystal clear advise. It comes from NIST, by the way, and so this is the official security advise for the American government.

Why, you wonder? It's simple. If you must use a password, then use a generated one. This will use characters from a limited set, but with a lot of entropy, which is the bottom line of a good password. Entropy, explained informally, is a measure of surprise. Do not make up important passwords yourself and hope to remember them; use a password tool or your browser's builtin facilities, even if that involves makes it scrape fields from HTML content when the passwords are entered into layers higher than HTTP.

Strong crypto is still better; the exchange will be different each time, thus disabling the replay of captured traffic. TLS is only a limited protection in this respect, for a number of reasons.

Passwords and Colons in URIs

So what about URIs that contain a user name and password separated by a colon? This form is firmly abolished in the same RFC:

Use of the format "user:password" in the userinfo field is
deprecated.  Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password).  Applications may choose to ignore or
reject such data when it is received as part of a reference and
should reject the storage of such data in unencrypted form.  The
passing of authentication information in clear text has proven to be
a security risk in almost every case where it has been used.

Or, passwords in URIs are a bad idea, and things following a colon are considered to be that, and are to be handled carefully.

If we did anything here, we would indeed use it for an authorisation identity, which means stepping down in the inheritance hierarchy but otherwise remaining the same person. But we will probably try to do this on the client, in order to control the visibility of identities -- better done before realm crossover than after.

Users in URIs for AMQP

AMQP 1.0 is a messaging protocol. It is a bit like email, but geared towards automation and high volumes of data that need to be delivered reliably.

AMQP URIs follow the general form, and can include a user name as well. See how they are worked out for RabbitMQ to get an idea.

Again, the user name is in the authoritive part of the URI, so it determines what is visible in the path. Interestingly, URIs can be used at both end points, so we can have two users, each at their own domain, talk to each other. This is very much like the pattern used in email. Compare this to HTTP, where the only URI is on the server side; it is no wonder that the idea of the client account got woven into the one URI that existed, but it should be read as an authoritative section; this is not incompatible with the uses of today, but it feels different. Standardising access to user information is good to do in a standard manner though!

Given the two end point URLs in AMQP, we can actually make two parties talk openly. So what is the relation between that form and authentication and authorisation?

Authentication in AMQP is the customary combination of TLS and SASL. This is a powerful combination for client-server protocols, where the server is authenticated through TLS before the client authenticates through SASL. AMQP 1.0 is a peer-to-peer protocol, but individual connections may be considered client-to-server. The trick is to realise that it is the remote party's URI that needs to be validated, not the local one. We generally consider an authenticated remote domain name to be sufficient grounds to trust all user names under that domain name too; but we could ask for SASL authentication.

Note that this is what BYOID boils down to: the client indicates its user@domain.name identity as represented locally, and authenticates it to the remote system. This is why realm crossover is an intrinsic part of BYOID.

The client approaches another user@domain.name identity on the server, and this is the authority part: it determines what view on the server's resource we would like to have. In other words, for AMQP it indicates where we would like to deliver our message. That may include virtual hosts, queues but also, importantly, the targeted user.

We have designed our ACL system with two kinds of access; resources and communication. The latter applies to AMQP, where two users in each their own realms want to communicate. Whether the remote user is welcomed is decided by the ACL, for which we were able to find a surprisingly efficient implementation based on just a few lookups in a key-value database.

URIs for IRC

Internet Relay Chat predates HTTP, and also the idea of URIs was developed later. IRC is still popular and under active development because of its culture, where it is not assumed that people will respond immediately. This makes it the more relaxed alternative to present-day use of instant messaging.

Connections to IRC are made to a host, not a user. On the host, one chooses an identity (or "nick") and joins in discussion groups. There is a trend towards user authentication so the nick consistently reflects the same user. IRC used to be based on simple fixed passwords, but proper SASL exchanges are a useful addition in present-day IRC, including EXTERNAL (to reference TLS-based login) and with some attention for GSSAPI (to enable Kerberos5), which define two powerful cryptographic means; for use with passwords, SCRAM is an excellent suggestion.

So what would it mean to have user names in IRC URIs? As defined for URIs in general, such a user name is part of the authority section, and defines a name space. So the suggested use is to constain the discussions in IRC that would be visible. Indeed, IRC URIs tend to look like

irc://example.com/topic

and when presented like

irc://john@example.com/topic

they would not lookup the topic under example.com but under john@example.com -- meaning that user john could present his own selection of acceptable topic names. These might overlap with the ones for the host example.com or not -- as he sees fit. Yes, we are talking about a personal chat server, or at least a personally decorated chat service! User john might even be in for chat only over this URI.

But a much more promising situation now arises. The URI indicates what user is being addressed, and this information is available before using the IRC command to initiate TLS. Could it be possible to setup the TLS exchange directly with this user, in a peer-to-peer fashion? This would make IRC into a secure protocol for peer-to-peer chat, useful for such things as exchanging passwords -- though nobody would use that, if even an aged protocol like IRC can recognise that passwords are a relic of last century.

Why is HTTP different from AMQP and IRC?

HTTP is different from AMQP and IRC in one vital way: AMQP and IRC are communication protocols and HTTP is a resource access protocol. This means that the end points in AMQP are really different users, while in HTTP there is a user who wants to access resources that may or may not be available to him. There is no notion of a user on the HTTP server, except perhaps to mirror the requesting user.

Even group resources, such as a shared object store or web-based groupware are all modelled as a resource in HTTP, not as a user or group as it would be in AMQP.

So, it is not HTTP that is so different; it is the different notion of access control involved here that has caused the misinterpretation of the user part in these URIs. It's probably time we got our act together, and took it for what it really is: a part of the authority section of the HTTP URI.

In the InternetWide Architecture, we are quite strict about our use of identity. In the case of HTTP, the identity of the user involved in the session is a property attached to the client, not the server. This is why a URI http://john@example.com/path is a good way of scoping information (presumably about a user named john) but not in any way related to authorisation or access control. Access control must be a matter of client identity.

We have proposed an upgrade to HTTP by adding general SASL mechanisms by defining HTTP SASL and allowing authentication schemes to mature for all protocols at the same time, and automatically adding their value to HTTP. This would abolish the "guidance" of password entry in JavaScript, and instead update HTTP to a level that IRC has already reached, along with a plethora of other protocols.

ARPA2 All Hands - October 2018

2018-10-09T00:00:00+02:00

The address:

Kantoren Hoog Overborch (Hoog Catharijne)
Moreelsepark 48
3511 EP Utrecht
The Netherlands

We start at 10:00h and hope to finish around 16:00h, after which we will make sure there are some drinks and finger food to continue the discussion and brainstorming.

The programme will be posted on:

https://www.internetwide.org

If you have an interest in the ARPA2 project, or one of the various subprojects, do consider attending. If you want to give a presentation about your ideas on ARPA2, you are invited to do so - we are eager to hear your ideas! Also, students and doctoral candidates that are interested in doing a research project inside ARPA2 should end up with plenty of exciting new opportunities. If you know someone that would potentially be interesting in building vital new decentralised infrastructure for the internet - or volunteer in some other capacity - bring them along!

RSVP: It would be kind if you could send a notice whether you are attending or not, so we can make sure catering etc is all scaled right. Informing us of any dietary requirements of you or your guests will make it easier to take these into account.

If you have any questions, don't hesitate to contact me as well.

Quantum Crypto will Break our backs & bones

2018-02-10T00:00:00+01:00

Quantum Computing is an emerging field of technology. Don't be mistaken, it's no longer purely fundamental research, but it's technology being developped. The field has shown the principles to work, and is working towards clearly set goals and has a clear idea of what aspects should be improved upon. Call it a road map if you like. And like in other fields of technology, the numbers are going up rapidly and, with that, the power to do the inevitable to cryptography.

To crack an algorithm that is designed to be particularly hard to crack, you almost need to change the rules of the game, and that is pretty much what Quantum Computers do; they make a lot of computations at the same time, and given smart-enough algorithms, they can do surprising things.

To take a bit away from the mystique surrounding the field, think of a string on a guitar. When you pluck it, you release a lot of random motion on the string, but the resonance of the string quickly dampens all frequencies except those that match in the length of the string. The result is a sharp beginning full of unstructured noise, and after a while, a bright tone. The selection process on many frequencies has happened completely independently. Now imagine passing some frequencies through to other strings, which also start vibrating and providing feedback on the resonance. And try to think of the structures, or algorithms if you like, that you could build with this; some string parts would end up vibrating on one tone, others on another tone, and yet other frequencies from the original pluck are lost. This is not exactly how a Quantum Computer works, but it is a somewhat fair image.

Algorithms have been devised to approach what we up to now thought uncrackable (the so-called "discrete log" problem) in a time that is structurally faster. Simply because operations can work on much data at the same time, and then be made to interact in ways that construct computations.

What gets broken?

In ten years from now, it is expected that all current public-key algorithms are broken. RSA, DSA, ECDSA, DH, ECDH, all our favourites. This is nothing short of devastating because we need these to build trust with parties we have not been in contact with — based on their proof of ownership of a key. Yes, that certainly includes HTTPS under any of the current forms of TLS. The game changes entirely when others can suddenly start claiming posession of the key, simply because they were able to crack it on a Quantum Computer.

There are some pieces that are left to use though. We can continue to use symmetric (or "bulk") ciphers such as AES, and we can still use hashing algorithms. Note that this means that Kerberos, on which we found most of our infrastructure, will continue to be safe, as long as it is not founded on the public-key setup protocol PKINIT. Some of you may know PKINIT as "smart card logon".

Work has started on devising new public-key crypto systems, and we should expect these to be commonplace when Quantum Computers hit the market. So, are we out of trouble? Not by a long shot, we do need to act well before that time. As in, now is the time to move.

What does it mean, in concrete terms?

We use public key crypto for a number of things:

Signatures for authentication, such as in web traffic
Signatures for legal authorisation, such as with PGP
Key encryption and key agreement, with or without Perfect Forward Secrecy

All these will be broken with the current algorithms. But their impact varies.

Authentication is usually a thing at the present time; there is no damage from future cracks of an authentication key because we have no mechanism to jump back in time and perform false authentication.

Legal authorisation is a bigger problem; looking at any legally binding signature made with current-day technology after the arrival of Quantum Computers is meaningless, as anyone could have forged the signature. Be sure to refresh all signatures before that time; this might be done with a timestamping service that freezes the original document with the original signatures as they were at any date before the arrival of Quantum Computing.

Key encryption and key agreement are ways of establishing a "bulk" encryption key for documents or network connections, including HTTPS. It is worryingly doable to capture and store all such traffic for future analysis. At this later moment, everything that was thought to be private traffic can be decrypted and looked through. Let's hope your credit card expires before that day has come!

Note well: The bulk encryption method itself cannot be cracked, but the keys used can be retrieved because their use in protocols depends on public keys. That's a very good design method, it just so happens that the current algorithms are up for renewal. And with the ability to rewind on such content, you should not wait until the first Quantum Computer is switched on.

This is why we indicated that it is time to act now. Unfortunately, we still need to wait for new public key algorithms. Guess why this article has serial number 1...

Very often, HTTPS is used to protect weak encryption schemes such as passwords. These will all be leaked and lapped up by intruders. Your services can then easily be boarded and your data hoarded. That's not a remote possibility; plenty of people on the Internet want to do this sort of thing, for good or for bad.

ARPA2 and Quantum Computing

We've been working quietly at a TLS variant known as TLS-KDH, which is based on Kerberos. During an excellent lecture on Quantum Computing by Tanja Lange we suddenly realised that this may well be the first form of TLS that is ready to face up to Quantum Computers. It uses ECDH, but folds some Kerberos-specifics into the operation that stops attackers from breaking the encryption on the connection. This is good, because TLS is used in most secure Internet protocols, including HTTPS. It is not-so-good because it assumes that people are using Kerberos.

We're also working on a mechanism for Realm Crossover with Kerberos, allowing clients in one security realm to access servers in another. The mechanism sets up an instant shared key between the two realms, through which the client can authenticate to the targeted remote server. This mechanism however, is a prey for Quantum Computing because it uses ECDH without the additional information that TLS-KDH uses. Knowing the shared key used for crossover would enable the decryption of all traffic that crosses over between the client and server realm.

This is precisely why it is good that security research makes advances and teaches us to stay moving the protective side to stay ahead of attackers and malpracticitoners; it makes us aware of things that we should improve. In the case of Realm Crossover, we have started the process of designing solutions that should make it undoable to crack.

More to come...

There will be more on this topic in later articles. The challenge that we are facing is incredible and complicated, but we're on top of it. In the end, we are likely to win through with an architecture that can easily roll new keys and certificates, and leave users protected.

[Lecture] IdentityHub: PKI for the Masses

2018-02-08T09:02:00+01:00

Download the presentation

Welcome. Let me explain why it is a good idea to have a globally spanning PKI, and how we believe our project holds just the right cards for it.
An example? FileSender is an application that allows the exchange of very large files, simply with an HTTP upload, an email to the recipients, who then download over HTTP. When this kind of service is hosted by a reliable party, your pricacy need not suffer. Through release as open source, anyone can control that aspect.

Starting with FileSender 2.0, encryption is added. The customary path is followed: a password is exchanged out-of-band, and the operator need not even be trusted.

But passwords are difficult to manage. If I share it with five people, can I also use it for another project where there are three people? Even when the overlap is complete, how about when a new person is added?

In a sense, a PKI could simplify and offload the minds of users. Or is a PKI too complex? We believe not. It's just that no single party is interested, or has a realistic plan, for making it available globally.
This is how easy a PKI can be. Using plain GnuPG, you can enter this simple command to ask it to lookup a recipient's domain in the DNS, prefixed with an LDAP server reference (protected by DNSSEC), then contact it and STARTTLS (which could perhaps be enhanced with DANE) and ask for the PGP key for the recipient. Download it, encrypt geheim.txt, done. All of this was automatic, thanks to the use of suitable protocols.

To make this secure, there is one requirement. The owner of the orvelte.nep domain must control the LDAP server, or pay a hosting party to control it so that no external parties can register PGP keys under this domain.
Domain hosting in general is the cornerstone of online identity and its security. You do not want to respond to a poll issued by mygov.stats-r-us.com because it may well be a phishing attempt by a party you don't know. It is reliable to respond to stats-r-us.mygov.com if you know you can trust mygov.com to delegate only to parties that are constrained where your privacy is concerned.

User names are similar to subdomains; adding a bakker@orvelte.nep address requires administrative control over orvelte.nep and can be trusted; and again, this is not the case for a third-party account named bakker-at-orvelte, as anyone can acquire that look-alike naam.

Domains are not just potent identity providers, they also enable us to run our personal flavour of services. That was the idea of hosting providers, but they grinded down to a halt. What went wrong?
When the web was attracting attention, we all wanted a domain name with a website and email. How cool we were to have our own corner on the Internet. And how right we were, this was the model of inidivual expressiveness as it was intended.

The hosting industry came to standardise on the LAMP stack, and never moved since. As a result, all further services were developed on top of HTTP, which in itself is a protocol with rather poor semantics as is shown by today's market that offers wonderful services but only when we run their software on the client side — most everything over HTTP is a proprietary protocol!
Technically inclined people have always withstood this trend, and ran their own servers. Often XMPP and IRC, but also more advanced things like SIP or Git. This model however, requires a lot of knowledge and does not scale up to the general public.
So, as a member of the general public, what you are left with is to run off to the GYM — by which I mean large silo's such as Google, Yahoo and Microsoft. They have different ideas about your privacy than you do, and their income is generated thanks to their massive scale. This income greatly outweighs what they could earn by selling hosting — but that does not make the model very stable. Users know this, and you can see a degree of cognitive dissonance with people who claim that they "have nothing to hide" or "have given up their privacy" [and are taking others down with them]. These people simply don't have a choice when it comes to running services that please them.
We believe that it takes a paradigm shift for the hosting world to get out of their price-competition. And the way we see this is by dividing the hosting role into two kinds of role: one for identity hosting, another for service providers. You would select an identity host on reliability aspects, like redundance and backups, but also protection of your credentials. A service provider would act as a plugin from anywhere, and would be selected on how well the provided service matches your interest.

This market, as we see it, benefits from diversity. If you are really good at something, you may attract customers. There will always be price-cutters, but quality has a clear role in this market. And there is no restriction by the package offered by an individual provider, so it is easy for end users to add services.

The InternetWide project develops a hosting stack to accomplish just that; with IdentityHub, our current project phase, we allow the central management of identities and key material through a hosting provider or perhaps partially under local control; with ServiceHub, the next phase, we design an umbillical cord between a service hoster and identity hoster.
So, how do you design an IdentityHub? It would have to be based on open protocols, and certainly more than just HTTP and Email. Open source software should be selected for the initial incarnation, and the pieces should be joined together (which turns out to be quite a lot of work). And our focus would be to centralise control in a cockpit run at the identity provider.
Not surprisingly in retrospect, we landed with the protocols that are in widespread use for internal centralisation of the management of large enterprises: LDAP for storage of automation-friendly data, and Kerberos for centralised authentication services. Pull an account out of Kerberos, and the user cannot obtain new rights anymore (after his current ticket expires, which usually takes about one day).
So we use LDAP to store public keys (for PGP) and certificates (for X.509). But we also use it to store other data, such as public contact information, references to resources ranging from a single website reference to a complete library of documents and/or media formats.

The choice for PKCS #11 is less common in this setting, and it is a big innovation in our project. PKCS #11 is an API that conceals private/secret keys. We want to make this into a hosted (and therefore remote) service, and not just for individual secrets, but also for those of the groups of which the client is a member.

Imagine how powerful this is. A member can use the private keys to decrypt documents, sign email, generally act on behalf of the group. At the moment he leaves the group these rights are withdrawn and, since the private keys remained concealed, gone are the privileges of acting on behalf of the group.

We really believe that end users can enjoy a PKI, once they get to using it.
We use Kerberos as our security foundation, and that is not shocking. It is a single-signon protocol and therefore very user-friendly. And, unlike similar attempts based on HTTP, it is not confined but is in fact already embedded in most other protocols, usually through GSSAPI.

More innovative is our approach to mobile computing, where we believe short-lived secrets are the only credentials that are secure to carry around. Loose the phone, or control over it, and the risk is manageable. This is another reason for using PKCS #11 as a remote protocol; it shares credentials without storing their sensitive parts on lossy or leaky devices. There is no common standard for Remote PKCS #11 but since we are not corners but instead build on solidly standardised protocols such as ASN.1 and GSSAPI, we believe we hold the cards to get this standardised.

Other things we are innovating relate to Kerberos. The TLS-KDH project has defined a TLS mechanism based on Kerberos and ECDH; where Kerberos is good for authentication but really needs encryption (preferrably with perfect forward secrecy), ECDH offers just that, but it needs authentication. Joining the two is like a fairytale marriage; it also is bloody fast and can support client-to-client connections. More importantly, it is a nice and general response to the urgent need for a more secure Kerberos method for HTTP. We expect Microsoft, with their AD product based on Kerberos, will be most delighted.

Another vital extension to Kerberos that we are working on is realm crossover or, as we abbreviate it these days, KXOVER (if you are Dutch, you might say klaar-over). This project uses DANE and DNSSEC technology to exploit the certificates that Kerberos realm controllers can already use, but now to connect between hitherto unrelated realms. This is completely new, but it is possible to perform a secure handshake to exchange a key that will allow clients of one realm to use the services in another. Yes, this is Kerberos at the scale of the entire Internet! And combined with TLS-KDH, the possibilities are almost endless.

(We are aware that some work is needed on the privacy of the Kerberos tickets as well, and have developer ideas on that too.)
It's just a simple though, but incredibly powerful; do not define identities for individual protocols, but keep it general so that all protocols can benefit. Then get carried away with a highly advanced identity system and any service that plugs in can benefit by interpreting the various flavours being offered.

As an example, consider groups. Central control over groups and ACLs would apply to all protocols, so services need not worry about this; all they need to do is assign a meaning to the ideas of groups, and hope that it captures the imagination of users. For email, a group could be made to function as instant list mail; For WebDAV, a group may be an account under which data is shared; For SIP telephony, a group address can connect members into a conference that needs no explicit configuration but simply sits there as an always-ready-to-go conference room.
More about our project can be found in our Tetralogy of a free Internet, missions statement and audiences. If you think you should be part of this growing family, please contact us! We are interested in collaborations where we can assign programmers to the many tasks facing us, while at the same time serving your project with those parts that help you forward. We work strictly in open source, and are generally dependent on external funding to be able to hire skilled developers. Through InternetWide, we acquire such funds that we subsequently use to finance parts of the solution space in individual ARPA2 work projects.

On Display #3: Perpetuum driver

2018-02-04T00:00:00+01:00

This is the third article in an article series On Display in which we report on the output from projects that fall under the InternetWide Umbrella of projects.

What is it?

Perpetuum, coordinates processes and generates code for them to relieve programs from the complexity of looking around for state and locks.

The processes involved are drawn as so-called Petri Nets. This is well-known mathemetical formalism, invented by Carl Petri when he was 14 years old. It is a language that expresses progressing control by passing tokens between places by transitions that "fire". When firing, a transition can start or end concurrent branches in a process, where ending concurrency comes down to the same idea as synchronising the original branches.

These diagrams can be drawn and simulated with existing graphical tools, and saved in a standardised XML format, named PNML. This is where Perpetuum sets off.

Perpetuum generates code to coordinate attempts at firing (events from the environment) and when they do, tries to cause changes by invoking a transition in underlying code. In a sense, the environment is being filtered and the application code is driven under the strict control of the Petri Net.

Design Criteria

What we wanted to achieve is to isolate the most complex part of these workflow-styled operations. Introducing a user is simple enough when all that needs to be done is add a username and a password in one database table, but in the IdentityHub it will do much more; keys must be generated for X.509 and PGP, installed in LDAP, possibly claimed in DNS and signed under DNSSEC, and various components of the infrastructure must be notified or called into action. Most processes in the IdentityHub follow a similarly complex plot; adding a member to a group involves instructing the Remote PKCS #11 component about a layer that needs to be added for that user, to give an example where the IdentityHub is more functional, but also more complex than an everage database table behind a PHP application.

The complexity of processes hits an application hard when it is distributed throughout the code. Specifically, when a bit of code needs to check if certain parts of a process have completed, and if not it needs to somehow wait for them to complete, be careful not to end up in race conditions when other threads are just finishing this work, and so on. In contrast with this, all the code dealing with concurrency and synchronisation is now captured in the Petri Net, and the application logic consists of elementary transitions that do simple, individual things. When a transition needs to make a DNS lookup, it need not know about success and failure branches, but is provided with a transition to trigger in each of these situations, as a way of feeding back to the Petri Net. (For now, this sort of data is still provided by a bit of code that is not generated. We are looking into ways of automating even that.)

Hanging over the Petri Nets is a management module. This module is manually coded, and creates new instances of a Petri Net when a new task arrives, and keeps feeding it with events to consider. It will take note of failures and may tear down Petri Nets that are finished. In future versions, it may also accommodate some form of persistency, probably by freezing Petri Net instances and storing their state in a database. This would allow for long-term processes to sit silent while awaiting a timeout, such as a renewal for a 90-day certificate.

So we have split the complexities of workflow management into three kinds of component:

management of instances
concurrency control, generated from Petri Nets
application logic, processing individual short actions

Behind all this is the goal of letting the Petri Nets be the driving force for flexibility. If you are administering a network with a somewhat different topology than an application assumes, you should have the freedom to add or remove parts of the Petri Net. It is the centralisation of these aspects and their automatic generation of code that makes this doable.

Finally, having graphical tools has already given us the very big benefit of simulation runs; without having written a single line of code, we could draw a Petri Net and go through several concrete runs to test the ideas. For complex processes such as those of network protocols, this adds value in terms of understanding and debugging a process early. Having to do this after coding, and then having the code spread all over an application, is orders of magnitude more difficult.

First Releases and Field Testing

We have had a working code generator for C for a while now, and believe it is working. Since C is wide open to various program structures, we have stopped this process at the point where we believed that it would integrate well with event libraries. We have since then realised that a richer semantics (and/or programming culture) for these concepts is helpful to provide better functionality, but in C that would have been restrictive and so we chose to let others wrap more refined models around our general one. What we have done for the C model is make it highly compact, in service of embedded applications. One can easily imagine Petri Nets to respond to buttons being pressed, but only at the right times, and then whatever hardware responses to be triggered in the application logic.

Perpetuum 1.0 also generates code for Erlang, along with intensive test code to ensure that it works as it ought to. Erlang has a very strong concurrency culture of habits in the form of the OTP library, and we have striven to integrate with those habits, thus delivering a higher level of service than we felt comfortabel with in C.

The Petri Net implementation used for Erlang is utterly efficient, because it uses a single integer to store the entire state of the Petri Net. It relies on Erlang's support of arbitrarily large integers and will rescale its representation when a Petri Net run needs more tokens in a place than available at that time.

We are testing this version with our own application for Kerberos Realm Crossover which involves a client process talking to a server process, both heavily leaning on DNS and DNSSEC, as well as some public key crypto, for security. Note how the individual transitions call for actions in the application logic that are all relatively simple and, most importantly, isolated from each other but for variable transport; things like sending a DNS query, or things like processing a signature as valid or invalid. This isolation and simplicity has been our purpose all along.

Based on this, we are learning a few lessons that will influence the next release. Things like asynchronous signalling without any feedback, which is not a desirable model; instead, we will be sending feedback to the management process that initiated the Petri Net. We are also learning that some events are triggered by the controller and others by a callback to the application logic. For now, the management process passes a "success" and "failure" event to the application logic, so that it may act on the response by triggering one of these without knowledge of the diagram. Ideally, we would have that encoded in the Petri Net or an accompanying table, so even the management process need not be aware of this ongoing work, or at least it might have a way of inferring this data from the automatically generated code.

Future Dreams

In some future version, we hope to have one or more ways of composing Petri Nets, so it will be possible to describe partial views on a problem; this might be useful for pluggable components, but also to specify client and server separately and see their interaction in a composed system.

A technical facility that we have designed but not yet implemented, is dealing with inhibitor arcs with multiplicity. This takes a slightly different path than our current bitfield vector model.

On top of that, we have several more computational wishes, some of which are:

persistency and process hibernation
ways to automate relations between transitions

We do not need that for our current work, which is a field test with KXOVER.

Getting Started

Although 1.0 is stable, it is not going to be an easy ride. Please be prepared to use your developer skills if you want to try it, and please realise that we too are now running our first field test. Having said that, we would love to get your input in this stage. Others might want to await the next release, which will also be announced on this blog.

If you feel like diving in, please head for these documents first:

Project README
Quickstart to play around
Tools, or just follow our advise and install GreatSPN
USING it for Designs
Proper INSTALL
Testing for an impression of what the code can do, and the test code to inspect how it might be done (in Erlang).

This is definitely going to take you some getting used to. If you are not accustomed to Erlang, you probably want to limit yourself to the C generated code, and integrate with your customary event loop. We hope that the documentation is up to that, but are open to your feedback and/or pull requests that may help people getting started with what will be a new approach for most programmers.

We are also quite keen on developments in formal model checking. Rick and Adriaan both have a background in it, but neither have this aspect high on their agenda at the moment. Do send us your ideas though, we are most curious!

Wild Ideas for Applications

The application area for Perpetuum is huge. One application might be an open source program driver for a washing machine. Very few tweaks are made in this mundane application, but a few interesting ones could be imagined; solar panels might be used for hot fill, for the soapy wash run but not for the initial rinse; signals might be sent to our preference of alarming device when washing has finished; and we might even respond to room temperature to send a reminder at the most energy-efficient time for running your laundry.

We are also playing with the idea of modelling a protocol implementation for TLS with Petri Nets. This might be a nice test for our ideas of Composition of Petri Nets. Composition would allow partial protocols drawn in individual diagrams, and them being composed on such linking aspects as matching transition names. This might allow for the individual specification of involvement with various stages of the protocol. When a CipherSuite cannot function in a given setting, it would simply remove the token that held it alive.

Petri Nets have the (at least theoretic) potential of model checking. Some checks are possible in general, some require a special class of Petri Nets, and some will run as long as the time is taken for a brute force over all possible markings.

Image credit: Bluecmd at WikiMedia Commons

Standardising the Hacker's RS-232 Jack Plug

2017-12-26T00:00:00+01:00

This article is about hacking hardware. Note that the term hacking has been hijacked by misguided journalists to refer to illegal conduct; the real term for that would be cracking. Hackers make things, crackers break things, as ESR famously put it. Usually, we do this on store-bought devices in an attempt to tinker with the way it works, and possibly improve on it, download our own software, and so on.

We are bound to call for hardware work in the time to come. If that is done, we will use this article as a reference point for the developers, so we can replay any hacks that they applied to devices on behalf of us. Useful enough to spell it all out.

Hardware Hacking 101

Got a neat device that you'd like to master? Chances are, if it's digital, that it runs on Linux, and if you open the casing you will find a set of three soldering islands (or sometimes more) on the circuit board, sometimes even with pins sticking out. Depending on the manufacturer's taste, it may have print next to it saying DEBUG or similar. Or, it may use terms like RXD, TXD and GND or just RX, TX and GND. Bingo, you've found an RS-232 serial interface.

What you don't know yet, is if the device acts as an endpoint (DTE) or as a communications device (DCE). These are normally connected directly without any swapping of signals, and because of that, the directions of the TXD and RXD are the opposive of what you would expect for the DCE. On a DTE, TXD sends and RXD receives; on a DCE, TXD receives and RXD sends. So make sure to test their direction, and make no assumptions; you may have to swap the two signals to connect two DTE systems, or two DCE systems. With the three-resistor test given above, you would find the receiving pin halfway the supply voltage while the transmitting pin is at the supply voltage.

When you would listen in on the connection, chances are you will see a Linux system booting over it. If you ever started a Linux system from scratch you will undoubtly remember text rolling over the screen, to disappear after all is done, and be replaced by a graphical interface.

Hardware is usually a so-called embedded system which means that it won't pop up a graphical interface, but instead continue in textual mode. This is a bit of a pain, but it mostly a gain. The pain is that you will need to know what to ask, which is not always simple. You will have to learn how to operate a shell. The gain however, is that all these systems listen to pretty much the same style of commands. So you can practice on a desktop system and continue using it on your embedded system. Also, the embedded system usually has no online manual pages installed, but they largely overlap the functions on your desktop anyway — albeit that embedded systems are usually dressed down in terms of functionality.

Connecting to Embedded Devices

It is important to realise that the voltage level of embedded devices is usually 3V3, but it does not have to be. And even though the signals may be called RS-232 after the famous serial interface, this is with the exception of the voltage levels. A PC serial port is likely to destroy these embedded connections due to the higher and even negative voltages: -12V to +12V is quite common.

The biggest challange is now to find a way to connect to either another 3V3 device; although a Raspberry Pi may seem handy, you should then avoid its normal use of the serial interface as a console and login terminal, and instead make it suitable to run terminal emulators that run against dito functionality on the other side.

Many have been lucky using a data cable meant for an older mobile phone. In the end, there are a few chips that are used to connect up to USB; these work well on Linux and Windows, but not so well on Mac OS X. (We view all devices as a DTE in what follows, which may mean that we end up swapping the names compared to what the PCB says. We mean output when we speak of the device's TxD and we mean input when we speak of its RxD.)

If your circuit board doesn't tell you, you should try to measure voltages on the pins while the device is switched on. You are looking for low (0V) and high (3V3) levels relative to GND; you can often spot GND as large planes of copper, or you can hook it up to another connector on the device of which you know it is grounded.

There are bound to be three signals, namely:

GND is fixed at 0V and won't divert from that voltage
TxD bursts out data, but might be inactive, at which time it outputs 3V3; it won't divert much
RxD is an input, and should be quite easy to divert to another voltage

The first two can be recognised as the 0V and 3V3 levels, but the third will also show up as a concrete reading; how to split that apart? The trick is, RxD will gladly follow input signals. So, take a resistor, somewhere in the range of 100 Ohm to 10k Ohm, and connect a potential input to a point at 0V, then to 3V3. Measure to see if it follows the change. If so, it is an input and so it is RxD. The other two are now easily identified.

Resistor tester. You might connect the same resistor value, for instance 22 kOhm, between each pair of these three signals and measure what that does to their voltage. You should find:

TxD is at 3V3
RxD is at 1V65
GND is at 0V

Note how the tip of a TRS jack plug is "hot", and the signals "cool down" on their path to the sleeve.

LED tester. An alternative (as yet untested) option is to use a red and green LED with a resistor of about 1 kOhm (to restrict currents to under 3 mA). Connect one end of the resistor, the red cathode and green anode in one dot of solder, and solder a 220 Ohm resistor to the free ends of the LEDs. Then, connect each of the free-hanging ends of the resistors to the three terminals under investigation. When a LED lights up, it has been connected properly; if not, you should suffle the wires. In the end you should find:

TxD lights up red (assuming a DTE, so this is the data output)
RxD stays off (assuming a DTE, so this is the data input)
GND lights up green

It would be relatively easy to pour this into a jack plug to allow a quick test. Very nice if you do this a lot, or to check up on your earlier work. This can in fact be plugged into a socket that has been wired up, when it is ready to be connected to the PCB.

It has also been suggested that a piezo connected to TxD sounds like an old-school modem while a device is booting (to indicate that it is dumping data over TxD). This might turn your LED tester into a multimedia toolkit :-)

Null modem. The trick is now to make what is called a cross cable, also described as a null modem, because it is like connecting two PCs directly, without intermediate modems and communications channels... RS-232 was intended for communication with telephone line modems, you see. The cross cable is called that way because the RxD of one device connects to the TxD of the other. You do connect GND of the two devices directly, as a shared reference voltage for the signals.

Never connect Vcc lines, even when they area available on both. The problem with that would be that you have two reference voltages, and they might end up competing if they differ slightly. Signals are relative to GND, and that should be your approach too. (An exception can be made when the Vcc on one device is meant to power the other device of course, but that is not usually what we want.)

Once connected, start the device and enjoy the text scrolling over your screen. Read it carefully, you may find many hints. And you can try to get in; many systems don't even ask you to login but simply end in a prompt where you will have root access to the system. Although the mechanics of storage are quite different on an embedded device, and you should carefully follow instructions if you intend to upgrade your device over this interface, there is no reason why you cannot look around, try to understand what is going on, and edit a file or two if you are sufficiently convinced that they are not a strict requirement for a successful reboot.

Standardised Jack Plugs

Now let's boldly propose that we be clever about this, to improve reuse and future access to those device in the future. I once started with OpenWRT, and soldered a few plugs on the PCB so I could access them. I've been making compatible pin headers ever since. But pin headers are not very practical:

You cannot attach them to the device casing
They can be plugged in in two ways
They may plug into a larger pin header
You may need to mod PCBs, including opening up soldering islands
You might feel inclined to use DB-9 connectors and pump up voltages

Enter the 3.5 mm jack plug. A variety of manufacturers have created all sorts of plugs and sockets. Very importantly, you can easily solder these things yourself. And, given a drilled hole in the device exterior, you can make the RS-232 console accessible on the device's outside. Your cost per device stays below 1 Euro, and that easily pays back as reduced effort in easy and consistent device hacking in the future.

Terminal and "Communications Modem"

The RS-232 terminology speaks of a DTE (Data Terminal Equipment) and DCE (Data Communications Equipment). In layman terms, your computer or printer or teletype are all examples of a DTE because it is the beginning and end of the communication line, and a modem, ISP infrastructure and cross cables all make up the DCE side of things.

The terms RxD and TxD are defined in reference to the DTE; the TxD signal is transmitted by the DTE and sent to the DCE (who receives it on its TxD input), and RxD does the opposite (so it is output by the DCE and input by the DTE). When you connect DTE and DCE, you will not be crossing over wires, but connect RxD to RxD and TxD to TxD and, of course, GND to GND.

In terms of Jack Plugs, we can define these quite simply as follows:

Sockets represent a DTE (they output TxD and input RxD)
Jack plugs represent a DCE (they input TxD and output RxD)

So, let's take the example of a USB data cable such as the DCA-540, which was commonly used to connect to a mobile phone over RS-232. Many variants exist, and most of these cables use the PL2303 chip for which drivers are part of stock Linux, widely available for Windows and somehow always causing trouble on Mac OS X.

Cut open the cable and find the signals that you need, either by looking up the mobile phone connector pinout or doing what you also did for the circuit board. You can connect the TxD, RxD and GND signals to a jack plug to make the cable appear like a DCE, which seems most sensible if devices present themselves as a socket. In the concrete example of the PL2303 given here, you should be mindful that it is configured as a DTE, so to attach a jack plug would require swapping the TxD and RxD signals.

This cable will be useful to plug into a socket that you mount into an embedded device. And you can pull it out, and plug it in elsewhere. You should keep a list of settings somewhere, so you need not fool around with the precise serial port settings for each device; you could print it next to the connector. The usual format is 8N1, meaning 8 bit words, no parity and (at least) 1 stop bit. The speeds vary; we often see that embedded devices use 115200 bits per second, but an older standard was 9600, and some use 384000. If you get it wrong you are not likely to destroy anything, but the device's output will look like scrambled eggs.

The null modem is a cable with two jack plugs so it looks like a DCE to both sides, which means that straight connections are not possible; it needs to swap the RxD and TxD signals. This means that a standard stereo connection cable cannot be used. Be careful and only use the cable that you marked as a null modem. You would create a short circuit if you used a plain stereo audio cable instead of a null modem cable!

Jack Plugs and Sockets are TS, TRS or TRRS

There are some forms of 3.5 mm plugs and sockets, known as TS, TRS and TRRS. You might know them from audio applications:

TS plugs are used to pass mono sound
TRS plugs are used to pass stereo sound
TRRS plugs have an extra ring for an extra signal, like mic or video

There are four positions where a socket samples the plug. These are best seen on a TRRS connector. Let's number the four positions 1,2,3,4 by going from the tip to the shaft.

TS sockets connect to make T=1, S=3
TRS sockets connect to make T=1, R=2, S=3
TRRS sockets connect to make T=1, R=2, R'=3, S=4

We might as well have spoken of 13, 123 and 1234 plugs and sockets. Note that a plug with less rings than sampled by the socket will create a short-circuit between those sampling points in the socket. As a special consideration, we could use TS sockets for devices with only output but no input, such as GPS receivers or DCF77 clocks or any radio station if you have no radio transmission license.

Normally, TRS means Tip-Ring-Sleeve, but we shall use it to conveniently means TxD, RxD, (signal)GND. Note how the customary letters are hints to the RS-232 use. As will be clear below this also makes good electrical sense, which is much more important, but the naming is a happy coincidence.

We let sockets connect to make TxD=1, RxD=2, GND=3. A TS plug might be used to receive TxD data from a device without sending anything back; in fact a TRS socket TRS would find RxD connected to GND by a TS plug, which in terms of RS-232 is a constant BREAK signal. More importantly, a TRS plug in a TS socket would simply ignore the incoming RxD signal and that is indeed as intended for a device that emits data but will not take any commands back. (It may not be worth the effort to specialise that far though. Much easier to just use a pile of TRS sockets and a few shared TRS jack plugs, and simply leave the RxD signal unconnected on sockets if a device has no need for it.)

Optional Bidirection Extra Wire

There is one more option available, and that is the TRRS jack plug and socket. These should be compatible, so they continue to have GND=3, but an extra signal OPT=4 is now available. When a TS or TRS jack plug is used with a TRRS socket, then OPT will be connected to GND. When a TRRS jack plug is used in a TRS or TS socket, it will be kept floating, because the socket does not connect on position 4.

You can easily include position 4 in the null modem as a direct connection. It may be of use to you someday. But you can just as easily simplify and use a null modem based on TRS jack plugs only. You probably are going to make one such cable, so TRRS may be worth considering, just in case.

The logic proposed below is a bit complex, but also powerful. There are safe and easy defaults. The logic is:

Each side can supply a signal via a 4k7 Ohm resistor, so the cable holds the average of the two signals;
An analog signal may be inserted around half the 3V3 supply, with a range of no more than 1V up or down, so 0V65 to 2V65, which will be averaged with the signal on the other side;
A digital signal may be inserted as the extreme values 3V3 or 0V, again through a 4k7 Ohm resistor to support averaging;
A side that sends and receives a signal would use an opamp to subtract half the local signal, and then double the outcome to find the original signal from the other side.

You can use this to signal quite a range of things, both analog and digital, which makes it very interesting. We don't specify anything but if you are looking for an easy suggestion it'd be to signal "am alive" to the other side, by simply wiring the 3V3 supply via a 4k7 Ohm resistor. Such a signal can be processed on the other side as a sign of life; how this is done depends on the configuration of the side (which is why we resorted to a general name of "am alive"):

The DTE can send Data Terminal Ready (DTR) and the DCE can receive Data Set Ready (DSR) as a sign that the other side is online, or at least powered up;
The DCE can send 3V3 (if it is a USB cable) or the other side's "am alive" (if it is a null modem) and the DTE can receive Data Carrier Detect (DCD).

This is quite directly how RS-232 connections do hardware handshaking. There are a few more such signals, namely Request To Send (RTS) and Clear To Send (CTS), together implementing hardware flow control. These are not directly possible in this setup, but characters XON and XOFF are often used to replace them, or on most terminal sessions the flow control problems are also regularly ignored. A few patches exist, and are common in null modems too:

The DTE can send RTS which may be ignored;
The DCE can receive RTS as a local copy of the other side's "am alive" signal, and pass it on as such;
The DCE can send CTS which may be ignored, or incorporated, along with its DCD signal, into the "am alive" signal being returned;
The DTE can receive CTS as a local copy of the other side's "am alive" signal.

A few points worth noting when passing analog signals:

When one end passes an analog signal and the other passes a digital, there may be distortions as a result of the more extreme ranges for the digital signal, and glitches on the analog signal may also be caused by the digital signal;
Channel separation will be limited by the precision of the resistors being used;
The 4k7 Ohm resistence is half of what the LINE audio signals of a PC sound card are destined to drive, but the signal range is also about half, so you can drive the LINE signal in here through a 10 kOhm resistor and find half the output on the other side — unless it is aware of this fact, and compensates for it;

Feeding Circuits

The OPT signal is protected from short-circuits but as a result it has more resistence than could be tolerated on a power line. As a result, it cannot be used to supply power to an end point. But, following the stretch of imagination that used to be common for RS-232 circuit hacks, we do have some possibilities to do this awful thing.

The RxD signal comes into a DTE with less resistance, and should be able to drive a modest load, especially when no data passes over it. As an example, a simple DCF77 circuit might draw 3 mA, taken from RxD. If it the circuit can run below 3V3 it may be beneficial to feed through a 100 Ohm resistance that feeds a capacitor, to stabilise the local power.

To take this even further, there are ways of expressing the output from a DCF77 module in terms of RS-232... each second, either a low pulse of 0.1 seconds or 0.2 seconds occurs. That might be interpreted as an extremely low bitrate serial signal at 10, 20, 30 or 40 bits/second as 8N1.

A shameless use of this jack plug RS-232 specification would then be to add a socket to a DCF77 clock, where it sucks power from RxD and feeds its output directly into TxD. Not that any practical RS-232 circuit is going to be able to sample at this low bitrate...

Just a Standard...

Andrew Tanenbaum said, with a decent bit or irony, that the nice thing about standards is that there are so many to choose from; and if you don't like this year's standard you can always wait for next year's.

This specification is like that. I only wrote it because I've never seen a proposal for a cheap 'n' easy connector that makes hardware hacks more compatible. We are likely going to use this in upcoming ARPA2 projects in 2018 or 2019, as we move into the realms of hardware...

The image was found on WikiMedia Commons and edited with Gimp before addition in this article. You may use it under the original license.

Identity 10: The link with Peer-to-Peer Networking

2017-12-04T08:40:00+01:00

P2P networks enhance the freedom of online users to communicate with a minimum of dependencies on centrally managed infrastructure. Even though the popular press got hold of applications such as music downloads, this is by far not the only use of these systems. In their purest form, they embody the most liberating principles of a well-oiled Internet.

Distribution of Control

The main reason to design a protocol as a P2P protocol is to distribute control over the network. This ultimately sets end users free, and allows them to communicate with less constraints. And yes, this allows so much that it even supports illegal activities, but that can be said of all mechanisms, even seemingly harmless ones.

In general, the added value of P2P networks, their promise of independency, greatly outweighs these exceptional corners that are indeed not as easy to catch in one large net.

The Internet was originally meant to distribute control. In our architecture, we implement this true to heart by making it easier for users to have their own online presence through a powerful, modern hosting stack. P2P networks take the opposite approach, where there is not even the infrastructure of current protocols, DNS and routing systems but even that is internalised into the network. It's a more accellerated form of the same idea.

The reason why control should be distributed is that we can see the opposite motion in today's Internet, along with its devastating effects. Most of us have accounts at Facebook because most of our friends do — and those who have decided not to sacrifice their privacy for the convenience of messaging that can be achieved just as easily with XMPP or even IRC are under a constant mild pressure from their peers, and are regularly overlooked.

But what does it mean to have an account at Facebook? It means agreeing with a privacy regulation that is not in line what we as individuals want. It is agreeing to be scanned, grouped and pattern matched, and more so, to be subjected to advertising triggers that we know will work. In the worst use ever, it's a means to get a president elected into a large country through customised sweet talk. This is not a World that serves the purposes of end users, but that serves to exercise control over users, to a dangerous degree.

As stated before, one of the problems is the HTTP protocol's habit of pointing you to one website, which then has full control. Part of the control comes from the fact that there is so little semantics involved in HTTP, so we end up downloading software from the very same site that delivers the data. This model is being replaced by various developments.

The solution always involves distribution of control. Just like in a democracy, where those in power still have to account for their actions, so they will be on behalf of the majority.

Not-so-tight Identities

The ARPA2 model has strong ideas about identity and how it should be used under a domain name. Indeed, when each person or organisation has its own domain name or at least user name with an abundance of aliases, then there is a good degree of control being distributed to somehwere near the user.

We have also defined a fourth phase however, which intends to grow to social structures. We call this our SocialHub phase. In this phase, we intend to open up the facilities of our hosted services for integration with others. We are keenly interested in things like attaching groups to other groups run elsewhere to form a joined service that spans domains. But we are just as interested in allowing networks such as P2P networks to spac across domains, or across user portions of services.

Where we assign a lot of value to identities in our current, second phase called IdentityHub, we are intruiged by the idea of letting go of identities, or adhering to another scheme of identities, or perhaps allowing certain new shapes of identity into our work as part of the SocialHub work to come.

The connecting concept appears to be public key crypto. Our IdentityHub facilitates key management, with an unheard-of degree of comfort for the end user, and with a refreshing level of service management for the hosting side. We explicitly enable storing key material locally, outside the control of the hosting party.

Many P2P networks use public key crypto as the cornerstone for their online activities. So, just like we will be supportive of X.509 and PGP for each and every ARPA2 user, it may be possible to just generate keys for use in P2P networks. The coupled identity may be published or not; that is the choice of the user and their network. Along the lines of the rest of the IdentityHub, it is at least possible to, say, store public keys in LDAP under a domain so it can be used to validate a user@domain.name identity, but not all P2P networks require that.

Efficiently Hosted

Another aspect that may be of interest to uesrs of P2P networks is the ability to host the "public service" parts of these networks. The aspect of overlay routing implies a lot of communication between peers, and this may not always be desirable. Mobile network connections are relatively expensive, and having a P2P network active on a mobile device would incur a fixed initial cost as a result, no matter if there actually is any communication addressed to the user of the mobile phone.

This can be remedied by splitting the P2P functionality into a part that is hosted (either at a hosting provider or somewhere under control by the user, like at home) and a part that is mobile and runs there just for the communication of the user. This "satellite" node would simply be exempted from the social functions to network peers, which are then handled by the hosted node.

Hosting providers may in fact run one P2P node for public services, and pick out only those messages that need to be routed internally. There are so many hosting parties that this easily leads to a proper level of distribution. Of course, there should always be facilitation for users who want to run their own, and not even be dependent on the hosting provider that they pay to fulfil some of their services for them.

Adding Value through ARPA2

Even when our identity model is not neccessarily shown in a P2P network, it is still useful to realise the value that it can add. If anything, we offer ways of filtering access and validating it based on key material. An advanced form of communication can involve encryption that is only viisble to intended recipients, such as those on our ACL, or in a list of accepted keys.

Having such generous supply of keys as we have after the IdentityHub phase is complete, it should be easy for us to support encryption on P2P networks. Just to be clear; the public keys in P2P networks usually represent a node, which may be a user, but not neccessarily so.

Example Service

For a well-crafted example of a P2P network, take a look at the Inter-Planetary File System or IPFS for short. It is designed as a new and improved web service, where a local node delivers information that is retrieved from a P2P network, and held in storage and kept alive any number of participating nodes. This is a vastly different model from HTTP, which points directly to one server and demonstrate its downtime and other shortcomings very easily.

We can imagine an extension to this young system that would incorporate access control, and quite possibly store resources only in a select number of nodes, namely those that have the keys to decrypt the content. We can imagine those nodes implementing access control on behalf of the originator, as a result of their key having been included in the encryption scheme as a statement of trust.

The ARPA2 Roadmap for SocialHub

Recall our intention to support plugin services as part of the third phase by the name of ServiceHub. We should take this into account when thinking about P2P network services just as well. So, what tasks does that leave for ARPA2?

It is a bit early to answer this question here and now, but the question may well be the central one for our work on SocialHub. If you happen to work on a P2P network and are interested in discussing what you think our architecture and specifically the IdentityHub can add, then please contact us!

An early thought of the directions for an answer is that we may want to add support for connections to P2P networks where the domain-based addresses form an "anchor" that seeds data for the domain:

P2P identities under our identity scheme
Key management fit for P2P applications
Access Control Lists for P2P nodes
Sharing for groups mixed into P2P networks
Encryption/Decryption of P2P content
Seeding content into P2P networks
Defining names that map to accessible hashes
Servicing peers on behalf of endpoints

One model that might underpin this line of action would be to work "internally" on draft versions of a document, through collaboration over the Reservoir, and sharing of the final content through a publication medium like IPFS.

On Display #2: LillyDAP library

2017-11-11T00:00:00+01:00

This is the second article in an article series On Display in which we report on the output from projects that fall under the InternetWide Umbrella of projects.

What is it?

LDAP is a protocol for access to a directory. Directories are hierarchically organised collections of objects, where each object can be of a different class and have a variety of attributes to hold data fragments. LDAP moves in this world, and operates on objects and their directory locations as well as on attributes and their relationship to the classes of the containing objects.

One might say that directories are semi-structured in comparison to the tightly organised structure of an SQL database. Indeed, where it takes an extra table (and an extra lookup) to allow multiple values for one attribute in LDAP, it is simply added to the pile in LDAP. In comparison to many no-SQL designs however, directories have a little more structure.

But that may not even be the most important aspect to LDAP. What we are incredibly pleased about, is that it is a standardised protocol. And not just a writeup of how software works, but the design of LDAP is elegant, extensible and semantically very, very rich. If that term does not appeal to you, then let me rephrase: for most of the things you might care to do to your data, LDAP has you covered. You can add your own object classes and attribute types, for example. And the way in which it is done precludes clashes with someone else's extensions. In many cases however, you will be able to simply apply the mountain of standard types; and if not, chances are that you can simply reuse the extension work done before by others.

And even though HTTP could do many of the things that LDAP does, it usually comes down to a very generic service (namely pushing around MIME-typed data blobs) and leaving all the interpretation of that data to software. As a result, you will often find that an application is delivered to you as a tighly coupled pair of client and server software; the ability to do this is a big part of the success of JavaScript. But it has nothing to do with open protocols; the only open part is the very generic service level of HTTP. LDAP has us covered at a much more refined level of detail, which is why you can find completely different client and server implementations talking freely.

Design Criteria

We designed LillyDAP to be a very small library in support of LDAP. It is in fact a wrapper around Quick DER, which itself is a very small implementation of DER. LDAP uses BER, but that is okay to Quick DER. Quick DER writes a more constrained format than LDAP requires, and it shrugs over the frivolous extensions made by BER.

Most importantly, we wanted to make LillyDAP a library that makes LDAP easy to use as a protocol in its own right. We have seen too many situations where people would have benefited from LDAP but decided to turn elsewhere because they could not find a simple enough implementation. Indeed, the OpenLDAP server has a steep learning curve. In general, the complexity of setting up a complete directory, so a data store driven by LDAP, may be avoidable for the kind of applications that we are aiming for with LillyDAP.

You can use LillyDAP as a client or as a server; or you can make it an intermediate to filter LDAP messages, and perhaps split off its SASL authentication of TLS flow. To that end, you are given fine control over the level at which LillyDAP's structural parsers invoke callbacks.

We wanted this to be a highly efficient component. In fact, we have our mind set to integration with the Nginx proxy server as a protocol next to HTTP, and have adopted several of the excellent programming techniques used in Nginx, most notably a compatible pooled memory allocation technique.

The library can work quite well in an asynchronous environment, where only one thread is active and midway data is stored away for future continuation. But we do support threading, and in the best possible manner, namely a lock-free implementation. This means that multiple threads may be running, and even when they get together on a critical piece of code they will not end up locking each other out of the criticial code; instead, each does its own bit in such a way that all can continue without being stopped. This is the modern way in which high-performance server-side code is designed, for optimum performance on multitasking CPUs. At the same time, for LillyDAP it happens to be the simplest solution to make the threads work together.

With the resulting library, it is possible to cover a large range of use cases; multi-tenant hosting should be as straightforward as a simple tool that runs from your user account to exchange contact details of PGP keys. In spite of the large range, the code is still very compact; so compact in fact, that we've been wondering if it could run on a ZX Spectrum with 48 kB memory, with the tape beeping interface for exchange of LDAP messages! (And if it hadn't been for the rejection by sdcc of certain coding constructs we might actually have done it.)

Manipulation of Data

LDAP can be viewed as an RPC protocol that operates on directory data. To implement an application, you can have callbacks for operations sent to you, or you can send out operations and receive callbacks when the results come in. There is a peer-to-peer extension that easily makes LDAP bidirectional, so it can also be used for the exchange of data in a standardised format in P2P networks.

The kinds of operations you can create include addition and removal of objects, of attributes within an object, but also things like locking and even complete ACID transactions are defined. Very important is searching for data, which traditional LDAP servers do with high efficiency due to proper indexing and mostly readonly operation, but there is no reason why a dedicated application server could not do better, possibly even on already-existing indexes and storage structures.

It is common for LDAP to frown upon delivered data, and check if it would break structural integrity. For example, removing a directory node that has children nodes underneath, or removing an attribute that is required by, or adding one that is not permitted by an object's class. Standardised error codes explain such things to the client.

For heavy-duty operations, there are replication and backup protocols, also usable as bulk update protocols and for subscribing to data changes. That is a common pattern: One party sends a new value for an attribute and a lot of lurking clients all receive an update.

Usage Ideas

LillyDAP can be used for domain publication of data, as well as for internal affairs. Furthermore, we designed LillyDAP because we need a tool to modify LDAP messages in transit.

LDAP defines a so-called global directory, which is a fancy term for the definition of an SRV record that appoints a domain's LDAP server. That server is the place to turn to for your queries. Since common uses of LDAP include contact information and configuration data, that's a good start for such publications that may be retrieved at will by others.

A few concrete ideas for a global directory:

Publish contact data of your employees. Include those things that are considered truly public; perhaps a phone number but not their email address. Since LDAP is highly suitable for automation, it may be an idea to use revolving temporary contact information. This can help to protect sensible access methods such as highly interruptive SIP phone addresses by making them somehow dynamically changing.
Since user identities can be easily searched in LDAP, use it to publish PKIX certificates and/or OpenPGP public keys to the World. LDAP happens to be the standard protocol for PKIX certificates; the LDAP global directory also supported by default in the popular GnuPG tool for OpenPGP, so outgoing mail servers might retrieve keys automatically.

A few concrete ideas for an internal directory, to which access may be protected with SASL authentication:

Publish internal contact data. This time, a lot more information can be made available.
Publish account configuration information, including groups and roles. This can be picked up by various servers; it is our intended use in the IdentityHub.
Publish contact information for external contacts such as clients. This allows all employees to access information entered centrally by one of them.
Publish public key information for external contacts, such as their PKIX certificates and OpenPGP public keys. Again, the data can be used by all employees but also by servers that access this automated resource. And again, GnuPG can be configured to use your LDAP server as its key server.
Publish PKCS #11 URIs along with public keys for local users. This is not a standard use, but it is very useful in our IdentityHub, which automatically creates, refreshes and destroys keys and certificates. Being able to search public key material in LDAP should yield great speedups in comparison to doing the same over PKCS #11.

A few ideas for user-level applications:

Publish your personal contact information to others on your LAN. You could even include dynamic data, such as your presence.
Publish your GnuPG key ring to your other locations, so the keys you collected (and signed, perhaps locally) are available everywhere.

Getting Started

If you feel like diving in, please head for these documents first:

The interface to C is the most developed, but the Python wrapper is currently incomplete (meaning, open to pull requests). The same holds for the projected utilities and controls; we add those aspects as soon as we need them, but if you are more in a hurry we welcome your pull requests. Note that neither of these is required for general use of the library.

On Display #1: Quick DER library

2017-11-09T00:00:00+01:00

This is a first article in an On Display in which we report on the output from projects that fall under the InternetWide Umbrella of projects.

What is it?

While the web world leans heavily on textual formats such as XML and JSON, there has long been a standard for representing data structures for binary transmission, named ASN.1 and developed by ITU. Never heard of it? That's probably because it works so well that you never noticed it, but rest assured that you use it many times a day. Like its textual counterparts, ASN.1 helps to pack and unpack data while in transit.

Data languages are a cornerstone of open protocols. They define in a precise manner what goes out and what comes in. Given accurate descriptions of such transit data, it is possible to choose freely from various implementations that adhere to the same specification. As a result, you can communicate with peers that use completely different software from what you are using.

ASN.1 is used in many open standards, such as RFC's, and ITU itself uses it in many of its telephony and networking protocols. It defines, in a somewhat abstract manner, how structures are composed. When using ASN.1 in software, it needs to be represented in some way in bits. Standard mappings have been defined such as DER (used for certificates, Kerberos tickets and much more), BER (used for LDAP), XER (which means XML) and, soon to come, JER (which maps to JSON). The same ASN.1 specification can be used with any or all of these representations.

Quick DER is a library that focusses on the most prominent representation in Internet Standards, namely DER. It also tolerates its more general cousin BER. With the library, you can pack and unpack such structures, and end up with structure fields that contain the data passed across the wire.

One advantage of DER over formats like JSON is that it is easy to skip ahead: the structures are nested and when there is no need for a part then its contents need not be explicitly skipped. Another advantage is that the format is binary, and can pass any data without escaping. You can include quotes, backslashes, and zero characters without worrying that it might be mangled while in transit. This not only means great simplification of code, but as a result of that, less opportunities for bugs or misinterpretation.

Design Criteria

We wanted Quick DER to be secure, meaning that it parses with great care. Bugs have been known to lead to security leaks before. So, simplicity was key in the design.

We also wanted a compact library, mindful of possible applications on embedded platforms, such as the IoT applications that are discussed so often these days. Compactness in terms of code size and memory footprint were both important to us. We achieved this by a surprisingly simple choice, namely to not allocate memory in the library. The cost that resulted from this choice was rather limited: repeating structures such as lists or sets of other elements are not unpacked, but should instead be iterated over.

We wanted a highly reliable interface, simple and consistent in use. We believe we succeeded by invoking der_pack() and der_unpack() operations with a simple command sequence that can be setup in the calling code as a constant bytecode array.

And, we wanted to provide programmer convenience. Though some luxoury automation is missing, such as for decoding integers, we added those as add-on utility functions that are only one call away. The general bit however, is really convenient to use: every unpacker output (or packer input) is represented as a pointer/length combination that holds a value as it is encapsulated in the DER format. Note that this is the best format to retain the ability to carry any binary data, including quotes, escapes and zero characters, so just as the wire format did.

Compiling Syntax Specifications

Given an ASN.1 specification, the accompanying tool asn2quickder can be used to translate it to a header file for use in C, as well as wrapper classes in Python. Both support an access pattern that is native to the language, and adheres to the structures described in ASN.1; structures (called SEQUENCE in ASN.1) have field names, which can be used to dive into the structure; C uses overlay struct definitions for this purpose, and Python has class members to achieve the same.

Without this compiler, based on the generic asn1ate parser library, the Quick DER tool would not be half as useful. With it, you can write your own ASN.1 specifications and translate them to bytecode and structures that allow simple packing and unpacking of DER encoded data.

We didn't stop by just supplying this tool. There are so many standards making good use of ASN.1 that we decided to setup for pre-compilation of their specifications. This also helps to make slight adaptions if the format is too difficult to process (ASN.1 is a big topic) or plain wrong (as we have indeed found in a few standards by using this tool). The intended result is that anyone who installs Quick DER is immediately rewarded with include files for the most commonly used standard formats.

If you want to add a standard to this library, please send us a pull request, and we will gladly add it. We can do a lot of good by sharing code, but even more when we additionally share these descriptors that allow straightforward handling of standard data.

Usage Ideas

DER is a very good facility for specifying your protocols. This is what Kerberos does, for example. It is also used for data formats, such as X.509 or PKIX certificates. It has never been so easy to parse a certificate and pull out, say, the name of its owner. This is the sort of use that we have in mind when we line up with existing protocols, and sometimes expand them with new ideas. This is why we thought it worthwhile to create the Quick DER software package.

Not all protocols and not all data formats follow DER encoding rules, of course. TLS for example, has elected to define its own formats and has many corners in which it finds yet other ways of formatting options and extensions. And GnuPG also has its own data formats. In both cases, the use cases would have been suited for ASN.1 description, but another choice was made.

In terms of specification complexity, the definition of a local encoding is rather costly. All implementations must go to the bit level, as does the specification, rather than start from a record level that assumes that the data is somehow magically transported. This is just how things work, but it could be a lesson to us all. Quick DER was created so not even the most open-source minded person would feel a need to invent yet another wire format, cause yet another stream of decoding bugs, and learn yet again the same old lessons. The choice, however, is yours.

Getting Started

If you feel like diving in, please head for these documents first:

The interface to C is the most developed, though you should feel happy with the Python wrappers as well.

Spam Filtering: Balancing the Odds

2017-10-20T00:00:00+02:00

Email is inherently stable; when mail servers pass around email they are always very clear on whose responsibility it is to continue to handle an email, so no messages can be lost. Unfortunately, the abuse through spam has introduced a need to reject messages before they reach their recipients, thereby introducing risk of falsely rejecting, or falsely accepting an email.

Spam Filtering Techniques

There are a few common techniques that help to combat spam. We will first describe those (briefly) and return to what the IdentiyHub can add further down.

Blacklisting is a technique based on publicly maintained lists of known abusers: spammers, phishers and virus spreaders. Whitelisting is the opposite, and is done to protect well-behaving mail senders from being classified as spammers.
Greylisting is a technique to challenge the sender within the constraints of a protocol. In the case of email, it is common to initially report I am too busy to take your email right now and rely on the sender to try again later. The principle of greylisting can be expanded to other protocols, always in their own way; phone calls may be redirected and messaging may be subjected to standard inquiries, for example. All these complicate the complexity beyond the usual simplicity of the simple implementations in the bot nets that are in use by spammers.
Standards compliance checks help to raise the bar that a spammer needs to adhere to. Where it has long been tradition to be lenient, there now is a reason to require things like a proper Date: on each email, an existing sender address, and so on.
Pattern recognition is where things get vague, and uncertain. The email is scanned for signs that indicate possible spam, like a Subject: with only uppercase characters. Many suspicious factors are collected, and an estimate is made by assigning a weight to each and seeing if the total spam score exceeds a threshold. This threshold causes a balancing question of whether we want to lean towards the risk of missing proper email or receiving improper email.
Spam training is the process where human feedback is used to tell a spam filter that certain mail is spam or non-spam. Spam training works by changing the weights assigned to the various patterns being recognised. It helps to personalise the separation between spam and non-spam, but it can never lead to a perfect and flawless result.

Spam Prevention Techniques

A few modern approaches exist to make it impossible or highly unlikely that spam can be sent. This usually consists of two things:

Authentication is used to get certainty of who sent an email. SPF lets the sending domain declares what the possible senders are for email from a domain. DKIM lets the sending mail server sign email so it can be validated to have come from the domain's mail server.
Reputation is the collected behaviour of a sender, and it works best when combined with authentication. This is used to weigh the probability that a sender is a spammer.

This may sound accurate, but it is in fact a branch of statistics, with its inherent uncertainties. What statistics can help to do is not just express average values, but also how certain these are.

Opportunities for Improvement

The balance to strike is best illustrated by looking both at the probabilities of something being spam, and something being non-spam. Let's say we want to have 90% certainty, then we can distinguish cases where we are less than 5% certain that something is spam as non-spam (green), and when we are at least than 95% certain that something is non-spam, we reject it without any misgivings (red).

We can combine the two diagrams, and show a yellow middle portion to indicate what we are uncertain about. To strike the best balance, we should aim for making that area as small as possible. Which of the following two systems looks more attractive as a spam filter?

Clearly, the narrower case is the ideal; it certain about more spam classifications, thus rejecting them rightfully, and it is certain about more non-spam classifications, thus passing them rightfully. The yellow portion is where we may get involved, and so the narrowest yellow portion is an attractive property of any spam filtering system.

The common interpretation of these boundaries between red, yellow and green is in terms of the spam score that a spam filter derives from the weighted evidence of a spam selection.

The rules used in spam filters are selected to have a high degree of probability of finding a good balance. In addition, when training a spam filter about email that the user considers non-spam or spam, the weighing of the many rules helps to get more accurate. Rules that turn out to be less effective (after training) are blunted in the result, whereas those rules that are most precise will be sharpened, and have a heightened impact on the selection of what is considered spam or non-spam.

Balancing Spam Score with Expectations

Spam scoring can be influenced on a per-person basis, based on personal preferences. It would be unpractical to do it for each alias in our IdentityHub, as that would impart a lot of maintenance work on the user. Distinction between pseudonyms is perhaps possible, though even here we might wonder if it is useful.

What we may do however, is alter our expectations based on the context in which an email arrives. We have a lot of that in the IdentiyHub, but the aforementioned techniques also help to raise or lower bars:

DKIM and SPF are frameworks for establishing sender identity. When we have expectations about the use of either or both technologies, we can raise the bar for a sender. The techniques are sensitive to forwarding and mailing lists, but email contains a trace of where it has been, which can help to recover from problems. To this end, we're looking into Lenient DKIM, Lenient SPF and Lenient DMARC; some of these may make it into a formal standard, others are not likely to get that far but may still be of use in local configurations using, for example, our IdentityHub.
Aliases help us to sort our contacts, and we can set different expectations on each. Where we may be lenient about spam in a naughty alias, we are likely to be less interest in our formal capacity. Also, aliases offer a good distinction between what we expect senders to do with DKIM and SPF; we may well have an alias for a business contact whose mail server always uses these techniques, for instance, but in return we may want to be light on spam checking. On the other hand, a generally reachable address info@example.com is more prone to receive mail from the general public and may be subjected to intense spam filtering. In short, we have different expectations and so we set different cut-off bounds for spam filtering.
Access Control Lists or ACL for short authorise access to an alias. These settings are very useful in the selection process. An ACL entry matching a complete email address is perfect, certainly when the expectations on DKIM and SPF match, an ACL entry with just a domain match is less perfect, but it gets less perfect when the user name is not matched, and when the domain erodes form accurate to subdomains, all the way to a wildcard matching any domain. This means that an ACL can be helpful to modify the expectations for each sender individually.
Mail Submission is the term for an outgoing mail server. When using IdentityHub, you will send mail through its related server, so the various forms of identity rewriting can be made — like adding an alias or changing to a group member identity. This is also needed to behave properly under DKIM and SPF. Even when using a webmail solution, you would setup the mail submission server for your addresses under an IdentityHub domain. There are various things that we may learn about outgoing mail, and that are commonly reused in reply email. This is a great help when receiving returned emails. So, we can use outgoing email to fill (volatile) databases with information scavenged from outgoing email, and use those databases to help to match incoming email.

The general idea is to raise expectations on spam score depending on these factors. As an example, aliases may allow us to group spam expectations per domain, per sender or other sender attributes.

Training spam and non-spam may be slightly different under such circumstances. In a first layer, there will be the need to learn about the expectations. This is similar to the learning process for spam filters, but this time the factors are of impact on expectations. Then, after learning these factors, it is possible to train a spam filter about spam or non-spam that remain after the new classification. This training should not aim for a fixed setting of spam scores, but instead be relative to the expectations (which is a complicating new idea).

Note that we may succeed in adding the aforementioned aspects as factors to a spam filtering solution; this is in fact a common practice in spam filters; but that may not work for all forms of computation; some things may be more logically arranged through multiplication thant through addition, for example. We have an interesting problem ahead of us, but the reason that we are optimistic about the ability of the IdentityHub to add value is that we do indeed have more information available, which is always good to improve filtering.

Identity 10: OpenPGP without Web Of Trust

2017-09-25T13:53:21+02:00

When someone sends you a message with an OpenPGP signature, or if you want to send them an encrypted message, you will need their OpenPGP public key. There are several ways to find these keys, but the difficulty lies in validating the key.

Shared Key Servers and Web Of Trust

There are a few well-known public key servers, in use by many OpenPGP users. Based on an email address, they will present the PGP key(s) attached. None of these keys is validated however; one may have been submitted by anyone.

To this end, people meet in so-called PGP Key Signing Parties, where they pair up and validate a photo ID card against the key, and later sign the other person's key with theirs. As a potential user of a key, you are supposed to find a path from your key to theirs. This is the so-called Web Of Trust.

This system makes it difficult to change to a new key, because one's reputation is literally at stake. With no paths leading to a new key, it is difficult for others to start using your key. With five independent paths, it's easy to place a fair degree of trust in a key. But what about intermediate numbers of parallel paths? Or how about very long paths?

Everyone has their own policies where the Web Of Trust is concerned. This is difficult, because it means that no certainties can be derived from OpenPGP keys. The competing technology X.509 is not ideal either, as it demands inclusion of a certificate in one (and no more) hierarchies; as with the Web Of Trust, a shared root certificate is required before two parties can rely on each other's validity.

In practice, the level of validation of an email address is at best that the claimant has clicked once on a link in a confirmation email. Not a very strong foundation for a cryptographic framework. Even when repeated use of the same key can put us at ease, this is not the instant security that we should ideally have in a world of ever-changing contacts.

Global Directory and DANE

The LDAP Global Directory is a thoroughly defined mechanism for announcing well-structured data under a domain name. One of its uses is to publish OpenPGP keys directly under a domain name, and this is indeed supported in GnuPG, the most commonly used OpenPGP software.

Downloading data from LDAP is a matter of automation, which is indeed shown to work by GnuPG. To completely rely on it, one may additionall use STARTTLS within LDAP, and DANE/DNSSEC to validate the certificate used for it; a lot of technology, but completely automatic.

The one factor relied on here is the domain, and the integrity of its management. This is only fair; even a large and open provider such as GMail is good at avoiding that their users can act on behalf of each other, and any smaller domain would strive for the same. Given that this can be trusted on, the Global Directory is a good solution. But it does imply a need to setup (quite) some infrastructure.

DKIM as Key Validator

Under DKIM technology, an (originating) mail server adds a signature on the message content, thus fixating the message because any change to the message would invalidate the signature. So, by checking the signature, a recipient can assure that the email has not changed while in transit.

DKIM is a very useful technique for passing around OpenPGP keys. As long as the From: header of the email agrees with the UserID of the OpenPGP key, and the DKIM-Signature: header includes that same issuer or otherwise their domain, and signs at least the body and the From: header, it is safe to trust that the body has not been modified since it left the signing/originating mail server. In other words, if that content includes an OpenPGP key, it can be trusted for that email sender.

Wow, we just introduced a simple and elegant mechanism to exchange OpenPGP keys without even needing the Web Of Trust. Now we can really create a public key and use it without concerning anyone else!

So, is these really practical? Yes, as it turns out to be within everyone's reach:

The sender creates an email account with DKIM, like with GMail
The sender creates an OpenPGP key with UserID set to the email account
The sender uses the email account to spread the OpenPGP public key
The sender can now use (any) email address to send authenticated email
Recipients can return encrypted email for the email owner's eyes only

To validate the submitted key, a simple piece of software like dkimpy already suffices. For now, this is commandline software, but it serves as a demo of what could be easily added to web and desktop mail tools.

DKIM to drive Bots

We explained before that we can see DKIM as a basis for automated interactions with email bots. No need for confirmation links (a really weak security model) but instead, validate an email including its contents when it is sent over normal pathways (that happen to do DKIM).

One service that we envision is a filter for outgoing mail to be used by government agencies and other large vendors, based on recipients that setup their OpenPGP keys.

Imagine the OpenPGP user with a suitable, DKIM-signing email account, as described above. And imagine a bot listening to +contact+pgp@example.com for emails holding an OpenPGP key. It would automatically perform the validations (perhaps also using dkimpy!) to extract the OpenPGP key, and install it in the outgoing mail server for outward encryption. And it may include it for incoming signature validation.

What we have now, is a model where we can (finally!) tell our government, bank, financial advisor to only send us email with encryption. And it does not even require those "professionals" to understand the privacy of their business and the corresponding use of OpenPGP for achieving it; it does not require them to remember that they should employ OpenPGP when talking to you; it is all taken care of by their outgoing mail server. A mail server to which they ought to have only access over an encrypted (MSA) connection.

So there we have it... OpenPGP can be omnipresent in a breeze. And nobody should be bothered when asked to apply it when communicating with you.

Mail Routing 3: Doing DKIM Perfectly

2017-08-28T07:57:19+02:00

In the setup of identities for ARPA2, we intend to given group members a local name consisting of the group name, a plus symbol and a nick that the member has picked to unique identify themselves in the group. This group+nick notation is not just helpful for their privacy, but it also helps to select an outgoing name that is local — even when the group member has an email address that is external to the group's domain.

The Last Nail in the Coffin

This may seem perfect, because we are now in a position to supply our own DKIM signature, but there remains one concern, and that is for publicly accessible groups. Sending to those would be permitted to non-members, and we need to find a DKIM-compliant way to address those senders as well.

As it turns out, this can easily be remedied. Yes, we could create a temporary name under the domain, but no we don't have to. We will simply keep the sender's address unprotected in the From: header instead of linking it to the group's domain. And even though we would evaluate the targeted group address for some special syntax forms, we would not alter the To: and Cc: in transit, nor the Reply-To: address, if any. This differs from the treatment of a remote user who is registered as a group member, because in that case we can pull the sender address into our own domain to the known identity for it. In both of these cases, the DKIM signature is valid; we just pass it along for unregistered senders while we modify it into a local alias for known group members or role occupants. A backlog of registrations and unregistrations by remote users to a group or role is kept, in support of abuse handling as well as living up to legal obligations to prove group subscription by externals.

This clearly demonstrates what DKIM is all about; it is about checking any verifiable headers. The link to the From: header is particularly strong, which is why it is important to "style" this header for good reception.

Benefits from Authentication Results

Upon entry, a modern MTA assesses the incoming email for authentication mechanisms:

Does it pass SPF, meaning did the email arrive from an MTA for the claimed sender domain?
Does it pass DKIM, meaning did a signature validate the message and its most important headers?
Does it pass DMARC, meaning that either SPF or DKIM passes and did the validated sender domain match the email's From: header?
Did the user login SASL under a TLS cloak, as is common when they are local users addressing the Mail Submission interface on port 587?
Did the sender sign the email with X.509 or OpenPGP, with an address that we could validate in their Global Directory?

Each of these helps to trust the sender's identity. And this can be really helpful.

Imagine signing up to an email list without the common pattern of a reply mail with a link to click. Given that your email address is validated upon entry, this would no longer be required (not all methods are equally suitable though; SPF is meaningless can arrive from a shared host, while DKIM normally uses domain-specific keys and is therefore quite reliable).

This pattern is just the beginning. How about submitting articles to your cooking blog by mailing your newly discovered recipe to the blog's service address +blog+TheExplodingStove@example.com and have the mail system sort out the insertion into the larger structure?

DKIM-Signature: XXXX
Subject: Broccoli on a Bed of Tomatoes

Trim broccoli and steam for 10 minutes.  Slice meaty tomatoes and bake
in butter for 5 minutes.  On each dish, layer tomatoes with hot steaming
broccoli, cover with Camembert slices and keep under a lid for 5-10 min,
or until the Camebert is molten.

And more techno-savvy, how would you like to edit your data in LDAP? You could ask the +ldap@example.com service for your objects, edit them and send a reply. Or you could just submit an LDIF if that's your style. This is an incredibly easy interface to an otherwise difficult-to-use service.

objectClass: inetOrgPerson
uid: rick
cn: Rick van Rein
mail: rick@example.org
description: A bit chatty, but not a complete idiot

Passing on the Pleasures of Authentication

Time to return to Earth.

We indicated that we want most of the outgoing traffic to point back to the domain managed under the IdentityHub that we are designing here, with the InternetWide Architecture. Being crypto-savveys, we love nothing more than to apply DKIM and SPF and all the other pleasures of life on all our external conduct.

But wait. What if we are passing on traffic that was not so well-protected? Then we might land with an external statement that is stronger than the incoming statement. This is certainly not a good idea.

So, when we pass traffic through our domains, we will take a look at the quality of the incoming data, and supply the output with similar quality.

Local users who authenticated with SASL over TLS are pretty reliable. There is no problem to mount a cryptographic firewall on their behalf, so we will happily apply SPF and DKIM for those users.
Users from anywhere, who present OpenPGP-signed content can also be trusted with that content. Their origin is a different matter, as that is not usually included in the signatures. Looking them up in the LDAP Global Directory, validating their user name and assuring that the LDAP service is protected with TLS, DANE and DNSSEC further pins down the security. Similarly for X.509 certificate holders.
Remote users who validate under DKIM, and who have included a decent supply of headers in the signature-protected scope, are can also be trusted to have come from the claimed original domain, and can be accepted when this matches their sender address.
DMARC wants to pin down the address in the From: header to one that resides under a domain that was validated under DKIM or SPF. It is good to reproduce the same status on output as we found on input, and that should be easy to do.
Remote users who validate under SPF, are not nearly making as strong a claim. SPF is mostly about exclusion of other senders and is not as strong in pinpointing that nobody has been tampering with the sender's identity. Meaning, based on SPF alone we shall not sign with DKIM when passing on the email, but we will once again arrange SPF. If SPF is not valid on input, we can usually generate a sender address that fails SPF testing, though that would at best qualify to suppress the relaying of spam.

In these days in which email authentication is coming up, we may easily make the mistake of relaying messages while stepping up their observed authenticity. That might lead to situations that would grant rights such as the ones from the previous section without actually being allowed to have those rights.

For SPF, a step-up in perceived quality is not a big concern, but doing DKIM perfectly may involve holding back on it... in der Beschränking zeigt sich der Meister!

Update 2017-08-30: Reply-To munging

We have considered to place remote and unregistered sender addresses into a Reply-To: field but, with a gut feeling that this had been a topic to people in the past, we asked around, only to be pointed to convincing arguments about the right approach to do this.

Changes to email bodies are not the post man's prerogative, and the headers should be kept as pristine as possible, too. The privacy concerns for group members are an overruling concern to us, so we shall munge those headers, but for unknown external senders we shall not modify the headers in any way; externals are supposed to know only the group address anyway. We may opt for rejecting group-addressed emails that reveal more than just the sender's address, but that is still an open issue.

As for modifying email with legal banners and [indicators] in the Subject:, this practice seems to cause more pain through breaking DKIM than relief through the ability to sort and mark emails. Much better facilities exist, which even provide better semantics than just placing texts in places that welcome arbitrary text but fail to convey any meaning for it:

The List-ID: header is deliberately designed to convey a unique identity for a list (or role, or group).
The Keywords header is designed to hold a comma-separated list of words or phrases describing the text.
The Comments header is designed to hold any additional comments on the text of the body of the message and this is much more telling than plunging legal text in a footer (after having read the body) or before it (which everybody understands to discourage reading the body at all). If anywhere, the Comments section is the place for legal disclaimers. It cannot be used to force legal conduct on a recipient, which is also the limitation ofttext in the footer, unless a prior contract between the sender and recipient forced the latter to comply. When you set these, you should consider including it in the DKIM-Signature: signed-header list.
Disclaimers stating that only the intended recipient may read an email are seriously misguided. Whenever this is a concern, use OpenPGP or X.509 encryption. Where this is a company-wide policy, stop sending disclaimers and apply encryption. And yes, we aim to make this easily doable with our IdentityHub design, through the use of a Global Directory. This enables recipipents to publish key material for encryption, and recipipents to automatically make use of it.

Mail Routing 2: Doing SPF Perfectly

2017-08-18T10:20:11+02:00

The ARPA2 infrastructure uses user names with aliases for all sorts of purposes, including for registration in groups or for occupancy of a role. At the same time, there is a (visibly related) name for a group member, and for a role occupant, and these have a one-to-one coupling with an alias. So, user john may speak of himself as john+admin while the sysadm role knows him as sysadm+mrsmith. Note the mechanism of attaching an extra label to the of name a user, role or group to turn it into an alias, occupant or member.

In support of our Bring Your Own IDentity design, we have always permitted remote identities to participate in groups, and said that there should be a facility to turn it into a pseudonym for use with the external entity, for reasons of privacy. What we haven't done het, is connect the dots.

What we need, next to the aliases for participation in groups and roles, is an alias for participation in other domains. Such an alias would count as an external identity and it would take whatever form is used under that external domain, though some general user@domain.name form would be assumed. By declaring this, we can choose how to approach the other service; as one of us or as one of them. Imagine email, where this construct offers a choice between sending an email from the local realm, or the external one.

Forwarding and SPF: Resolving the Conflict

Forwarding is still done a lot without modification to the envelope sender address, causing the receiving mailbox to reject the submission because the original sender is kept, but the email comes from another source. This is in some ways an internal responsibility, of the forwarding party, as they generally control both the forwarding step and the receiving mailbox. There are several solutions:

Expensively — do not forward, but setup a mailing list or ARPA2 group
Hopefully — introduce SRS on all those (very cheap) forwarding service
Impossibly — disable SPF filtering on the receiving mailbox
Perfectly — add an exception to the SPF filter on the receiving mailbox

The last option is presented here, and puts the work in your mailbox, where there already is more complexity and a more commercial breadth. The exception is also surprisingly simple to implement, given that external identities are explicitly setup for each of the recipients:

When an email enters, lookup its envelope receiver
From its external identities, collect the external domain(s)
Mail may enter under SPF of those external domain(s)
Mail may enter under SPF of the envelope sender domain

Note how this allows refined SPF-bypassing for the case of email forwarding. All it requires is a mapping, setup by the user, to acknowledge forwarded email from an external identity to a receiving mailbox. Specifically, there are no IP addresses to be entered, all that is needed are the names of forwarded domains — and that ought to be within the user's grasp!

Also note that domain names may be learnt from user actions who train messages as not spam even though they overruled SPF due to forwarding. All in all, this could be a very user-friendly approach to making SPF function at full strength, with -all at its tail to reject anything out of the ordinary; anything but forwarded email, that is.

Do Try This At Home!

You can now:

Be sure to have SPF active on your forwarded domains
Use email forwarding from forwarded domains to mailboxes with Perfect SPF
Setup SPF on the forwarded domain to include the mailbox domain
Receive email in the mailbox or under a sub-box for an alias
You can now answer with the mailbox address or a forwarded address
You can now send from the mailbox domain or the forwarded domain

It is still valuable if email forwarding adapts, because not every forwarded mailbox will follow this Perfect SPF strategy, and we do still want to be able to couple everything to everything.

What this does is give more control to the end user. That is basically our thing and a task we take rather seriously.

What this can also do, is help to speed up the introduction of SPF in all corners of the Internet — well, at least in all corners that we care about. Spammers are perfectly welcome to reject the technology and end up sending mail among themselves, of course.

Email is currently somewhat instable as a result of spam filtering, and the state of SPF is that it cannot be enforced hard, upon entry. This means that it ends up in spam filtering, which also means that bounce messages are dropped. Such messages are a nuisance to the user when they occur, but it is much more of a nuisance when email gets silently discarded, as is currently the case.

Given that the mailbox owner can now take responsibility of email forwarding to his mailbox (and because email lists behave properly and need no special care), it is possible to make the filter in the mailbox behave more strictly than required by sender domains! And that may mean that hard bounces can be produced once more. Senders with faulty setups can correct their announced SPF settings, and generally the World is moving forwards. Perhaps most importantly, the user is enabled to tighten his control over spam in a way that is very direct, and easy to understand. Suddenly, it is valuable for end users to understand the game of mail, and play it by the rules!

Update 2017-08-28:

As indicated, SRS is useful but may be too much work for the cheapest of forwarding deals. Indeed, there are excellent solutions but they require intricate understanding of one's MTA, not always the thing one is waiting for, and return traffic may always be captured, which potentially increases traffic. For this reason, we launched our own SRSrelay that acts just as a bump in the wire, an MTA on the way out to the upstream/smarter MTA. This is easier to configure, and it can be used with any other MTA because it speaks the general SMTP protocol. It is also usable without an upstream MTA; in that case the mail can be made to loop back into the forwarder's MTA.

We believe SRS is powerful because it holds a hint that mail has been forwarded; the aforementioned settings on forwarding can in fact be automated recognising the =SRS beginning of an envelope MAIL FROM address, treating it as a hint of the original email address (no more than a hint, as the signature is too weak and we cannot verify it) and try sending a verification email through the originating service when the user indicates that this is indeed an originating address for the email. Note that the DKIM approach of comparing the From: header to the envelope MAIL FROM should work perfectly with this reconstituted address from SRS. Once the user agrees, we can even verify the path by sending a test email through the system, with a self-signed instruction to accept the forwarded route.

Even without SRS, it is possible to collect recurring discrepencies between From: headers and the envelope MAIL FROM address. When the same thing happens again and again, it is either spam or a sign of forwarding. A similar procedure can then be followed, through a suggestion to the user and a validating email sent to the address in the From: header. Whatever the output would become a pattern for spam-versus-ham detection. The trick now is to avoid doing this for every possible attacker; to remedy that, the request is best posted in a quarantine mail folder which the user occasionally scans for email that was falsely classified of being spam.

Update 2017-08-29:

Don't be a forwarder — be a transporter.

Email forwarding is usually a straightforward translation of incoming email addresses or domains into outgoing variants. The outgoing address appears on the envelope, but the email itself is unchanged.

As indicated, the best solution is to make the final receiving mailbox aware of additional email addresses that are acceptable to it. It is more difficult than one would expect when forwarding takes place, because the outgoing recipient address looks like the expected address.

Given that a mailbox service is aware of any aliases for its receiving accounts, it would be much simpler to distinguish that email for such an alternate account is entering the system. Especially when a few steps of forwarding are made before the email arrives at the mailbox.

It is therefore a service to the owner of the forwarded address and the mailbox to not translate to the mailbox address, but instead to retain the forwarded address as an envelope recipient.

The way this would work is, to say it is Postfix terms, to move from a virtual domain map to a transport. Definitions in /etc/postfix/virtual that looked like

@example.com        @example.org

are replaced with entries in /etc/postfix/transport that look like

example.com     smtp:example.org

This triggers the SMTP client for the given domain name, forwarding its entries to the MX for example.org without changing the envelope name.

As a variation, if user names are to be substituted, a virtual map

info@example.com    john@example.org

would stay in the same domain, to be transported as specified above, with the following virtual map for the name change within the domain:

info@example.com    john@example.com

Note that various email filters may be supportive of this scheme, if they allow alias domains. In such a setup, the example.com domain would simply be configured as an alias to the primary domain example.org.

The one thing that this leaves open is the potential of mail loops. If you transport the email to something that functions like an open relay, you may receive the email back that you just transported, when your server is defined as its MX. You should detect such loops and take proper action if you choose this model. This approach is really just firt for delivery to those mail box servers that actuall embrace email from such a primary MTA.

Mail Routing 1: Doing it Well and Not-So-Well

2017-08-16T00:00:00+02:00

When I give you a piece of paper with my (new) phone number, you have no reason to doubt its validity. When a mutual friend gives you my new phone number, you are will probably also accept it. But how about if a stranger gave you my new phone number? You would probably reject it, and you should.

This logic has not been built into the email system from its early onset. Only recently have we starting adding this, using a technology called SPF. The working principle of SPF is to look at an incoming email, and compare the (envelope) sender address to the address from which the email was submmitted. This address must be on a list of addresses permitted to send on behalf of the sender's domain name.

Simple enough, right? Nope.

Email Complexions

Email is an incredibly complicated system. It does things like forwarding, which means that a server receiving mail for info@example.org can forward it to john@example.com. The sender may be from an unrelated domain, and this sender is traditionally mentioned while the email is being forwarded. This means that the mail server for the final destination address john@example.com sees an email arriving from the mail server for info@example.org, but the original sender's domain may not be permitting the info@example.org server as its origin.

This can be remedied. A system known as SRS has been defined to replace the (envelope) sender address to fix this. This sender address is a legitimate address that stems from the forwarding mail server, but it is coded so that when a bounce occurs, the original sender can be recovered and the bounce can be relayed back there.

Most email lists use SRS or VERP (though not all, there is a lot of crap out there) and should therefore not run into problems with SPF, so lists usually work. But email forwarding is not commonly given an SRS treatment, and it is so common that it has to be dealt with. Somehow.

Killing You Softly

To handle these problems, SPF has what is called a soft-fail option. Under this option, a mail server that is not a legitimate sender for an email address can still try to forward to a mailbox that checks SPF.

If SPF were completely black-and-white, an incoming mail server could refuse to take an email in, causing to a bounce that informs the originator that something went wrong. Bounces hold valuable technical information, so aside from a nuisance to the sender it is also useful. More useful than dropping the email anyway!

SPF is designed to constrain the routes that email travels to a path through valid domain mail servers, and ideally it would be checked black-and-white and upon entry. This works before forwarding, but is guaranteed to fail after a forwarding step. So, when a mailbox takes in forwarded email, which is ought to be a deliberate choice by the owner of that mailbox, exemption of SPF checking for these forwarded addresses should apply, and an email should get in anyway. This is a pattern that we see more often: party A must be willing to surrender data to party B, but it only becomes reality when party B is willing to accept from party A.

But in spite of much of it being automated, the setup of forwarding is rarely this tidy. To compensate for that flaw, many sites have setup SPF with the soft-fail option. Meaning, SPF is not cut off hard at the entrance port, but it merges with the statistics of a spam filter. This makes SPF look like an approach for spam filting. Unfortunately, spam filters are rather unwilling to send feedback to the sender, and all of a sudden SPF becomes a puzzle. Moreover, it becomes a game of chance, because the other variables in spam analysis will very. So what we have now is a system that is setup in a flawed manner, and to compensate it we made email delivery a game of chance without any feedback. Could we have broken the system any more? Just imagine debugging that, especially when the remote is another owner's domain and possibly manned with unknowing users!

It is the softness that makes SPF unworkable. And it is the large networks that lead the way in breaking email by using it. One might say that they have a vested interest to guide users away from communication systems that span the Internet and into their own walled-garden systems; but it is more likely a matter of making peace by being conservative. Meanwhile this is breaking the email system as a whole, so end users should not want to put up with this level of conservatism.

To get specific about the current-day setups:

Gmail and HotMail specify SPF records for their domains, with ~all denoting soft-fail characteristics. As a result, email sent from these domains will not be fully reliable in reaching its targets.
Yahoo specifies SPF records for their domains, but has a ?all never-fail characteristic. The result of this is a complete absense of protection against people using the email addresses under this domain.

It is the small, technical-savvy domains that do better by setting a -all policy. They will specify hard restrictions on the mail servers that may claim their email addresses. But, in light of SPF being used so often under soft-fail conditions, it is often incorporated into spam filtering, with the result of bounces being hushed.

Luckily, the ARPA2 project that aims to make such techy-savvy systems available to normal end users.

The ARPA2 Solution

The ARPA2 solution to SPF strictness is simple; never use (envelope) sender addresses except those that are locally hosted.

A good example are the groups that we defined for ARPA2; we allow local and remote users to be members of a group, and a group can act like as a sort of implied mailing list. And if you need forwarding, you can define a group with (initially) just one member receiving the email.

So, how do we handle groups? Well, in a few stages, really.

When Carl sends to his group of weavers, he does so under his dedicated group member name. If the group is called weavers@example.com then his member name extends the local part, like in weavers+carl@example.com. Behind this member address is a remote or local address, an alias, or anything else; but as far as the group goes, all his email comes from weavers+carl@example.com.
Mail sent to the group and originating from Carl's underlying email address is modified to the weavers+carl@example.com member address, setting both the local part and the domain. This is done for envelope and header addresses alike, to provide some privacy to the member.
Since the email is to the weavers group, its members are now listed. The sender weavers+carl will be among the members found, but this one may be dropped. Other members like weavers+mary would remain as a recipient. So the mail is forwarded to any such addresses.
The envelope recipient address for member Mary is translated into her underlying address, which again may be a remote or local address, or alias, or whatever else. As an example, let's say that it is a remote address mary.mungool@example.net (note the different domain). The original group address remains in the email headers, which is good for replies, but Mary's own address is now an envelope recipient.
We now relay the email to the mail server for Mary's envelope address, so the one serving example.net; since Carl's envelope sender address is still tied to the local domain, there should be no problem with SPF. We can make a hard claim about SPF if we trust the recipient to not forward it any further — which is not strictly needed because other list members only see the member address weavers+mary@example.com anyway.
When Mary replies to Carl's mail, she may either send to weavers or to weavers+carl. The first case works just like described above; the direct email to Carl works almost the same, except for the expansion of the group, which is replaced with a lookup of Carl's underlying address.

Do Try This At Home!

A simpler form of this scheme can be setup in a Postfix mail server. It takes three steps to do this.

Virtual Group. Define a virtual email address for the group in your /etc/postfix/virtual file, and be sure it is named in the virtual_alias_maps. The contents for this example would be

# Envelope recipient map for weavers group
weavers@example.com  mary.mungool@example.net
                     carl.czorski@example.org

Individual Forwarding. When group members contact members on their member address, we should forward the traffic to the underlying address in the same virtual map with

# Envelope recipient map for weavers members
weavers+mary@example.com  mary.mungool@example.net
weavers+carl@example.com  carl.czorsky@example.org

Incoming mapping. The last thing we need to facilitate is the local handling of member's underlying addresses. This is done in the /etc/postfix/canonical file, which must be listed in the canonical_maps setting to activate

# Envelope and header map for weavers members
mary.mungool@example.net  weavers+mary@example.com
carl.czorski@example.org  weavers+carl@example.com

This allows group members to contact each other directly, at their respective group member addresses, going through the mail server that defines the corresponding domain name. It also allows them (and anyone else, if you don't add access control to the group address) to send to the address of the weavers group.

There, you've done it. You created a simple DIY email list, without getting in trouble with SPF.

On top of that, there is (some) privacy because the canonical map replaces all addresses; it must do that for the envelope sender address that will later be the envelope sender for an outgoing message from this mail server; it may do that for the envelope recipient since a virtual mapping will correct that later on; and it may do that for sender and recipient headers in light of their membership privacy. Do note however, that there will still be Received: headers and possibly more traces of the original addresses, so privacy is not complete.

There are some limitations; you cannot subscribe multiple addresses to more than one list, for example. Interestingly, we were not planning to do it anyway; we wanted a user alias for every membership for any group, so there would be a one-to-one translation between the user's idea of his identity, and the group's.

Another limitation is that replies to the list will lead to duplicates. These can be filtered out in a IMAP server or mail client, but it is better when they are avoided. That is not possible with this simple setup in Postfix, but the approach of a mailing list is to remove addresses also found in To: and Cc: headers after expansion of the group to its members.

Note that Postfix also won't let you filter access to the group to be constrained to just the group members. This is because none of Postfix's maps looks at the combined sender and recipient. Such things are all more advanced, and need to go into a content_filter with custom code.

Forwarding is a bit different, because it entails arbitrary senders. To make this work, you really should use SRS to change the sender address. There is no premade solution for this in Postfix, though a plugin for SRS can be used. Though not ideal, as it applies SRS to all traffic, it does at least do it in the cases where it is required — and probably does no harm in others.

We are hoping to, someday, see a Postfix setting smtp_forwarding_srs = yes to indicate that any forwarding done by Postfix, perhaps defined as sending from a domain that is not in mydestination or a similar variable, should make the SMTP client use SRS. A similar setting for LMTP may also be needed.

Dissecting TLS for Operational Flexibility

2017-08-15T00:00:00+02:00

This article is part of a series of articles about TLS.

TLS is the protocol that wraps around an insecure protocol and, through the "magic" of cryptography, adds authentication and application data privacy. And it is possible to understand how this can be dissected, even without knowing anything about cryptography.

Handshake and Bulk Traffic

There are two operational modes of concern in TLS, namely the handshake and bulk traffic handling. The handshake initiates TLS connections, and ensures the identity inasfar as desired, and establishes keys for use in the second phase. In the second phase, application data such as web traffic or mail exchange is carried under a cloak of encryption and origin-protection.

The first phase is complex, and has many variants. Handshakes are what typically drives an application developer mad, in terms of added complexity for his application. It is the core reason why we designed the TLS Pool to separate application logic from security logic.

The second phase is pretty mundane, and has a limited number of variants, which are usually covered by straigthforward libraries that map plaintext blocks to secure blocks, or vice versa. Although we initially made this part of the TLS Pool, it would be inefficient to pass this (potentially bulky) traffic through the TLS Pool, at least when it is a remote connection.

The handshake phase derives so-called "session key" material, which is the input to the second phase. A session key is just a small series of bits that serves as parameters to the bulk security mechanisms.

Splitting up TLS

The question is now, can we split TLS into these two independent kinds of activity? The answer is yes, as far as we can see now. And it brings great operational convenience to do so.

TLS happens to consist of four different flows:

Handshake, the cryptographic and complex derivation of a session key and cipher suite
Change Cipherspec, to indicate that a handshake outcome moves over to the application data level
Application data, the payload of the wrapped connection, protected with a session key for a certain cipher suite
Alerts, to indicate when things go wrong

These are just marked with a few bits in the protocol, and this can be used to direct one type of traffic one way, and another type another way. So indeed, it is possible to keep bulk handling local while passing the complex handshake to a backend module. As for the other two flows in the TLS protocol, we need to be a bit clever about those.

Operationally, this is very attractive:

The handshake is relatively slow and rare; passing it to a backend is not as troublesome as doing it for the bulk application data
When the handshake is passed into the backend, the ability to protect the long-term credentials involved improves
Backends for handshakes can be centrally configured and controlled, simplifying operations and maintenance
Bulk application handling nearby the application makes sense from an efficiency perspective
It is easy to have many nodes doing their own bulk TLS handling; only the handshake is easier to do central

So, what remains is the question what carrier protocol to use for sending TLS to the backend. And this is the cause of a second surprise, because this protocol already exists, more or less!

The EAP-TLS and EAP-TTLS protocols are designed to carry TLS handshake packets over an EAP connection, which is customarily passed over to a backend over Diameter or RADIUS. Specifically Diameter, when run over SCTP, is quite capable of passing over the semi-long fragments of TLS without the inconvenience of delays through added round-trip delay times. When large TLS fragments need to be sent over EAP with a smaller MTU, then extra such round-trips need to be added, which is a disadvantage to efficiency. Both the Diameter and RADIUS protocol are capable of multiplexing a large number of ongoing connections.

One concern that is not covered by this setup is EAP-TLS or EAP-TTLS for clients. This is a reasonably straightforward extension however. It can initially be implemented in software, and later specified in a simple document describing best current practices. When an end point can play both the client and server roles, it also ought to be able to handle Symmetric TLS which can be useful in peer-to-peer networks.

Redesigning the TLS Pool

This realisation will reflect on our design of the TLS Pool. We intend to make it remotely accessible over Diameter/EAP, and specifically for the handshake flow. The result of this negotiation will then be passed back to a calling application, which will continue with the negotiated cipher suite and session key, and take care of the modest chores of adding and removing the secure wrappers protecting the application data.

This is a redesign of the TLS Pool idea in the sense that the responsibility for application data now returns to the application. This is possible because all the complexity of dealing with TLS is in the handshake. And it makes sense because the application now does not need to make as many context switches.

The origin that made us find this innovation was precisely this wish — to be able to keep bulk session crypto in the application, while handing off the handshake to a TLS Pool component that may or may not run on the same host.

In many operational contexts, the connection between a front-end application and the TLS Pool in its backend will be connected by a considered-safe network, thus requiring no further encryption and/or authentication. But even when this is considered useful then it is possible to encrypt the entire Diameter/EAP backend connection, which is done once for all the upcoming handshakes and so no real delay. As for authentication, Diameter is quite capable of interrupting its flow and asking for a credential.

Comparing the privacy of HTTP and LDAP

2017-08-14T00:00:00+02:00

Most development these days focusses on HTTP, for which we already argued that it has deliberately poor semantics which is perfectly suitable for passing around documents as a whole, but that at the same time makes it less suitable for the data fragments of an average interactive website. The ARPA2 projects assume that domains publish credentials such as public keys in the dedicated data protocol LDAP, which is much better suited for the detailed inquiries for which it was designed and standardised. We now add a new reason, and that is one of privacy.

When we mention privacy in this article, we are talking about the client's privacy, so the aspect that is so obviously trodded on by many HTTP applications. We shall see that LDAP raises no concerns to this end. (And, just as a quick note, LDAP allows the server full control over the privacy of its data.)

Ingredients of Privacy Assaults

To be able to attack someone's privacy, a profile must be made, consisting of minute actions. Given this profile, all those seemingly unrelated bits of data can be related; if not on their own then by comparing with others to learn what sorts of interests cluster together. This is done with statistics, which means that the overlap between peers does not have to be perfect, but trends can be detected. Then, based on what your profile is missing relative to comparable ones, you can be adv(ert)ised to look at something new.

This is an automatic process. No human eyeballs are involved, or even needed. And, as a result you can expect downright blunt associations to be made for you. We all know the story of the girl who was presented baby-driven ads in a store before she even knew she was pregnant — much to the horror of her mother who joined her. A very embarrassing situation. And we may not all shop in such shouty stores that display advertisements based on your profile, but we all share our browser environments to friends who want to "quickly search for something". Imagine the embarrassment of them seeing a pattern in your ads that covers an interest that you don't care to share?

Advertisements are not alone. Police states have a habit of confiscating the information and using it to find a culprit. In doing so, they require access to masses of information, including the innocent majority. It is available, so hey, why not use it? And if citizens complain, there is always the marketing approach of pointing at an offense that nobody approves of (child abuse is a common one) and continue to follow these techniques for many other, and often far less agreeable purposes. As an example of what we are heading for: a photo of you with a glass of beer, not necessarily taken by you, matched with car tracking records that show you driving later at night. That's easier too, so why abandon that option if we also allow it to find heavier perpetrators?

What is Privacy, exactly?

Most people consider privacy as a black-or-white matter. In fact, there are at least three flavours of how you want your data dealt with:

Pertinent Privacy is where nobody knows a thing about you.
Need-to-know is where information is shared cautiously, and only when the need for the knowledge is understood.
Total Transparency is where everyone knows everything about you.

Most people see Pertinent Privacy as an impossible model on today's Internet, and accept the exact opposite approach of Total Transparency. Anyone who complains about privacy is considered to aim for Pertinent Privacy, and seen as out-of-this-world idealists. The reality is that the spreading of information on a Need-to-know basis is what we can all aim for, and achieve. In fact, privacy laws are written that way; they balance between what information must not pass hands and exceptions that are legally permitted. Usually, the permits include anything under consent.

Given the sketch of Privacy Assaults in the previous section, it should be clear that the market is pulling to one extreme, namely that of Total Transparency, while users who are given a choice would opt for Pertinent Privacy. It is vital about any Privacy debate that this is like a contest of rope-pulling, and that the only viable answer lies in the middle, with the Need-to-know. This is why you are asked for your consent in matters of privacy.

It is good to realise that these are actual choices you can consider. You do not need to agree to things you don't like, because there are always others offering the same, or other sites announcing the same information, but under better conditions. You get to choose, and this is precisely how the market mechanism works; vendors get the choice of what they offer and under what conditions, but as a customer you get to choose from the many offerings. When you make selections on the way you are being dealt with part of your online behaviour, then you are helping the Internet mature, simply by selecting those vendors that you agree with.

A few simple starters that may help are browser plugins; the next section gives you the reasons for wanting them:

Privacy Plugins will remove content from pages that assault your behaviour
Ad Blockers stop advertisements from being downloaded and shown
Terms Summaries can help you to quickly skim through the conditions for a site; you can use this and maybe add an occasional site to the database
Browsers made by large-scale ad-sellers raise questions

How HTTP can Attack your Privacy

To build a profile, one needs two ingredients, namely bits and pieces of data (or terms used to search for them) and some way to identify you in a (more or less) unique manner. The pieces of data cannot be avoided, because that is usually what the entire exchange is about. But the identity is the place where you have some control.

Such identities can sit in many places:

URLs may have resource paths that include long codes, often including your identity.
Cookies may be set by a site, and your browser spoons them out when you return.
An account under which you logged in. This is why most Facebook content is invisible to outsiders (and closing networks is the clearest sign of having only the server side of interests at heart).
Browsers send a lot of information on their version, platform and so on; taken together, this identifies most browsers uniquely. (Yes, that one surprised me too.)
JavaScript is free to do anything, and may use localStorage where cookies are banned.

The power of the web is that it combines resources from all over the place; the privacy downside of this model is that it can spill your identity all over the place as well. Advertising and tracing networks tend to serve many sites at the same time, and they can offer behavioural tracing to sites that adds are lured to those services ("321 unique users online"), but some of these networks can also combine your behaviour across the many sites that take out their services. Quite a powerful mechanism to collect profiles.

Ways of stripping these unwanted identities that trace you include:

Use a Privacy Plugin and Ad Blocker in your browser to strip known tracking facilities. Enjoy being part of their network and consider what you can do back for them.
Use your browser's privacy mode.
Have multiple browser profiles or separate accounts for separate uses.
Sites with popups that make the content unreadable are not just a nuisance, they also mostly have a motive of tracking you; is it an important site to you, or just another search result? If you don't like it, get out. Excessive profiling will hopefully teach them that they are a nuisance.

Some sites complain that they can't live without advertisements. One of the ideas behind InternetWide is that the cost of publishing information and even services online is so incredibly low that this should not be a true concern to anyone. We should however move to a model where services can earn money for what they offer. And in that respect we see many, many clever starters that do it in a lovely way; free entrance-level service paid for by those who require a higher standard of service for which they are willing to pay. In terms of individual online presence, we believe that owning your own domain name offers you your vital square on the block, and the ability to publish information comes along with it for free.

How LDAP does not Attack your Privacy

Compared to HTTP, the LDAP protocol is much more the work of a technician who just wanted a good representation of data queries across networks. It also is a lot more tight in its specifications.

You should not ask LDAP for a large document, but you can ask it for the data describing a person, or any other resource, with given attributes that are known. It will then search the database and come up with the matching objects.

The representation of an LDAP client is very, very boring; it does not state what make, brand or version it is, let alone the platform on which it runs. It just states what version of the generic protocol it uses, which has been 3 for over ten years now, and probably many years to come.

Attributes have values and even a type that may be varied, could we put an identity in there? Well, the values are usually needed for processing, so that would look odd. And their types come from an extendable base, but applications will only process the ones they recognise. Neither of these stand a chance of being reflected to the server, where they could help to build a profile of the user.

Locations of data are another matter. In many cases, these are considered to be readable to the user, but as in HTTP, that is no longer the case. This means that references may be traceable. What is not possible however, is to start a trace with an identity setup in a prior phase, so the only form of tracing possible is "will an application follow a link from A to B or leave it alone?" — pretty much the usage patterns that may be of benefit to operators of the data store, but it will be too fragmented to be of use to profile users. There certainly is no way of linking the various sessions that a user has with different sites, again with the one exception of references between them.

Access to LDAP can be subjected to authentication. And indeed, when this is done, the user's behaviour can be traced. This is in fact always true for any protocol; it needs to connect a query to an account and so to the potential of tracing behaviour; that is in general unstoppable.

This problem worsens when the same identity is used in many places, because then all of a sudden it is possible for these places to get together, inasfar as permitted by law, and combine information from various sources. This would have been a weak point for our Bring Your Own IDentity policy, where the client determines an identity to be used on any service they approach; but this is why we also introduced pseudonyms and aliases and the automatic change of identities when crossing over realm boundaries.

Since profiles need to combine data to a form of user identity, it seems that LDAP is the winner from this perspective as well as from its much greater semantics; delving into LDAP for data avoids that this data can be lined up in a profile.

This can still be broken when HTTP references LDAP for data; it could generate paths to objects in LDAP that contain a unique identifier. At the risk of repeating ourselves, this is only possible when downloading complete applications in the form of JavaScript or an App, which is required when applications go beyond open protocols, as is the case with virtually all "web wrappers" for protocols that have independent stand-alone implementations that can do their specific task more aptly.

Conclusion

Once again, we learn that HTTP is a very potent tool due to its general nature, but that this also leads to problems. It is invariably better to rely on specialsed open protocols such as, in this case, LDAP as the only protocol for refined access to data stored remotely. A bit to our own surprise, it turns out that this is also true where privacy is a concern (which it ought to be in every situation where we cross over our realm boundaries).

Using SASL with HTTP, Mail and LDAP in Nginx

2017-07-18T00:00:00+02:00

Our ideas about identity our nicely shaping up, and prove to bring great benefits of control to users, such as aliases and groups and Bring Your Own IDentity through our work on Realm Crossover. But in the end, our architecture needs services to actually be beneficial to users. So what does it take to get there?

HTTP in need of SASL Auth

Most applications these days are web applications. Its popularity has led to many innovations, but surprisingly authentication mechanisms have been notoriously weak. So weak even, that we end up putting it into the website itself, as part of an application. Even if application programmers are not the least bit interested in authentication issues, and can think of little more than a username/password scheme. With credentials stored in the same unprotected database as their application data.

But wait — these applications tend to use JavaScript. Its code is downloaded from all over the place, and often includes behavioural trackers and advertisements with dubious intentions. How can we mix that with something as vital to protect as authentication?

The best approach is to perform authentication in a level below that which is controlled by the application. In web applications, that means either HTTP or TLS.

The standard answer is to use TLS with an X.509 client certificate. This introduces a lot of confusing work to the client, and is therefore only used in practice where it can be enforced — in corporate environments.

There is an option at the HTTP level as well, namely Kerberos authentication. That does require user settings and, again, being part of an infrastructure that is common in commercial environments but does not include regular users.

Most HTTP authentication applications come down to password authentication, simply because it is the lowest common denominator that is accessible to all. Even though the InternetWide Architecture aims to make both forms more readily available, it is unfair to assume that everyone will adapt. And so, it is not reasonable to expect web site builders to restrict their access to only those who comply with the X.509 or Kerberos profiles. But an important choice has been missing all along in HTTP; one that email tools have adopted, but that is somehow escaping the web, and that is to offer a choice by using a generic protocol that allows the user to select a form of authentication. Once embedded in the HTTP layer, this should work out to support both private and corporate usage patterns, especially if there already is software handling all this.

Such a protocol exists, and it is known as SASL. In fact, this is not a protocol in itself, but merely a description of a request/response interaction between a client and server to authenticate the client. This general pattern can be embedded in most protocols, and this is actually done all over the place: email protocols SMTP, POP3 and IMAP have it, data exchange protocol LDAP has it, chat protocol XMPP does it, and we could go on with a long list of useful protocols that you may not even have heard of. But HTTP, somehow, is still lacking SASL.

And there's so much to be had — most importantly, off-loading of authentication to SASL backends, possibly the same for all front-end protocols. It may include X.509 certificates, OpenPGP keys and Secure Remote Passwords through the EXTERNAL method; it may include GSS-API and so Kerberos5 single-signon through the GSSAPI method. And in all these cases the application programmer does not need skills; it is up to the operator to relay the SASL messages to a backend.

Adding SASL to HTTP should not be very difficult though. The HTTP Auth workgroup is in favour, as it is just another plugin for the general methods for authentication in the HTTP protocol. It just needs to be defined. And to do that, it needs to be built.

Expanding Nginx with SASL and LDAP

We believe that Nginx can benefit greatly from the inclusion of SASL support, first in a generic sense and then applied to HTTP. So it looks like the perfect engine to test these ideas on. This is a block diagram (that is not as daunting as it may look):

In the middle, we find a generic SASL block as a central switchpoint. This is an internal API over which the general SASL protocol would be switched.

Then there are backends. HTTP SASL is one over which the generic requests could be forwarded to a backend; a common alternative is LDAP, which wraps it into its authentication request. Plus, there might be a database with the various credentials, pretty much like a .htpasswd file; but that might be less in line with the Nginx style of being a proxy, rather than an endpoint.

An interesting backend type that could be supported, is to run SASL over EAP, which in turn travels over Diameter or its less-aligned predecessor RADIUS. Although EAP-SASL has not been defined yet, the recent uptake of network access as a user service (through VPN technology) indicates that reuse of user credentials for such "lower" uses is of more use to end users than it originally was when EAP was primarily the mechanism for network bootstrapping.

To the front, we see many ways of using the generic SASL block. The proposed HTTP SASL Auth extension is one, but did you know that Nginx also supports mail through proxies for SMTP, POP3 and IMAP? These stand to gain a lot from this backend, because the current implementation runs challenge/response interactions of SASL with a fixed challenge — which is a technical way of saying that the security is reduced to the level of a fixed password. In fact, sysops are aware that challenge/response cannot be replayed, unlike passwords, and many systems have default configurations to reject password authentication over unencrypted links, but not challenge/response — which demonstrates a true problem with current Nginx. But all that is needed to make Nginx as secure as its mechanisms claim it to be is to make hooks in the mail proxies linking them to the generic SASL block.

Nginx should support LDAP

We also believe that Nginx is a perfect proxy for use with LDAP. We believe that this protocol is a perfect carrier for public credentials, as well as contact data and even documents. We rely on it for X.509 certificates, PGP key service, and for publishing data including as the index for our Reservoir component.

We don't rely on LDAP for light-headed reasons. Its standardisation is of extremely high quality, including many standard attributes but also an ability for independent parties to add their own, without ever clashing into others, and when published it is open for anyone to adopt, without risk of misinterpretation. Wow.

On top of that, it is an efficient protocol for searching and storing small pieces of data, such as metadata to the Reservoir pointing into its object store; such as certificates and public keys for identity purposes. And, perhaps most importantly, it is a domain service, which means that you can run your own and represent everything you intend to share as structured data, rather than the loose, manually retrieved information found on most of the web. Although HTTP is attempting to define its way into structured data as well, it is inherently less suitable, and will therefore never achieve the same quality level as LDAP. In practice, the web world has a habit of inventing proprietary protocols for searching and passing data, but rarely with the broad and refined semantics that LDAP offers — on top of it being an open standard that does not demand code from the same vendor on both ends.

So, with that out of the way, why is Nginx such a good idea for LDAP? Well, as with HTTP you can have clients lurking for a long time, so pooling backend connections is a clever idea. And the model of "stripping off" the protective outer layers of TLS and SASL make Nginx into a gateway into a protected backend network, it becomes possible to mix connections by including a proxied authorisation control in forwarded LDAP request messages.

The code to handle LDAP for this purpose has already been made in our project, and is called LillyDAP. This is an efficient, flexible, pluggable framework for procesing and sending LDAP and making small changes to it while in transit. It was coded in the style of Nginx and we believe that integrating it into Nginx can greatly benefit the power of this lovely proxy.

Coding it as Open Source

We want to make this an open source project, as always. And we aim for integration of this work into the Nginx mainstream distribution. Given the many advantages that it has for Nginx, we believe it to be a valuable contribution to this wonderful proxy.

Are you interested in extending our team with your experience of Nginx internals? Then please contact us!

NGI 3: Own your IDentity

2017-07-16T20:00:00+02:00

This is part of a series of technical articles in response to the European Commission's initiative to explore the Next Generation Internet, an initiative that we warm-heartedly support.

We all use a variety of online services, and for quite a few of them we need to have a name, so we may access our own data and/or communicate with others using their name. Naming, more formally known as identity, is one of the most potent ways in which you can be yourself on the Internet — and it's one of the most neglected ones.

Have a look at your email address. It takes a general form user@domain.name where user is your name within the "name scope" of domain.name, which in turn is unique within the Internet at any given time. United in this everyday form, they represent a globally unique identity that you hold on the confusing and obstinate network that we all love so dearly. In comparison to your real-life name, you might compare domain.name to your family, and user would be your first name within that family.

You may have had some freedom what user part you got, but in the end it is determined by the administrative staff of domain.name — and it is there prerogative how long you may use that name. Many users have their email address under the domain.name of their connectivity provider for the Internet, most others use a generic provider such as Google or Yahoo.

Both are sub-optimal because you lack control. When your email address is held by a connectivity provider, you cannot count on keeping it when you change to another provider. The generic online providers are not problematic in that way, but they may change their privacy policies, or do other things that you don't like and then you have no way out without loss of your email address. Your email adress is never really yours with any of these providers.

Other services don't even use standard protocols; this is mostly the case with enclosed applications, usually available only over the web protocol HTTP. These services tend to provide you with only a user part because the domain.name part is sort-of implied — you cannot use their service except through their web interface. Facebook is an common example of this. Again, you are dependent on their behaviour where your privacy and online presence are concerned.

The way out is incredibly straightforward, though it takes some technical issues (of the kind that our InternetWide Architecture is designed to resolve in due course). The basic steps are:

Get your own domain name; it's cheap and not really difficult
Create users (and variations) at will, as you would for your new-born baby
Stick to open protocols

The result? If you have obtained example.com then you and you alone get to control its user names. So you can create john@example.com if you want to, but you might as well choose john+amazon@example.com as a special address to register with Amazon, to treat specially and to retract if it turned out that they were spamming you. In short, you now own your identity and you shall own it for as long as you renew the domain name.

As for standard protocols, you can use email with most providers today. That is perhaps the most important. If you look around, you may find one that offers XMPP (aka Jabber) service for chat, and if not you can purchase it separately for a modest amount of money. You have just set yourself up for a cost of around € 25 a year to pay for a domain name, email, web and XMPP chat service, but in return you are controlling the parties that provide these services instead of them controlling you. You have no need to accept the marketing ploys that were oozing over your eye balls.

Your friends may be a bit surprised, but already have multiple interfaces to the various lock-in platforms chosen by their friends. If they question your introduction of yet another one, you might explain that this is the one that is there to last — it is not a commercial whim, swayed by popularity or the need to have a large critical mass to hold on to investors, but that this is an open protocol that you control, and to which anyone can connect from their own domain.name, using the tools of their choice. This is the marvel that we have come to expect from email, but somehow we never demanded the same for chat and many other "lock-in" applications in a shiny web outfit or site-specific App.

In they wanted, you could provision your friends with their own identity under your domain, thus welcoming mary@example.com as your co-user. At least that will get your friends away from unpredictable forces; but it may be even better if they follow your example and pursue their own domain.

So, can you now do everything with this new-found identity? Well, yes and no. Many things will work for you, as long as you stick to the rich diet of open protocols. Examples are XMPP for chat, SIP for telephony, and of course SMTP for email and HTTP for your website. Let's be clear about what that can do to your online presence:

For normal email, you will be john@example.com
For XMPP chat, you will be john@example.com
For SIP telephony, you will be john@example.com
On the web, you can be john@example.com

And if we have it our way, you will be a lot more to a lot of other people as well. A few fundamental things that we are working towards in the InternetWide Project are these invaluable assets that today's Internet really needs in support of the aforementioned scenario's:

Strong security for your identity john@example.com
Single sign-on, meaning you logon only once a day (already covered)
Ability to use your logon with non-web protocols (already covered)
Ability to use your logon in other realms as your identity (realm crossover)
Ability to use your logon on the web (the worst-ever security protocol)
Ability to publish credentials and public keys for secure communication

Are you interested? Then go ahead, and register a domain name! It isn't expensive and you will learn many new things, plus you will gradually improve your control over your own identity. You are welcome to follow us or, even better, support us. We collect funds without strings attached, and set up projects that implement things like mentioned above. We are generally said to be highly innovative, surprising and moving in a really important direction — so important in fact, that we usually hear our peers say that we are doing what they hold to be important, yet lack a way of arranging in their own working habitat. And that's us all over; we are here to serve the Internet and its users.

NGI 2: The poverty of HTTP

2017-07-16T16:00:00+02:00

This is part of a series of technical articles in response to the European Commission's initiative to explore the Next Generation Internet, an initiative that we warm-heartedly support.

Most of the things we do online run over HTTP, aka "the web". We tend to think of this as a properly standardised protocol. In reality, this is only true in a very limited sense; HTTP is at its heart a protocol for pushing and pulling documents from remote locations, lardered with little more than a MIME-type, filename and language.

Contrast that with the modern tendency to pass all sorts of data over HTTP, including dynamic data. We use representations like XML and JSON, and pull it all together with a lovely JavaScript application.

This model is poor in many ways, and leads to problems that are a testament to the use of an unsuitable protocol; but problems have been patched with things like WebSockets and HTTP Events to keep it afloat. But at its heart, HTTP is not suitable for much it is made out to be today. Or has anyone spotted offline webmail reading, cross-site integration of travel booking, and editing local files?

Let's start with JavaScript. This allows us to run applications straight into our browser. Though this saves us from installing a real application on our system, it also disables that in many cases. JavaScript is basically a custom-made wrapper for undefined data. That is what you start doing when there is no specification to work on. Document push/pull is so abstract that many details need to filled in to make it into, say, a chat application. Notwithstanding the fact that actual chat applications are available everywhere, people are eager to rebuild it over HTTP, and end up being incompatible with the other chat applications that already existed. The entrance is zero-effort, but the price comes in terms of communication freedom.

Shrink-wrapping data with code can also be seen as a way to circumvent proper specification of the data. And that is expensive for users — it means that they cannot use their own software to operate on the data; not unless they are willing to figure it all out by themselves, and risk future breakage when the data format changes. The end result is that web-based access to whatever data source leads to one-sided automation which is prevented when properly specified and purpose-specific protocols are used. Since HTTP is not specific to the purpose at hand, it should not be used for everything. HTTP is as good a tool as any hammer, but not everything is a nail; there are no one-size-fits-all protocols.

There are many counter-examples, all of which are being tried over HTTP and all of which have led to problems; these problems have been addressed in a somewhat generic manner, and still less useful than anything purpose-specific:

chat is best done using XMPP or the older IRC protocols (problem: HTTP pulls documents, but messages may need to be pushed downstream)
telephony, with or without video, works best over SIP (problem: realtime traffic is best sent outside of connections like the one HTTP maintains)
data is best passed over LDAP (problem: data definitions and syntaxes are local and undefined when using JSON)

JavaScript is a very, very dangerous innovation. It made HTTP the generic application wrapper that it is today, but precisely that generic nature makes it damaging to its users. Advertisements can have adverse effects on privacy (think keyboard tapping), cross-site scripting leads to many security shocks but is nonetheless hallowed for its usefulness in enabling certain new tricks — as if opening up generic holes does not come with the responsibility of guarding what else comes through it.

And yet, a powerful movement drives more and more facilities into JavaScript, including sensitive ones. But this is a platform where anyone can run code and where the average session includes a few sources that do not have the best interest of the user at heart, be it advertisements or the website's pick of behavioural tracking.

It is already common to handle credentials in JavaScript, and a new movement is even trying to play key material into the hands of the platform. In general, keys and passwords as well as your local files are the sort of information that should never land in foreign and unverified hands and yet this is exactly what we are doing. Why, I wonder? In the case of credentials it is an attest to the poverty of HTTP authentication, but we'll talk about that in a separate posting.

WebSockets were invented to allow applications, written in JavaScript and running in a browser, to access "real" protocols through an indirection over HTTP. Not only does this introduce potential problems with HTTP itself, it also misses out on useful configuration hints that may be present in DNS (but wrapping the knowledge into code "solves" that — locally).

There is a growing tendency to specify APIs on top of HTTP. This does indeed address the lack of specification that stems from HTTP's generic nature; at least when properly worked out. But it comes loaded with the properties of HTTP, which are not always advantageous:

the need to escape characters
the requirement to parse with a security mindset
lacking reasonable support for binary strings
the unnecessarily strict request/response lockstep
a very low threshold, possibly leading to lower quality specifications
open to "not invented here" variety: incompatibility without a need
very often, localisation of a service is not standardised

The problem of localisation of a service has more impact than one may expect on first sight. It is not easy, for example, to use identities under one's own control (like when using one's own domain name) and announce the interface that we currently rely on for HTTP-based communication, which may change when, say, a user agreement changes to our disadvantage. The generic nature of HTTP and its resulting versatility makes it unlikely that such facilities will indeed be made generally available; but localisation facilities have been defined for most purpose-specific protocols. This is usually done through DNS records, which are relatively easy to define given full awareness of the purpose at hand.

The HTTP approach to the localisation problem is simply to have one "central" service and use it for the whole World. This leads to centralisation of the Internet and its protocols, which is generally bad for users and their privacy; their communications now belong to the website owner, and it is usually not possible to escape without breaking communication bonds. Though HTTP may be pleasant as a wrapper for special purposes, it is easily beaten by the higher level of automation and retained control of purpose-specific protocol implementations. This control over one's own communication usually does not cease when using a large-scale deployer, simply because that is not how purpose-specific protocols are designed; they are supportive of large-scale hosting, but not to selling one's soul.

In conclusion, HTTP is a powerful tool to exchange documents as-is, but it is generic in nature. This is perfect for that level of abstraction, but it turns into poverty when we try to stretch the model beyond its capacities. Even though it has been put on steroids with many new extensions, these too are kept general where specificity would be desired, and at the same time it can be too specific to capture a protocol's requirements well. The tendency to abandon purpose-specific protocols for hacks on top of HTTP is not a sign of proper engineering.

NGI 1: IPv4 is Killing Progress

2017-07-16T11:00:00+02:00

This is part of a series of technical articles in response to the European Commission's initiative to explore the Next Generation Internet, an initiative that we warm-heartedly support.

Among the many concerns that protocol innovation faces is the reality of having to deal with NAT routers. This is fundamentally more difficult than dealing with a firewall, in a way that blocks progress.

A good example of this is the ability of peers to connect directly. Crossing through firewalls is easy enough when the peers intend to collaborate, but the added complexity of a different public address/port from what is used internally, and specifically the inability to know for certain how things are mapped make it impossible to make such peer connections.

As a result of this, we see many applications fail. Passing a document over to a collegue on another network, for example. Or simply conducting a phone call or chat session directly over the Internet. Other application protocols are conceptualised but fail in the design phase, on grounds of "shifty" remote addresses/ports. All these things are blocked by the NAT concept, and therefore, by the over-extended life of IPv4.

One of the direct results is that all protocols in use today are client-server protocols. Meaning, someone with better technical equipment than an end-user places a server online, and all communication must pass through their systems. This cannot be done without gaining something in return; too often, this ends up in perverted privacy. End users have no choice but to live with that. Had protocols been more able to run directly between peers, as is the case when IPv6 can be counted on, then this assault to one's privacy could be resolved by more direct communication patterns, including peer-to-peer.

As soon as IPv6 is introduced, these clouded skies clear up. No more NAT means transparent addressing and no more "shifty" remote addresses/ports. The freedom that this brings to protocol designers is incredible, and true innovation can be expected once we get on with IPv6.

But IPv6 is not sufficiently sexy to catch the public attention. That is because the change is not noticable at the user level; and that is caused by a catch-22 situation where applications don't count on IPv6 because it isn't there, and it isn't there because applications don't count on it. Also, IPv6 only works when it is available on two sides, so one-sided investment in the extra work barely pays off; certainly not in general. All this holds back the development of new protocols that are vital for a healthy Internet, where users are better able to sever the bonds of online service providers. In short, the only way for this long-overdue update to the Internet if vital parties like the European governments stand up and start requiring it from anyone who deals with them.

It is possible to have IPv6 anywhere. It is a matter of getting enough critical mass, of making it a necessity on the Internet. Then, options exist, including the work we've done in the Peer-to-Peer Toolkit and for which an SIDNfonds innovation budget was awarded. Specifically, the 6bed4 tunnel is a European design that does what Microsoft's Teredo wanted to do but at which it failed utterly: to enable IPv6 on every machine on the planet. Unlike Teredo connections, 6bed4 can be relied upon to connect IPv6 everywhere.

The time is here to activate the move away from IPv4, and the road is simply making it a requirement. My proposal is the following:

All new ICT deliveries to the governments of Europe and its member states must support IPv6; products failing to do so will be phased out over a period of five years;
In the year following these five years, all European governments completely shut down their use of IPv4. Without remorse. This means becoming IPv6-only, through removal of backward compatibility with IPv4 from public-facing servers, of course including for web and email.

Such bold action, requiring all others to follow suit, forces the rest of the market to follow. This appears to be the only way to bootstrap the long-overdue transition to IPv6, and reduce the protocol headaches of IPv4 mere remnants of the past. Citizens throughout Europe, and probably far beyond, will recognise the need to facilitate IPv6 to be compatible with European governments; technical facilitators will find their customers demanding it. Protocol developers can now focus on an Internet that enables new protocols and once more experience a functional Internet. This way, Europe quite literally leads the way towards the Next Generation Internet!

The period of 5 years is based on the time it takes to replace devices. Device manufacturers and Internet Providers have long known that they should prepare for IPv6. Nevertheless, homes and offices may now still contain devices such as printers that need to be updated, for which 5 years is a reasonable and pragmatic time (because devices rarely live longer). It is even more than reasonable, as the message to upgrade to IPv6-capabilities has been sent for many years already.

The only thing needed now is a switch, which the free market clearly is not organising on its own. And this is where an important, large enough usage base should take the lead. Who should do that? It is not likely to be commercial businesses. The only party truly empowered here is the collective government infrastructure of Europe and its member states.

I expect an outcry from some Internet Providers about this -- but there is no need, there are many ways in which they can change over in the coming 5 years, it has all been shown to work by the few pioneers. Mobile networks too have developed the technology, it simply needs to be switched on. But outcries will come, and they will originate from precisely those Internet Providers that have been ignorant of this innovation that has been hoping for free-choice adoption for years; this freedom to hold back the Internet will indeed be taken away, because it is impairing the health of the Internet. Complainers are a sign of the stagnation that landed us with NAT, and they should be frowned upon, rather than supported in their stifling lack of action.

IdentityHub: Built with Blocks

2017-05-03T16:08:25+02:00

As described before, we have a schema with blocks that each fulfil a certain purpose. Making it easy to run such components will help a great deal to get hosters to accomplish the transition to this new service style. Also on our minds, these hosters are going to desire their own ways of setting up these services, in ways that we cannot and intentionally will not predict.

Docking into Containers

It is now common practice to build functional units in a container, and the most renowned technology for doing so is Docker. Though the most straightforward implementation is founded on Linux Containers (LXC), a Docker container can in fact be run on a plethora of platforms.

Docker further comes in two versions to suit everyone's needs; both a free Community Edition and a supported Enterprise Edition exist. We love this model; it means that business can be treated with knowledgeable support desks, but nobody is forced to pay for free replication of software for which they assume no human support framework. Moreover, having a business plan to back it is perhaps the best model for avid development and maintenance of free/open software.

Our current intention is to take each of the blocks in the block diagram below, and publish them as individual Docker containers. There will likely be versions with alpha, beta and RC level software.

Each their Own

We have explicit intentions of allowing users to run one or a few components under their own control. Some might want to do this for their PKCS #11 key store, for example. Others may cringe from the thought that someone else might get to manage their Kerberos Realm Controller.

When each block becomes a Docker Container, they already have the potence of being highly pluggable. What remains is a communication standard between them.

We were incredibly pleased to learn that Docker runs on Raspberry Pi, on C.H.I.P. and quite a few other embedded platforms. This means that we have an option to build Docker Containers for these platforms, and that users can even have implement them at home.

This embedded Docker system is founded on Raspbian, which isn't too far off of our development target platform, which is Debian, so the usual glitches that occur during transitioning to an embedded setup may not be as hard as they sometimes are.

Most interestingly, running these components as Docker Containers also means that the home user can still run his components for home automation (say) on the same machine! Plus, they would be able to hack around and make adaptions to the IdentityHub home kit. Hopefully with the intention to share ;-)

Messaging between Containers

As long as Docker Containers run at the permises of a hosting provider, without links to other players, it stands to reason that they trust each other on face value. This is a fair assumption when the network is protected by firewall and bridge ACLs, with monitoring and so on. So the link between components run on-site should be efficient, and probably not go through the hassle of authentication and encryption.

Remote components from users are a different matter, of course. We are talking about identity and the keys that represent them, which implies that we really must employ authenticated connections with message authentication codes. In addition, the information tends to be private, so we must employ encryption. So, between two sites we shall insist on a protection layer. Specifically, we shall use a GSS-API protection layer, and specifically the Kerberos5 mechanism.

Then there is the messaging system itself. We will not design one ourselves, but instead use AMQP 1.0 (or see the video), which is an OASIS standard — meaning, it is an open specification, therefore interoperable. And as may be expected, it has been implemented in various open source packages. As you may have guessed, AMQP can be wrapped in a GSS-API protection layer in a well-specified manner.

The first task at hand in the design of the IdentityHub will be to standardise on messaging formats, the queues between the various Docker Containers implementing IdentityHub components, and then we can start building.

Update 17-7-2017: The most beneficial part of AMQP is that it allows queues to stay erect while the components around it go down. This means that the components are not coupled too tightly, and that work can go on in the face of temporary downtime of some components.

While this may apply to batch processes (like creating key material and entering new data in the directory) the same is not true for live and interactive exchanges. Especially authentication and authorisation seem to demand more direct responses. In these cases, we fall back on SCTP, as that is a reliable, message-based protocol. It has many of the facilities of AMQP, but is more tightly coupled and this is just what is required for interactive traffic.

Identity 9: Phone Numbers are User Identities

2016-12-30T16:34:52+01:00

Identities do not always look like email addresses, even though these are the simplest form on the Internet. Other identities could be ISBN numbers, EAN and other barcodes, and of course, phone numbers.

We hereby present how phone numbers can be interpreted under the InternetWide Architecture as a form of identity, thereby helping their owners bootstrap a simple form of online presence that they are likely to expand to a point where they desire to have their own domain name.

Still, phone numbers can provide an ideal first step on the online scene. A few technologies are highly attractive to bring together:

ENUM is a representation of phone numbers in DNS, where it looks like a (funny sort of) domain name. A number like +12345 would look like 5.4.3.2.1.e164.arpa in terms of DNS, so let's try to never type that!
XMPP is the standardised chat technology that has also been pulled in by Google, Facebook and WhatsApp. There is no reason however, to keep chat constrained to isolated islands, and indeed, people who run their own chat service connect all over the World. Would be nice to do that with a phone number too, right?
MMS can be easily submitted (at data transfer cost only) to your XMPP infrastructure.
Having the Object Store from the IdentityHub under your phone number can help you share photos, videos and so on. Yes, your phone number has just been redefined as a personal cloud store!
Having the ability to construct groups and other users under your phone number means that you can setup chat groups that you can share with your friends.

In fact, there is a lot more possible. It all starts with this one identity that gets you going.

Phone Numbers are like Domain Names

As shown, a phone number is transformed into a silly-looking DNS name. You will not want to type that continually, but it really is not much to show that in a nicer way to you in the domain management interface of the IdentityHub. So you can just add your phone number instead of a domain name. All you need to know is to use the + notation, whose first digits are the country code. For example, a Dutch mobile phone number would start with +316. There is no restriction in adding landline numbers as well, by the way.

Aside from being usable as a normal domain name, you can also add a few special things that announce services; for example, a reference can be made from the domain to the XMPP chat server, an SMS and MMS redirection record may be added (servicing those who understand where to find it, so basically other online users like you). And there is room for much more -- including even a so-called directory server, which you can use as a reverse phone book.

Phone Numbers are like User Names

We will take the habit of defining the phone number (after stripping the leading + symbol) as a user name as well. So, if your phone number is +12345 then your identity looks like 12345@5.4.3.2.1.e164.arpa -- a bit silly. Once again, that's just cosmetics. You are free to use other user names, but might then confuse people, so you probably shouldn't.

Adding Services

You can also add other phone numbers as local aliases of their own phone numbers in the same silly format; this would mean that your friends could use your domain, and your online services, as long as they come from their funny-phone domain.

With multiple users, it is now becoming interesting to form groups. And you guessed it, these groups can now start to setup conference discussions.

The technology can be used for much more. If you choose a smart-enough client on your phone, you may be able to make voice calls and perhaps even video calls. And yes, there are a few conferencing facilities that you will probably be able to plug into your phone-number domain in a later stage of our project. Most of the technology relies on clever client Apps and fairly simplistic servers, so you should get your hopes up!

You are Free

Perhaps most importantly, XMPP technology will set you free. You are no longer confined to the locked-down services of the few large players. You can connect to people who never locked themselves into these silo chat services, but who use their email address for chat. And yes, you can talk with them too.

Welcome in the free world!

Image credit: Harry van Rein, a retired telecoms engineer who still keeps this phone operational.

Identity 8: 1+1=2 Authorisation Mechanisms

2016-12-30T11:32:50+01:00

During the SecureHub phase, we settled on a number of authentication mechanisms, notably the TLS-KDH mechanism that we built into our TLS Pool so it would be incredibly easy to use. We also started off on realm crossover and are following up on that in the next project phase, IdentityHub.

Authorisation is an entirely different matter than authentication. Once we are handed reliably validated remote identities, what can we do to assure desired access is granted? As it turns out, there are two kinds of authorisation in the InternetWide Architecture to deal with.

Authorisation for Resource Access

This is the most well-known form of authorisation, precisely because most projects are looking inward only. (This is why we use and need a second kind of authorisation, but more on that later.) The general idea to keep in mind is that resources are generally made available internally.

Note that public-access resources are still considered internal in the following; it just so happens that the internal World has become rather large for that particular resource.

The way we authorise resource access is as follows:

We have obtained a REMOTE_USER identity from an authentication mechanism
Given the resource being asked, the paths being followed, and so on, there may for an intermediate AUTHZ_USER, or a user that the resource-accessing party wants to pose as. We generally allow this when the arrows of identity inheritance permit it. We then continue with the AUTHZ_USER as the new REMOTE_USER. Note how this step is optional, but fatal when it breaks the arrows of the inheritance diagram.
We now lookup an AUTHZ_RESOURCE, or perhaps a more generally configured AUTHZ_POLICY, which applies to the resource being used. This resource would provide us with ACLs for a number of purposes: Readers, Writers, Creaters, Deleters and perhaps Owners and Originators. Based on matches of the REMOTE_USER against each of these, the permissions to be granted can now be computed. Note that some overrule others, such as the Writers that are all Readers as well.
While determining the privileges, we may find that the identities to grant them all are in fact not the REMOTE_USER but even more specific ones. Perhaps a user changes to a group member before it can continue. When this is needed to fulfil the ACL, the REMOTE_USER will be updated accordingly, and the result is passed back to the authorisation requester as its identity to use. TODO: When we return a list of rights, this might be ambiguous! But it oughn't be -- we generally don't want to write with another user name as used to read the same data. To be resolved.

We now have a set of rights, together with a REMOTE_USER name that can be used to exercise these rights. We are ready to go!

The entries on each ACL are formatted as DoNAI Selectors, which means that they may capture anything from perfectly concrete address to catch-alls for domains or every anyone anywhere anytime. If you like, you may care to review some examples of DoNAI Selectors.

Authorisation for Communication

The InternetWide Architecture is, well, Internet-wide. This means that it also handles authentication and authorisation between realms. Not everyone is our friend, and so not everyone may be welcome to talk to us.

To be able to communicate between realms, we employ a black and white list, with authorisation outcomes that may be black, white or sometimes gray.

Outbound communication is always permitted; when contacting a new remote peer, its address will silently be added to the white list. The peer may contact us with replies, and we should be open to him, at least initially. Do note that only the exact address of the peer is added — not his domain, not his aliases and not his marketing mail generator's no-reply address.

Inbound communication is filtered through the black and white lists. Like other ACLs, each list holds DoNAI Selectors with the patterns of senders that are welcomed. More on that can be found here.

Depending on the presence or absense of black and white lists, there are a few approaches:

Neither list is present: Communication is prohibited.
Only a white list is present: Communication defaults to rejection, but the white list may overrule that.
Only a black list is present: Communication defaults to acceptance, but the black list may overrule that.
Both are present: Find the most concrete matches on each list; discard those that have more concrete entries on the other list; hope to be left with either black or white entries.
When left with both entries, proceed through gray listing.

The topic of "most concrete matches" is concerned with how abstract the DoNAI Selectors are. Very abstract forms are like @. or @.net or john@., and they are all more abstract than john@example.net so they would cancel against it. This can be used to remove entries from the white list against the black list, as well as the other direction, but it may also be used within a list.

Note that a list may not have a single most concrete value. Both the values @example.net and john@.net are abstractions of john@example.net, but they are not relative to one another. The same may apply when comparing entries between black and white lists. In fact, there are two dimensions of abstraction, namely the user name and the domain name, so up to two may be left on each list.

When something remains on both the black and white list, there is a need for gray listing, which is meant to resolve the uncertainty by trying to get the local user to communicate with the remote peer. The current best method is to contact the user over XMPP with a contact request, perhaps after trying to get one approved by the initiating remote peer, which should of course have opened up for us already. While all this is going on, communication is on hold; this may mean that it is deferred (SMTP gray listing), ignored (interactive protocols like SIP), or not consumed yet (AMQP queue processing). There may well be a timeout triggered as a response of this, which is why we think that XMPP is the best device for doing this. The hope is to always end up with a concrete entry on the black or white list, so that future uncertainty will not rise.

Implementation

The middleware discussion pointed out the TLS Pool for authentication, and an open block for authorisation. The logic for that block has hereby been given more clarity. Do let us know how you feel about the directions taken, and the choices made!

Clearly, the implementation should pre-work the various complexities that are caused by the model, especially the inheritance diagram:

Responses are probably going to be provided in a number of forms. Our Diameter format over SCTP is going to be likely. Another one may well be the Auth Request module in Nginx, which makes a simple HTTP request and interprets the response code as an authorisation choice.

Something not decided on yet, is whether we should also support the OpenStack Keystong API and would therefore service OpenStack components beyond Swift, which may be of interest to the hosting providers that we want to help forward. The reason of doubt is that we currently think of the OpenStack authorisation as tenant-level, so perhaps domain-level authentication, rather than a direct match for all the users, aliases and groups that we develop under the InternetWide Architecture. We suspect that this is also going to be the level at which any other components from OpenStack are going to be of use to the hosting provider — domains own things like virtual machines, and in turn those virtual machines hold accounts and groups to welcome the plethora of user identities from the InternetWide Architecture. Here's an example /etc/passwd fragment...

john      :x:1000:1000:John Examplar:user :/home/john      :/bin/bash
john+singr:x:1000:1000:John Singer  :alias:/home/john/singr:/bin/bash
john+sales:x:1000:1100:John Salesman:user :/home/john/sales:/bin/bash
mary      :x:1001:1001:Mary Examplar:user :/home/mary      :/bin/bash
mary+sales:x:1001:1001:Mary Saleswoo:user :/home/mary/sales:/bin/bash
sales     :x:1100:1100:Sales Account:group:/home/sales     :/sbin/nologin
sales+john:x:1101:1100:Salesman John:grpmb:/home/sales/john:/bin/bash
sales+mary:x:1102:1100:Saleswoo Mary:grpmb:/home/sales/mary:/bin/bash

...and this is a portion of an example /etc/group file...

john      :x:1000:john
mary      :x:1001:mary
sales     :x:1100:john,mary

...showing that very funny things can be done; we can set the same userid for an alias, but end up in another root directory. Does this stuff work? Not completely sure, but it ought to. Anyhow, that's just a quick impression of the level where it does seem to make more sense to pickup on users and groups, much more than at the level of OpenStack Keystone. For now, we assume that we will implement some form of Keystone, but just for domain names annex realms.

It is very, very likely that we will add support for existing IdP systems, such as OAuth, OAuth2, OpenID Connect, SAML-based authentication and authorisation, and perhaps Mozilla Persona; we would simply use our own mechanisms as local access mechanisms to get to the internal IdP, and then make that flood out to everywhere the user wants to surf today.

Image credit: Azmie Kasmy — the work has been edited to fill a horizontal bar.

Identity 7: Welcoming Guests

2016-12-30T11:18:47+01:00

A proper identity architecture should have a way of dealing with unexpected guests. There is always the possibility of granting anonymous access to anyone, but could there also be a mechanism that grants rights to returning users, and that will continue to welcome them with the same user identity as they presented before? That would really make it a Bring Your Own IDentity platform!

And indeed, this is possible. When we consider the inheritance of identities it is clear that some rewriting of addresses needs to be done. Much of this is internal to the realm or domain name, but there are some extra paths over which foreign identities are welcome too:

Clearly, there is a use for translation of foreign identities into realm-bound welcoming identities that they might take up. There may in fact be multiple such identities for any given foreign identity, so in general we need to concern ourselves with a list of local renames.

Given this, what could be more natural than allowing a special role named guest, and assigning role occupants some names such as guest+c669d08ba0d920f09b16343cbd3daadabb89b3e7fa789529c5768d5e87f946f5 (based on a SHA-256 hash) when we care about the security of the returning visit, or perhaps guest+c3427811db296605 (based on a prefix of a hash) if our primary concern is privacy of the guest, or even just guest+jAwMDAwMjAg (based on a 64-bit fast but insecure hash) if we believe that even that is not a true concern? Sizes matter, but variation is thinkable. We may also think about the form being a hex number, base64 encoding or even just show the original identity in the plain.

There is no real reason for not supporting such guest identities for foreign identities and, in fact, for local identities as well. The one thing we need to do is set aside a user identity to serve as the guest role, and decide on the occupant production rules. We shall not be granting anyone any access until they actually pass through an ACL that allows them.

Note that we are not saying that we intend to setup any service for such guests, but rather to welcome them as authenticated but pseudonymous visitors in parts of our infrastructure that have been setup with a sufficiently permissive ACL.

The ACL is where things may get interesting; this is where we can easily specify user names like guest+sha256 to indicate that the first format is welcomed. Although it is theoretically possible to generate identities on the fly, we would rather be lazy and do it only when it is called for. So a bit of special handling in the authorisation phase might be all that is called for.

The use of hashes means that we do not get to log the identities of our visitors; we only get to distinguish them as being the same as before. And when presented with a complaint from some foreign user, we can help them, because then we can forward-compute the hash and lookup log entries.

Image credit: fletcherjcm — the work has been cropped to a horizontal bar.

IdentityHub 3: Services to Thrive on

2016-12-21T00:00:00+01:00

The services of the IdentityHub are the user-facing facilities that make the IdentityHub worth using. It contains pretty standard components, but goes well beyond that; after all, the whole purpose of having an IdentityHub is to provide end users with control over their online presence -- and that means adding security and privacy through a number of novel facilities that they are currently deprived of.

Please note: If you followed our postings with some degree of accuracy, you may have noticed how we gradually refine the architecture and are pretty much delivering to our promise. The most obvious question that bothers us is our financial continuity, to be quite honest. So, if you find parts of this design useful and others promising, maybe you should contact us to help us settle the financial side.

Web, Email, AMQP, XMPP, ...

The classical distribution for a hosting provider has been the so-called LAMP stack for 20 or 25 years now; providing web with PHP and MySQL, plus Email, in a manner that should have been a one-size-fits-all but, as it so often goes, turns out to fit most of us badly and would eventually hollow out the market and lead people to accept "free" services, in spite of their assault on individual privacy.

The choice made in the IdentityHub is to provide very basic services, and add plugin services during ServiceHub; these plugin services are then capable of replacing or extending on the basic services. The choice for basic services means that we can generate their configuration automatically from a Service Directory.

So, the web support provided in the IdentityHub is for static sites -- with access control of course. And email is a very basic service -- except that it does provide support for groups, aliases and even black and white lists.

New protocols to most will be AMQP and XMPP. We are currently considering these as serious candidates for inclusion in the IdentityHub. The protocols each serve a very particular purpose.

XMPP is instant messaging, a service that has been around but for some reason not to do with technology ended up encapsulated in proprietary services. Well, getting out is as easy as getting in -- and an XMPP node may be self-controlled, but it can still connect to any other domains and their users that also follow this standard protocol. The nice thing of open protocols is that they combine these two facets that are so important in an online life: self-control and connectivity. As soon as you have open protocols like XMPP and AMQP, you get to distribute the responsibility and pull your identities under your own realm of influence and control. Meaning, to a hosting provider that will be happy to sign you up under a contract that serves you, not them.

AMQP is a relatively new protocol, and replaces email in many of its uses with attachments. Where email is ideal for letter-styled communication between users, AMQP is strictly meant for passing data files between users, without introduction or other human-processing aspects, but with the annotation and authenticated secure transport that enables automatic processing. Some people may be welcome to send you movies of yet another Parkour jump, while others should not even try; some may be welcome to add things to your agenda, while others better call you and make an appointment that you will add yourself. This is the level of control that AMQP is perfect at supplying. In general, we will use AMQP to fill (and empty) queues in the Reservoir conceptual design. In some future, we expect to even add workflow logic, so as to support standard handling for standard operations.

This general concept of a Reservoir is just the level at which we want to have the IdentityHub; it can easily spark of many interesting plugin services, because it can be a transport for media files, EDIFACT traffic, calendar scheduling invitations, and so on. In these things, it is very useful that AMQP is run over a secure layer which we intend to filter on sender identity as well as on the MIME type of the data transferred.

Global Directory

The global directory is a well-defined manner of using LDAP under a domain name, to store its semi-structured data. Specifically, this can be used to lookup information for john@example.com by searching for (uid=john) in an LDAP server that has an LDAP server underneath example.com. This is not an ARPA2 invention, but an Internet standard.

We use the Global Directory to lookup X.509 certificates an OpenPGP public keys for someone like john@example.com. Not only do we publish it underneath the (uid=john) outcome, but we also look for it when the TLS Pool attempts to authenticate a user. This can be used instead of, or in addition to, a trust hierarchy in the common X.509 sense; this however is a system that never really took off for identifying end users.

Some alternative methods to locate user certificates and public keys exist; the only well-defined ones store this data in DNS. The disadvantage with that is that it reveals that information to anyone, whereas it is our intention to only reveal information for a user like john to people who directly ask for it using (uid=john) or by looking up entries under, say, uid=john,ou=Users,dc=example,dc=com.

In the backend we described the Object Store, where barren files may be uploaded; we also hinted at AMQP as a queue delivery protocol above. In both cases, these documents will be stored in what we have come to call the Reservoir, and what is in essence a nested collection of resources underneat a user's LDAP node. So, users can store data or have data described and linked to an actual storage location in the Object Store. To search the Reservoir, they would use LDAP; and to download the (potentially large) document, they would turn to the Object Store. This gives the best of both systems.

Not all entries are, like (uid=john), references to individual users; there will also be references to other forms of identity such as groups and roles. Under each, there can also be public credentials that would then be shared by group memers (or role occupants). This is the manner in which groups may share data to collaborate on.

Realm Controller

The realm controller is an active online component for authentication of local users (and groups, roles, aliases and so on). It is essentially a Key Distribution Centre for Kerberos, forming the cornerstone for user logins.

The specific bits that we add here are for realm crossover, a problem for which several solutions have been proposed, but always with downsides. After analysing the options, we concluded that the approach through Kerberos holds the best cards -- except that it is not yet worked out. We have taken it upon us to do so, as it is an essential component for Bring Your Own IDentity. While at it, we also take privacy into account, by allowing the change of a client identity to an alias, role or other inherited form of identity.

Kerberos is empowered by GSS-API authentication and our own TLS-KDH mechanism, but bootstrapping it is difficult; especially on mobile devices, people tend to type short PINs in the presence of others. We plan to replace that habit with a simple swipe of an NFC Tag with the purpose of loading a Kerberos credential into the device. The NFC Tag is assumed to have been programmed at a stationary device in a secure location. It is actually possible to carry multiple NFC Tags, and swipe them to change identity. Security is great, but will only be used when it is made practical enough for daily use!

These extensions are fairly large to the Kerberos commnunity, but at least the realm crossover changes can be made without changes to client code (!) and the changes for privacy are not just optional, but should also prove trivial. The NFC Tag extension will work through a new App, but the Kerberos client itself should not change on account of it.

The quality of protection can vary when using Kerberos; the initial login may be protected with more than just a secret, for instance through number-generating tokens or other devices. This gives room to hosting providers to vary, and thus to distinguish themselves on the market.

Hosted PKCS #11

Next to Kerberos, we present solutions for X.509 and OpenPGP credentials. With a Global Directory to publish the public sides, what remains is a good solution for the corresponding private keys. We intend to use Kerberos to bootstrap secure access to Hosted PKCS #11.

An important reason why public key systems are not widely used is that they confront users with the need to roll their keys at regular intervals, such as annually. This is a task that must be done with great care, yet it is difficult for average users. As a result, the framework is considered too difficult for most, and not even erected for those who would benefit from having it in place. We solve this by offering the end user to take over the responsibility of private key management, if the user believes that is a better allocation of responsibilities. In those cases, the middleware holds the Credential/Key Manager to regularly rollover private keys and public credentials to avoid the expiration of identities alive.

Having decided to offer "Hosted PKCS #11" to users, we innovate one step further, by adding "Layered PKCS #11". This means that the user who accesses Hosted PKCS #11 will not just be able to use private keys for its own identity, but also find an additional readonly layer that is shared from the inherited identities of roles, groups and such. This means that all group members can decrypt traffic that was encrypted to the group, that any role occupant can sign on behalf of the role, and so on. That is, if these also rely on Hosted PKCS #11.

It is vitally important that users can control their own security in any way they like. For that reason, the Hosted PKCS #11 layer (as well as the Realm Controller) should facilitate self-control; that is, a user should be able to run these components in their own premises, if they intend to avoid that the hosting provider of their domain could access their data. For some sensitive applications, this may be a legal requirement to be able to use the IdentityHub infrastructure.

The quality level of PKCS #11 is going to be a place where hosting providers can vary, thus creating a more lively market: the general interface ranges from software implementations all the way to rack-mounted, tamper-proof, redundant and highly available Hardware Security Modules.

As a final remark, the relationship between the Global Directory and PKCS #11 objects is tight; the ARPA2 Global Directory will represent the private objects in PKCS #11 with references to the public credentials derived from it, but such PKCS #11 descriptors will only be made available to those users who can also access the described private objects over Hosted PKCS #11. Briefly put, this means that LDAP can be used to look for private keys and public credentials that can be used in pairs.

The complete series

IdentityHub 2: Middleware from Heaven

2016-12-20T00:00:00+01:00

The middleware of the IdentityHub is designed for flexible use; it supports our powerful use of identities and implements our goals of privacy and security through self-control over online presence. This is where concepts such as Bring Your Own IDentity and its technical realisation through Realm Crossover come alive.

Authentication in the TLS Pool

During our first project phase SecureHub we separated TLS handling out into a TLS Pool that is now approaching its 1.0 release. We also designed and implemented the TLS-KDH mechanism that enables proper use of Kerberos within TLS connections -- an astounding amiss in today's security landscape, certainly because Kerberos is in common use, for instance as part of Active Directory. Many other protocols use SASL for authentication, which is not (yet) done in the TLS Pool, but that often also leads to Kerberos authenication.

In all these cases, we aim to implement and support realm crossover, meaning that users from remote realms can employ their local Kerberos credentials to authenticate remotely. This is new in the sense that the crossover can be made on the fly, when it is in demand. We also do this for X.509 and OpenPGP, using the LDAP Global Directory, but there it is much more expensive: Kerberos realm crossover is done once between two realms, and the crossover is established for all users at once, for days to come; X.509 and OpenPGP on the other hand, need to validate the same things over and over again, using expensive public-key cryptographic operations. Our research into TLS-KDH found that our approach is about ten thousand times faster on average!

Note that we use the TLS Pool strictly for authentication and treat authorisation separately below.

Authorisation

The mechanisms for authorisation build the IdentityHub's flexible user identity logic on the foundations of an identity that was authenticated by the TLS Pool or SASL.

This phase answers questions such as

Can user_A behave like user_B?
Can user_B access resource_R, and if so, what rights does it have?
Can (remote) user_B communicate with user_C?

Within the IdentityHub, we have one entity of control (the hosting provider), so we do not have to put in the privacy effort that we need towards plugin services. Our main concern here is to be efficient, and support large-scale operations. To that end, the authorisation module is responsible of caching and low-cost access mechanisms in the service of other components.

Control over the IdentityHub

Users of the IdentityHub will regularly want to do things to their service; they may want to add domain names (or phone numbers), user accounts, aliases and pseudonyms, they may want to add or remove members from a group or role, and so on.

The control of such requirements is managed over remote control interfaces. There are currently two that we are contemplating:

remctl because it facilitates simple user interfaces to be operated from relatively poor user interfaces such as those found on mobile phones and tablets;
a RESTful API because it integrates well with most other software and client platforms, including laptops, desktops and automated processes run from server systems.

Our current expectation is that both will be used.

One task of this control interface for the IdentityHub is to list the currently available options to authorised users; for instance, to show the current list members to the list administrator, so that one may be removed or perhaps upgraded to list administrative status.

The interaction with the component comes down to sending a command to schedule configuration actions; some of these will involve generating new key material and configuring new access relations.

Managing the IdentityHub

Sitting behind the control interface, there is the logic of the IdentityHub, which is silently groveling on whatever tasks it needs to. This involves not only the generation of new key material and cleanup of old, but it also deals with automatic rollover of keys. All this is possible inasfar as (private) keys are hosted by the IdentityHub.

On top of this, many signaling paths may be initiated by the IdentityHub as soon as it is possible. Relatively complex facilities such as DNS data with DANE and DNSSEC also find a place in this component.

You may view the module as a guard for the health of the entire cryptographic logic of the IdentityHub.

The complete series

IdentityHub 1: Backends to Die for

2016-12-19T00:00:00+01:00

Everything in the backend is designed for scalability. Meaning, there is hardly any overhead per item or per request; instead, everything in the backend is designed for bulk handling. To further this advantage, it is all designed to support redundant and load-balanced operation, or at least the hosting provider who installs the IdentityHub can configure it in that manner.

Object Store: Reservoir, Web, Queues, Backups...

The IdentityHub involves a storage component, meant for putting away large data files, as well as smaller ones. This is imlemented through an "Object Store", a concept from the Cloud Storage world.

This generic service can be useful for many applications, including:

Plugin services may store their backup files as an object
Static web sites may store documents and style sheets directly (and future plugin services may add dynamicity to the websites)
Queues may use objects for intermediate storage of data between users and between sites
Reservoir is a (public, user-only or group-shared) collection of annotated data files (such as media, calendars, writeups, ...)

We standardise on a RESTful interface for the Object Store, with additional facilitation of access control. Our current choice of implementation is OpenStack Swift because of its cut-and-dry API that might be reimplemented if we wanted to; but mostly because it is flexible in its degree of replication and supportive of off-site replication, and because it scales down to a simple file-based service if so desired. Finally, it has pluggable authentication which integrates well with our IdentityHub plans.

We are not saying that other backends, such as Git will never end up in the IdentityHub, but it is simply not being planned for now. Also, we aim to support only bare essential services of a generic nature in the IdentityHub.

We believe that an Object Store facilitates a diverse market of providers, varying replication levels and similar factors. As an example, the off-site replication facilities could be combined with ordering or selection of DNS records to offer replicated web services with a preference for servers near a requesting client. This level of service is quite new to the market of general-purpose service hosting!

Service Directory

We standardise most of our semi-structured data with LDAP, and have already started facilitating it with the SteamWorks components. These enable a subscription to the data with sheer-instant updates, meaning that any configuration changes can arrive in their intended sweet spots in little or no time.

For the time being, the IdentityHub focusses on its own services, such as those described in part 3 of this series. But when we enter the ServiceHub phase, quickly after we finish IdentityHub, we are going to fan out and use the same setup to share configuration information with plugin services from independent service providers.

The Service Directory is different from user-facing data precisely because of its bulk nature. Rather than sorting information first into domains, and then perhaps describe services, this component first sorts descriptions into backend providers or service categories, so that a single subscription suffices for each of these, and they can receive configurations and updates over a single bulk query. This is much simpler than separting connections per domain, or per user; and also much simpler than filtering from a generic description for many services. And also note that access control is much simpler to arrange in this bulk style!

Access Control

This part of the diagram has been dashed for now, because it is really just part of the ServiceHub phase. We will formulate authorisation requests using Diameter lingo so that plugin services will be able to learn whether certain users may access certain resources and/or communicate with particular peers.

We are hoping to facilitate plugin services on a need-to-know basis only; at the same time, it is in the interest to facilitate some form of caching. This is in fact one of the more interesting challenges in our infrastructure!

In case you are wondering why we selected Diameter over RADIUS: this is the protocol that is more aligned with the future; moreover, translation from RADIUS to Diameter is straightforward and sufficiently implemented to be of no practical concern.

Funnel Tunnel

The funnel tunnel is something we envisioned quite a while ago, as a sort of umbillical cord between a plugin service and the IdentityHub. It is specifically designed to facilitate bulk operation of protocols, and it runs over a reliable, and easily secured transport namely SCTP over IPv6.

The protocols being run may vary between plugin services, but will most likely include access to the other backend components Object Store, Service Directory and Access Control. In addition, it may do much more.

The protocols are wrapped in a secure layer en masse, to avoid overhead due to encryption on every end-user request. This contrasts common design approaches of security in web systems; and indeed, systems that follow this per-request authentication and authorisation approach are usually on the slow side as a result of all the public-key operations needed.

The complete series

Identity 6: Inheritance of Identities

2016-12-18T00:00:00+01:00

As we develop the kinds of identity that we need to implement our ideals of improved security and privacy through identity control, we refine the InternetWide Architecture into what is needed in an ARPA2 project's technical detail level, and how we can relate this to current-day open source software.

The normal user login is made using the initial user identity supplied to the user by the administrator of their domain name. Users may then continue to setup aliases, pseudonyms, memberships of groups and occupancy of roles. This gives the user great control over how they appear to the outside world under our Bring Your Own IDentity (BYOID) concept.

Having multiple identities is only usable in practice when one login suffices to get to all those identities. This is why we speak of inheritance -- access to one identitie implies access to the rights granted to another. This is often a directed operation (namely, in the direction of the arrows in the diagram above), because a group should not be able to use the access privileges of its members, for instance.

(We have a few undecided issues, denoted with dashed lines in the diagram, and that is whether pseudonyms should be completely separated (as their key material is) and therefore warrant separate login; and whether there is a use for having an alias for group membership, as we have it for role occupance; finally, whether external users should in certain circumstances be granted rights to a local user name / account. But we're getting ahead of ourselves.)

What the Inheritance Diagram Means

The user identity is the primary point of login for a user. Have a look at the three user+yyy forms pointed at from the user identity; these three forms are controlled by the user, who creates them on top of the primary user id. We might think of them as sub-identities, and their different name grants us variation in access control even when it is visible that the names are derived from a primary identity.

Aliases are just that, but when used like user+role (or user+group), the basic idea is that the occupancy of a role (or membership of a group) receives explicit an notation for the user. It is this form that then subsequently enters into a role or group, in which the user is represented as role+occupant or group+member, as a sub-identity of the role or group primary identity. This enables a form of address translation, where a user is represented externally with another identity, and with the key material that is designated for use with the role or group. The sharing of key material with other role uccupants or group members is vital in the equivalent handling of group members or role occupants; when one person with an administrator role is out on sick leave, another may take over; when one member in the purchasing group receives encrypted messages, the other group members can read them too.

Role occupants have a distinguished sub-identity to facilitate continued communication with an inidividual role occupant, even when they all behave as one; group members have a distinguished sub-identity to distinguish a poster in a pseudonymous manner. For roles, the usual response will go to the role occupant, whereas for groups it will normally go to the group as a whole.

Note the inclusion of foreign role occupants and group members as though they were local members. This is not just a consequence of our intended support for BYOID, it is also a modern alternative to what we've been hacking away at with mechanisms such as email lists; such a list could become a group and it must be capable of welcoming foreign members, under access control rules that match the group's feeling of privacy. Note how a sub-identity will be assigned to each (foreign) group member as it would for any local user.

Groups can be nested. Let's say that you have a breakdance club which also hosts hiphop dancers, then you can create two groups for the types of dancer, and combine these groups into a club members group. It is theoretically possible that cyclic group definitions arise in this manner, in which case we do not define behaviour (but will try to implement recursive references as empty lists wherever possible, to have meaningful semantics and to be able to suppress error messages, but we give no guarantees at this point).

Roles are used for access control, and nesting them is probably confusing. We therefore have not offered nesting facilities for roles. What is possible however, is to assign role occupance to not only individual internal and external users, but also to groups of users. Since roles are about access, they are not parts of groups. Access to group settings would be assigned to roles, but that is a different matter from allowing roles as group members, which, once again, would be confusing and is therefore not defined.

Impact on Authentication

With authentication or authn, we mean the mechanisms that prove the ownership of one's identity. It involves credentials of a cryptographic nature, such as a certificate, public key or ticket. In much of what we do, we use the LDAP global directory to provide information on credentials supported by a domain.

One of the major tasks in the IdentityHub project phase is to create credentials for authentication and publish their public sides in the LDAP Global Directory under a managed domain.

Primary identities xxx receive their own keys / credentials, and their public sides will be published in LDAP for search filter (uid=xxx) under base DistinguishedName dc=example,dc=com to represent the DoNAI xxx@example.com. This applies to the user, pseudonym, role and group identities. Foreign users are not incorporated, but are expected to facilitate their identities in a similar or otherwise cross-realm acceptable manner.
Secondary identities such as xxx+yyy are stored as directory objects underneath the ones matching (uid=xxx), and they can be sought in the same manner to not require knowledge of the sub-identity idea in remote dependants; so xxx+yyy@example.com is also found under base DistinguishedName dc=example,dc=com with search filter (uid=xxx+yyy). This applies to the user+alias, user+role, role+occupant, group+member and user+group forms. The forms publish credentials with these alternate identities, based on the same key material as for xxx@example.com.
Pseudonyms such as zzz are different from xxx and has its own key material, so any relation to xxx cannot be inferred. It is a more heavy-weight, computationally more expensive identity. Internally however, it is useful to be able to login as xxx and be able to use Pseudonyms such as zzz without separate login. It is the user's choice whether he wants this (for reasons of complete separation) or not. Pseudonyms require creation permissions at the level of the domain user, unlike aliases for which each user has complete control.
The forms role+occupant and group+member each have a reference to the occupant or member identity; this may be a form like uid=user+role or uid=group or mail=foreign@domain to indicate local and remote elements incorporated into the structure. Such remote elements might be pre-selected by using an alias reserved for that purpose on the remote end, which is why the alias forms user+role and user+group are demonstrated in this diagram. Note that the referenced LDAP entries may or may not exist; when they don't, the facility is simply not available and group membership or role occupance should not be considered complete.

Where public credentials are shown, there is an additional facility of a PKCS #11 reference that is only visible to the originating user. This can be used to gain access to the credentials. While this may sound like a recursive definition of private key material, it is actually useful to hop from one authentication method onto another. We use it to initially login using Kerberos, and from there be able to gain access to private keys stored in PKCS #11 for use with X.509 and OpenPGP.

Impact on Authorisation

The arrows indicate access from one identity form to another. The direction of the arrows is meaningful. The complexity of the pointing structures makes it likely that we will derive the forms beforehand and unite the information into a table or view that details just:

domain as the realm for the problem at hand;
source as the authenticated domain user or foreign@domain user;
target as the identity being targeted;
public as the published identity when using the target.

Most authorisation questions should end up making requests to this table, but the basic question would be

Can a path from source to target be constructed under domain? And when this is done, what public identity should the source take on?

For the future ServiceHub phase, we will attempt to not distribute this table as-is, because that would publish more information about a domain than strictly required, so there is room for a more subtle approach. The model however, would still aim to answer these same questions.

Each resource would have an access control list or ACL to identify the various identities that are granted access. Roles are not enforced in this process, but they are highly advised in the support of easily configured access control based on general inidiactions -- such as an admin role that can occur in many places, but that only needs to be modified in one place to add a user to this role, or more importantly, to retract it. One place where a role is not ideal, is when group members have access to group privileges.

Note that this framework defines who may use what identities on top of their current ones; it does not indicate that one user can communicate with another. This is a separate matter altogether, that we will discuss separately under the concept of black and white listing.

We introduce a form group+ or role+ or even user+ to indicate any sub-user under the given primary identity group, role or user.

Impact on Privacy

The form user+alias is not a good way to conceal one's identity, but when user has more restricted access control, it suffices. In other cases, a totally independent pseudonym can be defined (at the expense of separate keying material and separate login).

Much more useful are the forms role+occupant and group+member which conceal the actual username behind it, even though it may be practical to choose voluntarily to indicate the user: for example, john may choose to be take on the admin role as admin+john, but that would be his choice.

When logging or publishing activities form a group or role, then the sub-identities are used to indicate the user. For example, on an email list, which is automatically setup for every group, the sub-identity of the group would be used in the From header when an email is forwarded to the group.
For groups as well as roles, the To header would be set to the group or role by the sender, unless he wants to address an individual member or occupant, whose group+member or role+occupant address would then be used as the To address.

When traffic passes back to the group (or role), then access control is applied as it is needed for sending to the group or role; and when it matches, then the reply can be forwarded to the local or remote user. Once again, reply settings are made to pass traffic through the group or role.

The result is that group members have the option of being somewhat anonymous. Administrators would still be able to find the member's identity, even when it is remote, but normal group members would not.

The manner in which group members or role occupants pass response traffic through the group or role means that they appear to their remote correspondent party as though they really are acting on behalf of the group or role; this is why we suggested the trick of using this mechanism for generic addresses such as info@ or support@ under domain names. This enables replies from the same identity and is therefore helpful in maintaining black and white lists that permit response traffic base on outwards contact attempts. Unlike NAT for IP addresses, which suffers from a lack of storage space, the sizeable nature of higher-level protocols such as email permit the insertion of another address in an email address. For example, as a special sub-identity group+nat+member or whatever the mail solution thinks is useful.

Post Scriptum

Addition 2016-12-30: There may be good reasons to permit references from user to user; this could support pseudonyms without explicit login into the other identities. A great convenience, but it also means that we must account for cycles in the users. A similar problem is less useful, but still not impossible between groups.

This calls for special algorithms, namely for the computation of transitive closures. Probably the best algorithm for this is Floyd-Warshall which not only computes the existence of a path, but it even provides the length of the path, which is helpful in determining which from a selection of available alternatives would be the preferred choice. There are even slight modifications that construct a shortest path in only modest extra storage space.

The Floyd-Warshall algorithm consumes O(N^3) time and O(N^2) space, given that there are N identities involved. We can drastically cut back on this time through a number of optimisations, such as partitioning beforehand, and/or computing partial graphs only, such as looking just at users at one moment, or looking just at groups (after incorporating group members) at another moment and then doing the fairly straightforward composition in the aftermath. This greatly reduces the graph sizes, and therefore the number of cycles to be expected. Though tricks might help to extend the graph, it is possible that a complete recomputation is needed after removing arrows from the graph.

An alternative algorithm exists, namely Dijkstra's algorithm which is more efficient in sparse graphs, running in O(N^2.log N) and, possibly more efficient under proper conditions. The algorithm compute for a single shortest path, which means that its results do not yield a good overview and are therefore less suitable for caches, but it may be possible to mix the two approaches when known pieces of the cache have been invalidated by changes.

Addition 2017-01-01: Happy new year... with a few decisions made to the inheritance diagram. The Pseudonym has been introduced as a real target, pointed at by the Primary user identity. This means that inheritance from user to pseudonym has now been decided as a possibility. This means changing the user name and associated key material without a separate login. Not the only way to go, but it can surely save a lot of work. Foreign identities now link to the Pseudonym, instead of the Primary user. Furthermore, the user+group variation has been accepted, because it can be very useful to pick this alias locally before moving over to a foreign realm. Although this use was already possible with the plain user+alias form, it is now more visible through its parallel to the local diagram. Also note that this enables multiple memberships of a group, so lonely people can finally talk to themselves (and people who are curious in both meanings can test group facilities by talking to themselves).

ARPA2 All Hands - November 2016

2016-11-29T00:00:00+01:00

We are organising the second ARPA2 All Hands meeting. This is scheduled to take place on November 30th 2016 from 10:00 AM to 16:00 PM (UTC +01:00), followed by informal drinks and food to continue the discussion and brainstorming... Thanks to the national research and educational network SURFnet for kindly providing the venue for this event.

The participants of this All Hands meeting of the ARPA2 project will get an overall introduction to the architecture and thinking behind ARPA2 and an update on the status of the various sub projects. Importantly (and the main reason for an all-hands) you will meet the other people that are active elsewhere in the project, and brainstorm about the future direction of the project.

Address

SURFnet, room 4.1
Kantoren Hoog Overborch (Hoog Catharijne)
Moreelsepark 48
3511 EP Utrecht
The Netherlands

Please find the directions on how to reach the venue.

Who should attend

We will do our best to arrange some form of remote participation, so if you physically cannot attend but would be interested in attending remotely, let us know.

Tetralogy of a Free Internet

2016-06-24T00:00:00+02:00

Our mission

We have made it our mission to construct novel software that enables end users to take back control over their online presence. This has disruptive impact in the areas of security and privacy, but also the ability to easily add hosted services to their online presence, and keep full control over them.

The way we do this is through concrete projects that really zoom into the technical details, always using open standards and where we see an opportunity we donate back with further advancements in these standards. The software that helps the Internet to place end users central is published as open source.

We realise that our work is highly disruptive to the economy-driven Internet of today, and though we do not fear for people earning an income, we do believe it should never be at the end user's expense.

Our Tetralogy (a story in four parts)

We are currently approaching the roll-out of our first phase in alpha software. After that, we intend to continue, but building open source software does make us dependent on independent funding. So, if you think we can help you then please consider helping us to do this for the Internet!

The four phases are:

SecureHub builds a number of basic security mechanisms; we have identified a need for the following concrete projects:
- TLS Pool is a local-machine service for an extensive TLS implementation. It is contacted by applications, which the TLS Pool relieves of everything security-related; the application designer can simply think in terms of his application's logic and handle remote parties in terms of their (validated) identities. The infrastructure is so simple that TLS can be added to an application in less than an hour!
- SteamWorks is a configuration framework that spans networks. It is geared towards central management of the TLS Pool through provisioning, though it is general and could be used for many more things. In later phases of the InternetWide project, we will use it to configure hosted services that can be plugged in from a independent service provider, for instance.
- TLS-KDH is a new mode of using TLS connections, built into the TLS Pool. It combines Kerberos authentication with the strongest (ECDHE) security possible. This is original research and part of a major standardisation effort to allow anyone to use it. Our research has indicated that Kerberos, being a centrally managed single sign-on system, is the most probable mechanism of connecting the Internet in a secure manner. To do this, later phases are planned to expand Kerberos with realm crossover and pseudonymity for privacy.
IdentityHub constructs hosted identity management. This provides a central management interface for identities including such advanced facilities as groups and pseudonyms and the infrastructure for realm crossover which basically means that you login locally, once a day, and then bring your own identity (BYOID) to whatever remote service you visit. We are even considering to integrate commonly used authorisation technologies like SAML in the mix. Finally, the end user will be able to publish precisely those bits of information that he desires about himself or his online actions over automated protocols such as the web and LDAP; with such access control just as he pleases.
ServiceHub is a hosting environment split into an identity component (centered around the IdentityHub) and plugin services that can be pulled in from anywhere. It will be possible to create markets of freely exchangeable service plugins across hosting provider boundaries. The result will be that services can specialise, and move on a free market. This is quite different from the current model that uses LAMP as a least common denominator but that brings users nothing in terms of hosted functionality, unless it is run over the web from insecure scripts, with a misunderstood protocol leading to ineffective architectures in which there is a great lack of proper security practices.
SocialHub is the last phase, and the least developed. We intend to make the network itself into a social network. This very specifically means that we drop the dependency on the web protocol, which has the downside of making us dependent on a services hosted by some party that we may or may not want to rely on. Not having to make that choise is the main interest of this last project phase for InternetWide.

We are currently collecting funds for phase 2, and you are quite welcome to contact us if you think we have a shared interest.

Automating Communication Privacy

2016-03-01T07:45:00+01:00

The form of a Communication Filter

The big thing about a communication filter is to specify a number of rules of conduct for potential communication peers. These rules are a sequence of individual rules, gradually developing from general statements to exceptions; later rules can override preceding ones. An empty sequence signifies the default privileges defined by applicable law, and the first rule may be seen as a first exception to that default situation.

CommunicationFilter ::= SEQUENCE OF RuleOfConduct

A rule of conduct is either a permission or a retraction of a pattern of communication. These patterns involve communicative actions taken towards our own communication end points and are applied to a selection of potential peers. All of the actions, end points and potential peers are described as sets, and the rule of conduct, whether permissive or a retraction, applies to all combinations. Note that either of these sets could be empty, but that would mean that this rule has no impact on anything. Contrast that to the possibility of removing these entries; when that is done, it is considered to range over all possible instances.

RuleOfConduct ::= SEQUENCE {
        isPermitted [0] BBOOL,
        action      [1] SET OF Action OPTIONAL,
        endpoints   [2] SET OF CommunicationAddress OPTIONAL,
        appliesTo   [3] SET OF PotentialPeer OPTIONAL
}

An action description is an object identifier that we hope will be recognised. Might communication filters like these ever be embedded in law, then it would be important to make clear which set of actions must be recognised, and whose responsibility it is to see that these are found. These are the object identifiers that we described as being useful for their universality; and for which we stated that a small, and widely carried set would be useful. We define a number of examples below, under oid-action.

Action ::= OBJECT IDENTIFIER  -- For instance, oid-action-...

Similar in nature to actions, there are categories of potential peers, and these too are described as object identifiers, described under oid-peer below.

PotentialPeer ::= OBJECT IDENTIFIER  -- For instance, oid-peer-...

Communication addresses can range over many values. As was stated for actions, any embedding of these communciation filters in law would have to be clear on the required support for a selection from the wide range of possibilities covered here. In general, it a communication address is a set consisting of entries that can take various forms:

The context may provide it, e.g. an email sender, a directory object or a digital visiting card;
It may be specified in the form of a Filter applied to directory attributes;
A directory reference for a communication endpoint.

These choices are all spelled out below.

CommunicationAddress ::= CHOICE {
        contextual [0] NULL,
        filter     [1] Filter,
        ldapref    [2] LDAPDN,
        ...
}

Now that it is clear how a communication filter can be structured, it is time to turn to the actions and players.

Object Identities for Communication Actions

Let's start an (experimental) object identity tree under which we shall define our communication actions by adding as many "dot number" extensions as we like, starting with 1.3.6.1.4.1.44469.666.25.1.1; note that it is possible to make statements at this general level, and claim the opposite in later rules of conduct.

oid-action ::= { 1 3 6 1 4 1 44469 666 25 1 1 }

Various forms of communication action can now be defined underneath the object identity "tree" of oid-action, by adding numbers; for brevity's sake we let the labels speak for themselves:

oid-action-initiate-contact ::= { oid-action 1 }

oid-action-response   ::= { oid-action 2 }
oid-action-followup   ::= { oid-action-response 1 }
oid-action-reminder   ::= { oid-action-response 2 }

oid-action-repeated   ::= { oid-action 3 }
oid-action-newoffer   ::= { oid-action 4 }
oid-action-newsupdate ::= { oid-action 5 }

oid-action-response-human       ::= { oid-action-response   1 }
oid-action-response-automated   ::= { oid-action-response   2 }
oid-action-followup-human       ::= { oid-action-followup   1 }
oid-action-followup-automated   ::= { oid-action-followup   2 }
oid-action-reminder-human       ::= { oid-action-reminder   1 }
oid-action-reminder-automated   ::= { oid-action-reminder   2 }
oid-action-repeated-human       ::= { oid-action-repeated   1 }
oid-action-repeated-automated   ::= { oid-action-repeated   2 }
oid-action-newoffer-human       ::= { oid-action-newoffer   1 }
oid-action-newoffer-automated   ::= { oid-action-newoffer   2 }
oid-action-newsupdate-human     ::= { oid-action-newsupdate 1 }
oid-action-newsupdate-automated ::= { oid-action-newsupdate 2 }

Many more things could be defined, but you probably get the idea; you could deny general contact patterns with 1.3.6.1.4.1.44469.666.25.1.1, then permit any responses to your emails with 1.3.6.1.4.1.44469.666.25.1.1.2 and only human-sent followups with 1.3.6.1.4.1.44469.666.25.1.1.1.1 and this format can be processed automatically by software. You can also see how others might elaborate on the actions by adding their own under another "prefix" than oid-action, and how it would be needed to somehow regulate what sources of these object identifiers must be processed.

Object Identities for Communication Peers

We now setup a second "tree" of communcation peers that we recognise. We start off defining the general "prefix" for such object identifiers, 1.3.6.1.4.1.44469.666.25.1.2

oid-peer ::= { 1 3 6 1 4 1 44469 666 25 1 2 }

And again, in the interest of brevity we let the labels speak for themselves:

oid-peer-friend        ::= { oid-peer 1 }
oid-peer-commercial    ::= { oid-peer 2 }
oid-peer-collegue      ::= { oid-peer 3 }
oid-peer-collaborative ::= { oid-peer 4 }
oid-peer-interest      ::= { oid-peer 5 }

oid-peer-commercial-present   ::= { oid-peer-commercial 1 }
oid-peer-commercial-past      ::= { oid-peer-commercial 2 }
oid-peer-commercial-future    ::= { oid-peer-commercial 3 }
oid-peer-commercial-potential ::= { oid-peer-commercial 4 }
oid-peer-commercial-unrelated ::= { oid-peer-commercial 5 }

oid-peer-commercial-potential-requested ::= { oid-peer-commercial-potential 1 }
oid-peer-commercial-potential-offering  ::= { oid-peer-commercial-potential 2 }

oid-peer-interest-optout          ::= { oid-peer-interest 1 }
oid-peer-interest-optin           ::= { oid-peer-interest 2 }
oid-peer-interest-optin-groupcomm ::= { oid-peer-interest-optin 1 }

As before, it should be obvious that this enables us to be expressive, with just the right level of generality or specificity. We could grant all contact with friends with 1.3.6.1.4.1.44469.666.25.1.2.1 or actively suppress commercial contacts with 1.3.6.1.4.1.44469.666.25.1.2.2 with the exception of present contacts 1.3.6.1.4.1.44469.666.25.1.2.2.1 and potential relations that we requested 1.3.6.1.4.1.44469.666.25.1.2.2.4.1.

This concludes this demonstration of how automated processing of legal terms could be described in terms that support automatic processing. We might define a directory attribute for it, and place it with our contact information in a directory. Or we might define a standard for attaching these statements to an email.

END

Much more can be said about this, for sure. For example, we did not cover restrictions, such as the use of encryption and/or digital signatures, and how our identities should be validated; these are all technical provisions that help to protect our privacy and security; it might for instance be used to ward off anything that looks like it came from your bank but that, given ignorance of these rules can be automatically classified as spam.

Because there are so many more possibilities, we are not proposing that you start using these example definitions. Instead, you should take the demo to heart as a statement that automation of legal terms is possible if we put our mind to it.

Are you interested in working out this example, or others? Then let us know how we could facilitate you -- we might setup a website, mail list and so on.

Automating Legal Terms

2016-02-22T06:16:00+01:00

Anyone who provides a service feels the responsibility to put up terms and conditions under which they are supplied; without them, the risk of users driving them to court is simply too great for most. Laws like privacy laws additionally require explicit statements of such usage patterns.

There is nothing wrong with having clear terms whenever parties enter in an agreement. What is wrong however, is the form in which this is done, namely lengthy proze that takes much more time to actually process than the relation may be worth. Having an automatically processable form of contract, together with a mapping to readable text, would be helpful to automate acceptance of terms, and make the legal agreement efficient, while still permitting careful scrutiny of the terms.

Everyhting is an Object

Contracts usually limit themselves to a few simple handles on reality, such as

Parties, such as a service provider and its user or group of users
Objects, such as services, software, elements of data
Rights, both permissions and requirements to parties
Actions, such as starting and ending a contract, payments
Events, such as bankrupcy of a party, or breaking with contract terms

In terms of programming, we would refer to each of these as an object and each of these has its own identity. Not a human identity such as a word (or domain name), because those change (or expire). Numeric identities are more neutral and are therefore totally open to definition.

A numeric scheme that is especially of interest here, is the so-called Object Identity, commonly abbreviated to OID. Many of these have already been specified to represent, for instance, a bit of information. Two examples are

1.3.6.1.4.1.1466.115.121.1.41
1.3.6.1.4.1.1466.115.121.1.50

representing a Postal Address and a Telephone Number, respectively. When such an OID is used together with a bit of data, it is clear what this data represents, as well as what forms it may take.

Note that these valued OIDs function like form fields; they are not meant as placeholders for legal text, because that would defy the purpose of automation. Many OIDs will not even carry data, but merely express "the offering party" or "contract termination".

There are a few very nice properties to OIDs that make them highly suitable for extensible legal automation:

They are numeric. Unlike human identities such as words (or domain names) they do not change (or expire) but once defined, they are set in stone. The owner of an OID is usually advised to publish the meaning of such OIDs, once they are defined.
Their ownership can transfer at any of the dots between the numbers. The initial part of the OID notation is owned by standards bodies, but gradually lower entities are granted control over the OID. In fact, "lower" may also be in the service of peers.
Anyone can get hold of OIDs, so there is nothing exclusive about OIDs, merely about prefixes assigned to certain members. Meaning, if you really need to define a new object then you are not dependent on others. It is merely a matter of coming to a uniform (and easy to process) format that it is advisable to hop on with existing definitions already made by others.
The numbers are extensible at the end, which is usually done for refinement of the above-ordered OID. An OID could indeed specify what such refinements mean, for instance adding rights or adding obligations. This might be used to construct a notation for generalisation and specialisation of objects.
The numbers have canonical representations. In decimal, one could state that leading zeroes are not written down, and all of a sudden there are no variations in writing down these numbers. A similar thing applies when these numbers are written down in a binary format, such as DER. Having a canonical representation means that numbers can be compared very easily, either for equality or for one falling under another (as a dotted extension).
The numbers between the dots are unbounded. Not only in theory, but even in practice it is possible to write down numbers of arbitrary sizes; binary notations such as DER are not constrained to computation boundaries such as 32 or 64 bits, as our computers are. Comparison of numbers still works without needing to map OIDs to their numerical form.

These properties make the OID system highly dynamic and extensible. This should be a great value in composing a standard set of objects.

It is in the interest of all parties concerned to use a limited set of OIDs. It reduces the pressure on end users to accept new definitions and also helps with automatic processing. Especially the possible combination between new OIDs and all the ones that already exist can be dramatic, and should be avoided as much as possible if the intention is to get away from legal agreements that are in effect obscuring a relation, rather than clarifying it.

It is the immutable nature of the OID definitions that makes their terms readable; and technical constructs can be created to have third parties add notary signatures to what they have seen as definitions in another party's registry of OIDs.

Everything is a Relation

Things get interesting when objects are related. They start to form a logic. When (event) happens, then (action) will follow. During (service), the (party) may (right). And of course (party) resides at (postal address) and can be contacted at (phone number). There should be a fairly limited set of these relations. And each of them can be defined accurately... with yet another OID.

But now we turn to the topic of grammar or, as data formats name it, syntax. The relations that are possible between any number of objects should be written down in a form that is clear enough for automated processing but, at the same time, be extensible.

Being open to automated processing means that the logic should be really simple; when processing complex logic expressions, computers can end up being heavily loaded. Most contracts take a form "a AND b AND c" anyway, possibly with a few "(a1 OR a2)" variations. Generally, the use of "NOT" should be avoided. To get even more technical, implications may not be ideal on grounds of soundness.

So, what languages are there to write down such logical things? Plenty, I would say. But it is very important for security to not use a programming language but a data format, and that limits our choices. In addition, we want it to be supportive of future extensions and map to various forms. XML comes to mind for its easy mapping to readable web documents, but binary formats are much more compact and are easier to get into a canonical form suitable for digital signing. (XML can be signed with XML DSIG, but that is incompatible with the notational flexibility of XML, which leads to many problems in practice.)

The extremes can meet in the ASN.1 language. This is a data format specification language that can be mapped to various equivalent representations, inlcuding XML, JSON and canonical binary formats such as DER. So it would be possible to pass a binary form between parties, with digital signatures applied to them, and present it to the user through web interactions.

Having a general syntax that can be signed in one representation and deliver another representation for actual reading is a useful and unparallelled property of ASN.1. When it comes to this level of flexibility, which can greatly aid the user in presenting terms in a style that they like to review, there is no alternative, really.

So, what should be done?

If we want to go this way with InternetWide, we are going to need legal help. We will need authors who

Standardise objects as OIDs
Standardise relations as OIDs
Standardise an ASN.1 legal notation

and who can make a start describing the process of writing legal terms under these constraints, and helping people understand the importance of shared legal notions and a world-wide limitation of variation.

In addition, there will be a need for software to

Translate legal terms to the old, wordy form
Store and edit legal constructs deemed acceptable by a party
Fill out a party's details (using LDAP, for instance)
Mark unrecognised parts
Automate acceptance when nothing stands out as non-standard
Establish third-party timestamping of OID registries

Who knows, in some remote future we might end up negotiating terms, and end up with truly professional relationship management. But for now, the goal of automating the boring acceptance of agreements under a personal set of values is going to be much more useful than merely trying to get away with "TL;DR".

Want a demo?

Then take a look at the communication filter example.

New Web Era 1: Frontends and Backends

2016-02-04T22:00:00+01:00

This document is part of an article series on Web Architecture.

We often hear remarks such as “everything should be done over TLS” but this discussion barely touches upon actually securing the web infrastructure. As an example, hardly anyone realises that anyone can substitute for a TLS client. As a weak protection against this we have gotten used to passwords, but those are barely a challenge to an insisting attacker. So what can we do to actually make life better, while keeping the practical usability of the whole system?

Statics and Backends

The web began with static pages, later extended with dynamic pages, and later entire web sites became server-generated; nowadays, clients embellish a static basic site by rendering small pieces of dynamic data into it. This dynamic data often comes from a separate component that is plugged into the web server. The web server can then be simplified to serve static pages, and only be involved with dynamicity by proxying requests to purpose-specific backends.

Recall our intent on splitting domain hosting into identity hosting and domain-related services. In this architecture, the proxy web server is best located at the identity host and plugin services are perfectly located with a service. This way, the backends can offer configuration and browsing and whatever else they would like to offer to the identity host’s frontend web server. It also enables the combination of multiple services in that one frontend.

Crossing the Channel

One problem to solve in this infrastructure is the connectivity between the proxy/frontend and the backend. Since these are located at different parties, they may cross long distances of the Internet. More so, they may cross between independent realms of trust, so there must be some way of authentication and perhaps encryption. If we followed popular demand we would be calling to "do it all over TLS", but we can be smarter than that.

The static pages are relatively simple to resolve; any filesystem caching mechanism will do, with emphasis on publishing updates quickly. A very simple mechanism could be authorised uploads from the backend to the frontend/proxy, using a mechanism like sftp or rsync.

Dynamic backends in a website usually take the shape of JSON or XML snippets; backends rarely work with large blocks of information at a time, but their responsiveness is of direct influence on the feeling of interactivity. This means that the backend must be designed for this purpose. This guided us towards a number of interesting choices:

Connections between a frontend and backend are bulk connections. They carry traffic for lots of sessions at once, preferrably everything that links the frontend and backend. This evades the setup delay for new connections, especially the extra exchanges and heavy-duty computations of cryptographic authentication and key agreement;
Connections between a frontend and backend are made over SCTP. Being a bulk channel, the separation of frames is helpful. In addition, most dynamic frames will be smaller than SCTP's 64k frames, in which case they can be sent without care for delivery order, but still reliably; this avoids the head-of-line delays to which TCP can be subjected.
One connection between a frontend and backend can carry more than just web service. Additional links can be made for logging and monitoring, and general service management.

Example: HTML, CSS, JavaScript, JSON

Imagine a web server publishing static files containing HTML, CSS and JavaScript. Users may logon to this system, and access dynamically generated content, inasfar as they are authorised for it. The backend defines authorisation levels for users and service administrators, and the frontend is configured to map its idententies to these authorisation levels.

The protocol run over the SCTP connection between frontend and backend is supposed to be neutral to programming languages and other technological choices. A surprisingly potent mechanism to this end is the relatively old FastCGI de-facto standard protocol. This is already in wide use for backend connectivity within a web server, with a fresh TCP connection for each backend access, which would work badly over distances; we should instead pass it over an SCTP stream. The nice thing about FastCGI is that it has been specified with multiplexing capabilities, thus leveraging the flexibility that stems from an SCTP carrier.
The web proxy handles various forms of access control; our favourite example is TLS-KDH, because it is a single-signon system that can be used across realms and across application protocols. Based on the authenticated identity, the frontend can assign one of the authorisation levels. In addition, it may apply pseudonymity and roles if this is desired by the users.
Any dynamic portions of the web site are passed to the frontend as JSON fragments over such authenticated HTTPS connections. Meaning, the frontend knows that they can be trusted but the backend must still be convinced.
Now assume that one or more secret keys were agreed between the frontend and backend. These keys can be symmetric, to keep their interaction really simple. Using the appropriate key, the frontend could wrap the JSON request into standard JSON Web Tokens, using signing and/or encryption in a one-to-one fashion. The symmetric mechanisms skip the hard work of public-key crypto, making them light-weight and still leading to the desired certainty of protection from rogue access to the backend.

Solutions ought to be Generic

An approach based on JSON Web Tokens provids a good cryptographic mechanism, and it is relatively easy to get going. What it is not, is general. It covers JSON applications, but a parallel mechanism for AJAX would introduce the severe complexities of XML Digital Signing, and many other backend formats are not covered. Moreover, non-web applications are not covered. This is why we chose another general approach for the InternetWide Architecture.

We let the backend register with the frontend using GSS-API over one of the bulk SCTP streams. This means that the backend logs on as part of the Kerberos5 realm and services are created for paths like HTTP/www.example.com/svc/mail. Similar patterns can be defined for non-web services such as monitoring and logging. The backend would execute administrative commands over other paths than user commands, and rely on the web proxy to apply access control to these paths. The proxy does not contain application code, so it is far less likely to be corrupted than the backend with all its application logic. Meanwhile, GSS-API protects the link to the backend from rogue access just like JSON Web Tokens would — or better, since all symmetric keys are regularly replaced under GSS-API.

As far as end users are concerned, their separate passwords for the various sites they use are all replaced by the single sign-on benefits of Kerberos. This makes security much easier to manage, especially because Kerberos tickets last only for a day or so, and a derived ticket is tailor-made for each web site visited.

The internal structure of InternetWide web services is more complex than the current localised LAMP stack, but we have seen the progress of the LAMP platform come to a stifling halt since its inception 25 years ago, to a level where the distributive nature of the Internet is systematically in danger. The added complexity of the InternetWide Architecture exists solely to achieve the flexibility arising from separating roles for identity providers and service providers, which is meant to create a flourishing market for service offerings. Where an identity provider would focus chiefly on arranging access control, privacy and security, there is an additional option of revenue for service providers if they focus on specialised plugin facilities that can be used under any hosted identity on the Internet. The current “central” services on the Internet would co-exist with new, independent services that can connect liberally among each other because they adhere to standard protocols. And that is a future Internet that we believe is worth the investment of some added complexity.

ARPA2 All Hands December 2015 presentations

2015-12-17T00:00:00+01:00

The first ARPA2 All Hands meeting took place on December 9^th 2015 in Utrecht.

View the presentations

10:00-10:30	Arriving, settling down, getting coffee
10:30-10:40	ARPA2 Architectural Overview (Rick van Rein)
10:40-11:00	Getting over Quantum Computers (Rick van Rein)
11:00-11:15	Best Practices Git Workflow (Adriaan de Groot)
11:15-11:30	ACL work-in-progress (Tim Kuijsten)
11:30-12:00	Kerberos Realm KXOVER explained (Rick van Rein)
12:00-13:00	"Broodje Mario" lunch
13:00-13:45	Follow-up dialogues from the morning topics
13:45-14:15	Presentation and demo of SASL, tlspool and cmake work (Henri Manson)
14:15-14:45	Best Practices Git continued: tagging and releases (Adriaan de Groot)
14:45-16:00	Dialogue on project progress, integration and working together (Rick van Rein)
16:00-17:00	Drinks!

10:00-10:15	Welcome (Michiel Leenaars)
10:15-10:45	Introduction round
10:45-11:15	The Internetwide.org principles and ARPA2 roadmap (Rick van Rein)
11:15-11:30	TLS-KDH (Tom Vrancken)
11:30-11:45	Tea break
11:45-12:00	Steamworks (Adriaan de Groot)
12:00-12:15	Realm-crossover in Kerberos (Oriol Caño)
12:15-12:30	YourRealm/LDAP Hosting (Tom Vrancken)
12:30-12:45	Q&A
12:45-13:45	Lunch
13:45-14:15	TLS Pool (Rick van Rein)
14:15-14:35	Proxying (Jos van den Oever)
14:35-14:45	Q&A
14:45-15:00	Break
15:00-15:40	Brainstorm
15:40-16:00	Wrapup
16:00-17:00	Drinks

ARPA2 All Hands - December 2015

2015-11-30T00:00:00+01:00

We are organising the first ARPA2 All Hands meeting. This is scheduled to take place on December 9^th 2015 from 10:00 AM to 16:00 PM (UTC +01:00), followed by informal drinks and food to continue the discussion and brainstorming... Thanks to the national research and educational network SURFnet for kindly providing the venue for this event.

The participants of the first All Hands meeting of the ARPA2 project will get an overall introduction to the architecture and thinking behind ARPA2 and an update on the status of the various sub projects. Importantly (and the main reason for an all-hands) you will meet the other people that are active elsewhere in the project, and brainstorm about the future direction of the project.

Address

SURFnet, room 4.1
Kantoren Hoog Overborch (Hoog Catharijne)
Moreelsepark 48
3511 EP Utrecht
The Netherlands

Please find the directions on how to reach the venue.

Programme

10:00-10:15	Welcome (Michiel Leenaars)
10:15-10:45	Introduction round
10:45-11:15	The Internetwide.org principles and ARPA2 roadmap (Rick van Rein)
11:15-11:30	TLS-KDH (Tom Vrancken)
11:30-11:45	Tea break
11:45-12:00	Steamworks (Adriaan de Groot)
12:00-12:15	Realm-crossover in Kerberos (Oriol Caño)
12:15-12:30	YourRealm/LDAP Hosting (Tom Vrancken)
12:30-12:45	Q&A
12:45-13:45	Lunch
13:45-14:15	TLS Pool (Rick van Rein)
14:15-14:35	Proxying (Jos van den Oever)
14:35-14:45	Q&A
14:45-15:00	Break
15:00-15:40	Brainstorm
15:40-16:00	Wrapup
16:00-17:00	Drinks

Who should attend

We will do our best to arrange some form of remote participation, so if you physically cannot attend but would be interested in attending remotely, let us know.

Something's Cooking #3: Advancing TLS

2015-11-24T00:00:00+01:00

Perfect Forward Secrecy

Most current work on TLS assumes that we establish a property called Perfect Forward Secrecy. What does that mean?

Recall that security is based on certificates. This certificate contains a key, and it is valid as long as the certificate is in use, often for a duration of 1 to 3 years. For some of the highest-profile sites, it may be interesting to crack the keys in use.

Of course, keys are selected to be long enough to make this unpractical. But that does not mean that future developments could not cause a crack on such keys; we never know for certain that such things can never happen. In addition, truly rogue crackers might try to break into a server and gain direct access to a private key, in which case the size of the key is immaterial.

Given a private key, an attacker can do two things; first, it can fake being a site (meaning that a certificate must then be retracted and replaced with another immedately) but it may also look back to recorded TLS-traffic from the past, and try to decyrpt that. Perfect Forward Secrecy is the property that says that this cannot be done.

Not surprisingly, modern deployments of TLS take this important property into account, in the interest of protecting the privacy of their traffic.

TLS-KDH adds Kerberos to TLS

We are working on a long-felt need to bring two frameworks for online security together, namely Kerberos and TLS. The Kerberos world is very good at access to all sorts of services, such as email, shells including database connections, remote file access and so on. Strangely, it does not have a very good solution for secure access to websites. There are a few halfway solutions, but none of them is both secure and general.

With TLS-KDH we aim to fill this need for a general binding between TLS and Kerberos. The DH in KDH means Diffie-Hellman, which is a technical way of saying the Perfect Forward Secrecy is supported, another facility that Kerberos is longing for. Note that TLS is used a lot for the protection of secure connections, including for secure websites; it is what turns HTTP into HTTPS, basically.

Kerberos uses a type of algorithm known as symmetric. These algorithms are much faster than the public key systems that are otherwise being used for things like website certificates. In fact, it is surprising how clever Kerberos is in using these relatively simple algorithms and build an infrastructure on it. It does have the problem that a few central nodes, namely the Key Distribution Centres, have knowledge of all the keys in use and could potentially decrypt all traffic under their reign, but this is resolved with the addition of Perfect Forward Secrecy in TLS-KDH.

Future Preview: Kerberos with Impromptu Realm Crossover

The web is a world-wide system, and TLS-KDH is based on Kerberos, which is not. At least, not yet. This means that TLS-KDH is highly useful for a secure realm's internal services, and perhaps some that were explicitly incorporated in a federation-style, but TLS-KDH cannot currently connect the entire Internet securely.

The thing is, Kerberos bases everything on securely established relations between secure realms. This is model breaks the possibility of gaining access to arbitrary remote services with Kerberos, and thus with TLS-KDH.

This problem can however be solved in today's World, because we now have a globally signed, vendor-neutral infrastructure named DNSSEC. In addition, we have something called DANE that permits us to affirm service's certificates in this signed infrastructure. Combine the two, and it is possible to gain trust in a remote party, without any need for a mutually trusted certificate authority other than the technical providers of the DNSSEC infrastructure.

Based on this, it is possible to achieve what could be called "Impromptu Realm Crossover" with Kerberos. We have a project running to test the ability to do this right now.

Combining Impromptu Realm Crossover with TLS-KDH, we arrive at an infrastructure that can establish the Kerberos system. We have known this since we started designing TLS-KDH, and although the mechanism is going to be useful for in-house secure connections such as to internal websites, it will automatically upgrade to the entire Internet when we get Impromptu Realm Crossover in place!

Future Preview: YourRealm

Given that we are forecasting an Internet where Kerberos is everyone's friend, and indeed the richness of this highly developed authentication system enables secure access to services anywhere, we are left with the problem that not everyone currently has a Kerberos setup.

We aiming for a future where hosting providers will split their offerings into identity provisioning and service providers welcome guests under a Bring Your Own Identity mechanism.

But how about people without a hosting provider? For them, we envision public identity providers, perhaps as a service of an online shop that you frequent, as part of a family or corporate domain name, or as a general and independent service. It is for these types of service that we are developing YOURREALM.ORG; this system establishes your online identity with a sufficient degree of certainty, and then provides the cryptographic mechanisms that make it easy for other players to act on it. And of course we have Kerberos close at heart when designing this system.

Secure Remote Passwords

A final mechanism worth mentioning is Secure Remote Passwords, or SRP for short. This mechanism is gaining popularity because it is not just any other password mechanism, but comes with very advanced cryptographic properties.

First, SRP establishes an encryption key that has the Perfect Forward Secrecy property. Second, and much more impressive, it also is what we call a Zero Knowledge Proof; the remote service can validate the password without actually getting to see it. The service cannot possibly use whatever it got to login to another website on your behalf, even if you used the same password for that site. That is so much better than the current web practice that it is mind-boggling.

SRP is a strong mechanism in itself, but we are trying to take it even a step further. We are trying to integrate the mechanism with secure tokens, usually in the form of a simple USB key, that hold the password and would never hand it off. Since the rest of the pathway is a Zero-Knowledge Proof protocol, this means that it will be impossible to authenticate with SRP without this token. So, unplug the token and further logins are disabled. This does a great thing for reliance on midly untrusted desktop environments.

Moving towards Elliptic Curves

Cryptography is moving towards Elliptic Curves, for reasons of compactness and efficiency. This is a new generation of cryptosystems, and in some cases they are in high demand. A place where they are especially called for is Diffie-Hellman, which is the mechanism to achieve Perfect Forward Secrecy.

For TLS-KDH, we are not going to use the older ("modular exponentiation") generation of Diffie-Hellman anymore. And our work on Kerberos will also center around the newer "elliptic curve" generation.

Another point where Diffie-Hellman is used is in Secure Remote Passwords. Here, the mechanism is entwined with the mechanism, so replacing it is not trivial. In fact, a number of competing alternatives is under discussion. Our work on showing SRP combined with a hardware token is meant to influence this discussion towards making similar things possible with a future "elliptic curve" generation of SRP.

A lot of talking

We do not accomplish all these things on our own. We are actively engaging discussions on these matters in the Internet Engineering Task Force work groups that relat to these matters, especially Kitten and the TLS WorkGroup.

Imagine a bunch of highly skilled technicians, openly discussing ideas and open to external input. Dropping an idea in those groups tends to raise both interest and a lot of technical feedback. It can be daunting, but is in fact highly challenging, to live up to the combined expectations of these top-notch engineers, most of which are highly skilled in a diversity of expertises.

I dare say, we have a thing or three cooking...

Something's Cooking #2: TLS Pool

2015-11-16T00:00:00+01:00

For an overview of the recent changes see Something's Cooking #1 or the GIT version with these changes.

Up next: Validation... finally!

It may sound silly... the TLS Pool is an architectural improvement on how we manage TLS connections such as secure websites, but the most vital part of it is still pending. This is the actual validation of the remote identity.

The reason for this is simple. We didn't want to launch a "first stab" that would do a few things right, but without proper integration with the rest of our framework. We are now ready, in terms of design, to add validation in a way that we feel to integrate properly. It should be obvious that this is a major requirement before the TLS Pool can actually be put to use.

Clever Databases

As described in the TLS Pool documentation, the TLS Pool maintains a number of databases that parameterise the TLS Pool with just what it needs to know about certificates, keys and passwords. These are the so-called credentials, and we setup a refined system to help its users control how to authenticate remotely, such as what external identity to portray; this is an important part of our policy to Bring Your Own Identity which we feel is an important step to let users control their online presence.

The databases that control TLS Pool behaviour contain the following information:

Local identities include credentials, including references to private key material behind a protective PKCS #11 interface;
Remote identities map remote peer identities to the local identities that we have decided to reveal to them;
Trust details the trust anchors that we rely on;

The latter is in fact a new addition that we introduced for the validation framework.

Sources of Validation Constraints

The three databases represent different angles on the TLS process, and each of these angles could give rise to constraints to be applied to the validation of the TLS Pool:

Some of our local identities may only be used in highly secure connections;
Certain remote identities may only be trusted under extremely rigorous security checks, while we could be more relaxed about others;
A particular trust anchor may only be trusted when certain added constraints are validated.

This means that the databases, in which we already tend to lookup information for the purposes of TLS connection setup, provide us with excellent places to store validation constraints. The constraints found in these three sources will be combined; each of them must independently apply.

Several of the lookups in databases actually follow a search path; that is, if an exact match is not found then a more general alternative is tried, until we hit on a match or until we cannot generalise any further. The mechanism used is that of the DoNAI Selector, because that links well with various Internet technologies, and indeed it lends itself rather well for introducing constraints; we also described a similar idea for access control before.

Expressing Validation Conditions

The expression of validation conditions is done in the form of a logical formula; ideal for both administrators and automatic processing vehicles such as the TLS Pool. The nice thing of these formulae is that they can be combined at will, without structural exceptions.

We have even designed the validation system to be, as much as possible, independent of the type of authentication system used; for instance, DNSSEC-based validation would be implemented through DANE's TLSA records for X.509 certificates, and through CERT records for OpenPGP keys. And if we ever add OpenSSH as an alternative transport to TLS, then the DNSSEC-based validation would make use of SSHFP records.

This style of validation is much more general and much more expressive than the customary choice between cipher suites, which is more technical and more zoomed-in on incidental technology. We do achieve the same effect, but at the same time we establish a mechanism that can describe alternative protection mechanisms. This is a main part of the design of the TLS Pool, to have many security mechanisms to choose from, so as to be able to switch to another game when the originally used game is over, for instance during temporarily elevated security risks.

Checks to be Built into the TLS Pool

The following is a current list of the types of elementary validations that we intend to make combineable through logic expressions in the three databases mentioned; each is represented with a single letter, where uppercase indicates a stronger check than the lowercase form:

Trust anchorage (T, t)
No known revocations (R, r)
Forward secrecy (F, f)
DNSSEC-based identity checks (D, d)
Pinning, including TOFU-style (P, p)
Anonymous precursor privacy (A, a)
Online / live information checking (O, o)
Global Directory checks (G, g)
User-defined security levels (L, l)
Presence of remote identity (I, i)
Extensions / flags fit for purpose (E, e)
Username match (U, u)
Server-only and Client-only roles (S, s, C, c)

Each of these mechanisms gives rise to separate lookups of (online) information that leads to a positive or negative decision about the validity of the connection built up in the TLS Pool. When positive, the connection passes and may be used by the application; when negative, the connection will be reset and the application receives an error message.

Distributed Control

The requirement to specify this type of expression may feel like a burden, because it is rather technical in nature. But this is precisely the purpose, namely to control security with a fine comb. It is not our intention however, to load this burden onto every user.

We have an infrastructure prepared to setup these fine controls over security in a central place, and distribute them to users in various places. This is the SteamWorks infrastructure. This uses LDAP technology to download configuration information, and stay up to date with new settings. The resulting system is the best of all worlds, where changes in security settings pass through to end-user and server stations almost immediately, provided that they are online.

The setup of the TLS Pool around databases now pays back; external programs are permitted to modify the database, and precisely that is what we intend to do for the TLS Pool; namely, to extract data with a so-called Pulley component from the SteamWorks architecture, and to deliver the information found in these databases that steer TLS Pool behaviour.

Authentication Framework Integration for Applications

Within a connection whose transport security is protected by the TLS Pool, there usually is a desire to authenticate a remote user. Since the TLS Pool supplies authenticated identities for both the local and remote peer, and since these are subjected to validation procedures that can be flexibly controlled by professional administrators, there is no need for individual applications to concern themselves with the mundane details of authentication and security. This is a design goal of the TLS Pool, to separate the tightness of security from the frivolity of application logic.

The separation may be a new idea, but the mechanics are actually available in current-day protocols. It is very common to use SASL as an authentication mechanism inside TLS; this is in fact inefficient and less secure than it could have been, because the encryption in the TLS connection is not cryptographically bound to the authentication of SASL. It is a method for using relatively weak password-based authentication mechanisms, though.

But instead of this two-stage process, it is possible to rely on a special authentication method within SASL that is called SASL EXTERNAL. This mechanism was designed to make use of any authentication that could have been setup in an outer layer -- and our TLS Pool is a very obvious example of this mechanism. With SASL EXTERNAL, the application logic only needs to say "I would like to be jimmy@example.com today" and a simple check with the credentials provided by the external layer (in casu, the TLS Pool) will suffice to pass the request.

I dare say, we do have a thing or two cooking...

Something's Cooking #1: TLS Pool

2015-10-26T00:00:00+01:00

What is the TLS Pool?

The TLS Pool project is a design of a program that handles authentication and encryption of TLS. You may know TLS as SSL, or even just as the protocol that turns websites into secure sites -- even if it also protects your submission and retrieval of email, your chat and much, much more.

The idea of making a separate program (that runs in the background) for TLS is that this separates the sensitive handling of security mechanisms and keys from the applications that sometimes hold rather frivolous code -- including adverse code such as advertisements that may do anything to get an idea of who you are and what you are up to.

In addition, although we don't discuss it here, it is possible to use the TLS Pool under our SteamWorks architecture, which means it can be controlled centrally. In other words, the complexity of security settings can be turned into a service that may be organised and controlled by a knowledgable specialist party.

More than just TLS

The initial versions of the TLS Pool were full of TLS. The code and ideas of this protocol were everywhere. We restructured the code to concentrate everything TLS-specific in one module, so that future extensions could choose to use other protocols instead of TLS.

The idea behind this is that TLS itself has problems at times. Ideally, there would be alternative carriers, perhaps the OpenSSH protocol or something based on GSS-API. Being able to setup multiple such protocols in parallel and then to weed out one that is (temporarily) having problems offers great control to the security officer.

This extension may seem far-fatched, but it isn't. Not really. Most protocols start without TLS protection, and then issue a command that is often called STARTTLS to turn the connection into a TLS-protected connection. There is no reason why there could not also be commands STARTSSH and STARTGSS to do the same thing with another protocol. The only thing that would need to be done is to define such extensions, and get them implemented in software.

As far as the TLS Pool is concerned, this change can be started. Although it is not directly usable, the internal structures of TLS Pool have been adapted to be highly supportive of this change.

Separating out service knowledge

Under the TLS Pool, knowledge about TLS and its configuration is kept away from the application. This helps to simplify applications, and thus to keep them secure with less effort. Examples we've seen in adding TLS to an application ranged from hours to days of work -- because all that the application needs to do is hand off a connection and start a new TLS-wrapped connection. If it wants authentication, its only requirement is to offer and consume the established identities that the TLS Pool provides as a result of its setup work.

As a result of this, it has also been necessary to take out service knowledge; that is, how to differently treat certain security aspects of web versus that of email versus that of chat, and so on. This is now handled by simply naming the protocol in a standardised way, and let the TLS Pool derive from that how to deal with it.

Part of this handling may be configured by a (central) security officer, who may decide that some protocols deserve different treatments from others. All this refined control is available to the application if it only does what it can very easily do -- provide the name of the protocol it runs within the TLS connection.

Local Identity Selection

The local side of a TLS connection may need to prove its identity to the remote peer. It may be desirable to select the local identity in a manner that depends on the remote peer's identity. Reasons for this include privacy, and the desire to change from a personal identity to a group or role identity.

The new TLS Pool comes with an extra interface over which a user can register to be asked when identity decisions are made. Such decisions may be popped up in a manner that is standard for the operating system environment, and choices can be stored for later reuse if it turns out that the selected local identity succeeds in terms of TLS setup.

It is especially useful that this happens through a separate interface, and not as part of an application's interaction with the TLS Pool. For one, this keeps applications simpler and therefore easier to secure. Secondly, the application may contain frivolous code that should not get in the way of these privacy-sensitive choices. Thirdly, users will appreciate having one central and standardised interface for these operations that sets up the same identity for all kinds of protocols relating to the same remote peer. Finally, it is possible to construct an identity selection mechanism based on a simple menu where one sets the identity that should be used for all current actions, and that identity can be changed with a simple pull-down menu in a standard place of one's interaction with the system.

End-User Password Exchange

Even when two parties are connected, they may still have a hard time exchanging a password or other secret key. One side may generate a value and pass it on, but that does not always lead to the same security level as provided by TLS itself.

To remedy that, a standard has been created for derivation of passwords based on the complete TLS security that has been established. This standard has been implemented in the TLS Pool. This permits applications to do such things as pick a password securely while on a web page, or engaged in a chat session, and so on.

Better Anonymisation of Traffic

Before the TLS connection is setup, it exchanges credentials that may leak private information to bystandars, including rogue inspectors of traffic. There is a facility that first achieves an anonymously encrypted session, and then continue exchanging the privacy-leaking credentials under that cloak. This facility is not commonly used, but it helps because it makes it impossible to do such rogue inspection without being noticed.

The TLS Pool has been extended to consider the service that is being run over TLS, and based on that to make a choose whether anonymisation would be safe to incorporate. Doing this means that the TLS Pool can be very tight in using this anonymising precursor to the rest of the TLS exchange.

Preparation for Symmetric TLS

The TLS protocol normally needs to be quite sure which side acts as a client, and which acts as a server. Although that is reasonable for applications such as the web and email, it is not necessarily so with modern developments.

The client-server model on the Internet is progressing towards monstrous-sized server parks, which are devestating to the distributed model that makes the Internet such a powerful mechanism. We won't even begin about the potential impact that such "central" sites can have on end-user privacy. In a logical response, we see a strong movement of Internet technology towards more peer-to-peer functionality; although started off as file sharing technology, these functions are now also used for things such as chat, telephony and more.

Such a model does not have the clear separation between client and server roles. The old TLS Pool would start TLS as a client or as a server, but the new version will simply start TLS, and use a couple of flags to signal for the local and remote sides if they could be a client and/or a server. The ability to specify that either is acceptable is helpful towards the client-server model. As soon as the TLS stack supports it, the TLS Pool can start to use that and be highly beneficial for such modern directions of Internet development.

In addition to the above, the authentication model has moved along; rather than speaking in terms like client identity and server authentication, the change has been made to speak in terms of local and remote authenticated identities, and whether they are locally provided and remotely required. The result is a more evenly balanced TLS model that can still do everything the old model did.

Efficiency Updates

When initiating TLS, the TLS Pool assumes that a connection has already been setup. It is then passed this connection, and a new connection with TLS added was passed back. We changed this, and now let the application pass in a connection over which TLS should be used.

This is a minor (although incompatible) shift in how the interaction with the TLS Pool works, but it is a major benefit in terms of efficiency. Connections can now be completely handed off to the TLS Pool if the external connection can be setup. Its main benefits are less context switches (which make a processor purge its state and start from scratch).

In terms of user applications, it is now very straightforward to have a tunnel setup TLS and then disconcern themselves from the process. This means that a TLS tunnel can be highly scalable. And yes, we're including precisely such a tunnel with the TLS Pool.

Flexibility through Detachable Control

We have improved the flexibility of handling the TLS Pool from applications. One application may "detach" the control over a TLS connection and another application may pick it up. This gives application programmers greater control over the TLS Pool.

Possible extension: On-the-fly Certification

Some applications work better when a trusted component sits between a TLS end point and the general Internet. To do this, the trusted component usually terminates the TLS connection, and protects all its traffic to the end point with certificates that it generates on the fly.

This is a function that we are currently considering for inclusion into the TLS Pool. We are not yet sure if it belongs in the TLS Pool itself, or in a tunnel application running on top of it. The design of the TLS Pool however, is based on strong protection of security credentials behind a PKCS #11 interface, and that may be a good reason to add it to the TLS Pool.

I dare say, we do have something cooking...

Identity 5: Integrating Kerberos and SAML

2015-04-25T00:00:00+02:00

As explained in lessons learnt, bring your own identity, forms of identity and even tricks with identities, we have a clear notion of how to conceptually deal with identity.

These structures are presumed to be feasible for the web using one technology, namely SAML, and for most other protocols with another technology, namely Kerberos. The two can even come together with our own work on the KDH CipherSuite for TLS. The one thing that we need to address is how the Kerberos and SAML systems can work together. This introduces quite a bit of research because both systems need enhancements to match well and their coupling needs to be defined and preferrably standardised.

Meet Kerberos

Kerberos is best explained in a dialog that explains how a client, a service and a central realm controller (named the KDC) collaborate to get the client to securely access the service. The client logs on under the KDC for its realm, and in the simplest case the service falls under the same KDC.

When client and service realms differ, a facility for realm crossover is needed. This is defined for Kerberos, but only for statically created realm links. We therefore described dynamic realm crossover based on modern techniques such as DNSSEC and DANE; we have drafted designs that enable such automated linkage. All this is done as part of internet-wide standardisation processes in the Kitten workgroup of the Internet Engineering Task Force. Such standardisation processes represent a major effort, since it involves many experts which judge proposals to achieve the optimal protocol from a multitude of angles.

Recalling the picture for our architecture,

the most innnovative part for Kerberos is the "Identity Perimeter" that conceals internal identities, or permits clients to act on behalf of groups of whom they are members. At present, Kerberos can only offer a generally recognised anonymous identity; but there is no facility for changing to a pseudonym, role or group in current Kerberos systems. We believe this is beneficial to gain control over online presence as well as to permit group co-operative account.

Meet SAML

SAML is a web single sign-on system. When accessing a servive the browser will be redirected to the client's SAML identity provider, which could be an IdP component of the InternetWide.org infrastructure (or, in terms of code projects, an ARPA2 identity-providing component for SAML). The client would logon on this locally-known site or, if that had already been done, skip that step; the client's browser would then be redirected back to the service, carrying an Authentication Statement. On the service provider's end, there would be an authorization decision based on this statement, and the outcome would determine the client's access rights to the service.

Note that, as incorporated into our infrastructure, authorization decisions and access control reside in the server's realm, whereas the identity provider and its release of Authentication Statements runs in the client's realm.

An extra building block in a SAML infrastructure could be a SAML proxy like OpenConext that is a single stepping stone between a collection of identity providers and a collection of service providers. One task we have ahead of ourselves is to integrate with such software, to make it possible to find the identity provider that we build into our APRA2 projects.

Introducing Attribute Statements

One aspect of SAML that is really inspiring is to pass Attribute Statements from identity provider to the authorizing service. Unlike an Authentication Statement that reveals the identity of a client in a verifiable manner, and Attribute Statement is designed to only make verifiable statemenQs that are somewhat general and could apply to many. Example are whether the client is a student, whether he is an adult, or what colour of belt he holds in Jiu Jitsu.

Both types of statements from the identity provider have their purpose; when access is general and there is no need to store individual data, then the attributes suffice. When client-specific storage is required, an identity will be needed to find back the stored details during a future visit. As explained before, we think pseudonyms, roles and groups can can add value in such situations. Even when an identity is provided, it may be helpful to provide attributes; given that the client realm can be trusted to make these attribute statements accurately, they can relieve the service from administering the information, and keeping it up to date.

SAML meets Kerberos

The integration between SAML and Kerberos can enable arbitrary exchanges between the two single sign-on systems. Meaning, login once and from that moment on continue to use that access.

Although many facilities exist to "pre-authenticate" to Kerberos with external mechanisms, and it is certainly possible for a KDC to learn to accept a SAML Authentication Statement or even an Attribute Statement and produce a Kerberos ticket, it is not the logical way to go: This would take credentials from the highly dynamic, externally exposed browser environment and apply them to the more stable desktop / OS environment that hosts Kerberos. The opposite direction appears to be much more reliable.

In short, our aim will be to use Kerberos infrastructure extended with SAML carrying facilities that can then be used in SAML environments. In SAML terminology, we define a SAML Kerberos binding to carry SAML statements over Kerberos' messaging channels.

The SAML information carried around must support authentication. For the client, this will be founded on the origin being the local KDC; for the service, authentication is based on concealment in a ticket that can only have come from the client's KDC as established through realm crossover between the client's KDC and the server's KDC.

As it turns out, Kerberos messages and tickets have various places that can hold SAML statements. Using the technical terms to keep it accurate, the apparent options are:

A PrincipalName, covering the client's identifier under a realm, can take on numerous forms; a new and easily readable form could be defined for attr=value settings.
The AuthorizationData embedded in Tickets can be made to hold a SAML fragment, such as an Attribute Statement or an Authentication Statement. This may be done when crossing over to another realm, but will generally be determined by the local policy on the client's KDC.
For realm crossover, we already expressed the intention to have an Identity Perimeter that could optionally replace a client's identity. This issue would arise when a client, contacing his local KDC, needs to crossover to another realm. The KDC can recognise this situation and implement policy to switch to another identity, be it pseudonym, group or role; or he might simply validate a requested identity switch requested by the client during a query for a service ticket.
The flows for SAML allow an Authentication Request (sent from the service to the identity provider) to ask for a set of desired attributes, which is not currently possible with the forward-only flow of a Kerberos system. Solutions can probably be constructed by incorporating the set of desired SAML attributes with the DNS record that we need to introduce for realm crossover, to state things about the service such as its Kerberos realm name. This DNS record would also be the place to select whether an identity and/or a set of attributes is required; and even to define whether SAML is welcomed at all during Kerberos exchanges.

This framework would be advantageous to both Kerberos and SAML:

Kerberos gains facilities of identity modification, dynamic realm crossover and attribute-based statements that enable simpler filtering in an authorization service;
SAML gains accessibility to other protocols than just the web; it gains an additional binding that enhances its security by integrating with the transport level and staying out of control of the same JavaScript level that hosts adverse applications, including arbitrarily sourced advertisements.

In short, there is a lot of work to be done to actually make this integration, but it is such a valuable investment that we believe it deserves our attention.

Identity 4: Tips and Tricks

2015-04-24T00:00:00+02:00

Earlier parts of this series covered lessons learnt to this series and presented various forms of identity usable under our bring your own identity policy. We now turn to a number of tricks that can be nicely positioned in this framework.

Collections of Roles

It may seem awkward that we decided to reveal a user's base identity as part of a role. The shared key material explains it technically, but still it may seem awkward to conceal john@example.com as john+singer@example.com.

Where this is considered problematic, it may help to create a group or pseudonym next to the primary identity, for instance artist@example.com and define roles such as artist+singer@example.com as totally independent of john@example.com.

When artist@example.com is a group that contains john@example.com, then he will be able to access communication to the group without separate login; if artist@example.com is created as a pseudonym, it will require separate login.

Regardless of the use of role, group or pseudonym, there will be separate access control for each new identity (although the role inherits white and black lists from its base identity, and expands on them).

Temporary Identities

A portion of the framework can be setup to permit only temporary identities. These identities can be useful to deal with remote services that need a one-shot treatment or those that insist on sampling an email address. Of course, for longer-used services, a role is better because it reserves an identity for a longer term.

A temporary identity can take various forms; a few could be

timed+1430049266@orvelte.nep
code+3bae0bcfacd8fc07f08f19f6b7efc29f@orvelte.nep
tmp+xxyyaa@orvelte.nep

The interpretation would be dependent on the part before the plus sign. For example,

timed+1430049266 may indicate an identity that times out at the given timestamp, which is a few days after publication of this blog article;
code+3bae0bcfacd8fc07f08f19f6b7efc29f might incur a check on the messages passed, for instance to see if an email quotes a particular Message-Id or related header.
tmp+xxyyaa@orvelte.nep could be a simple account setup under a temporary name xxyyaa and that will only pass traffic for as long as a client is listening. When the client logs off, the identity is retracted from service.

Generic Names

Many sites choose to setup local names such as info@ and sales@, so they can be reached by guessing customers. Given some attention to spam filtering and perhaps to staff removing false positives, this may make sense.

Such generic names can be setup as a group name and address any number of members, or they can be setup with a foreign identity to which theh traffic is relayed, in a bidirectional manner. The result of this is that traffic sent to these generic names are also replied from those generic names.

Identity 3: Forms of Identity

2015-04-23T00:00:00+02:00

As described in the introduction to this series and in the components used for it, we ARPA2 users can exercise great control over their online presence. We will now explain what forms of identity can be unleashed.

Individuals -- with aliases and pseudonymity

We have all seen user accounts, where we receive a unique name under a "secure realm", also referred to as a domain. In terms of the InternetWide Architecture and the implementations of it as ARPA2, we always write such identities in a notation similar to email addresses,

bakker@orvelte.nep

Here, orvelte.nep is the secure realm, and bakker is a local identity, probably of an individual client, within that secure realm. Nothing new up to this point, except of course the ability to bring your own identity that supports use of this identity everywhere online.

But using the same identity can also facilitate tracking, and it can make it difficult to filter traffic. These two issues are addressed with different variations on these identities.

Totally Separated Pseudonyms

Our client known as bakker@orvelte.nep may wish to have a totally separate identity, and toggle between those as he sees fit. The second identity might be

smid@orvelte.nep

Reasons to separate identity could be many:

The online activities in the new identity are totally different, and should stay separate, from the ones in the first identity.
The groups in which the identities co-operate are not the same.
The second identity may be subject to independent ownership changes.
The user wants to act under privacy for certain online conduct.

The idea that we pursue with pseudonyms is not to be anonymous, and thus have no facilities to collect state or access accounts, but to have completely separate online identities.

In terms of security, the InternetWide Infrastructure will create fresh keys for the establishment of certificates and PGP public keys and so on. It will not make any administrative connection between the identities.

Given that we present a single sign-on framework, it is important to realise that each pseudonym is completely separated from other identities; in fact it is just an extra user identity. This means that login to each identity must be done separately; having three pseudonyms means that three "single" sign-on logins must be done per day, rather than one. This is the price to pay for privacy; it also means that each of the pseudonyms can be logged out separately, which may be advantageous.

Light-weight Aliases

Based on a client identity, variations can be made by adding a plus and (what could be called) a sub-identity. For instance, the identity

bakker+shop@orvelte.nep

could be used to signify shop-related affairs. This mechanism is lightweight, in the sense that the identity of the original account is hinted (although no formal conclusions may be drawn from this client-local naming habit) and therefore the same security keys can be shared that were defined for bakker@orvelte.nep.

This sharing of key material makes all the difference. The creation of new key material is relatively costly, and storing it most certainly is. There are bound to be limitations to the ability to stretch this key material, which are bound to translate to price levels and maximum numbers in licenses. This level of control is not reasonable for this light-weight alias.

Another advantage of sharing key material is that it is not necessary to login to each alias separately. In that sense, the alias is much lighter in use on the end user as well.

The major benefit of a alias, aside from its separate name that helps to sort traffic or give it somehow other treatments, is that it also gives rise to separate use within our access control framework which uses the local name as an index to determine what remote identities are permitted to access it. In case of bakker+shop@, the approach would be to combine whitelists and blacklists for the identity and that of bakker@, and to use the default policy from bakker+shop@. Newly contacted remote identities will end up with the identity that was used in outward direction, so that would be bakker+shop@ when that was used for communication.

This permits use cases such as:

Block all traffic to bakker@ by default, but permit traffic to bakker+shop@ by default. When bakker@ is not used for outgoing traffic, the ACL would learn to accept only access to bakker+shop@ and similarly could the ACLs of other aliases be filled. When bakker@ is used directly, it too can learn an ACL, and its members would have access to all aliases as well. This principle acts like the aliases of an identity being separated.
When contacting a new webshop, a new alias can be created on the fly. The authentication is founded on previously established cryptographic keys, but the new identity is strictly meant for access by the webshop. Their use of any other address can easily be blocked. When done trading, the identity can be closed. This puts the user back in control regarding "spam" from parties with whom they had a business relationship. Privacy laws don't always enforce client control over such relations, and termination of such relations is a bit vague. Using this mechanism, the client doesn't need to jump through the questionable hoops of a determined "business relationship".

Identities for Groups

In many cases, you will want to work together in a group. This is an important part of identity management, as you will often want to define access control to services in terms of a group. Why? Because it is easier to manage a group then to grant access to a list of online services. This is especially true if remote services are part of the mix; it is usually more difficult to setup their access control, while it is relatively straightforward to add or remote a member of a local group.

For this reason, the InternetWide Architecture not only lets you create users, pseudonyms and light-weight aliases, but also to create groups quickly and easily. Groups are created as lists of users, in which the creater is entered by default.

Groups are subject to access control for the CRUD actions: create, read, update and delete of members. By default, a user may read and update its own membership entry, but creating a new entry (for oneself) or deleting it (for one's own entry) may or may not be controlled by the members themselves, let alone for other members.

Groups have a common name, like

ambacht@orvelte.nep

As you can see, there is no distinction in the form of identity compared to users.

Members can be assigned a subname that looks like the form for aliases, namely

ambacht+bakker@orvelte.nep

Addressing the ambacht@ address means addressing the group, while addressing ambacht+bakker@ means addressing a group member that is known within the ambacht group as bakker. There may or may not be a relation to user by the name of bakker@orvelte.nep.

What it means to talk to a group, or even a group member, depends solely on the application. When you select services to run for your identities you should take notice of the choices made here. A few examples that may or may not work as we can think of abstractly:

Websites accessible to a group are either accessible to individual members or, more practically for remote service access, to the group as a whole; when a member is added to, or removed from the group the website will automatically adapt to the new group configuration.
Email to a group is only permitted for group members; email is forwarded to all current group members; email history is stored in an IMAP mailbox that can be accessed by all current group members; but how is encrypted email handled?
SIP telephony to a group rings on all the phones of all the group members; the first one to answer will get the call, and cancel the incoming call on the other devices; alternative implementations could introduce ordering, and so on.
XMPP chat to a group is delivered on a group channel, to which group members are permitted to subscribe. When the group configuration changes, so does the access permission of group members to the group channel.

Identities for Roles

Roles are used in authorisation issues, so to answer questions like "can this user A access resource R?" -- so roles are assigned to users. A common example of a role is admin, but it might equally well be sales, research or parent to shield of parts of the infrastructure.

Users can have aliases such as john+admin but that would not be a safe way of assigning a role to a user, since aliases can be created on the fly. Instead, roles take the same external form as a group with a member; there is no need to externally distinguish about these forms, and internally a lookup will add the desired information.

Administrators might be assigned the role admin, and when John is added he might go as admin+john -- which does not refer to the user john but to his alias john+admin. Note that nobody but john can create this alias, so this use is secure.

As with a group, there is a separate key for a role that all role occupants can gain access to with their matching alias.

Distinction between Roles and Groups

Roles and groups look similar, and in many ways they are similar. Communication protocols however, are likely to treat them differently. Where a message to a group member would normally be copied to other group members, this is not the case with roles.

Users from Another Planet

Protocols generally have ways of dealing with accounts that pass on their traffic to another account. In its simplest form, this is comparable to email forwarding, but that simple form brings about many problems:

Frameworks for spam filtering like SPF can get confused because they receive email forwarded from a source that is different from the permitted ones, namely the forwarding mail service; this however, is a local problem.
Messages relayed to a "real mailbox" from a general name such as an info@ address are replied to from this "real" address, causing message filters to have less control over whether the reply is reliable. Note that the change of address is also not generally what the sender wants; their "real mailbox" is often of a temporary nature, perhaps because it is assigned by their current ISP.

In general, it is better to use something akin to network address translation, especially because its inherent problems for the IP protocol don't apply to the flexibly-sized strings used as identities.

If anyone flies in from another planet and should be granted an identity under a given secure realm, then a foreign identity may be assigned to the identity may be attached. For incoming traffic, this would get forwarded just like is customary for email, but there must be an arrangement for return traffic as well. The method used for this is specific to a service.

There is no reason to limit this facility, other than to make it usable only for individuals; so, individual users and pseudonyms, aliases, group members and role players can all be from outer space, as far as the identity framework is concerned; groups and roles on the other hand, are always locally defined.

Note that a service should also be selected for its support of this facility, as not all may be able to support foreign identities; in that case, the visitor from outer space cannot use that particular service, be it email, chat, telephony or whatever else is being suppressed.

Simple one-sided forwarding is explicitly prohibited under the InternetWide Architecture; it leads to hacks, and reduces the opportunity of other users to filter content.

To the Remote Service, it's All the Same

A final thing worth noting: To the remote service, that is the one to which you are bringing your own identity, all these forms of identity look the same. Sure, the use of a plus sign is more often used to do these things, but no-one can assure you that this is indeed the case as it is subject to the local policy on the client's end. And groups are not distinghuishably named from individual users, which is also relatively common. Of course pseudonyms, with their strong emphasis on absolute separation of usage patterns, most certainly are not distinguishably named.

Update 10 december 2016: The name role was applied to what is now called alias. The current use of a role as an authorization mechanism had not yet been defined.

Identity 2: Bring Your Own Identity

2015-04-22T00:00:00+02:00

This article explains the architecture to build the ideas from the introduction to this series.

Client and Service Realms

When we speak of Bring Your Own Identity, or even just BYOID, we want to express that you are running an identity provider under control of the client, and use it to access a service. Although it would be possible for the service to reside in the same "secure realm" as the client, it is more general to consider them as (possibly) different:

The action of the client to bind to its realm is called authentication, or proving that you are permitted to use a certain identity. This can take the form of a (daily) logon with the local identity provider. Assuming that the identity provider is under your control, for instance due to a service contract that you can influence because you pay for it, you can rest assured about your privacy being protected by the client realm.

The service usually wants to limit access to whatever "resource" it provides, and to that end it conducts authorisation to establish what rights are available to the identified client.

Before authorisation can commence, there first is a need to establish that the client's identity. This is a difficult problem, because it involves realm crossover, and in general needs to establish trust in an independently managed realm. The link explains the various mechanisms available to do this, and inhowfar they are suitable. We believe that Kerberos holds the best cards:

It is a highly secure mechanism
It is relatively easy to expand with realm crossover
It is widely used in infrastructures
It is the most efficient mechanism due to symmetric keys

Changes to the client identity

Even when a single login gets a user through the day, that does not necessarily mean that the same identity should be used throughout that day. There are a few reasons to change the client identity:

local client identities may not be meant for public use
services may be best accessed from a group identity
some services should only get a temporary, or remote-specific identity

This means that we want to have a facility to change our identity when we crossover to another realm. The general idea is one of limited disclosure of identities; or more accurately, the end user gets to setup a desired identity for each remote service accessed.

The resulting infrastructure now boils down to an outgoing filter at the client side, and incoming filtering at the server side. This looks like the most general facility one could have.

Identity 1: Learning from the Present/Past

2015-04-21T00:00:00+02:00

The present situation

When you want to use a server, you usually go to its website. And when that website wants to store data just for you, it will ask you to create an account on that server. You are asked to pick a username, a password, perhaps click on a link in an email, and you're done. You think.

First, the username; why must you pick a unique name? Because the data attached to that username should not be mixed with that of others. But isn't it a nuisance to have a different username for different services? This is aggrevated when you use these services to communicate with friends; each needs to learn of a new identity for you over each of those mechanisms.

Then, the password; this is an insecure mechanism to access online services. This is especially true when you share the same password (and username) accross a number of services. Basically, you are allowing them to login to each other's sites. A more technical drawback of passwords is that they are often the same over long periods of time, and that they are not sufficiently secure. Patches can be made with clever client-side tricks, but they are mere patches, and won't live up to the level of security of a proper cryptographic solution.

Then, the email address; you usually need to supply this as a method to recover a forgotten or lost password. Providing such a general form of communication also means that "service announcements" can be sent to you, which you may not be interested in when they take the form of advertisements. In general, you would rather not provide your email address to each service you try. Also, the habit of checking an email address by sending a link to click on for confirmation is a manual, silly mechanism of establishing your online presence; we can do much better than that.

A useful property about an email address is that it is not subject to clashes, like usernames are. So an alternative scheme is popular, where a complete email address is used as a username.

The wrong way forward

These disadvantages are clear to most end users, and services are popping up to resolve them. Unfortunately, this is far from perfect.

Large networks that provide "free" services to end users are starting to offer a login service to other sites; their present popularity indeed makes sites accept such forms of login.

Users however, should think twice before using such facilities. The login services are given full access privilege to the account data, because those login services cast the decision on whether it is you or not; combine this with the practical situation on today's Internet where such "free" services have an unsatisfiable hunger for data, and gradually worsen the privacy of their offerings, and a path is created to offer evermore well-structured data to those "free" login services.

Bring Your Own Identity

There is nothing innately wrong about a site that confirms your online identity, and indeed this resolves many of the disadvantages of the user/password/email scheme, but the identity provider must be under control of its users. This will usually imply that some modest payment is required for the service, in return for which the interest of assaulting end user privacy is reduced. Furthermore, it is vital that such forms of identity are related to domain names or perhaps your phone number, so it can have the distributed nature that makes the Internet so much stronger than the centric nature that most "free" services try to establish.

We relate the BYOID scheme within the InternetWide Architecture to domain hosting parties; in fact, we propose to split domain hosting into two components:

identity provider
service provider

The idea is that one's online identity can be managed and controlled, users and groups created, and so on. Identities can take on various forms:

user@domain.name, so users underneat a domain name
domain.name, so domain names
1234567890, namely phone numbers (through ENUM)

With BYOID, you can use these identifiers when you are accessing remote sites. This is not dissimilar to the idea of using your email address, except for a few things:

your identity does not have to support email or other communications
you are not using passwords, but strong cryptography

As an end user, you won't just be better protected, but in addition you will benefit from Single Sign-On, meaning that you logon once a day or so, to be able to access services without further need to enter passwords. It's all a matter of proper architecture.

read the next installment

Control over your Online Identity

2014-11-26T00:00:00+01:00

Many of us have a lot of identities stuck to us. Our names, social security numbers, phone numbers are examples of offline identities; our email address and a lot of account names with various websites are examples of our online identities. It's a rather confusing bunch for most of us.

ARPA2 intends to simplify one part of it, and complicate another, both with the intention of improving our control over identities. We do limit our architecture to online identities.

One identity is easier

The first thought is that it is silly to have another identity in any place you visit. Why does every website need to assign you with another username? This is especially daunting because "your" name may already be taken, and usually there is a password policy that is more silly than secure. And let's not forget about the difficult-to-read pictures from which we need to parse words or numbers while creating those identities. It's a bloody mess.

Compare this to the following idea: You have one identity, and each place that you visit allows you to bring that identity. Online structures exist so that the visited place can validate that the identity is correct, and if you are using a Single Sign-On system, you can access that new system because you already logged in when you started your day.

This is close to achievable these days. Realm crossover is a bit tricky, but can be resolved in a reasonable amount of time. And Single SignOn is trivial; the Kerberos system has done this since somewhere in the 70s, and it has since then seeped into almost all the pores of the Internet!

The identity can be of the predictable form john@example.com, which looks like an email address (and may or may not be one in reality). This format of identity is usable with pretty much all the protocols on the Internet, and that means there is a form to bring your own -- as long as you can prove that example.com, the domain-name part of the identity, approves your subordinate identity for john.

This is similar to the email-based system that we have now: "we sent you a link to verify your email address, please click to confirm" -- but it really is different. Rather than needing this manual trick and depending on the existence of an email address for the given identity, it is possible to use domain-name properties to validate the identity and approve you without manual intervention. It's easier, quicker, more secure for the relying party and you cannot be contacted if you don't want ot.

You no longer have to be faceless.com/#!john but instead you can have your own domain name -- or your family can have one, or your company, or group of friends. That's the part after the @ sign; anything in front you can pick since you have full control over the domain name and its namespace.

Being of two minds / Having two faces

The problem with a single identity is that it is very straightforward to trace your online behaviour. In fact, your behaviour will be a bit scattered if it involves multiple of your activities.

Both for the clarity of your online conduct and for your ability to separate roles that you play in life, the ARPA2 architecture therefore proposes the use of different identities. You can have one for the grocery store, another for the school teacher, and yet another for your family. All these reflect another aspect of your life, covered by a separate identity.

This may seem odd, after arguing the advantages of having one identity, but there is a difference -- one identity is useful to have across all the technical communications facilities that you are using, but it is useful to be able to separate your tasks or roles in life. Note only does it help you to sort your online presence better, it also helps others to get a coherent picture of you.

For this reason, the ARPA2 architecture aims at lightly created identities that include support for all the normal mechanisms that make them useful to establish your online presence.

Many authorisation systems work in this direction as well; they summarise personal identities to groups or roles, and use that to judge whether you are permitted to order a piece of work to be done. We will turn to this in several future articles.

Sub-domains

Given that domains give us total control over our online presence, and that the ARPA2 architecture will let us create as many users as we wish, it is becoming more and more interesting to own a domain name.

Another form of identity underneath a domain name is a subdomain; for example, the name other.example.com is a subdomain of example.com and can be managed on its own terms. We intend to exploit this, by given the owner of example.com the choice whether to keep the other subdomain, or perhaps delegate it to another party who controls it on their own. They other party is dependent on the owner of the domain as a whole, but is otherwise free to manage his identity, which should suffice in most trust-based relations.

Sub-users

Another form of sub-identity that we are considering is a sub-user. Imagine that john@example.com is a board member; he could be addressable in that position with a variation on his identity that is different, but in a way that is clearly recognisable for humans and machines. We intend to use a plus sign for this purposes, so in this case john+board@example.com would mention john+board as a sub-user of john.

We imagine that this could be helpful during access control definitions. Perhaps anyone can send email to john@example.com but only a limited group (namely, the board and secretaries) would have access to john+board@example.com. The former address could have another treatment, may be redirected to a secretary, and so on. The same address might also be used as an instant email list, addressing all who are whitelisted on the access control list.

This last point is under consideration. If you have opinions, then please ventilate them!

Phone numbers

Since we are considering domain names as identities, we should probaly also rake up our mentioning of ENUM of a few days ago.

Phone numbers can be treated as online identities, just like domain names and users at domain names. As far as we are concerned, the main aspect of any hosting package is the management of online identity, in all its forms.

Emancipation of Telecommunication

2014-11-21T00:00:00+01:00

The promise of ENUM

ENUM is a standardised method of using phone numbers in DNS, which is the central name resolution part of the Internet. With DNSSEC, the resolution of names is even verifiable.

The idea of ENUM is to attach Internet services to a phone number, just as you like. Pretty much like you can do with a domain name, basically. A few ideas?

Add a (reverse) directory server where people can lookup further contact information when they receive a phone number. This may send them the number user's name, perhaps their geolocation and whatever else the number user cares to share. This information is public, and could for example be retrieved when someone receives a phone call, even before answering the call. Just imagine the reduced hassle of exchanging business cards and keeping them updated!
Deploy servers that offer standard protocols like SIP for telephony or XMPP for chat, and refer to them from a phone number. It would even be possible to define inputs to the chat system for classical SMS and MMS submitters. The servers can be run under your control, so you can control the privacy policies applied to it. And because ENUM is a standard, there is no dependency on any service provider to connect users of different hosting providers.

These facilities enable modes of operation that are similar to the classical telecom constructs, but with the greatly improved flexibility of Internet protocols. And there is no reason to stick to current usecases for phone numbers, because ENUM basically defines a similar name structure to domain names.

The introduction of ENUM

When ENUM was introduced, nobody was using it. This may sound trivial, but in fact this need not be the case if you treat it like a normal domain name. What has been done however, is define rather specialistic technology for it, using special NAPTR records in DNS that are not commonly used with normal domain names. And these records need to be defined in registries that were specially defined for ENUM. This is not a problem when it is popular, but when it is not, nobody cares to update these registers when new protocols are updated.

And ENUM never was popular. No wonder either -- if you introduce something new you need to create a critical mass to get it accepted, and this is notoriously hard. The network effect works negatively in this case; both a client and server would need to support it before it can be useful, so if 1% of the people adopt a technology then only 0.01% of the interactions will use the new technology.

If anything helps to avoid the formation of critical mass, then it is what was done with ENUM: separated technology, sufficiently difficult implementation sides to make developers defer it until others had taken the bait, and a cost to get started.

The introduction of ENUM was fraught with mistakes, and it is no wonder that the popularity of it has stagnated after a few early adoptors set it up.

Still, there are places where it is popular. Confined environments that have adopted it to serve a specific purpose. Countries that use it to grant phone users control over the telco that answers their calls, for example. This helps those users, but also the telco's, that usually prefer to call out over the Internet. Another success story is the non-official ENUM deployment that connects universities all over the World.

The technical side of ENUM

Technically, ENUM is an international phone number written in reverse, with a dot between each digit, and a standard suffix .e164.arpa attached. For example, the international phone number +123456789 would translate to 9.8.7.6.5.4.3.2.1.e164.arpa Users who pass through a mild check of phone number ownership can get hold of such a domain name and post information as under any domain name.

The specialist records that were defined for ENUM include things like

NAPTR 40 10 "u" "E2U+sms:mailto" "!^.*$!mailto:mms@example.com!" .

This is the standard way to direct SMS to an email account. Note how processing it involves handling a regular expression (although that has been simplified recently) and a lot of funny patterns and flags, including ones that setup for recursive handling of NAPTR records. The NAPTR have been defined for domains as well, but are not normally used. What is used are simpler definitions through SRV records that point to servers for a named service:

SRV   40 10 5090 sip.callfilter.net.

The simplicity of processing this sort of reference is widely accepted; but the NAPTR is avoided, probably for its complexity. Still, it is good to realise that something is available for linkage with telecoms infrastructure, even if the real uses of ENUM probably lie with communication over the Internet, using the phone number as an identifier.

Another round for ENUM -- it is not too late

With the benefit of hindsight, one might say that the introduction of ENUM has been a little too pompous. Had it been just another form of domain name, without all these specialist technology issues, then it would have linked in with the existing developments for domain names. And it could have been a light-weight mechanism with easy entrance.

What is needed to treat phone numbers as domain names, is to interpret phone numbers in places where server- or hostnames are expected. So, the only thing a communications app would need to know is that something entered is a phone number and how to rewrite it. After that, it's just a name as any other. It's the responsibility of the ENUM entry in DNS to mention the right information.

Some places don't use a hostname but a user@hostname construction. In such cases, it is possible to use the phone number without the + as a user account name. So +123456789 would translate to 123456789@9.8.7.6.5.4.3.2.1.e164.arpa -- and be handled just like joe@example.com.

In these approaches, some luxoury is possible, but not strictly required; an app aware of the local dial plan could recognise local numbers and translate them to the international format and further handle them like such phone numbers are.

A last entry form is that of URLs. In those cases, it is possible to interpret URIs like tel:+123456789 and make sense of them with approaches as given above.

To help it being bootstrapped, the ideal is to provide ENUM for free. This is perhaps the most challenging part of it, as a bit of infrastructure is needed to maintain it. Still, given that a registry is operated it does not even need to add much; it may in fact be information that is taken from WHOIS records already kept; it would then be a free extra on top of a domain name.

Verified phone numbers take more effort, but can also be provided with a stronger sense of security. Specifically, a DNSSEC signature could be added for such numbers, thus showing to the outside world that it can be trusted. This might be used as an added value, for some payment. Apps that are security-aware would validate DNSSEC and skip unsigned numbers, while others might not care. Validation procedures should probably leave room for appeal, and for withdrawal of disconnected numbers.

What we at ARPA2 are willing to do is to add phone numbers as a syntactically more pleasing way of entry for domain names. Such entries would be an online identity like any other, and could be configured with users, groups, roles and communities. And with subdomains, including single-digit subdomains that would act like elongated phone numbers. So if you needed your family to be directly reachable with a personal number, that'd be possible.

There is a lot of room for emancipation of telephony, and ENUM is the one way of doing it. The approach taken so far has failed, but there is much more that can be achieved, if we do it right this time.

Back to Hosting

2014-11-19T00:00:00+01:00

The Internet is constantly evolving, and new protocols and standards are being added each day by the Internet Engineering Task Force (IETF). The development of software keeps in pace with these developments, and a wealth of options for communication is available to us all. But in the end, that's not enough.

The original Internet

The most wonderful Internet imagineable is one where every user is in full control of their use of the Internet. Having software and a connection suffices to get online in any way one wants. Moreover, the software can connect to other software running one of those protocol standards that are constantly being developed. There is just one problem with this -- not all users have the knowledge or time to run their own servers.

In retrospect, it is no surprise that the initial surge in Internet popularity occurred together with the rise of hosting companies. Such companies help you to a domain name that represents your own corner on the Internet, and they run the servers for you, with possibilities to set it up as you desire. The so-called LAMP stack, consisting of Linux, Apache, MySQL and PHP was provided and users could go their own way.

The current problems on the Internet

As discussed in other postings on this blog LAMP has its own problems, but perhaps the most problematic problem of all is that nothing has been added ever since. PHP enables people to run all sorts of web applications, so when things like online payments and blogging are introduced, it is implemented as a PHP application. Meanwhile, the hosting industry came to a halt, and ended up competing with each other based on pretty exchangeable service packages.

The problem of the current situation is that all that a hosting deal supports is web and email. It's been like that for 25 years, or put differently, since the times that we all carried around floppy disks! And users simply want to get more out of the Internet -- and they should. No chat, no telephony (who wants to be a number? I don't!), no contact information available to clever client-side utilities that could dig it up automatically. All we have is the web and email. It's no wonder that more refined services have taken the lead on the Internet, in spite of their full control over user's online presence; users simply have little choice.

It would not be fair to put the blame on hosting companies, however. Things have simply grown this way. And a single hosting company is not able to affect changes; they need the others to follow suit, or else their work has been in vain. The introduction of new protocols has a very big critical-mass problem; this is much easier for the well-known silo's that basically create an internal domain, shielded off from the rest of the Internet. And it is only natural that developments start that way, and mature into the distributed model that keeps the Internet a robust whole.

The InternetWide project takes a very clear stand on how to get to this mature version, and thereby help users to regain control over their online identity. This solution consists of two things, described below.

A Hosting Distribution named ARPA2

One of our aims is to construct a hosting distribution that not just one, but many hosting providers can install. The distribution is a direct alternative to LAMP, and it introduces modern protocols alongside the ones that we already love. With the main expenses of hosting being bandwidth and maintenance staff, the cost of running such services is often low.

Being able to offer more abundant selections is helpful for hosting providers; even if they cannot charge much more for an added service, this scales up over the large numbers of domain names that they tend to host.

Note how this distribution overcomes part of the critical-mass problem, for one because all hosting providers receive the same offerings at the same time, and in part because a ready-to-go distribution simplifies the roll-out of those new alternatives. ARPA2 will take into account that users must be managed somehow, that they own domain names, and so on.

Specialising the Hosting market

New protocols can be knowledge-intensive. This means that not all domain hosters will be able to offer the full spectrum created by the IETF. This means that there is room for specialisation. Ideally however, specialisation should not lead to not running certain services because a hosting provider is not offering it. That would retain some of the critical-mass problem that blocks the introduction of new protocols!

To facilitate the optimal situation, there is a need for procuring a domain hosting package at one location, and plugging in externally hosted components from anywhere else. We therefore split the hosting landscape into two roles:

Domain hosters are those parties that register domain names, and offer a central cockpit to control it. Think of creating users, assigning rights to them, and... adding external plugin components.
Plugin providers run an individual service in such a way that it can be plugged under a domain hosted elsewhere, and even be controlled by it.

This model should automatically lead to a sincere payment model for the Internet. And since bandwidth is cheap and support can be a for-pay option, this should not lead to great expenses for end users. Actually paying for services used is fair, and directs money to the people who actually do the job. Moreover, as part of a contract the user is able to select those offerings from the market that employ reasonable privacy terms. Thanks to local laws in various countries, businesses are often forced to consider those privacy terms, and that ensures that the market will actually offer options with good privacy.

Eye on SNMP 1: The Good, the Bad and the Ugly

2014-10-05T09:43:00+02:00

This document is part of an article series on Monitoring.

As our understanding of our perceived hosting platform matures, we need to look into monitoring. Most existing solutions focus, naturally, on internal network monitoring. Since we aim to support even these facilities with cross-over between platforms, we need to look into a standard. And even though some solutions are commonplace (like Nagios), they generally do what the standard solution does, but with proprietary solutions. So we had to look into SNMP and analyse its properties.

The Good

SNMP is a standard. That is probably the most attractive property it has; RFC's have been written and packets standardised. This means that SNMP is the one product that can be plugged into any network, or made to crossover between networks. It is worth noting however, that monitoring generally follows the same model as SNMP, so the translation is not necessarily a difficult one. It is also common practice; routers and switches tend to use SNMP (and RMON) because their producers want to deliver their devices with monitoring-agnostic firmware.

SNMP is typed, which makes it highly informative. For every piece of information there is a specification that describes its interpretation. This is a rather big advantage over the more popular monitoring approaches, especially when sending monitoring information across realm boundaries. Unlike scripted plugins such as Nagios's, where textual information is provided along with a good/bad judgement, there is an option for much more refined monitoring.

An intruiging facility in SNMP is that it also permits setting of values over the protocol, and even to create instances in monitoring tables, which could have all sorts of side-effects. Imagine adding a hostname in your monitoring solution, and seeing it added to your DNS, webserver and so on. It is possible with SNMP, but mostly in theory. This is due to minimal attention for authentication. Still, if it was wrapped in a more secure protocol this might be a very interesting opportunity.

SNMP monitoring is an extensible system; it uses ASN.1 Object Identifiers to uniquely identify the so-called objects that can be monitored, and it is possible to define indexes; for instance, there is an OID for network interfaces, and a number can be added to iterate over multiple of them. Indeed, there is a facility called conceptual tables which presents information in such a format that it can be printed as tables, where rows reflect instances and columns reflect attributes, just like in the SQL database model.

The IETF has had a craze over SNMP for a while, but it stopped at some point; the aspects covered in RFCs roughly come down to networking and systems monitoring. There is a specification dealing with applications, but very little of the content of applications (mail queues, DNS zones, virtual web hosts, and so on) are supported by standard RFCs. This is often expanded by vendors who have created their own extensions.

In terms of SNMP, extensions define their structures in a MIB, which is an ASN.1 dialect that basically pins down OIDs and their use. The OIDs are the vital choice that makes SNMP extensible through these MIBs. IANA maintains a registry into which each private organisation can request an OID for their own use; for example, our ARPA2 project has been allocated 1.3.6.1.4.1.44469 so that any extension after that with dot-number pairs is our prerogative.

The tables that we mentioned are a bit special about SNMP, as they enable something very interesting, namely discovery of things to be monitored. First, if SNMP servers (the so-called agents) are run on their standard port, it is possible to scan the network for them. Second, within an SNMP agent it is possible to walk through the tree structure defined by the OIDs for objects that can be monitored. Or, based on the MIB for things to be monitored, it is possible to iterate over a table of things, such as a table of network interfaces. A smart monitoring system can do all of this automatically, when it is only provided with the MIBs to monitor.

Agents themselves follow a rather intelligent design; there is a master agent which communicates with remote peers, and which is the expert on the SNMP protocol; then there is a standard socket interface known as AgentX, to which local sub-agents can register to add their own detailed knowledge about applications.

Finally, a choice in the design of SNMP is that it polls with lossy packets. This means that an overfull network will not suffer under even more load due to SNMP, which is especially useful because that protocol may be more active on stressed networks, thus worsening the problem. Running SNMP over UDP therefore seems like the prudent choice for internal network monitoring.

The Bad

SNMP is particularly bad at authentication. It originally mentioned a word in plaintext by way of authentication; the SNMPv3 improves on this but has not been generally accepted as a result of the complications it brings. When monitoring on an internal network, this may not be a problem, and this is improved by firewalls, VLANs and VPNs. Still, it is an oversight in the original design that needs extra work to be remedied. In the ARPA2 project, we intend to experiment by wrapping SNMP frames into GSS-API frames, using the Kerberos5 mechanism to sustain encryption and mutual authentication.

Once authenticated, access control is a possibility. Lacking a practice of authentication, this facility is barely usable. Firewalls are probably the best bet that is available -- and probably the most efficient one too.

The lack of authentication and access control has another disadvantage; it means that the potential of using SNMP for remote control is underexploited. It has to be, since permitting control to anyone endangers network stability.

Although many predefined MIBs exist for SNMP, both standardised and from vendors, there is virtually nothing for application state monitoring. This is the realm of system administrators, and it is not surprising that the functionality has been implemented in scripts, accessed over protocols such as OpenSSH. This lack of MIBs at the application level is something that ARPA2 is likely to work on; when applications can summarise their internal state and push it out, or register functions to pull it out, they should have a valuable extension to their interface with their context; Net-SNMP agent establishes such an API, and provides example code that guides the way.

The lossy transmission medium of SNMP has is disadvantageous when transmitting the data across operational realms, that is, over the Internet. On this front, ARPA2 intends to experiment with SCTP as a transmission channel. SCTP is the protocol that can send frames out-of-order, but with reliable delivery.

Perhaps as a result of our interest in a reliable transport, we have been looking for mechanisms that limit traffic, by not polling over and over but instead use a subscription mechanism. Typically, this would require a few extra SNMP operations, which the master SNMP agent could handle on behalf of its sub-agents, who may only need to process GET and GETBULK requests. Similar, but not quite the same, we imagine that it would be useful to support a generic form of pro-active submission of data from an SNMP agent to a monitoring station; this is possible with the so-called traps of SNMP, but it has not been defined in a generic manner yet.

As part of our interest in subscription over reliable transports, we would appreciate a facility for a table column type "valid through" that gives the timestamp until which no further polling is necessary. This may be used in pro-active or passive responses to indicate that the monitoring system can relax for some time. Applications include DNS-related timing certainties: "rest assured that we will be serving this zone until time T at which the current SOA specifies removal of the zone".

Note that these potential extensions are specifically of interest to tables, and especially large ones; they enable a mode where only changes are transmitted, but nothing more.

The Ugly

SNMP is a binary format. This adds to its compactness, making messages less than 100 bytes on the wire, but it also means that we need non-trivial tools such as Net-SNMP and WireShark to decode them. (It might be argued that the hex dumps are quit readable, but that is not for everyone.)

Object Identifiers are ugly identifiers. The strings of dots and numbers are virtually meaningless to human users, even if they have the great advantage of gradual delegation of control. But most human users are not able to memorise them.

The formalisms that define the format of monitored objects are the MIBs. These are written in a macro-language defined on top of ASN.1. Where ASN.1 specifications for data formats are quite readable, this property is not inherited by MIBs. They tend to be difficult to read, making it a skill to actually use them in any other way than through tools.

All these aspects are generally covered in software, but in spite of the S in SNMP meaning Simple, it cannot be said that this software is simple at all. Yes, a switch may parse the few formats that it understands and respond directly; an AgentX implementation may be similar, but the entire system consisting of master and sub-agents, as well as monitoring and the potential of control, result in rather complex interactions. This is best embedded into an application.

Conclusion

We have learnt that SNMP is a powerful structure for monitoring, and it is fully understandable that other monitoring solutions mimic it. The binary format of its messages are less appealing to administrators, but it does make expansions of applications with SNMP simpler; in a sense, applications could have built-in support for monitoring, which is not currently the case. It is this lack of built-in monitoring that makes us script around textual output from commandline interactions with a program or its file system. And it is this need for scripting which has made script-based solutions such as Nagios more practical.

We are going to experiment with built-in monitoring for applications. This is the model that is also successful for switches and routers, and we believe it may be worthwhile using the modular format of many applications to create an SNMP plugin.

Specifically, we will be adding SNMP to our SteamWorks Shaft component. In addition, we may explore getting some useful data directly out of OpenDNSSEC and perhaps SMARTd -- we find Shaft interesting because it helps to monitor infrastructure that spans across a network; we think OpenDNSSEC is an interesting target because it distributes zone management over two components whose state should ideally end up in one table; we think SMARTd is the typical target because it does not need separate setup and testing when it plugs into a standardised monitoring infrastructure. The latter two examples may use SNMP as an optional extension; only when they can open the libraries and register with the master agent would they actually employ SNMP.

Delivery of Crank and Shaft specifications

2014-09-19T20:09:00+02:00

InternetWide.org drives an ideology of a free and open, well-distributed Internet architecture. As part of our endeavour we work towards an architecture to distribute configuration information between independently operated parties.

Using the LDAP protocol

Most current technology is designed to work over web interfaces, and much to our surprise that includes topics of automation. Although it is one of those protocols that are not visible to the public, it drives a lot of infrastructure. It is the storage component for Active Directory, to name just one commonly known application.

The value of LDAP lies in its well-defined data structures and protocol. This enables users to go and fetch data across operational boundaries, because the remote party is bound to communicate in a standard manner. In comparison, the web lacks standardisation in many places that LDAP has solved: locations, searching, data structures, references between resources. All this has been solved and standardised in LDAP. This aids greatly to automatic retrieval of data.

The SteamWorks Project

The SteamWorks project aims to make configuration information easy to distribute across operational realms. For instance, one party could enter the configuration details and another could pickup on them. We don't really need to say what those details are; they are already standardised and may in fact be modified without breaking standards, simply by assigning unique numbers to the newly constructed data.

What SteamWorks adds is an architectural asset. It provides components to author, collect/redistribute and process the information in LDAP, because this is where LDAP infrastructure has traditionally been lacking in easily accessible functionality. The entire project aims for near-realtime distribution of information, so that central changes to configurations end up reconfiguring programs virtually immediately.

Crank is a data entry component, built for easy access from a web interface. Data entered is made available for immediate transmission to subscribing Shaft components. Aside from controlling the data, the Crank also makes access control easier to manage than "manually" in the configuration of a concrete LDAP product. The interface is suitable for integration with a web environment, since this part of SteamWorks does take manual input, and the web is very useful for that. see more info or read the spec

Shaft is a data collection and distribution component, whose goal it is to subscribe to Crank and Shaft components and get an integral local copy from various sources. Shaft is intended to cross over to other operation realms, and authenticate to a Crank or Shaft instance. The locally consistent state of various sources is integrated, and made available to subscribers as one whole. see more info or read the spec

One more component to come

There is one more component to follow as part of the SteamWorks, namely Pulley. This will be quite a surprise, because it will enable powerful queries against the Shaft, and impacting local programs to use the settings.

This mechanism is useful to a very broad audience, because it makes extraction and processing of information from LDAP doable without a background in LDAP. It will feature a scripting language which is highly intuitive, as well as geared with lots of plugins to get some real work done.

The future is smiling

Our current purpose and testbed implementations will be to support the TLS Pool with configuration information, such as certificate pinning or lower bounds to TLS algorithms. One central cockpit can be managed to impact lots and lots of servers and workstations, and get them to implement changed security requirements.

We see many more opportunities though. One would be to use SteamWorks in collaboration with FreeIPA, an identity platform that can be used to configure systems locally. At present, FreeIPA is geared towards identification of users and machines, but the same architecture might use SteamWorks to also impact applications such as web/mail/chat servers setup on a (potentially complex) network.

Work ahead

There certainly is work to do. We aim to have these components implemented in the months to come, and work them into our TLS Pool project. We will be reporting on progress on this channel, so don't zap away!

Delivery of KRB5-KDH and TLS-KDH protocol specs

2014-09-05T15:16:00+02:00

InternetWide.org drives an ideology of a free and open, well-distributed Internet architecture. As part of our endeavour we engage in standardisation work in the Internet Engineering Task Force.

The intention of this work was to realise a combination of:

Mutual Authentication (client to server and server to client)
The extremely efficient Kerberos5 infrastructure components
Perfect Forward Secrecy through Diffie-Hellman

We have aimed to introduce these mechanisms through extensions of Kerberos5 and TLS. Today we released a first version of the two protocol modifications for public review. These are highly technical documents, intended as proposals to a community that is aware of the inner workings of Internet protocols and standardisation.

We have first investigated related work and then continued into the design of a conceptual protocol to describe our intentions. Doing this, we have been able to innovate in various places. Interestingly, the modifications made are small, and they are perfectly integrated with the existing protocol environments, so they can be put to use where available without hindrance to parties that do not support them. This is not special in itself -- it merely marks proper protocol design.

We then proceeded to make a minimal enhancement to Kerberos5, to enable it to cryptographically bind Diffie-Hellman key exchange (description, spec) into the application protocol. This is the protocol that is used between users and services; for instance, between your mail reader software and your IMAP mail server. What we added here is Perfect Forward Secrecy, a facility that makes it impossible for an attacker to grab your traffic off the wire and decode it on a future date when they guess the password that protects your access to Kerberos.

The second enhancement we made was to TLS, the basic security protocol for many Internet traffic -- you may know it from the "lock" in your browser. The common protocol is as complex as the certificates that it uses for server authentication. The approach that we introduced is based on the much simpler Kerberos5 protocol, which also is simpler to keep secure. We introduced a Kerberos5-protected Diffie-Hellman key exchange (description, spec) into TLS to establish a similar user experience as with Kerberos5, but this time using the Internet's favourite security protocol.

This is not the end of the line of research though; we may have created solutions that fit well with the desires of a closed infrastructure such as that of a corporation or a country's government, but crossover to other realms is ideally extended until it can cover the entire Internet. This is the work of a continued project on realm crossover that can build on the achievements of the prior two projects.

Specifications themselves also are not the end of the line. They may now be implemented, which may turn up new insights that will advance the proposals; also, peer review by Internet experts and security experts may reveal all sorts of technical improvements. After that, there remains the matter of achieving tool support. For our ARPA2 project, that is easy to do; we have an upcoming TLS Pool project that will encompass these ideas, or at least TLS-KDH.

Web Architecture 4: Proper Authentication, anyone?

2014-07-03T15:10:00+02:00

This document is part of an article series on Web Architecture.

The original idea

Websites make resources such as documents accessible over the Internet, which is a great utility that avoids that we need to remember to pack not just our suitcases, but also our laptops (and batteries!) before we travel.

Some of the documents shared this way are not supposed to be public, so their access can be protected. This is a normal practice on the Internet at large; you would be rather surprised if your mailbox didn't require you to provide a credential of some sort.

Very strong security mechanisms have been developed to stop people from attacking the privacy of our online documents. And these mechanisms are so powerful that everything but the actual credential can be made public -- all that public knowledge will not help an attacker one bit.

How we wrecked it

The customary "technology" for website protection is a password. That in itself is rather lame, because the same passwords are often used in many places, and so one website could use it to login on another, and act on your behalf.

Users being as they are, they cannot be trusted to memorise difficult passwords. Some site administrators realise this and come up with frivolous requirements about characters that should and should not occur inside passwords. Yet others impose an upper limit to the number of characters in a password (really!) or have other frivolous ideas about pesturing users into behaviour to compensate for their site administration shortcomings.

Like it or not, passwords are bad. They have never been much good, but very little is available as an alternative. And so we keep typing them. Over and over again. Even if we are aware that they cause grand trouble.

We have recently seen a different movement on the web. "Free" service providers who represent many online users are offering login services. What this means is that a user will login with these sites, and web site owners go through a quick exchange with the "free" service's site to establish that the user can indeed login.

There are a few disadvantages to this scheme. First, it usually applies only to the web, as if there is nothing more of use to our online behaviour. Second, it makes the user a subject under that "free" service's umbrella, which means that the online identity of a user is not fully under his own control; it is subjected to the well-being and agreement of a that party's definition of "free". Third, providing information about each and every login provides an excellent opportunity to track and trace a user's online behaviour. And, seeing how the web is developing, I would not even be surprised if login service user agreements in the near future will permit the "free" service to login to your account and look around -- perhaps to "make sure you are not doing anything illegal". Yeah, right...

When it comes down to authentication the web is very, very much out of control. Specifically, it is out of the control of end users.

How we can fix the web

Surprisingly, there are a few good solutions for authentication with websites. Some of these are fairly new and still getting started. Others have been rolled out in the interest of large corporations who require single sign-on and proper security because they are internally accountable; it is easier to command an employee to adhere to a usage policy than it is with the web at large, but do we really want that to stop us from getting some decent security?

Large-corporation solutions revolve around infrastructure, the precise thing that many small-office and home users don't have. The common forms of infrastructure are a Public Key Infrastructure, usually based on X.509 certificates, and Kerberos which is a single-signon system that involves much more than the web alone. Of the two, Kerberos is by far the most refined method, but Kerberos authentication to web servers is not ideal, so we are working on an improvement that is helpful for anyone from an individual to large corporations.

Both infrastructures are well-spread, that is they are embedded in a sufficient number of browsers to offer it to anyone. For X.509, the user would install a certificate and with Kerberos they would acquire a ticket, usually once a day and usually automatically when the login to their desktop. Both systems make it possible to run in and out of a protected site without explicit authentication, but they do establish strong trust.

A few down-scaled alternatives are also moving in, albeit slowly. One of them is SRP, a password system that does not tell the website what the password is, but instead juggles cryptographic numbers around to prove knowledge of the password that matches a verifier that is known to the website. And for those without an X.509 certificate and some reason not to get one from CAcert of StartSSL, OpenPGP keys can provide an alternative to authenticate with a website, although most browsers don't support that yet.

These last few options are helpful for small players who lack the infrastructure of large corporations, but they are not as widely usable. We believe that end users should have the same comfort level (and security level) as large corporations, so why not share their technology? For this reason, we are aiming at the development of Kerberos and PKI solutions for those who host their domain name with a hosting provider.

The end result is that everyone who goes online has a fair option of being their own identity provider. Or perhaps a family can pick a member to arrange it for them. But at least control stays where it is most democratic: nearby the people who are subjected to it.

Web Architecture 3: the Database Backend

2014-07-03T14:00:00+02:00

This document is part of an article series on Web Architecture.

The original idea

When the first dynamic websites were created, they did things such as showing lists of items, for example the inventory of a shop. This was a pleasant interface to what would otherwise be too complicated to handle. The normal interface would have used the Set Query Lanague, usually abreviated to SQL, with complex statements like select user.name,user.birthdate from user where user.gender = 'M' which would output the names and dates of birth for all recorded male users — believe it or not, this language was considered fit for human consumption when it was designed in the 70’s! And indeed, it is somewhat readable, but not a pleasant language to actually write your computer interaction with.

Of course, when presenting items in a list you need to be terse. But sometimes you do need more detail. So the thought quickly arose to turn items into clickable links to a detail page with everything you could possibly want about an individual item.

SQL also excells at relating records, so it is possible to do things like listing all orders made by a given user. Once again, lists. The opposite also works, an order could link back to the user who placed it. You probably recognise the structure of web shop systems and such that you must have used.

How we wrecked it

SQL is meant to handle sets. In practice however, the majority of database searches that we do involves individual entities. This is because SQL is used to overcome the stateless mindset behind the original web design. So you will often see a session identifier linking to individual records to present individual bits of information.

And even though SQL is capable of doing these individual queries efficiently by setting up indexes, it still is a lot of work to be contacting a database, often run on a separate server across a network connection, to be posing it a question in SQL’s stylish English, to lookup the index and pull up the desired record. Or, in more complex situations, to trace through the database to collect the data required from individual bits and scraps of information.

SQL is by no means that best model to be storing web data. Much of the work relies on a simple location from which to retrieve individual entries, and the available power of set calculations is very general, but that generality comes at the usual price of overhead.

To make things worse, these database queries are not only used to setup actually dynamic pages, but many web frameworks have a lot of generic tendencies, treating things as objects of certain classes, and when an application starts thinking along those lines they need to rely on the generic powers of a database. Even if the website does not use it, or does not actually need all that power.

We are tossing compute cycles into our everyday websites without thinking much of it, but all these cycles take energy on a very large scale and, more in the individual interest of website owners and their visitors, they slow down the responsiveness of websites.

How we can fix the web

Many websites that use some form of web framework with builtin flexibilities are actually static in nature. These sites can be rendered after they have been edited, and then stored in their final form on the web server. Plenty of modern tools exist to do this efficiently, and they result in great websites.

Consider a blog. The index page changes with every newly posted article; but does that mean that a program should reconstruct the index for every user who wants to see it? Of course not; it could be done when new articles are added.

Consider a web shop. Do you really need to lookup the inventory in a database, everytime product #31807543 is requested? Nope. You could easily render a static page for that product. The one thing that is variable is perhaps the number of items in stock; it would suffice to retrieve only that piece of information, but there is no reason to download the description, specifications and images of the item from the database.

Consider your photo gallery. Sure, the application developer stores your image descriptions in a database and runs the same code with different parameters to show differently annotated photos or different index pages. But come to think of it, the number of pages is limited and you don’t need live updates of any kind, do you? So why render your gallery pages on the spot?

In fact, what this approach means, is that what we currently view as database-stored data will be split into a part that can be rendered statically, and perhaps a part that needs be drawn dynamically. This greatly improves page loading times and it completely disarms script-kiddies and other attackers. You want an example? How about InternetWide.org?

When a database is used, it is also clever to question the paradigm that makes most sense to your application. MySQL has long been the de facto standard database for hosting solutions, as part of their generic LAMP platform. But there is a growing NoSQL movement that agrees it is not a lingua franca and may need rethinking. Technologies such as Redis / Mnesia are popular, but perhaps chiefly of interest for “large sites”.

On the small end however, we have always had DBM available, a very straightforward key-to-value lookup system. Well… simple… if you want then there it can come with full-blown transactions, and redundancy across multiple servers.

Or do you need more querying facilities predefined? Then consider LDAP. It may not be able to relate objects, but the objects that it stores have dynamic fields and typing possibilities, which may be much more useful to you. Moreover, many things you might want to put in there have been standardised ages ago. Since LDAP is a well-defined protocol the data can be shared without the intervention of a web interface; this is the kind of thing we also discuss in our global directory series of articles.

The base setup of a hosting package may still rely on SQL, but alternatives are mounting and gaining in popularity. Do ask yourself if you want to spend countless compute cycles on repeated work, if you if you prefer a crisp site that loads like lightning.

Web Architecture 2: Spoiling Script Kiddies?

2014-07-03T13:30:00+02:00

This document is part of an article series on Web Architecture.

The original idea

If you run your own website, then either you may be a large corporation or a hacker, but the majority of web authors have a standard way of hosting their website — they get themselves a domain name and have a website hosted by a hosting provider.

This is a perfect setup. Maintaining a web server is technical work, and it is very useful to have a market offering of these services to less technically inclined people. The web, after all, should offer a place to everyone.

When the web grew into a dynamic place where applications were run and interaction with users became common, so did the complexity of the technical structures needed, but this only adds to the arguments of web hosting providers being useful market players.

How we wrecked it

Still, something is wrong; hosted web sites are very often the victims of attackers, the so-called crackers. Or, more likely, naive script kiddies who merely download and run tools that automate an attack so they need not even think for themselves.

Indeed, when looking at a web server’s log files, it is apparent that many such attacks are constantly being attempted on every web server out there. In many, many cases the patterns are specific to a particular web application.

Web applications are the work of humans, and humans make mistakes. Perhaps web developers make a few more than other developers, because they need to work within the confines of a stateless paradigm and at the same time deal with lots of end-user requests that are full of distracting user interface problems.

So what we see a lot is that such applications end up having a “magic location” or other form of web-based attack vector that makes them skip security checks and do something unintentional. Such things are usually fixed rather quickly, but then what?

Web hosting providers usually offer a web environment with a database, but little more. Users then pickup a web framework that can live in that environment, usually following the advise of a website developer who has fallen in love with the framework. After installing it and getting it to work everybody stops caring. Updates including security fixes will never come to the user's attention because they did not subscribe to the announcement mailing list that goes with the application, and neither do most website developers.

The problem is that now nobody takes responsibility for the security of the web framework. The domain hosting provider couldn’t possibly, because they would need to tend to far too many frameworks (and versions!) in existence, and they are usually selected for providing generic support that can carry any framework; furthermore, site owners would be rather upset if a hosting provider did upgrade web frameworks and cause an incompatibility with someone’s site design.

This situation leads to websites that are often lagging behind on updates, which then have widely known security flaws in them. Needless to say that there is a subculture on the Internet who love to get their hands on that, and do things they would think “cool” but that are in fact destructive.

How we can fix the web

The insecure situation of web applications is not easy to fix. The web framework selected is often the preference of a website designer, but they usually lack the technical skills to deal with security problems. Moreover, they are usually paid once for a web design job, and website owners may not appreciate them sending by-the-hour bills based on such maintenance tasks.

For the domain hosting party, it is undoable to manage each web framework separately; there are simply too many out there. Furthermore, websites might do something naughty that makes them incompatible with the intentions of a web framework. Or it could rely on deprecated functionality that, at some point, will be dropped out during an update. Any problems that this would cause would end up with the “guilty” party who performed the update; and that party is not paid enough to be able to handle that kind of helpdesk calls.

Education of site owners is also too much of an effort. Security is a highly specialistic skill, and couldn’t possibly be made suitable for such a large audience. Moreover, it would constrain the audience that could successfully run a website, which we have already stated is a good thing to keep as general as possible.

The only ones who can realistically update your website are the developers behind the code that website owners installed as part of their site content. These people know when they deprecate behaviour and what could possibly break when moving up one version. These are also the people who know when a security bug is discovered, and they could fix it before announcing the problem in wider circles (which include crackers and script kiddies).

The only way in which this would work, is when such developers run their software as a service that you can incorporate into your website as a plugin module, basically through forwarding or proxy’ing your website, or a part of it. And they would be providing a professional service, for which you could pay them. And given the size at which it is done, it is likely to be fixed instead of by-the-hour. You are very likely to get your money’s worth.

So next time you develop a website, consider actually paying someone for running your web framework, even if it is open source. Or otherwise make sure that you are aware of security updates, and install them immediately. After you’ve done so, you or your website developer may need to go over the site to see if everything is in working order, or needs a fix here and there.

Web Architecture 1: Stateless Applications?!?

2014-07-03T13:00:00+02:00

This document is part of an article series on Web Architecture.

The original idea

The original design of the web is a rather straightforward concept: A server provides access to resources that reside at locations, and on which operations can be executed. For example, one could PUT a document into a certain location, and GET it back later from that same location. The range of operations can be extended, for example to permit co-operative editing.

This concept centers around stateless service, meaning that each operation stands on its own and has no relations with earlier operations. The model has been very useful for storing web sites, whose pages were composed of a number of resources such as HTML text, images, style sheets and even JavaScript code; each of these resources would sit in its own location, and the HTML text would contain links to the various parts that combine to form a page.

Interestingly, the various resources are typed, so they are not dependent on local file naming conventions, but instead adhere to a scheme of so-called MIME-types, which classify a resource as text/html or image/jpeg which are standardised by the Internet Engineering Task Force.

This model permits a web designer to reuse elements in a multitude of pages, and such reuse actually saves on network bandwidth, because a browser need not reload resources that it has recently seen.

How we wrecked it

The web mechanisms are ideally suited for static content that is stored passively on a web server that basically functions like a remote file system whose content is suited for use in a web browser.

In fact, even the dynamic use we make of the web these days is not a problem per se. It is more the way in which we do it.

The wonderfully interactive sites that we like to use are based on JavaScript programs that run in our browsers, and that push and pull small bits of information to and from the web server. These small bits are often the only dynamic portions, and thanks to the JavaScript code these can be rendered in a lovely way in our browser.

Other applications may not be so interactive, and use the web server to generate full HTML pages, whose content is constructed on the fly, based on database lookups and so on.

In the backend of web servers, we see that both kinds of dynamic information are built up from scratch. This is a direct descendant of the statless style of the web design, but it means that the same database queries need to be run over and over.

Meanwhile, we are trying to tie pages together, so most frameworks do carry a session identifier along with the individual requests to GET or PUT a resource. You may have heard of these identifiers, they are also used to profile your online behaviour and are stored in cookies — but for this purpose they are actually functional; they help the server keep many of the same-time users separated.

But the stateless properties of the web service have caused servers to not store any information. So, based on this session identifier, all sorts of session information must be dug up — from the database. Again.

We’ll speak of databases in a later article in this series; for now, let me summarise that this is not as efficient as we’d like it to be.

How we can fix the web

Based on this analysis, you may well see the solution: to be better at handling web queries, we simply need stateful web services; that is, web services that can maintain state between individual resource requests. And this is not such a strange concept — sitting behind your browser, you experience a session, and you expect your just-made clicks to impact your future ones. You actually need this information stored.

The current practice of confining storage within the bounds of a single GET or PUT on a resource is more limited than what we are experiencing, but it is still being honoured by the majority of web applications. So they end up saving state in a database, and pulling it back up in the very next request. And the one after that. And after that. A lot of work is done repetitively, and only because applications are confined within the one-page-at-a-time trap.

But a revolution is mounting, and it is a healthy one. Applications are once again becoming programs, that retain internal state just like your word processor holds a copy of the document. They just happen to interface with remote users over the web. There is no reason you couldn’t GET or PUT resources on such a remotely run application. And come to think of it, this still counts as interaction with a resource, except that this web service probably has more knowledge of the content, can provide indexes and cross-links in a more versatile manner than a remote file service ever could.

A modern-style web server will not even run all these programs locally, but permit them to be run on any nearby server; the web server would simply be configured to forward certain chunk of its resource locations to an application that interfaces over the web. For instance, you could have all locations that start with /blog/ forwarded to a blogging application.

Need to fix PHP

A major application framework on the web is PHP. This is a language in which many dynamic web applications are built. PHP has a few tedious properties, but it is widely appreciated for its fast development cycle.

The PHP model is strongly centered around this one-page-at-a-time model, and indeed it can be observed that applications load relatively fast until you start adding modules and features; when you do that, you quickly see your web service slow down because it needs to reconstruct every page from scratch. Had this been an application that happened to interface over the web, then the modules would have been written to load, and retain state and caches that help to quickly service any requests.

In terms of the topic at hand, PHP is not a problem in itself; it is more a problem how it is used. PHP is run as a standalone application, and the forceful development of PHP libraries more than suffices to come up with a web serving interface. Then, programmers can migrate their applications from the one-page-at-a-time model to the application-with-state model. Chances are that the creativity in the PHP community will establish a style of programming that suits both approaches; that would be ideal for a smooth transition from the current style to the application-oriented style, without the need to rebuild all applications in existence.

April 8th, 2014: SNI everywhere

2014-04-08T00:00:00+02:00

Practical Solution

Support for XP is ending soon. The practical solution to this problem is to use the Server Name Indication to switch TLS connections. Since this is sent before encryption starts, this can be done by a fairly simple utility that reads out this extension, and forwards the TLS-connection as a whole to its proper destination. Since this means connecting two TCP connections, it is even possible to crossover from an external IPv4-based port 443 and relay traffic to an IPv6 address.

The solution is coded into a simple tool named SNItch. This tool is configured with a label (the server name from the TLS extension) and where to forward it to. You run it as a daemon on the place where your web traffic comes in, and you relay the traffic. You can decide whether to setup IPv6 for direct web server contact (in DNS and firewalls) or whether you prefer a single entry point for all your web traffic, IPv4 and IPv6 alike.

SNItch

2014-02-08T00:00:00+01:00

Practical Problems

This is a very practical article. It deals with problems found in everyday network management.

When running secure web services, a dedicated port must usually be reserved for TLS-based protocols. This is necessary because a server shows a certificate to authenticate that it really is the server you are looking for, but this must be done before the client has told the server its assumed name. Catch-22, really.

This does not apply to all protocols; sometimes a protocol starts off in plaintext, and then executes a so-called STARTTLS handshake after which the client and continue with TLS setup and further traffic is protected. But this has not been built into all protocols. And on the Internet, the most-used protocols are the least likely to change (because there is so much code implementing it), so specifically HTTPS is a problem.

What you usually end up with is the wish to run multiple secure websites on a single default port number 443. An extension to TLS, known as SNI, solves this problem. It makes the client send the Server Name in an extension, prior to the server sending back a certificate. So, using this, the server can return the right certificate.

At another level, there still is a problem. When all software runs on one piece of software, such as the Apache web server, the server name can be used for internal switching. But what about running service components, over HTTPS, in self-contained programs? This is actually the way forwards for the web, because it deals with the silly structures of sites that build up a lot of state for every page, and always starting from zero. A dedicated web service can handle state with much more grace, and is therefore more in line with the way we use HTTP nowadays (which differs from the original design intention to make it statelessly serve resources).

It may seem like a solution to use the Apache web server as a proxy, and simply forward the TLS connection. But you quickly run out of luck trying this; you cannot crossover between HTTPS and HTTP due to differences in initiative; you may use SSLProxy in mod_ssl but cannot do the same thing with mod_gnutls. So you may get stuck, and have to do everything inside Apache.

Global Directory 8: Secure Remote Passwords

2013-07-10T00:00:00+02:00

Distributing Passwords

Since the Global Directory is implemented with LDAP, and LDAP is used for internal central administration, there are bound to be methods for password sharing accross a local network. And indeed, there are; for instance, the userPassword attribute can attach a password in an object. This may either be in the plain, securely hashed, or salted and then securely hashed. In other words, it is possible to mention information that can be used to verify a password.

This is usually applied internally, on a network that is more or less reliable because it falls under local control. This is important for passwords, since they may be prone to attempts to dig up the password, even from the securely hashed forms. The most notable attack is a dictionary attack, which uses the fact that people often use simple words as their passwords. There are even attacks that harvest information published on social media to determine the words to try. This alone means that a password file should not normally made public. The aforementioned userPassword attribute would become a challenge by attackers when published.

The problem of dictionary attacks may be overcome by picking a random password, and salting it heavily. Both strings have the same entropy ("number of surprising bits") as the secure hash outcome -- more bits would not increase security and less bits would weaken the security without much benefit. This can either be accomplished by very well-trained users, or by using a machine-provided password. In fact, the password should not be supplied, but it should be made accessible for challenge/response type interactions, so that the password cannot be extracted; an interface like PKCS #11 would be suitable for that, as it can calculate secure hashes over pieces of data and intersect an internally kept secret while at it.

Interesting about a public store of password verification information is that it enables instant global password changes. This is a very practical measure that can lead to greatly increased security. Because it attacks the other factor available to attackers -- time. If a password remains unchanged for long periods of time, they become vulnerable. Cryptographers make it a hobby to estimate how long a cracking attempt on a password with a certain amount of entropy takes. Note that the publication of a password verifier in the Global Directory makes it possible to alter the password at a whim. This is also a great help in rolling to other secure hashes, in case the concrete hashing algorithm is cracked; although this usually is a slow and gradual process, nobody can claim with certainty that an algorithm is never cracked overnight. Again, the handling of passwords in a protective shell like PKCS #11 helps to make the password change unnoticable to its user.

So we come to a few principles for sharing passwords in the Global Directory:

Principle: //Do not publish passwords that are selected by human users; generate them with a secure random generator to ensure a minimum level of entropy.//

Principle: //Rather than making the literal password available to the user, it is preferrable to make algorithms available that perform security calculations over the password.//

Enter SRP

The Secure Remote Password mechanism, abbreviated to SRP, can fulfil the aforementioned requirements. It is defined in RFC-2945 as SRP-3 and since updated to version SRP-6. SRP makes a calcalulation similar to Diffie-Hellman but it incorporates the password on the side trying to gain access, and a password verifier on the side trying to grant access. The password or other re-usable credentials cannot be derived by the latter, so we are not spreading access privileges through the login procedure.

The SRP mechanism can be implemented over a PKCS #11 interface, so it can co-operate with anything ranging from a software program, through cheap USB tokens, to high-end HSM devices. A PKCS #11 implementation is also suitable for generating password-like key files and the password verifier information. The result is that the password is generated on this device and never has to leave. Not bad at all for a poor man's credential!

SRP has [[http://blog.dzhuvinov.com/?p=1113|bindings for LDAP]], so publishing it in the Global Directory should not be an issue; you can follow the [[globaldir-5-openpgp|same procedure as for OpenPGP]] to import it into your OpenLDAP directory. The schema does not permit multiple versions of the SRP verifier information, so it is not possible to present alternatives in parallel. That is only a mild problem -- software generally implements sufficient varieties to accept different secure hashes (detectable?), and rollover of a published SRP credential would be instantaneous but that would at worst lead to a one-time login disruption. Those are probably acceptable situations.

SRP is implemented in SASL libraries, which means that it is available to a large number of password-reliant protocols. As long as they are flexible enough to notice the presence of SRP and provide it to protocol clients, this means that a lot of server software can actually use SRP. The trick that now remains is to train those SRP implementations to retrieve their credentials from the above LDAP scheme. It would need to derive a location from which to retrieve the SRP information in LDAP. This could well be done in the same way as used for the [[globaldir-7-tls-secured|TLS pool]], interpreting a domain name as a series of dc=,dc= patterns and interpreting user@domain as that same dc=,dc= pattern under which a (uid=) search must be made. On most SASL software this should be a straightforward extension that then applies to the entire range of applications that use this implementation.

Finally, SRP has been integrated into TLS, as specified in RFC 5054. The resulting protocol is called SRP-TLS and offers an alternative to the use of client-side certificates as a light-weight credential. It is not immediately clear if this enhances the potential of TLS, but it is supposed to be more efficient.

Global Directory 1: Introduction and Concepts

2013-05-18T00:00:00+02:00

Usage Examples and Introduction

Imagine receiving a phone call from someone you never met. They may use a modern Internet-based mechanism, like sip:bakker@orvelte.nep or they may use an old-fashioned phone number, like +12345. In both cases, you would be able to locate a directory server that spills information about the caller, even before you answer the call. Imagine what that would mean to your pizza delivery service. Imagine how that would help you to send a document to the person you are talking to. Imagine how that would help you to find that person's chat address, an Internet bypass for their phone number, their map location and much more that they care to share publicly. And if you enjoy your privacy, imagine how the directory could help you to that person's key material to encipher your phone call and email attachments.

It gets even prettier when you contact the remote directory through a hub of your own. Your hub could help you to attach personal notes to that particular caller. For example, the pizza they ordered last time. Or an internal contact reference code code. Or whether the caller is an idiot ;-) Your hub might even dig up letters or bills that you have sent to the caller. And if you enjoy your privacy, it could even store the Short Authentication String used during the previous ZRTP-enciphered call.

Interestingly, the technology to do this already exists, and it is commonly used because it is rock-solid. Chances are that your mobile devices can use it with a simple app already -- an LDAP client is available for most desktops and smaller platforms. The technology is just not usually installed by default, because most people don't ask for it -- they simply don't realise how much more the Internet has to offer than web and email. Below, I will explain what directories do, how they form a global directory, and I will say a few general things about technology. I will also explain how this helps you to get more control over your online presence.

The later parts of this series will focus on technology in-depth. In this article, the focus will be on explaining the concepts and only give a broad overview of how it actually works.

Technology Overview

The idea of a global directory is that everybody who wants to publish information, does so under their own domain. Then, if someone wants to find your information, they approach your directory service and download it. Pretty similar to websites, except that the information in a directory is highly structured to contain, among other things, contact information. Everyone can see information that you published, so they never need to enter it themselves. When your contact information changes, it can be updated by all those who track for updates. These are the predictable benefits from structuring directory information -- it becomes subject to automation! Compare that to sending all your contacts an email that you have moved or changed your mobile phone number!

The magic that makes such directory services work together as a global directory is that individually entered bits of information are glued together. If we leave it to commerce, this is done by creating one "central" site into which everyone enters their information. Given enough traction for such a site this does actually work, but this model has grave privacy implications, especially when it is offered as a free service so that the provider needs to cover their expenses indirectly. It is much better if every party hosts their own (directory) services and conform to a standard way of publishing them.

LDAP is a standard protocol for providig a directory service under one's domain, and there is a standard method for glueing these together, through particular announcements in the DNS. If your domain name is orvelte.nep, you will add a "DNS service record" under the standard name _ldap._tcp.orvelte.nep in your domain's DNS data, and suddenly your directory has gone public.

The other part of the deal is finding the lead to your domain and its directory service. The common practice with many Internet protocols is to identify users in a format like bakker@orvelte.nep, can be translated to a directory location like uid=bakker,dc=orvelte,dc=nep -- meaning, user bakker under domain orvelte which falls under top-level domain nep. This is what is called a "Distinguished Name" or DN in LDAP-lingo; a unique location for finding information about a person. Since the domain name orvelte.nep is included as dc=orvelte,dc=nep it is possible to lookup the "DNS service record" for the directory and ask there for uid=bakker,dc=orvelte,dc=nep. The response would be a list of properties known about this user, such as there phone number, street address, email address, website, map location and whatever else they might care to share.

All this could be done by a clever-enough LDAP client. In practice however, not all clients are that clever, which is why we will introduce the idea of having your own outgoing hub servicing your LDAP queries by approaching the global directory. This hub can also perform other functions, such as caching and storing notes locally, and perhaps extra descriptions for people that are not yet part of the global directory. There is no magic here, only a stack of practical solutions.

One remark about phone numbers -- these are not normally part of the Internet, but through ENUM they can be turned into domain names. You can simply acquire ENUM access for your phone number and add the aforementioned "DNS Service Records" under those zones.

Note how you are in full control of your information -- you decide what you publish, and since you do so under your own domain name you can retract it at any time. There is no service, free or paid, to subscribe to other than what you need to get LDAP service going.

Technologies: Web, DNS, LDAP

There are several ways of getting to contact information. LDAP clearly is the best option, but it is good to explain why it is better than the obvious alternative technologies -- DNS and the web.

DNS is the system that translates domain names (like rickywiki.vanrein.org) into IP addresses, and that contains references to specific services such as for email and chat. When dealing with identities that look like bakker@orvelte.nep, it usually deals with the orvelte.nep part -- the user identity bakker is not commonly shown in DNS. This is pleasant, because DNS is a public infrastructure without any access filtering. You probably don't want to give spammers an easy way to browse through the World's contact information and find yours. This is one reason why DNS is unfit for directories. Another is that it was quite simply not designed for that purpose; even simply downloading a photograph over DNS stretches the system well beyond its design assumptions. DNS is perfect for pointing to a directory service under a domain, but not for providing the actual data.

The web is the other possible technology that would be a mistake for a global directory. The web is very suitable as a mechanism to present human-readable information and even documents, but its automation on a global scale seems to be very difficult. Although efforts to this end are being made, there are many problems that remain unanswered, and that introduce new ones of their own -- like who to show what and how. Another problem with web technology is that it is relatively inefficient because it needs to take so many alternative approaches into account at once.

There is a modest protocol by the name of LDAP, which was designed as a directory service with all the facilities for a global directory purposefully built in. Purpose-built solutions are almost always better than generic ones like DNS and web, and LDAP certainly demonstrates this point. It is a reasonably light-weight protocol for retrieving information from a remote site, it has proper access control built in, it comes with a plethora of standardised attributes for contact information and, perhaps most importantly, it is flexible about the kind of information you care to store in it. LDAP is the only reasonable choice for a global directory.

There are many implementations of LDAP; you might know it as IBM Tivoli, Microsoft Active Directory, Lotus Notes or Novell eDirectory. Large companies tend to use one of these products as an internal directory, as well as to manage systems and users within the organisation. The upcoming articles in this series will not focus on these products but on OpenLDAP; not because it is thought to be a better product, but simply because this is an open source implementation, freely available to anyone.

LDAP has many, many integrations with all sorts of software, ranging from desktop applications to technical processes such as mail servers. It is mature, used widely and it is very, very potent. An interesting recent development is the integration of directory data with AJAX web environments, using JSON representations of directory objects, so that the information stored in a directory can be presented in a form fit for human consumption. JSON is a very good match with the LDAP object model, because this object data is structured yet flexible, like JSON; in many applications the integration can make more sense than the integration with an SQL database. An added value of LDAP is of course that it is a protocol and not just a data store that can only be used internally. Note however, that there are also types of application that work better with SQL than with LDAP.

Getting started with LDAP

Accessing an LDAP service is not much different from accessing another server; you login to a hostname as a user and some form of credential (like a password). The one thing that LDAP generally adds, is an entry point (base DN, like dc=orvelte,dc=nep) in the directory where you want to start searching. This extra detail is required because you are in fact accessing a node on the global directory that may host other parts of the global directory as well. There generally is a way of using LDAP as a visitor, in which case you are only shown those parts that are configured as public information.

Later articles will detail how you can setup an LDAP server under your own domain. When you have done this, you should be able to attach to it from your desktops and mobile devices. Until then, you could connect to a few local directories that are publicly available:

On Linux, you could try Luma. Also note that Evolution has LDAP-support integrated.

On Mac OS X, both the Contacts and Mail applications can query LDAP; neither will upload information to LDAP, but LDAPManager will.

On Windows, //please let us know what tools you use

If you prefer to install it on a web server, you should have a look at web2ldap .

On Android phones, you could use ???, which integrates with your contact list.``

On iPhone and other iOS platforms, you could use ???, which integrates with your contact list.

Visit the WikiPedia page List of LDAP software .

??? -- please tell us about the tools that you like best for your platform!

Note that this is not the global directory at work; it merely shows a number of local nodes that you can explicitly connect to. The global directory will make these connections automatically, once you connect to your own proxy LDAP server.

Global Directory 7: Decentral TLS Authentication and Authorization

2013-05-18T00:00:00+02:00

Introduction

The everyday practice of using TLS is not what it could be. Certificates and private keys are usually managed in an ad-hoc manner, since applications all have their own way of dealing with them. As a result, certificate and key files are often spread accross the local file systems of servers. This makes it difficult to manage their security and their renewals.

On the other end of the spectrum, certificate authorities have shown to be less reliable than they would like us to feel about them; one instance has actually been under attack without revealing this harmful fact to reliant parties; others have installed such low validation barriers (such as email verification or a faxed copy of a local government license) that they can be tricked into supplying certificates that do not live up to the strength of the embedded cryptography.

This article describes a more integrated approach of dealing with TLS, and manage it locally in a more coordinated manner. Within a host, TLS connection setup and teardown is concentrated into a "TLS pool", which works accross protocols, and which will use standard a PKCS #11 interface to manage certificates and keys with better operational control. The separate daemon for this TLS pool is the only place that needs access to private keys, so it is the only place where secure credentials float around. None of this needs to end up in a web server or other promiscuous program.

At the same time, it explains how modern developments in certificate infrastructure enables a model with distributed control accross operational domains. Once again, the Global Directory is used as a place to find certificates for remote parties. In fact, what this does is implement the kind of check that a certificate authority should do when being presented with a certificate request. The difference is that we do not need to rely on an external party anymore, and that we are not presented with information that may have expired. The infrastructure around certificate authorities have evolved to include certificate revocation lists to stay somewhat up to date, but nothing can beat a live check at the time it is needed.

Pooling TLS

Protocols that support TLS come in two flavours: Some have a separate port for the secure variety (and, usually, a separate protocol name: http becomes https and its default port changes from 80 to 443) and some start off in plaintext, negotiate features, find the ability to switch to TLS and issue a so-called STARTTLS command after which TLS negotiations start. The former is not advised for new protocols anymore, and could be seen as the second form with an immediate STARTTLS as soon as the connection starts. The implementation of the facility is usually embedded into the service, and based on a general library such as OpenSSL or GnuTLS. Libraries run as part of the program, and their access to private keys means that the security features are incorporated into the service that uses TLS. No problem if the service is a implemented in a secure piece of software, but some are so flexible, and provide so many facilities to non-technical end-users, that this might lead to problems. Web servers running PHP for example, have shown over and over again that they can fail on security grounds; applications built on top of this software stack is often equally flawed, and maintenance practices that install upgrades are far from common.

All this can be remedied by externalising the TLS handling to a separate program. Then that program gains access to private keys, but it will not relay those to the web server, or whatever program might be facing remote users. The STARTTLS point is a definitive point at which both client and server start TLS negotiations of the connection that they have had up to that point. At this point, the server can pass its communication end-point (the "socket") to the TLS pool, ask to setup TLS, and it gets a new socket returned over which it continues normally, except that the TLS pool now handles encryption and decryption over that protocol.

The TLS pool is not even the place where private keys are accessed; it uses the industry standard PKCS #11 as a secure key store. This means that a private key can be generated over a standard API but only the public part can be exported. The PKCS #11 interface will handle requests to sign or decrypt things with the private key, but only to PIN-authenticated programs such as the TLS pool. The PKCS #11 standard has been implemented in many places, ranging from free software modules and cheap USB tokens to expensive and redundant 19" rack-mounted security devices that can be addressed remotely by multiple servers at the same time. Effectively, the TLS pool is an application protocol layer on top of this industry standard with a vast range of usable implementations. Independent applications use a simple API call starttls_server() or starttls_client() to setup TLS, and this is basically all they need to do to implement TLS security.

One added benefit of this approach is that it becomes possible to iterate over certificates that are used behind a PKCS #11 store. This makes it easier to see if any need to be renewed, for instance. Or whether they are still active. Public information such as certificates, PGP keys and SSH keys could be automatically published in LDAP and DANE/DNSSEC, and removed when they are no longer available. Certificate management could be virtually painless and hardly manual.

As part of TLS pooling, it is possible to let the TLS pool decide which of the available certificates to use for external contact -- it should be something that has been published for some time, so as to ensure that relying parties can actually validate the certificate. And this brings us to the topic of decentralisation of authentication.

Decentralising Authentication

The model with certificates hitherto has been one with a strictly hierarchical control over identities assured in certificates. Several recent developments now loosen the strictness of this structure, while at the same time solidifying the level of security that is achieved.

First, the failure of DigiNotar to report that they had undesirable visitors on their infrastructure has shown that it is desirable to be able to "pull the plug" on such authorities, in a much more flexible manner than a browser upgrade. To this end, DANE was proposed as an additional constraint on the certificate, key or authority behind a domain's certificate. When DANE is used under DNSSEC, it cannot be falsified and so this information is secure. It is even so secure that one could choose to accept self-signed certificates, which are not acknowledged by any certificate authority, for the simple reason that they occur under a domain that one intends to rely on.

DANE stores its information in so-called TLSA records. A similar approach has been the CERT record, but did not get the infrastructural interpretation that DANE is establishing for its TLSA records. The SSHFP record for a server's SSH keys. It should be clear that any or all of these records can be derived from more or less centralised key repositories such as the aforementioned PKCS #11 store underpinning the TLS pool.

For user certificates, these structuress are not ideal. The information in DNS should not be considered private, and user information often includes identities that are somewhat private, such as email addresses and personal names. In these cases, LDAP is a much more useful mechanism and, to make this useful accross operational domains, LDAP. Indeed there are several structures for LDAP that permit users to incorporate their key material, as is described in several other articles in this series. One advantage of LDAP is that it can do more filtering, such as explained in the Publishing Information with OpenLDAP article of this series, thus protecting user privacy much better.

Note how this introduces an upside-down treatment of certificates. Where originally the idea of certificates was that they would make a hard claim on reliabiliy, more and more facilities have been added to weaken these constraints: DANE, OCSP and Certificate Revocation Lists. It ends up being necessary to do quite a lot of checking in order to check the original claim of identity made in the certificate. But, if those identities are mechanical and domain-bound, they may as well be automated. A servername is a domain name and can be looked up in DNS; an email address or any other protocol-specific user@domain address can be split into a domain for which an LDAP server can be looked up in DNS, and a user to be found in that server. In both cases, information regarding the authenticity of certificates can be found, like the certificate, its contained key or its secure hash. This means that signatures on the identities are no longer needed; we simply step and out and check for ourselves.

One last development that helps to decentralise TLS is that it now supports not only X.509 certificates, but OpenPGP as well. If a properly standardised flag is sent along with the initial negotiations of TLS, then OpenPGP keys can be used by both endpoints as a mechanism for authentication. Such keys hold a User ID, which is usually formatted as an email address inside angular brackets. And such keys are renowned for not needing a strict hierarchy to be useful; they may be validated through a web of trust where each party can vouch for each other party, or they may be validated as described above, through DANE and LDAP.

Note that, aside from the protocol details of TLS, this procedure is largely mirrored. Both client and server could authenticate themselves, so mutual verification can be done. This is generally helpful in getting a strongly relationship between end points. In this respect, the flexibility of PKCS #11 shows its true beauty; TLS pooling could be extended to desktop clients, and made to work based on either a software-based PKCS #11 key store, or one could use a hardware device that plugs into USB and holds one's X.509 certificates, OpenPGP keys and SSH keys.

The authentication process performed by a TLS pool takes some time because it needs to go online and query resources; this means that its results are good candidates for pooling in something like a memcached. This is especially useful for systems which continually see users come by, perhaps over multiple protocols and possibly visiting a multitude of servers. The distributed nature of systems like memcached makes it possible to centralise knowledge of succeeded authentications in a trusted (namely, local) place. Timeouts could be in the order of one hour, since recalculations can be performed automatically by the TLS pool.

This ends the story about authenticating remote parties, that is establishing their identity. Depending on further needs, it is now possible to decide which party has access to which resources: the process of authorization.

Decentralising Authorization

This is work in progress. Questions and issues include:

`` * use of attribute certificates?``
`` * for web apps, use an OAuth service based on the above``
`` * cache authorization results (again, memcached)``
`` * NEA's "standard" authorization model (white/gray/black listing, with a default policy)``

Development Status

This project is work in progress.

We have had two students working on a proof of concept, and are currently expanding on the experiences gained from that work.

InternetWide.org

Identity 17: Future Warfare may be about Identity

Sovereignty

Selling out 101: University of Twente

Future Warfare over Identity

InternetWide Sovereignty is up for grabs

Liberation Day is worthy of Celebration

Access 5: Juggling Keys in the Rules DB

Hierarchy of Keys

Rule DB and Password

Database Secrets

Lower Secrets

Juggling Keys is What We Do

Access 4: ARPA2 Access Control for Mail

About AxeSMTP

Filtering Incoming Communication

Processing Outgoing Communication

Delivering to Group Members

Access 3: ARPA2 Access Control and Groups for Admins

Rules Database

Communication Access

Document Access

Group Members

Demonstration Code

Further Reading

Think Globally, Act Locally

Concrete Examples

Access 2: Shaped like a Matrix

Access Control in Rows and Columns

Resource-Centric view on the ACL

Example Service using the ACL

Remote-Centric view on the ACL

Access 1: Dialing into Access Control

Barring access

Country Codes are like dialing Hosted Domains

Area Codes for dialing Application Types

Residential Numbers for dialing Individual Resources

The Key to Access Control

Technicalities of Trunking

Metaphorically Speaking

Identity 16: Support Levels for Realm Crossover

Level 0: Plain SASL Authentication

Level ½: Plugin Services or "Static" Realm Crossover

Level 1: Realm Crossover with SXOVER

Pseudonymity

Mixing Support Levels

Kerberos and GSS-API

Quantum Proofing your VPN

Perfect Forward Secrecy

Craving for Entropy

Protocol Structures

Survey of VPN Systems

Networking #2: Reliable Peering over 6bed4

How Addresses Look in 6bed4

How Routing Works in 6bed4

Return Traffic over 6bed4

Reliable Peering in 6bed4

Traffic Classes in 6bed4

Networking #1: Backward Compatible with IPv4

Advantages of IPv6 over IPv4

IPv6-only Internal Networking

Mapping IPv4 to IPv6: Incoming Traffic

Mapping IPv6 to IPv4: Outgoing Traffic

Full-Strength IPv6 for IPv4 users

Knowing your Priorities

Conclusion

Identity 15: Entering Security Codes

Helm Keys are Long Codes

Counting Entropy

Entropy Lost due to Typos

Examples

Extensions to SASL

Extensions to ARPA2 Helm

Identity 14: Bootstrapping Online Identity

Placing you at the Helm

Flying in from Different Angles

Finding a Wingman

Unlimited Boarding Passes

SASL Extensions

LDAP Extensions