-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ
BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl
Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx
NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T
ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL
Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB
AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL
X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF
AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+
8lqrLQ7YpTzyE74pKR1cl5TAUU4=
MIC-Info: RSA-MD5,RSA,
DGAymaXjVr7hZ5vzLgiAZqH0Qo60S9DnekQD9rb6G8Mc+00Yl/kjjoKchjZN5l0p
ZkFjUxXcsfgRg/B9Q7HtGU8=
X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED
X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED
I too am getting tired of the X.400/SMTP debate -- mainly because it is
obvious that few of the participents have any knowledge of the X.400
family of specifications, although they are quite willing to voice strong
opinions about them.
There are at least two major classes of security concerns with electronic
messaging:
1) end-to-end concerns, i.e., how can you, the recipient of this
message, be sure that it really did come from me, that it hasn't
been tampered with, and that prying eyes have not had access to
it in transit. This is not a firewall problem.
2) subversion of the infrastructure, i.e. how can we prevent
attackers from telnet'ing into port 25 and exercising the debug
features of SMTP, and how can we prevent messages with
handcrafted headers from making sendmail do bad things.
This is definitely a firewall problem.
In the SMTP world we are developing solutions to the first problem. This
message is signed using the IETF's PEM protocol and my private key. If
you have access to my public key and the certificates required to verify
it, you can verify my signature. There are other SMTP solutions to this
problem, including the popular PGP. There are no SMTP solutions to the
second class of problems.
While there are many things wrong with X.400 (note from this message that
I prefer SMTP), what it does specify fairly well is security. In
fact, X.400 provides better solutions to both types of security problems than
can be found for SMTP. X.400 itself, integral to the 1988 P22 specification,
provides for end-to-end security using public-key cryptography. Another
X.400 protocol, P48 (MSP), is preferred by the Department of Defense for
protecting its messages. MSP serves as the basis for the Defense Messaging
System (DMS), which will provide secure email services to over 2 million
users throughout the Federal Government. Both of these protocols are
superior to PEM, PGP and the other SMTP offerings because they provide
non-repudiation services, which are a significant consideration in business
transactions.
In addition, the 1988 specification of the X.400 P1 and P3 protocols, which
are used for MTA <--> MTA and UA <--> MTA transactions respectively, provide
for the use public key cryptography to ensure that all message transfers are
fully authenticated. If implemented and installed, this would give a
firewall a number of major wins: bogus traffic could be easily detected
and rejected; malicious actions from an authorized user or system component
can be positively identified; audit logs can be accurately maintained to
track security and message delivery problems.
The key to the X.400 problem is not that the specifications lack the
necessary security services required by a firewall, but rather, very few
of the vendors have fully implemented them. However, many vendors are
now scrambling to do so, for the DMS procurement requires all of these
features, and requires that they be available in COTS products. The
government has failed before when arbitrarily mandating OSI standards. This
time they may have it right -- never underestimate the influence of a large
captive market.
Charles Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----
|
|
