Thoughts on X.805

At the IETF Security Area Advisory Group (SAAG) meeting in Paris, Zachary Zeltsan from Lucent gave a talk on ITU X.805:Security Architecture for systems providing end-to-end communications. This document falls squarely into the ITU tradition of abstract models which don't really match up with networking practice.

Overview of X.805

The official title of X.805 is "Security Architecture for systems providing end-to-end communications", but the term architecture doesn't really mean what most people would take it to mean. Taxonomy or model might be better words, since the purpose seems to be to divide all possible network security tasks up into categories.

These categories exist along three axes: Dimensions, Layers, and Planes.

Dimensions

Security Dimensions appear to roughly correspond to what most comsec people would think of as basic security services. There are 8 dimensions:

• Access Control
• Authentication
• Non-repudiation
• Data confidentiality
• Communications security
• Data integrity
• Availability
• Privacy

This list is strangely non-orthogonal. Many of these features depend on other features (e.g. Privacy and confidentiality or Non-repudiation and authentication/integrity). Also, some of them don't really make sense in an end-to-end context.

Another confusing factor is that in standard terminology "Communications security" is a collective term for all of the major network security servics (authentication, origin integrity, confidentiality, etc.) Here, however, it seems to refer to arranging that your data isn't delivered to the wrong person. This isn't a concept that makes an enormous amount of sense from the end-to-end perspective. There are two reasons you might care about your data being misrouted (1) you don't get it (2) the wrong person does. The first issue is one of availability/DoS. The second one is a confidentiality issue, solved by crypto, not routing.

Layers

Each of these dimensions can be applied at any of three layers (note that these layers are NOT the same as the layers in the OSI reference model, so you need to think of the cross-product of security layers and OSI layers.) The layers are:

• Applications Security
• Services Security
• Infrastructure Security

I find this division to be fairly muddy. In particular, the line between the Applications Security Layer, which involves "applications accessed by Service Provider customers" and the Services Security Layer which involves "services that Serivce Providers provide to their customers" seems vacuous. For instance, Instant Messaging is listed in Services but e-mail is listed in Applications.

Planes

"A Security Plane is a certain type of network activity protected by Security Dimensions...."

The security planes are:

• Management Plane
• Control Plane
• End-user plane

I'm having a terrible time decoding this, but when I read it I get the impression that e.g., SIP would be part of the "Control Security" plane but RTP would be part of the End-User Security Plane.

Modules

There are 9 possible combinations of layers and planes, which are labelled modules 1 through 9. Each security dimension can be present in each module, so there are 72 different component interactions. The last 9 tables indicate the application of each dimension to each module in tabular form, by which I mean they handwave about the kind of service that you would expect each dimension to offer. e.g.,

Module 1, Infrastructure Layer, Management Plane: .... Non-repudiation: Provide a record identifying the individual or device that performed each administrative or management activity on the network device or communications link and the action that was performend. This record can be used as proof of the originator of the administrative or management activity. ....

Assessment Of Use To Practitioners

So, the obvious question is: what does X.805 bring to the party?

The first thing you have to realize is that it doesn't embody any actual technology, even at the architectural level. It doesn't describe any security protocols or even provide detailed enough descriptions of the components (modules) and their interfaces that you would be able to determine, design, and build artifacts that fit into these modules and have any chance that they would interoperate in a sane way.

The abstract of X.805 indicates that it's the architecture for ITU security and that "To achieve such a solution in a multi-vendor environment, network security should be designed around a standard security architecture." In practice, however, X.805 is so vague that it's hard to see that designing something around it has any meaning at all. I'm pretty sure I could take any random protocol and forcefit it into this conceptual architecture (sound familiar?) but what would that achieve?

Based on the presentation at SAAG, it appeared that there was some feeling that the style of analysis promoted by X.805 would be potentially useful for others who wanted to design security protocols and systems. I don't believe that this is the case, for a number of reasons:

Extreme Complexity

The most basic problem with X.805 is its astounding complexity. Any system with 72 basic components is simply not a useful analytical tool--unless your goal is to produce reams of paper indicating that you've followed some analytical procedure given to you from on high. We have a hard enough time getting people to do *any* security analysis, let alone the kind that would be implied by X.805 (to the extent to which it implies anything).

Excessive Factorization/Componentization

The complexity problem is largely a result of the desire to factor the problem into as small pieces as possible (see the Security Dimensions comments above.) Unfortunately, this isn't the way that real security protocols are designed. On the contrary, they generally offer a small number (1-3) sets of security properties which cannot be orthogonally mixed and matched in the way implied by X.805. Creating a bunch of new services just confuses issues. Security can't really be provided a la carte like that.

Bad Fit With The Internet Model

At the end of the day, the outlook implied by X.805 doesn't fit well into the Internet model. The extensive componentization creates an impression of separate security services at each Module.Dimension point. By contrast, the trend in IETF is towards having a very small number of security protocols that we reuse as much as possible and that provide a relatively fixed set of security services.

In addition, the emphasis on provider security services in this document implies a commitment to a much more active core (despite the references to e2e) than has been characteristic of Internet designs. (see above comments about "Communications Security" which is interpreted as an availability issue in Internet Security contexts). In general, the terminology and methodology implied here is so foreign to the mindset, that I doubt that X.805 can realistically be applied as an analytical tool.

Summary

The good news about X.805 is that it doesn't actually embody any security technology, so as far as I know there's no reason to believe that it's the start of some alternate ITU suite of security techniques--ITU's track record here is even worse than IETF's. The bad news is that as an analytical framework it's basically irrelevant to current network security practice. That's fine if people ignore it, but not so fine if it gets mandated as a hoop for people to jump through. That wouldn't be something that's likely to contribute to successful new protocol development.