ietf-corpus

rfc-3853

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

J. Peterson
date2004-07 streamIETF arearai wgsip statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc3853 doi10.17487/RFC3853
RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIME. [STANDARDS-TRACK]

updates

Extracted elements (12)

design-rationale §1

AES is widely believed to be faster than 3DES and comparably secure, with lower memory requirements that make it suitable for mobile or embedded SIP devices. This performance and resource profile motivated replacing 3DES as the mandatory ciphersuite.

sip, crypto, security

design-rationale §1

S/MIME had not seen widespread deployment in SIP user agents at the time of this update, meaning the change from 3DES to AES as the mandatory ciphersuite would not obsolete any substantial existing deployments and would likely make S/MIME support easier to implement.

sip, crypto, security

design-rationale §1

SIP already has a normative SHOULD for TLS, and TLS in SIP requires AES and RSA. Requiring both 3DES/DSS for S/MIME and AES/RSA for TLS created duplicated implementation effort; unifying the algorithm requirements for TLS and S/MIME simplifies security implementations.

sip, tls, crypto, security

interoperability-note §3

The base S/MIME specification (RFC 3851) mandates support for 3DES encryption, DH key encryption, and DSS signature; however, the SIP profile of S/MIME overrides these to RECOMMENDED, making AES, RSA key transport, and RSA signature the mandatory-to-implement suite for SIP.

sip, security, crypto

normative-requirement §3 MAY

All signature and encryption algorithms beyond the mandatory set MAY be supported; implementations can negotiate support using the 'SMIMECapabilities' attribute.

sip, crypto, security

normative-requirement §3 RECOMMENDED

In the SIP profile of S/MIME, support for 3DES, DH, and DSS is RECOMMENDED but not required, downgrading what was previously mandatory in the base S/MIME specification.

sip, crypto, security

normative-requirement §3 MUST

S/MIME implementations in SIP MUST at a minimum support RSA as a digital signature algorithm, SHA1 as a digest algorithm, and AES as an encryption algorithm. This updates the previous requirement for 3DES specified in RFC 3261 Section 23.3.

sip, crypto, security

normative-requirement §3 MUST

S/MIME implementations in SIP MUST support RSA key transport as specified in section 4.2.1 of RFC 3394 (CMS Algorithms). This replaces the previous requirement for DH key encryption.

sip, crypto, security

normative-requirement §3 MUST

S/MIME implementations of AES in SIP MUST support 128-bit AES keys, and SHOULD support 192 and 256-bit keys.

sip, crypto, security

normative-requirement §3 MUST

Since SIP is 8-bit clean, all implementations MUST use 8-bit binary Content-Transfer-Encoding for S/MIME in SIP. Implementations MAY also be able to receive base-64 Content-Transfer-Encoding.

sip, security

protocol-element §3

The 'SMIMECapabilities' attribute is the negotiation mechanism by which SIP S/MIME implementations advertise and agree upon supported signature and encryption algorithms beyond the mandatory minimum set.

sip, security, crypto

security-consideration §4

The migration of the S/MIME mandatory ciphersuite requirement from Triple-DES to AES is not known to introduce any new security considerations.

sip, security, crypto