Current Meeting Report
Slides


2.5.8 S/MIME Mail Security (smime)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 24-Sep-01
Chair(s):
Russ Housley <rhousley@rsasecurity.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion:ietf-smime@imc.org
To Subscribe: ietf-smime-request@imc.org
Archive: http://www.imc.org/ietf-smime/
Description of Working Group:
The S/MIME Working Group has completed five Proposed Standards that comprise the S/MIME version 3 specification. Current efforts build on these base specifications.

The use of Diffie-Hellman Key Agreement as the mandatory to implement key establishment mechanism may expose some implementations to vulnerabilities based on "small subgroup" attacks. An informational document will be prepared describing techniques that can be used to avoid these attacks.

The Cryptographic Message Syntax (CMS) is cryptographic algorithm independent, yet there is always more than one way to use any algorithm. To ensure interoperability, each algorithm should have a specification that describes its use with CMS. Specifications for the use of additional cryptographic algorithms will be developed. An additional suite of 'mandatory to implement' algorithms may be selected.

To aid implementers, documents containing example output for CMS will be collected and published. Some of the examples will include structures and signed attributed defined in the Enhanced Security Services (ESS) document.

Current methods of publishing certificates in the Directory do not allow the inclusion of secondary support information such as the SMimeCapabilities attribute. A method of publishing certificates along with authenticated secondary support information will be defined.

In some situations it would be advantageous for the CMS RecipientInfo structure to support additional key management techniques, including cryptographic keys derived from passwords. A mechanism to facilitate the definition of additional key management techniques will be defined. S/MIME version 3 permits the use of previously distributed symmetric key-encryption keys. Specifications for the distribution of symmetric key-encryption keys to mmultiple message recipients will be developed. Mail List Agents (MLAs) are one user of symmetric key-encryption keys. The specification will be cryptographic algorithm independent.

S/MIME version 3 supports security labels. Specifications that show how this feature can be used to implement an organizational security policy will be developed. Security policies from large organizations will be used as examples.

S/MIME version 3 can be used to protect electronic mail to and from a domain. In such an environment, S/MIME v3 processing is performed by message transfer agents, guards, and gateways in order to provide "Domain Security Services." Mechanisms are needed to solve a number of interoperability problems and technical limitations that arise when domains supporting different security policies wish to interoperate.

The S/MIME Working Group will attempt to coordinate its efforts with the OpenPGP Working Group in areas where the work of the two groups overlap.

Goals and Milestones:
Done   First draft of CMS RecipientInfo extension.
Done   First draft of security label usage specification.
Done   Last call on small subgroup attack avoidance
Done   First draft of CAST algorithm specification.
Done   Last call on KEA and SKIPJACK algorithm specification.
Done   First draft of mail list key distribution.
Done   Last call on certificate distribution specification.
Done   Updated draft of domain security services document.
Done   Last call on CAST algorithm specification.
Done   Submit small subgroup attack avoidance as Informational RFC
Done   Submit KEA and SKIPJACK algorithm specification as Informational RFC.
Done   Last call on security label usage specification.
Dec 99   Last call on CMS and ESS examples document.
Done   Last call on IDEA algorithm specification.
Done   Last call on CMS RecipientInfo extension.
Jan 00   Last call on mail list key distribution.
Jan 00   Submit certificate distribution specification to IESG for consideration as a Proposed Standard.
Feb 00   Submit security label usage specification as Informational RFC.
Done   Submit CAST algorithm specification as Informational RFC.
Mar 00   Submit CMS and ESS examples document as Informational RFC.
Mar 00   Submit CMS RecipientInfo extension to IESG for consideration as a Proposed Standard.
Mar 00   Submit mail list key distribution to IESG for consideration as a Proposed Standard.
Done   Submit IDEA algorithm specification as Informational RFC.
Done   Last call on domain security services document.
Sep 00   Submit domain security services as Experimental RFC.
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC2311 S/MIME Version 2 Message Specification
RFC2312 S/MIME Version 2 Certificate Handling
RFC2630PSCryptographic Message Syntax
RFC2631PSDiffie-Hellman Key Agreement Method
RFC2632PSS/MIME Version 3 Certificate Handling
RFC2633PSS/MIME Version 3 Message Specification
RFC2634PSEnhanced Security Services for S/MIME
RFC2785 Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME
RFC2876 Use of the KEA and SKIPJACK Algorithms in CMS
RFC2984PSUse of the CAST-128 Encryption Algorithm in CMS
RFC3058 Use of the IDEA Encryption Algorithm in CMS
RFC3125E Electronic Signature Policies
RFC3183E Domain Security Services using S/MIME
RFC3126 Electronic Signature Formats for long term electronic signatures
RFC3185PSReuse of CMS Content Encryption Keys

Current Meeting Report

This message includes the official minutes of the IETF S/MIME Working Group (WG) meeting held at the 52nd IETF in December 2001 in Salt Lake City, UT, USA. Briefing slides will be available from

<ftp://ftp.ietf.org/ietf/smime/>. Reported by Jim Schaad.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions: Russ Housley covered the agenda for the meeting. No changes were made.

