1 Raindrop

Mission Statement for Federation

Bruce Sterling (11/20/2001):

You know what I want? I don't want a National ID Card. I want a Global Coalition Visa.

Like it or not, we've got a huge global diaspora now. It is a fact of life. Nations with stupid and corrupt politics have seen their clever people brain- drained away, to places where the cops don't shake you down twice a day. And jet-setters go everywhere. And properly so. If you're in a true global society, then you spend a lot of your time among aliens. Quite often you are the alien. You might notice that even Al Qaeda is a genuinely multinational group. They gravitated to wicked, lawless places like Sudan, Chechnya and Afghanistan, where the locals shoot you if you ask for a badge.

But what about all us bright, shiny, world-trading jet setters, huh? There are thirty percent fewer Yankees in Europe this Christmas, and that is bad. Let me pose the problem this way. If I am going into a Japanese restaurant in Japan, I would rather like to be able to haul out some gizmo and flash it at my fellow civilians, and have these kindly people understand with a high degree of likelihood that I am not a mass murderer. On the contrary, I am quite civilized, and I should be brought a beer immediately.

A platinum VISA card and a five-hundred-dollar suit will almost do that, but those are too easy to forge and steal, plus they are not very democratic. The UN should get together on this. We should have a high level summit about digital hardware support for the crippled tourist economy. Fear and ill treatment shut down tourism faster than anything short of open warfare. That is bad for all of us. Killing off tourism harms our civilization and impoverishes our cultures. People in civilized states shouldn't routinely treat one another as criminal suspects. I don't want to get done-over for three hours every time I get off a plane in London. When I go to London, I go with empty suitcases. I don't plan to stay, but I am better news for the London economy than a lot of the people who live there.

They should know all that that before I get off the plane. My arrival is excellent news for Britain, so I should be treated that way. If this is a new kind of war, I don't want to be the evil guy hunkered down in the bunker; I want to fly with the boys from Air Assault. I want one of those handy crypto-style Friend-or-Foe IDs.

These people who normally meet me whenever I am an alien, they don't need to know my nationality, my home address or my shoe size. They just need to know that, despite being alien, I'm sort-of okay.

I want a democratic, citizen-to-citizen device that will bridge those social barriers and language barriers. I think we could invent devices and means of verification that would strengthen the global social fabric that terrorism wants to rip. It wouldn't be easy or simple, but it's not beyond our ingenuity. Our social capital sustains all civilized societies, and it is all about trust. So let's invent new methods of trust.

I added bold to the last sentence because I think this is the mission statement for building out federation systems.

Security Services Deployment in Federated World

Its easy to get hung up on security protocol design, finding the right fit for your architecture and so on. Its really hard to find security mechanisms that do something useful and scale as well. In my opinion, this is the single biggest issue we face in security today - how do find useful things that solve security problems, that can scale in real world systems.

To that end, my favorite paper in a long time was written by Patrick Harding, Leif Johansson, and Nate Klingenstein called "Dynamic Security Assertion Markup Language: Simplifying Single Sign-On." They begin by asking questions companies face when entering into a federation:

How should trust between providers be managed? 

How should information about providers (metadata) be provisioned? 

Which SAML profiles and bindings should be used? 

Which messages and what part of each message should be signed? 

Which identifiers and attributes should be exchanged? 

What are the semantics of those attributes and identifiers?

Organizations understand the benefits of SSO and federation, but don't always answer the above questions in a way that sets them to scale. Harding, et al.'s work describes a way to partition the architecture into separate layers - a metadata trust fabric,a metadata publishing fabric, and a metadata validation and signing fabric - enabling dynamic federation. If you design stuff for a large scale distributed systems, this is a really big deal. No wonder these guys win all the good awards. 

I have often used Federation as an example of security as a business enabler - improving the brakes, ABS, and airbags so we can drive fast and safe. Federation creates value for the business through more deeply linking it with its customers, partners, and business users; it solves some security architecture problems through encrypted and signed tokens; and it gives the user SSO/SLO. You don't always get a win like this in security architecture, but when you find one its good to ride it for all its worth.

Openly IDentify your attributes with Open ID

As developers are inexorably drawn down the rabbit hole that is identity, they continually conflate authentication, authorization, and attributes into one big "identity" jumble. Lately, there has been a lot about OpenID, which as com.burtongroup.analyst.identerati.neuenschwander.mike (known unambigously around the identity water cooler as "Mike Neuenschwander") points out that OpenID is about attributes:

