Difference between revisions of "RFC3853"
imported>Admin (Created page with " Network Working Group J. Peterson Request for Comments: 3853 Neustar Updates: 3261 ...") |
|||
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Network Working Group J. Peterson | Network Working Group J. Peterson | ||
Request for Comments: 3853 Neustar | Request for Comments: 3853 Neustar | ||
Updates: 3261 July 2004 | Updates: 3261 July 2004 | ||
Category: Standards Track | Category: Standards Track | ||
− | |||
S/MIME Advanced Encryption Standard (AES) | S/MIME Advanced Encryption Standard (AES) | ||
Line 28: | Line 21: | ||
Abstract | Abstract | ||
− | + | RFC 3261 currently specifies 3DES as the mandatory-to-implement | |
ciphersuite for implementations of S/MIME in the Session Initiation | ciphersuite for implementations of S/MIME in the Session Initiation | ||
Protocol (SIP). This document updates the normative guidance of RFC | Protocol (SIP). This document updates the normative guidance of RFC | ||
3261 to require the Advanced Encryption Standard (AES) for S/MIME. | 3261 to require the Advanced Encryption Standard (AES) for S/MIME. | ||
+ | |||
+ | Table of Contents | ||
+ | |||
+ | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 | ||
+ | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | ||
+ | 3. S/MIME Ciphersuite Requirements for SIP . . . . . . . . . . . . 3 | ||
+ | 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 | ||
+ | 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||
+ | 5.1. Normative References . . . . . . . . . . . . . . . . . . . 4 | ||
+ | 5.2. Informative References . . . . . . . . . . . . . . . . . . 4 | ||
+ | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||
+ | 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 | ||
+ | 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6 | ||
== Introduction == | == Introduction == | ||
− | The Session Initiation Protocol (SIP) specification ( | + | The Session Initiation Protocol (SIP) specification (RFC 3261 [1]) |
currently details optional support (a normative MAY) for the use of | currently details optional support (a normative MAY) for the use of | ||
− | secure MIME, or S/MIME ( | + | secure MIME, or S/MIME (RFC 2633 [8]). Since RFC 3261 was published, |
the S/MIME specification and the underlying Cryptographic Message | the S/MIME specification and the underlying Cryptographic Message | ||
− | Syntax (CMS, | + | Syntax (CMS, RFC 3369 [3]) have undergone some revision. Ongoing |
work has identified AES as a algorithm that might be used for content | work has identified AES as a algorithm that might be used for content | ||
encryption in S/MIME. | encryption in S/MIME. | ||
Line 52: | Line 58: | ||
As an additional consideration, the SIP specification has a | As an additional consideration, the SIP specification has a | ||
recommendation (normative SHOULD) for support of Transport Layer | recommendation (normative SHOULD) for support of Transport Layer | ||
− | Security (TLS, | + | Security (TLS, RFC 2246 [7]). TLS support in SIP requires the usage |
of AES. That means that currently, implementations that support both | of AES. That means that currently, implementations that support both | ||
TLS and S/MIME must support both 3DES and AES. A similar duplication | TLS and S/MIME must support both 3DES and AES. A similar duplication | ||
Line 68: | Line 74: | ||
these changes will probably make support for S/MIME easier). This | these changes will probably make support for S/MIME easier). This | ||
document therefore updates the normative requirements for S/MIME in | 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 | Note that work on these revisions in the S/MIME working group is | ||
Line 76: | Line 82: | ||
implementers some warning that the S/MIME requirements for SIP are | implementers some warning that the S/MIME requirements for SIP are | ||
potentially changing. | potentially changing. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Terminology == | == Terminology == | ||
Line 91: | Line 88: | ||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT | "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT | ||
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as | RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as | ||
− | described in | + | described in BCP 14, RFC 2119 [2] and indicate requirement levels for |
compliant SIP implementations. | compliant SIP implementations. | ||
== S/MIME Ciphersuite Requirements for SIP == | == S/MIME Ciphersuite Requirements for SIP == | ||
− | The following updates the text of | + | The following updates the text of RFC 3261 Section 23.3, specifically |
the fifth bullet point. The text currently reads: | the fifth bullet point. The text currently reads: | ||
Line 130: | Line 127: | ||
known to introduce any new security considerations. | known to introduce any new security considerations. | ||
+ | == References == | ||
+ | === Normative References === | ||
+ | [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., | ||
+ | Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: | ||
+ | Session Initiation Protocol", RFC 3261, June 2002. | ||
+ | [2] Bradner, S., "Key words for use in RFCs to indicate requirement | ||
+ | levels", BCP 14, RFC 2119, March 1997. | ||
+ | [3] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, | ||
+ | August 2002. | ||
+ | [4] Schaad, J., "Use of the Advanced Encryption Standard (AES) | ||
+ | Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC | ||
+ | 3565, July 2003. | ||
+ | [5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", | ||
+ | RFC 3394, August 2002. | ||
+ | === Informative References === | ||
+ | [6] National Institute of Standards & Technology, "Advanced | ||
+ | Encryption Standard (AES).", FIPS 197, November 2001. | ||
− | + | [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC | |
+ | 2246, January 1999. | ||
− | + | [8] Ramsdell, B., Ed., "S/MIME Version 3.1 Message Specification", | |
+ | RFC 3851, July 2004. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Acknowledgments == | == Acknowledgments == | ||
Thanks to Rohan Mahy, Gonzalo Camarillo, and Eric Rescorla for review | Thanks to Rohan Mahy, Gonzalo Camarillo, and Eric Rescorla for review | ||
of this document. | of this document. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Author's Address == | == Author's Address == | ||
Line 186: | Line 176: | ||
EMail: [email protected] | EMail: [email protected] | ||
URI: http://www.neustar.biz/ | URI: http://www.neustar.biz/ | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Full Copyright Statement == | == Full Copyright Statement == | ||
Copyright (C) The Internet Society (2004). This document is subject | Copyright (C) The Internet Society (2004). This document is subject | ||
− | to the rights, licenses and restrictions contained in | + | to the rights, licenses and restrictions contained in BCP 78, and |
except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | ||
Line 250: | Line 200: | ||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | ||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | ||
− | found in | + | found in BCP 78 and BCP 79. |
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any |
Revision as of 13:57, 24 September 2020
Network Working Group J. Peterson Request for Comments: 3853 Neustar Updates: 3261 July 2004 Category: Standards Track
S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. S/MIME Ciphersuite Requirements for SIP . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Normative References . . . . . . . . . . . . . . . . . . . 4 5.2. Informative References . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6
Contents
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.
Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
S/MIME Ciphersuite Requirements for SIP
The following updates the text of RFC 3261 Section 23.3, specifically the fifth bullet point. The text currently reads:
o S/MIME implementations MUST at a minimum support SHA1 as a digital
signature algorithm, and 3DES as an encryption algorithm. All other signature and encryption algorithms MAY be supported. Implementations can negotiate support for these algorithms with the "SMIMECapabilities" attribute.
This text is updated with the following:
S/MIME implementations MUST at a minimum support RSA as a digital signature algorithm and SHA1 as a digest algorithm [5], and AES as an encryption algorithm (as specified in [4]. For key transport, S/MIME implementations MUST support RSA key transport as specified in section 4.2.1. of [5]. S/MIME implementations of AES MUST support 128-bit AES keys, and SHOULD support 192 and 256-bit keys. Note that the S/MIME specification [8] mandates support for 3DES as an encryption algorithm, DH for key encryption and DSS as a signature algorithm. In the SIP profile of S/MIME, support for 3DES, DH and DSS is RECOMMENDED but not required. All other signature and encryption algorithms MAY be supported. Implementations can negotiate support for algorithms with the "SMIMECapabilities" attribute.
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.
Security Considerations
The migration of the S/MIME requirement from Triple-DES to AES is not known to introduce any new security considerations.
References
Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[3] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
[4] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
RFC 3394, August 2002.
Informative References
[6] National Institute of Standards & Technology, "Advanced
Encryption Standard (AES).", FIPS 197, November 2001.
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[8] Ramsdell, B., Ed., "S/MIME Version 3.1 Message Specification",
RFC 3851, July 2004.
Acknowledgments
Thanks to Rohan Mahy, Gonzalo Camarillo, and Eric Rescorla for review of this document.
Author's Address
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
Phone: +1 925/363-8720 EMail: [email protected] URI: http://www.neustar.biz/
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- [email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.