It’s fascinating to see how the world changed in telematic security for open systems, over 20 years. Gone are the international standards bodies (in favor of IETF/IESG, which are proxies for American interests); and largely gone are the type of telematics standards designs that thought about everyone’s needs (not just the land of the exceptional, and its perhaps “friends and allies” – providing they spy on each other).
If I think back 20 years, when folks were thinking about how the security architecture of today could be so “structured” to preserve information and telecommunications dominance (without getting in the way of innovation, job and wealth creation), I recall how the goal was to maintain a gap. No, not a gap of being better or faster. But a gap as in gap analysis – within a security model. Somehow, SOMETHING is not in the standard (that should be). Its a lie by omission.
What is that, then? Its the failure to deliver distributed cache protection. This is the intended gap – the lack of countermeasures of which facilitate the desire to subvert and contaminate the security critical cache contents, the cache addressing model, and the caches own integrity and trustworthiness. The absence of the countermeasures is put there so that one – with unique information dominance – has the potential now to subvert all the other countermeasures (lauded on silly IETF RFCs, pompously marketed as security standards for everyone).
When you look at technology of layer-7 application building today, vs 20 years ago, of one notes that the platform has changed. I expect today to be using an android phone, soon, and indeed logging into the phone (and its native apps) using a Gmail account accessed via opened connect protocol. But, in the phone I obtain I expect it to come bundled with office 365 Apps too – from Microsoft. These apps will not talk at launch time to googles security infrastructure – despite being on a Google controlled phone. They will talk to AZURE AD (AAD), albeit in much the same way that the Google apps on the Google controlled phone talk to Google’s cloud based security services.
But, its a pain to have to login again and again to each office 365 app, particular now when using a live or organizational/work credential rather than the Google credential one just used to open up the app desktop replete with a mixture of Google native, play store, office, and third party apps that may use Google or Microsoft cloud security infrastructure.
As the Microsoft identity story comes out, we can see how its all being addressed – for both personal and work model phones.
Through caching, apps in a sub-family such “office apps” on an android phone can simulate single sign on. Launch a second app in the family, there will be no second login challenge. Of course, launching the first app, especially the very first time, may well present a challenge that typically would demand one’s live or work account credentials. AAD would cooperate with one of those IDPs to act now as an Authorization Server, and duly mint tokens that get stored in that cache, that control app loading, and app behavior when talking to remote APIs.
Now, if I were creating a “hole” in the internet identity infrastructure as a DARPA thinker – doing his job of having foresight, 20 years ago – Id be knowing (today) that the token cache is the gating factor on opening apps (and their local data store), and their interaction with web services. And, Id also know that tokens, minted by AAD, may not only be being supported by the live or organizational IDPs any longer. It may be, be user consent, be the Google IDP (or the Google AS token already on the phone systems-cache) that is leverages by AAD to grant opening power to the office apps … on the Google phone!
Ok, we see how the world of the us national identity infrastructure works now. And we see how Microsoft further allow non office apps and non office sites to also fit into this “office-family” …resident on the Google phone. Since AAD is the gatekeeper on office app culture, other third party apps (e.g. MLS and real estate apps) also tied into AAD might also be authorized to access the windows-app-only cache (on android) and thus get all the same single sign on, opening, data wiping…. features as do the Microsoft-delivered apps of word and excel.
So, clearly, the cache is king.
And it DARPA is playing king maker, as is its function, it will be doing what we scoped out 20 years ago as a “useful gap” (albeit for the tokens and protocols of the X.500 world, now aped and updated a bit by opened connect and AAD).
What I should not really talk about is how we thought about countering the strategic gap vulnerability (at a technical level, since obviously we were powerless to prevent the strategic vulnerability insertion). That’s because it requires an enhanced https – that protects the cache as a function of the security connections that derive from its keying/token material.