But don’t get me wrong: OpenID isn’t the problem here. OpenID simply calls into sharp focus something I’ve believed for years. It’s a kind of axiom, so I’d like to give it a name. I’ll call it, “identifiers.axiom.neunmike’s.axiomproxy.info”—that way you can easily refer to it unambiguously from anywhere. Here it is:

    There are no identifiers, only attributes

Names are slippery. Most people have many more than one legal name, none of which are unique. They also have several dozen nicknames. There’s no practical way to get any of these every-day-use names onto a global namespace. And what’s a name after all but a synthetic attribute—a foreign key that we hope the receiving party stores somewhere so we can remember them later? Names are invaluable communication aids, but they have little to do with recognition, which is what’s at issue in most identity management contexts. Biologically, creatures don’t recognize others based on names but rather the confluence of attributes appearing within a certain context.

Lao Tzu (who goes by several dozen names) had a pretty good post on this idea over 2000 years ago. In a section called “Ineffability,” he writes:

The Way that can be told of is not an Unvarying Way;
    The names that can be named are not unvarying names.
    It was from the Nameless that Heaven and Earth sprang;
    The named is but the mother that rears the ten thousand creatures, each after its kind. (chap. 1,  tr. Waley)

I understand why from a programmer’s perspective, it would be so much more convenient if everybody could simply have one globally unique, unambiguous, resolvable name. But such a quaint design constitutes a wanton disregard for reality.

The tech industry is adolescently ID-fixated. But I’ve had it to here with IDs! Would somebody please start seeing my avatars as something more than identification objects? So here’s to being an OpenAttribute power user!

Leave it to com.burtongroup.analyst.identerati.neuenschwander.mike to provide clarity on a much misunderstood issue.

org.tbray.ongoing.proprietor.bray.tim (aka com.sun.softwaredivision.canada.ubergeeks.bray.tim) kicked the tires on OpenID and came to a similar conclusion:

What Could I Use It For Today? · Here’s what I think I’d be willing to do: in the commenting system here at ongoing, I’d be inclined, if I had manually approved a comment with someone who’d authenticated via OpenID, to subsequently accept further comments from that OpenID, unmoderated. ¶

I can’t think of anything else.

The real work for developers is not about assigning an uber-GUID to people, it is about unmarshaling attribute values into a PEP and putting them into a context to make them meaningful. As Butler Lampson says, "all trust is local." Again, I mention Bob Blakley's work on Security Design Patterns, that describes several ways to do this in a distributed system.

Hunter S. Thompson said "buy the ticket, take the ride." But don't conflate yourself the ticket and the ride.

CardSpace - not just for Windows any more

Turns out that open source Apache apps can also now leverage stronger portable identity through the work of Ping Identity. Ashish Jain announced the Apache Authentication Module for CardSpace. Kim Cameron commented on another mind-altering announcement from Ping Identity, enabling authentication via cardspace to an Apache relying party. Since many sites use weak username/password combinations this creates a much stronger and flexible access control approach:

The whole cardspace processing can be a black box for the administrators

The module puts the attributes in the session. So if you have a PHP application, you can do the following to retrieve the attributes

$email = $_ENV[’auth_infocard_env_emailaddress’]
$ppid = $_ENV[’auth_infocard_env_privatepersonalidentifier’]

The same thing works in any other programming language, since they all give you access to your environment variables.

So this is pretty much as simple as it gets. I hope everyone with a product that runs on Apache will look at this.

But wait! There’s more! When I wrote to Ashish to congratulate him on this development, he added:

We also have a .jar file for java that serves the similar purpose (we internally refer it as the cardspace-magic.jar and we will open source some day). Same idea…drop the .jar file in, then:

xmltoken in -> attribute’s map out

So if you use Java, you can go that way too.

This is very cool stuff -- real enabling technology for building stronger distributed apps.

Build Security Into Your Web Apps and Web Services

Here is the list of public web application and web services security sessions starting this March in Chicago, San Jose, and coming to other cities near you...(assuming you live in NYC, DC, LA, or Boston that is). I am teaching these in conjunction with Aspect Security who are some of the primary contributors/founders/energizer bunnies behind OWASP. Brief Description of the courses

Building and Testing Secure Web Applications

The course starts with a module that demonstrates just how insecure most web applications are. It demonstrates how hackers are able to attack web applications, and what common vulnerabilities they exploit. The next modules detail specific security areas, discussing the foundational principles and best practices, and review code examples of design patterns for solutions.

SOA, Web Services and XML Security

Focused on Web Services and XML attack patterns; using WS-Security, SAML, XML Encryption and XML Digital Signature; Identity services and federation with SAML; Hardening Web Services; Input validation for Web Services; Integrating Web Services securely with backend resources and applications using WS-Trust For more details, dates and registration see below.

