Steve,
I think Rich's point is extremely important in the long term. To
read the original paper in question, one receives a clear impression
that security within the bounds of the X.400 Blue Books is not possible.
The paper contains several erroneous statements, and even more
misleading ones. I believe that I'm not alone in my certainty that it
is possible to develop a functional profile of X.400 Blue Books that is
secure. Whether that approach, or the creation of a new, non-standard
protocol sublayer (a' la MSP) is *better* in the technical/religious
sense is a subject of protracted debate.
What is more, such a religious discussion would probably be futile
since resources have already been spent to make MSP a usable product
before any secure X.400 profiles. Whether this situation is good or bad
is now moot. What is important is that we ensure that the security
mechanisms in the international standards merge with the requirements
of MSP users in the future. ISO is certainly aware that there is
additional work needed on the 1988 security protocol specification, so
it should not be too difficult to have the impact we want.
Personally, I think the subject DMS paper does not answer the
question that was asked (or maybe should have been asked) by the AMH
ISME which was, "Could a profile of the X.400 security services and
protocol provide the desired level of services?". Instead, the paper
addresses the question, "How badly can someone choose to implement X.400
security?". Since today's vendors are building to profiles rather than
just the base standards, I think the paper was a couterproductive
attempt to justify the way things are in retrospect. What is scary is
that a lot of people thought it was such a great response. I don't know
where your ducks are for the long term, but with defense budgets the way
they are today, I think I'd buy stock in X.400 security rather than MSP
vendors.
Of course, that's just the view from MY office window :-)
Chris
---------------------- Replied Message Body -----------------------
Date: 1-13-1992 9:44am
From: {Richard(_dot_)Ankney(_at_)emc2-tao(_dot_)fisc(_dot_)com}:unix:niaid
To: bonatti chris:bethesda:bah
Subj: Re: Re: MSP v. X.400
Also-to: kent(_at_)bbn(_dot_)com, pem-dev(_at_)tis(_dot_)com
--------------------------------------------------------------------
Steve,
Well put... I was just pointing out that it is POSSIBLE to do
end-to-end access control and not violate 1988 X.400 syntax. The
standard emphasizes primarily MTS-level access control (except for
10.3.6.1.) Even MTS access control is still subject to bilateral
agreements on the semantics of the security label (e.g., allowable
security categories), as well as the label matching rules themselves.
I brought it up for two reasons:
1) The topic has occasionally surfaced in the MIST OSI Implementors
Workshop. We have no agreement on security labels, even as recommended
practices; which labels are checked by the security context service is
determined by the security policy in force. (The label may be a per-
message extension, or it may be in the signed or encrypted portion
of the token. In the latter case, obviously, it can only have end-to-end
significance.)
2) My former employer was developing an X.400 version of their
secure mail product and wanted to ensure that it was possible (even if not
architected) for labels to have end-to-end significance (see X.402,
10.3.6.1). What was particularly infuriating was the fact that we also
did a significant amount of business with those government agencies that
are interested in MSP and SDNS, and it was incompatible with 1988 X.400
security (which was, even worse, a UK contribution to support the NATO
security requirements).
In fact, one could go so far as to say that all of the SDNS security
elements not in 1988 X.400 could be defined as 1988 Extensions. Then,
of course, you no longer have a COTS product, and it is not as easy to
certify as one in which, like MSP, the security elements are isolated
to a protocol sublayer.
As to the content integrity check, I apologize for misreading the standard.
The message origin authentication check is the per-message extension, but
it is computed over the encrypted content rather than the cleartext, to
allow untrusted MTAs to do origin authentication. Thus it doesn't really
provide non repudiation.
As of V6 of the Implementors Guide, there is some text about symmetric
tokens, but not much more than what I mentioned (plus the fact that they
don't provide origin authentication and non repudiation). One could also
use a symmetric algorithm for the content integrity check (with the key
conveyed in the encrypted token data), and the signature on the asymmetric
token would provide non repudiation (this seems to be another alternative
which the authors thought through in some detail). But there is still a
content integrity check in each token in this case.
Regards,
Rich