At the IETF Security Area Advisory Group (SAAG)
meeting in Paris, Zachary Zeltsan from Lucent gave a talk
ITU X.805:Security Architecture for
systems providing end-to-end communications
. This document
falls squarely into the ITU tradition of abstract
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,
Security Dimensions appear to roughly correspond to what most comsec
people would think of as basic security services. There are 8 dimensions:
- Access Control
- Data confidentiality
- Communications security
- Data integrity
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.
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.
"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.
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
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:
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
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.
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