Location	Dates	Class 1	Class 2
Chicago, IL (downtown)	March 6-8	Building and Testing Secure Web Applications	SOA, Web Services, and XML Security
San Jose, CA (downtown)	March 20-22	Building and Testing Secure Web Applications	SOA, Web Services, and XML Security
New York City, NY (downtown)	April 17-19	Building and Testing Secure Web Applications	SOA, Web Services, and XML Security
Columbia, MD (In conjunction with WSSC Conference)	May 7	Foundations of Web Application Security	SOA, Web Services, and XML Security
Boston, MA (in Burlington)	May 15-18	Secure Coding for .NET	SOA, Web Services, and XML Security
Los Angeles, CA (near LAX)	June 12-15	Secure Coding for Java EE	SOA, Web Services, and XML Security
Northern VA (near Dulles)	July 17-19	Building and Testing Secure Web Applications	SOA, Web Services, and XML Security

More details are here.

2006 in review

Here is a look back at this blog in 2006

January

Service Oriented Security Architecture - paper published in ISB. This paper deals with a security model for a distirbuted system the assets are separated as Identity, Message, Service, Deployment Environment, and Transaction. This way the risks and countermeasures can be understood and the elements and constraints dealt with in their own domain to the extent possible.

Learning from EAs: The EA Bill of Responsibilities - the role of a useful EA

Phasing Security into the SDLC - a comparison of approaches, top down, bottom up and so on

February

Bugs v. Flaws

April

Governance and Assurance Synthesis

Darwin Lives - Governance Models and the ability to govern

May

SOA security metrics - from my SOA, Web Services security training in Leuven

O, Perimeter Where Art Thou

June

Assertion Federation Assurance - putting strong authN on the wire

July

Intro to Identity Management Risk Metrics - published in IEEE Security & Privacy

August

Notes from MetriCon 1.0 Part 1, 2, 3

September

Laws of Identity and Web Services

October

Decentralization and Good Enough Security - Part 1, 2, 3

J Peterman's Threat Levels - watch out for the Enterman's shim sham

Whatever happened to give 'em enough eyes? - open source security lagging MSFT

Firewall this

November

Defining Misuse in the development process - published in IEEE Security & Privacy

Playing for keep across the board - thumb fingerprints or cut off your opposeable thumbs -- the choice is yours.

December

A series of posts looking at Rest security issues Part 1, 2, 3

Security Concepts, Challenges, and Design Considerations for Web Services Integration - published the DHS/ CERT Build Security In portal

Pragmatism in the house

The whole WS-* versus REST thing is beyond tedious. They are both supposed to be about interop not world dominance. On the other hand, here we have an example of pragmatism winning out over fundamentalism - Ping will show OpenID / CardSpace integration. At RSA Ping is demoing "An OpenID IdP Server that uses CardSpace for runtime authentication."

Paraphrasing George Clinton "free your digital identity and your mind will follow." Since, he synthesized about a half dozen musical styles, spanned about three musical eras and is sampled by every record that does not only sample James Brown...clearly this is a man whose identity cannot be captured in a single namespace.

I'll Take Transactions in Distributed Systems for $200, Alex

A single transaction in a standard enterprise architecture traverses multiple policy domains, namespaces, and technologies. Part of the problem to be solved by the security architecture is how to deal with authentication and authorization. At a high level there are subjects making requests objects and the communication is mediated by a Policy Enforcement Point (PEP).

Now the role of authentication services is verify and bind some set credentials onto token(s) that are used to make other decisions. The role of authorization is granting access, but where and where do you need to authenticate in a distributed system? In a single transaction lifecycle such as the one below, the user traverses a half dozen different technologies, namespaces, and so on. In addition,each system may rely on its own proprietary security mechanisms.

This is a very common scenario and far simpler than many architectures. So one question, is how far do you propagae the user's credentials? Do you keep a record on each user in all six systems? What abotu Oracle and SAP who (hypothetically of course) are charging you by the user? From a security standpoint do you really want to propagate identity hazmat (aka authentication credentials) throughout more than one system? Probably not. From a IDM standpoint how compelx do you want your provisioning to be? So in general, from an economic, risk, and compelxity standpoint, you probably want to limit all this to the extent you can. And instead push authentication to the edge of the system. The PEP (along with the PDP) has to map all its access control decisions to all its objects, so these will always, by necessity has some locality with the object it is protecting.

The best documentation I have seen in the open literature of the possible variants here is in Bob Blakley and Craig Heath's Security Design Patterns. This book contains the genesis of the problem we face

Security properties, especially authentication, often do not compose. Nevertheless, information systems are often built on composition.

