Home · About · A-Z Index · Search · Contacts · Press · Register · Login

Secure Messaging Workshop

24th July 2003

Introduction

Introduction to Secure Messaging

The Security Debate

Next Steps

Attendee List

1. Introduction

Mike Lambert introduced the day. For the benefit of those new to the Messaging Forum, he gave a brief overview of the history of the Forum and its current work areas:

• Unified Messaging

• Secure Messaging

• Coping with Spam

• Instant Messaging

Mike reported that the CIO Forum of the Mass Health Data Consortium (MHDC) had agreed to co-operate in the development of a Certification program for Secure Messaging Gateways.

[Because the majority of attendees had seen the introduction to the Forum earlier in the meeting, the presentation material was not used.]

2. Introduction to Secure Messaging (Russell Chung)

Russ Chung provided an introduction to secure messaging and the continuum of possible solutions, including

• Types of encryption

• Digital signatures

• Certificates

• Devices: Smart Cards/Biometrics

Successful secure messaging implementation requires consideration of

• Technical aspects - Established and controlled by IT technical people

• Organizational aspects - Policies, procedures. Established by company management

• Inter-organizations aspects - External policies, practices, procedures. Established by contracts between organizations, via senior management, boards, legal counsel

Technical aspects:

• Key generation

• Key management, distribution, archiving, recovery, revocation etc.

Non-technical issues are often overlooked or underestimated

• Organizational: Usage policies, training

• Inter-organizational: Certificate policy, certification practice statements, relying party agreements

Secure Messaging Models

There are a number of different approaches to secure messaging, using Transport Layer Encryption, Message Encryption or a combination of the two.

Three models

• Model 1: End-to-end Encryption (e.g. S/MIME, PGP)
  • Public key/private key generated for each user
  • Message is encrypted at all times
  • Nearly impossible for anyone except the intended recipient to read the message
  • Nearly impossible to do virus/content filtering
  • Key management is a burden
    
• Model 2: Gateway-to-gateway Encryption (e.g. DomSEC)
  • One asymmetric key pair per domain
  • Fewer keys to manage
  • Possible to do virus/content filtering
  • Messages not encrypted between user and gateway
  • Messages not encrypted in storage
    
• Model 3: Secure WEB mail
  • Examples (Authentica, Tumbelweed products)
  • Keys may be generated on per user or per message basis
  • Recipient does not requires special software .. just a WEB browser
  • Must prevent unauthorized person from obtaining the key
    
• Hybrid Models
  • Combination of some or all of the above.
  • Interoperability is a challenge

There is no "best" model. All are applicable in different situations.

Some points from the initial discussion:

Graeme Lunt: This presentation only focused on encryption .. what about digital signatures? Is this something that the Forum should be considering.

Ben Littauer: We have to consider signatures.

Russ Chung: The EMA Challenge in 2000 demonstrated the use of certificates and bridge certificate authorities.
In the subsequent Secure Messaging Challenge, we did test Digital Certificates to ensure that keys are not forged/changed.

Claudia Boldman: Have we considered how applications unpack certificates?

Ben Littauer: Having standards in that area is very important.

3. The Security Debate

The objective of the session: to probe the strengths and weaknesses of the different approaches, the applicability in different environments and the extent to which they can interoperate.

Ben Littauer introduced a panel of people with experience of implementation of secure messaging:

• Ken Beer, Tumbleweed
• Victor DeMarines, Authentica
• Ben Littauer, Consultant to the MHDC
• Dean Sepstrup, The Boeing Company

Ken Beer started by talking about some trends that he has seen and reactions that Tumbleweed has taken in response to those trends.

• Secure WEB based messaging is different to traditional eMail. The model is to let people live within their email infrastructure and allow the gateway to decide (on an individual basis) how to handle secure messaging outside the company.
  
• The major challenge with WEB based secure eMail is authentication. Encryption comes with the browser, but ensuring the identity of the user does not. This has to be implemented without increasing the number of administrators.
  
• In B-C relationships, WEB based solutions will prevail for some time because it does not require additional software. In business environments, there is a desire to stay within existing messaging environments. There is a need to be able to transfer users from WEB based to S/MIME environments quickly.
  
• Disadvantages: Moves away from the store and forward model, and also there is a need to archive mail. Consumers are forced to use a WEB based interface. Tumbleweed are developing a push model, sending an HTML attachment with embedded password checking.

Ben Littauer: We are not going to replace traditional email so this does not eliminate complexity and the need for training.

Ronny Serrano: This breaks the security model. When I send email I want to know that it is delivered to the specific person.

Ben Littauer: Not necessarily. The strength of authentication depends on the difficulty of decoding the certificate.

Claudia Boldman: There are requirements for different types of security.

Dean Sepstrup explained how Boeing moved towards the end-to-end secure messaging challenge. 

