RFC 3853 (rfc3853) - Page 2 of 6


S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)



Alternative Format: Original Text Document



RFC 3853             S/MIME AES Requirement for SIP            July 2004


1.  Introduction

   The Session Initiation Protocol (SIP) specification (RFC 3261 [1])
   currently details optional support (a normative MAY) for the use of
   secure MIME, or S/MIME (RFC 2633 [8]).  Since RFC 3261 was published,
   the S/MIME specification and the underlying Cryptographic Message
   Syntax (CMS, RFC 3369 [3]) have undergone some revision.  Ongoing
   work has identified AES as a algorithm that might be used for content
   encryption in S/MIME.

   The Advanced Encryption Standard (AES [6]) is widely believed to be
   faster than Triple-DES (3DES, which has previously been mandated for
   usage with S/MIME) and to be comparably secure.  AES is also believed
   to have comparatively low memory requirements, which makes it
   suitable for use in mobile or embedded devices, an important use-case
   for SIP.

   As an additional consideration, the SIP specification has a
   recommendation (normative SHOULD) for support of Transport Layer
   Security (TLS, RFC 2246 [7]).  TLS support in SIP requires the usage
   of AES.  That means that currently, implementations that support both
   TLS and S/MIME must support both 3DES and AES.  A similar duplication
   of effort exists with DSS in S/MIME as a digital signature algorithm
   (the mandatory TLS ciphersuite used by SIP requires RSA).  Unifying
   the ciphersuite and signature algorithm requirements for TLS and
   S/MIME would simplify security implementations.

   It is therefore desirable to bring the S/MIME requirement for SIP
   into parity with ongoing work on the S/MIME standard, as well as to
   unify the algorithm requirements for TLS and S/MIME.  To date, S/MIME
   has not yet seen widespread deployment in SIP user agents, and
   therefore the minimum ciphersuite for S/MIME could be updated without
   obsoleting any substantial deployments of S/MIME for SIP (in fact,
   these changes will probably make support for S/MIME easier).  This
   document therefore updates the normative requirements for S/MIME in
   RFC 3261.

   Note that work on these revisions in the S/MIME working group is
   still in progress.  This document will continue to track that work as
   it evolves.  By initiating this process in the SIP WG now, we provide
   an early opportunity for input into the proposed changes and give
   implementers some warning that the S/MIME requirements for SIP are
   potentially changing.








Peterson                    Standards Track