Introductions Russ Housley
Working Group Status Russ Housley
CMS Update Status Russ Housley
Interoperability Matrix Jim Schaad
CMS and ESS Examples Paul Hoffman
AES and RSA-OAEP Jim Schaad
Symmetric Key Distribution Sean Turner
Intended Recipient Attribute R. Housley & J. Schaad
Policy Requirements for TSAs Denis Pinkas
Signature Delegation Denis Pinkas
Wrap up Russ Housley

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Working Group Status and CMS Update Status: Russ covered the current status of the active documents in the working group. Current statuses are:

- Password, Triple-DES/RC2 Key Wrap, and Preventing the Million Message Attack on CMS documents are in RFC Editor 48 hour review.

- Security Label Implementation document is on hold by request of working group chairman, and hold will be released when the Attribute Certificate Profile is published.

- Compression, ECC, X400 Wrap, X400 Transport, and Symmetric Key Distribution drafts are currently with the IESG.

- RFC2630bis and CMSAlg are in IETF Last Call.

New versions of these RFC 2632 and RFC 2633 are needed since RFC2630bis has removed algorithm requirements. Blake Ramsdell, the editor of these documents, has recently changed jobs so a delay in updating the documents is expected. The updated documents will reflect the mandatory to implement algorithm requirements that were previously debated and accepted:

Signature Verification: DSA and RSA (PKCS#1 v1.5)
Signature Generation: DSA or RSA (PKCS#1 v1.5)
One-way Hash Function: SHA-1
Key Management: RSA (PKCS#1 v1.5)
Encryption: Triple-DES CBC

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Interoperability Matrix: Jim Schaad presented a briefing on the current state of interoperability testing for the RFC2630bis and CMSAlg drafts. In the core of the two documents SignedData has 6 items left, EnvelopedData has 10 items left, SigningTime has 2 items left and HMAC-SHA-1 has 3 items left.

Jim also presented two issues that had arisen during interoperability testing:

The first issue dealt with the problem of wrapping an HMAC key with a
Triple-DES, RC2 or AES key. Currently, one password-based key management includes a defined method for this operation. A new draft is to be prepared to define a mechanism.

The second issue dealt with DER encoding of SignedAttributes within the SignerInfo structure. Three alternatives were presented for a straw poll: 1) SignedAttributes must be DER encoded, 2) Attribute must be DER encoded, 3) AttributeValue must be DER encoded. Option 1 was the unanimous selection of the voters.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMS/ESS Examples: Paul Hoffman discussed this document (without slides). He is ready to request that the working group chair make a last call for the document to be published as an Informational RFC. There is an expectation that an update to the document will be produced in the future to deal with omissions from the current document and new examples that employ the AES algorithm.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

AES/RSA-OAEP: Jim Schaad presented the current status of the AES/RSA-OAEP draft. AES became FIPS 198 on 16 November 2001. Additionally the AES key wrap candidate algorithm was released in November. As this is still a draft document, and NIST has not produced a document that can be referenced. An informational track document covering the AES key wrap algorithm will be produced by the working group. The authors believe that the AES/RSA-OAEP draft should be ready for working group last call before the next IETF meeting.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Symmetric Key Distribution: Sean Turner gave a presentation on the status of this draft. He has received a few comments, even though the document has already passed working group last call. One set was editorial, and the other was a request for an additional attribute dealing with security policy. The latter request will probably be handled as a separate Internet-Draft to avoid delaying the symmetric key distribution draft. So far, an author has not volunteered.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Intended Recipient Attribute: Don Davis (from Curl Corp.) has identified a potential problem. The concern is that a recipient of signed and encrypted message can decrypt the message, preserving the original signature, and then resend the message to a new recipient. New recipient may act inappropriately based on the fact that they received a message signed by the original originator, not the middleman (for further discussion see draft-ietf-smime-sender-auth-00.txt). Russ Housley has prepared a potential solution to this problem (see draft-ietf-smime-ira-00.txt).

Russ presented the problem and his solution to the group, including the benefits and some potential drawbacks. Jim Schaad then presented a second view of the problems, attempting to resolve the issue in an Email environment. In the discussion that followed Phillip Hallam-Baker raised the point that while this solution covered the question of the TO and CC header lines, it did nothing to solve the problem of preventing the leakage of the SUBJECT line in a message. Following the discussion two straw polls were taken.

- Should the sender-auth draft be progressed as an information draft? The vote was unanimously no.

- Should the ira draft be progressed, and if so, on what track? The vote was unanimously for non-progression of this document as well.

Russ Housley took an action item to bring the question of general protection of the headers to the mail list.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Policy Requirements for TSAs: Denis Pinkas presented the status of the ETSI document on this topic. The final version of the document has not been published yet, but the current document is available at http://portal.etsi.org/sec/STF178Task1FinalDraft.pdf.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Signature Delegation: Denis Pinkas then presented some thoughts on a mechanism for a person to delegate their signature authority. A possible mechanism using the id-aa-ets-signerAttr was presented. Comments on whether the problem should be addressed by the working group and possible solutions will be discussed further on the mail list.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wrap Up: Russ Housley asked if there were any other issues to discuss.

No additional issues were raised, and the working group meeting was adjourned.

Slides

Agenda
Working Group Status
Intended Recipients Attribute
Cryptographic Message Syntax (CMS) Status
Policy requirements for Time-Stamping Authorities
Signature delegation
AES/OAEP
CMS Interop Matrix
S/MIME Symmetric Key Distribution