• Boeing has had internal secure messaging since 1996, with approx 80000 users. So, the complexity of management of a PKI environment had already been addressed. Perhaps Boeing overestimated the extent to which PKI had been  adopted in other enterprises.
  
• The goal was to build a system from standard components.

Ben Littauer: How many administrators to handle key issuance and management. - A couple of people plus a key management leveraging the existing NT certificate management.

Claudia Boldman: How about handling external certificates. - This proved to be a challenge, addressing transfer of trust and certificate contents mapping.

Victor DeMarines: Is this a single platform solution. - Pretty much so, Windows 2000 based.

Claudia Boldman: How do you handle the risks associated with not being able to filter mail at the gateway. - This is a trade-off, we use desktop virus checking.

Ken Beer: One approach is to get mail encrypted for the mail gateway. This was in a closed defense environment, may not work in the commercial environment.

Dean Sepstrup: This creates a node in the system with unencrypted high value information. i.e. a honeypot.

Ben Littauer explained the background to domain security. 

• A company signs an eMail at the domain boundary to assert that the mail originated within the domain. The value of this asserting depends on the contents of the relying party agreement.
  
• The MHDC DomSec approach does not use this. TLS not acceptable for domain to domain communication because messages are stored on intermediate nodes in the clear.

Victor DeMarines: We have to have a hybird solution with facilities for end users. The only practical approach is currently WEB based.

Ben Littauer: Who owns the data.

Victor DeMarines: The data is being staged, not archived. In effect the owner of the WEB service is acting as an asp and has to take ownership and responsibility for the data.

Claudia Boldman: Don't WEB services normally allow download of messages. - Yes, but it leaves the message in the clear.

Dean Sepstrup: Because of what was already in place at Boeing, any solution other than end-to-end was ruled out because of costs.

Ken Beer: The gateway to gateway approach has to be the most cost effective. There is just one exchange of keys and little user training required.

Ben Littauer: PKI has a bad reputation. In some circumstances it is not acceptable.

Dean Sepstrup: It is possible to buy certificates from organizations like Verisign that publish them via LDAP.

Claudia Boldman: One issue that we have not addressed is integration into the enterprise mail system.

Dean Sepstrup: End-to-end has been demonstrated with several different mail systems.

Ken Beer: The MTA cannot change the message in any way.

Russ Chung: There are some companies that need internal encryption to avoid industrial espionage. Is it possible to encrypt from client to gateway and then use the domain key to encrypt for outside the company. -- Yes.

Ken Beer: One problem with client-to-client is CRLs. Dean Sepstrup: Boeing decided not to check CRLs as a simplification decision.

Ben Littauer: Encryption does not mean that the originator is validated. Is this a training issue?

Mike Lambert: Is this a usability issue. Make the products communicate with the user in a language that the user can reasonably be expected to understand.

At this point, Russ Chung led a discussion around diagrams on a white board which tried to capture the main features of the different approaches in diagrammatic form:

Figure 1 : Integration of SMG and WEB Mail

Figure 1 shows the interaction of Secure Messaging Gateways with WEB mail.

In system A mail is encrypted at the Gateway using the Domain certificate.

In system B mail is encrypted between the user and the Gateway and re-encrypted using the Domain certificate at the Gateway.

In system C WEB mail used between client and the gateway, using HTML and SSL for encryption and encrypted at the Gateway using the Domain certificate.

Figure 2 : Integration of SMG and End-to-end

Figure 2 shows the interaction of Secure Messaging Gateways with end-to-end Secure Messaging.

The systems at the top are both configured for end-to-end secure messaging (as in the Messaging Forum Secure Messaging Challenge).

The system at the bottom has a Secure Messaging Gateway.

This can work providing that the end-to-end systems are able to accept a domain certificate in place of an individual user certificate. It seems possible that this process could be made automatic (depending on policies .. the enterprise may or may not find substitution of a user certificate by a domain certificate acceptable) and if there was a way of locating the appropriate LDAP server to retrieve certificate (e.g. via the DNS record for a domain).

Some questions that need to be addressed:

1. To what extent is the SRV record work in IETF being adopted. That could provide a means for advertising LDAP servers.
2. To what extent are companies adopting LDAP for outward facing directories.
3. Is there an adequate LDAP proxy mechanism to make a subset of directory contents externally visible.
4. Would this approach meet the needs of users.
5. Is is a practical approach for vendors.
6. Can we treat WEB mail as the same as any other mail server.
7. How much of the nature of the mail system has to be visible to allow the sending organization to implement their policies?
8. How do we integrate signatures into the overall approach.

4. Next Steps

there was a general sense that developing an overall architecture that integrates the different approaches to Secure Messaging is feasible and that the Forum should continue to work on this.

Next steps

1. Document the output of this meeting.
   
2. Develop the skeleton of a White Paper for Secure Messaging 
   
3. Build a list of information that is needed (starting with the questions above)

Attendee List