Using S/MIME for Domain to Domain Security - experience from a real world deployment

["Craig McGregor" <[e-mail]>]

Part 1: The Test Lab (October 2000) 

===================================

After receiving responses from an RFP, three vendors claimed that they
could supply a solution using S/MIME gateway products. We created a
test-lab (October 2000) to test the interoperability between these three
S/MIME gateway products. Typically these products were e-mail content
filters with S/MIME add-ons - although content filtering was not part of
our requirements.

Achieving interoperability was a more challenging task than we first
envisaged. 

We relatively quickly got to a stage where we were able to achieve one
way interoperability between products - We had a scenario similar to: 

Product A could send to Product B but not to Product C 
Product A could receive from Product C but not from Product B 

Product B could send to Product C but not to Product A 
Product B could receive from Product A but not from Product C

Product C could send to Product A but not to Product B
Product C could receive from Product B but not from Product A


Obviously the fact that although each product used S/MIME there had not
been much interoperability testing with other products.

It was clear that each product was implemented very differently for how
they identified domain secured e-mail. One product implemented a very
early draft of what is now RFC3183, another relied on a custom X-Header
line and the other implemented manually configured matching. 
There were also some issues even with the S/MIME implementations
interoperating as well. E.g. When certain elements of s/mime messages
were DER encoded rather than BER encoded would cause one product to fail
- but not the others...

We were eventually able to get each product interoperating after some
testing of why products didn't like each other and a combination of
vendor provided work-arounds, patches and upgrades to their software.

- All three products were able to deal with manually configured groups
of domains for gateway to gateway S/MIME interoperation
- Interoperability was only achievable by using a lowest common
denominator approach of S/MIME v2.  We also applied the naming
conventions from the DOMSEC draft of the time to ensure that we had
consistent naming conventions in our certificates.
- There was not a great deal of vendor enthusiasm for updating their
products to enable us to upgrade our interoperability spec to use either
draft or experimental technical specifications because of the potential
for such specifications to be 'moving goalposts'. There were suggestions
that the relevant product managers would consider support for something
that was deemed 'standard' in their products.

To state the obvious it would have been ideal if all S/MIME gateway
products were able to interoperate 'out-of-the-box' and thereby reduce
our necessary testing to compliance with our business rules rather than
with technical specifications and our business rules.


Part 2: A pilot group and a small community of participating domains
(Nov 2000 - Early 2001) 

========================================================================
=====================

We started with a pilot between three central government agencies - The
Treasury, The State Services Commission and Parliament. 

This pilot involved a manual exchange of certificates between the
gateways and was highly successful. End users no longer needed to manage
certificates, or, choose whether to secure a message - it just happened
for them.

We had now secured internet e-mail communications between more users
than was possible during our previous (failed) pilot of
desktop-to-desktop e-mail security. 

Other government agencies joined our secure e-mail community. It had now
become the standard way of securing e-mail between public-sector
agencies.

As more and more agencies joined the use of manual certificate exchanges
were becoming burdensome in the opinion of system administrators at some
government agencies. 

We found that manually implemented key management was prone to errors
because system administrators key management operations were not
performed regularly - once a year for your own domain and a few times a
year for the different expiry dates on the other domains. Similarly,
keys seemed to expire at inconvenient times (such as when system
administrator was away) and cause e-mail disruptions.  There is a
potential paradox between e-mail being high availability and PKI being
"failsafe" for high security (therefore stopping if something is wrong).



Part 3: Managing a large community of participating domains (2002-2004) 

=======================================================================

A. SMARTS (S.E.E. Mail Automated Reference Test Server)

Misconfiguration of S/MIME gateways in participating domains can cause
delivery of e-mail to other participating domains if such
misconfiguration does not conform to the business rules, and thus an
e-mail alert would be sent to the end user. E.g. a Postmaster
Non-Delivery notification is not signed and encrypted by a participating
domain, then the recipient of another participating domain will get an
e-mail to say the e-mail (the NDR) was received insecurely.

To counter problems created from configuration errors of S/MIME gateways
we setup a test server that works by exchanging e-mail with an
administrator from a participating domain. This test suite of e-mails
contains tests for our business rules and any exceptions that we have
found to cause problems over time. An administrator from a participating
domain is therefore able to test that they correctly process e-mail as
per the business rules whenever they make configuration changes to their
networks.

The SMARTS server tests for compliance with our business rules rather
than interoperability which is proven before upgrades or new products
are included in our S.E.E. Mail community.



B. Key Management

As the size of a 'community' that secures their e-mail communications
grows, the likelihood of poor key management occurring and having a
negative impact on the system increases. Using server-side software,
rather than interactive client software means that choices cannot be
made interactively at the time if there is a problem with a certificate
(e.g. expired, revoked). Some automation is required in order to take
some action - you cannot put a prompt on the screen and expect a user to
do something about it!

To correct this we have required changes to the products used in S.E.E.
Mail to be able to use an LDAP directory for two purposes:
	- To obtain the current membership list of the S.E.E. Mail
community. (i.e. which domains need S/MIME gateway
signing/encryption/decryption applied)
	- To obtain the current certificates for members of the S.E.E.
Mail community (e.g. a certificate becomes invalid, new member)



Where to from here?

===================

When comparing our real world deployment against the specifications
contained in RFC3183 there would appear to be a number potential areas
for simplification of RFC3183, or, possibly an opportunity for a
completely new rewrite that is a simpler Informational or Standards
track RFC along the lines "Securing e-mail between domains using
S/MIMEv3.1".








For more information on the S.E.E. Mail project please refer to
http://e.govt.nz/see/mail/

You may also be interested in a similar project by the Massachusetts
Health Data Consortium http://www.mahealthdata.org/initiatives/e-mail/.
Although I have not had any involvement in this project, the
documentation contained on their website shows very similar findings to
the S.E.E. Mail project.



-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Thursday, 22 January 2004 4:26 a.m.
To: Craig McGregor; [e-mail]
Subject: Re: Status of RFC3183: Domain Security Services using S/MIME


If there is sufficient experience from deployments such as yours, then I

would not be opposed to expending the charter of the S/MIME WG to
progress 
the DOMSEC document from Experimental to the Standards Track.  Of
course, 
people with the lessons learned from such deployments must be willing to

participate in the discussions.

Russ