My recent GSS-SAML musings lead me to think about the relation of security, applications and platforms. My firm belief until recently was that security should be handled low in the stack: in the network protocol layer, the operating system, etc. The benefit is quite obvious: by securing the transport, OS, etc., the applications and their developers can be fairly ignorant about security (which they mostly are anyways) and yet build a reasonably save solution.
Now, there is one problem with this model. In order to be really secure, the network and OS developer tend to put fairly restrictive security system in place. This in turn inconveniences the application developer whose first reaction to a security problem will be to simply shut security off. The results can be seen all over the internet …
The security stack
I better solution – I think – would be to start formalizing a full security stack. By that I mean essentially the same as when talking about a network stack. A security stack should define clear security layers, with well-defined boundaries of security domain.
Such layers should be isolated, yet permeable for permissable security information. One example would be the public key of a specific identity for message integrity and confidentiality. The associated name and other attributes are not strictly required for this operation and should – as such – not be permitted to pass through the security layers.
A possible arrangement of the security stack could be modeled along the ISO network layer model (lowest to highet layer):
- physical network security – This would include very low level protocols, such as e.g. EAP/802.1x
- network transport security – I would put protocols such as IPSec into this layer
- platform security – Here, GSS-API, Kerberos, and maybe SASL would be located
- application transport security – Within this layer, we could find things like HTTP authentication
- application security – This layer might justify another division, but probably not horizontally, but vertically in different silos, such as web services and applications (Liberty, SAML, WS-Security), databases, etc.
In today’s world, many of the different protocols are not capable of easily passing security information through the different layers of this stack (although there are some notable exceptions).
It should also be noted that while some security protocols do provide for the inclusion of authentication and authorization data, many do not.
What would we gain, if we had such a stack?
A clearly defined stack could serve as a framework for classifying, combining, and architecting new security protocols. Features available in different layers of the stack could then percolate up and down. An example would be the privacy features in SAML that – when profiled properly – could then be available at lower levels, effectively allowing anonymous (or psedonymous), yet authenticated access to resources.
Most vendors that participate in the Liberty Alliance are missing the point on federation. I have posted my own thoughts here: http://duckdown.blogspot.com/2005/12/round-two-federated-identity.html