They define a simple interaction with two possible guards

A secure proxy patterns deals with the following forces:

• The user would like to sign on only once.
• Both guards would like to authenticate the user.
• Both guards would like to enforce a policy based on the user’s identity.
• The authentication protocol may not authenticate the user to more than one partner.
• The user may not want (or be allowed, or be able) to divulge a passwordor other
authentication data to Guard1.

And they enumerate the following choices

Now the ideal scenario describes authentication (froma user standpoint_ occuring in only location so this resolves some of the aforementioned economic, risk, and compelxity issues. SSO (and SLO) which could be accomplsihed using SAML or other federation implementation. This is the ideal scenario, but none of the patterns individually give you exactly what you need. A combination of the patterns needs to limit the amount of authentication and instead use previously authenticated attributes to authorize access. Federation, then, is an enabling technology for these systems to work together.

Gerry Gebel raises some other salient authorization design considerations, which I will explore in the next post.

I blogged earlier about the ATM puzzle that Robert Morris Sr. gave at Blackhat awhile back. And as usual, we can learn a lot from ATMs. We have relatively strong 2 factor authentication at the edge, now there are many paritcipants between me and my bank, but my PIN code should not be revealed to all of them, right?

Update: Mark O'Neill weighs in on authorization in general, XACML in particular and how Vordel's products help you deal with it. Mark nails the importance of portability:

This is a big advantage XACML gives you. Your AuthZ requests suddenly are XML messages which can be routed, logged, monitored, and managed using standards-based infrastructure. I put this in bold type because it really is a big deal. AuthZ requests are no longer some piece of invisible "internal security plumbing". It means you can bring XML infrastructure (such as Vordel's :-) ) to bear on it.

So in a nutshell, step 1 is to decouple authN and authZ, step 2 is to use technologies and standards that enable you to use attributes that have already been authenticated to perform authorization.

PITM: Phisher in the Middle

How to deal with phishing - shouldn't that be at least part of the marching orders for any new identity technology? I talked in the last post about the importance for higher assurance use cases to be able to take some identity and registration communications out of band. Of course, there are lots of intermediaries in any given transaction. Your identity data in an average hosting center or corporate data center is likley to traverse many policy domains, technical domains, and a host of routers, servers, proxies, and so on. So there are always going to be some intermediaries in the middle. The so called man in the middle (mitm) attacks are all based in some way on turning any one of these intermediaries to a malicious purpose. In addition, you can expect an uneven distribution of hardening and vulnerability management on these intermediary devices because they are seen as part of the infrastructure. As a practical security matter, though this doesn't mean they don't have any holes. When designing for these types of environments, we have very useful design guidance from Brian Snow

"If we cannot trust, how can we safely use?"

This is a very important consideration. A given project that is, say, rolling out a new web app, is not going to be able to unilaterally audit and update all the infrastructure it relies on, and that infrastructure (even inside the proverbial corporate four walls) is the ideal place to locate a mitm.

From a phishing point of view, automation and reuse is key to their attacks reaching as many victims as possible. The current state of OpenID seems to make the phishing problem much worse, see Ben Laurie's analysis (ht ec). Basically, the possibilities to deliver an automated phisher in the middle (pitm) are increased, because the pitm can fool you once into giving up your credentials and then use those same credentials to discover all other accounts. What was a point failure at a single website, is now a cascade failure from a personal point of view. Don Park is working on this vuln to eliminate the password so that it cannot be propagated by the pitm.

Key Enabling Technology: Identity Bands

Kim Cameron and Dick Hardt debating the pluses and minuses of OpenId and Infocards. I agree with Kim that these are largely apples and oranges, sure there is some use case overlap, but they are designed to solve different identity problems. One of the big advantages I see in Infocards' approach that is particularly valuable for medium to high assurance systems, is that there is flexibility to treat certain identity communications in band and out of band. If you think about a lot of the security and privacy issues we see (like phishing, mitm, session playback), a lot of them are related to single band communications that, once breached, crumbles (or worse propagates). SOAP's support for many different communication protocols and WS-Security support for multiple token formats create a useful enabling technology for security architectures - the ability to move portions of identity conversations in and out of different bands.

At the OWASP conference last spring Andrew van Der Stock described a large banks design options for dealing with phishing. They wanted to go to two factor authN. They were looking at USB dongles, but they assessed that 2/3 of their customer's PC had some malware on them, so they did not want to put their "good stuff" (the dongle) into their customer's bad stuff. So instead they sent authZ codes via SMS to the customer's cellphone. "Perfect" security? No. Nice, incremental improvement over current state? Ya sure, ya betcha.