This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality for SIP (Session Initiation Protocol) based messaging using S/MIME (Secure/Multipurpose Internet Mail Extensions). It updates and clarifies RFC 3261, RFC 3428, and RFC 4975 in an attempt to make it easier to implement and deploy in an interoperable fashion. It also updates cryptographic algorithm recommendations previously specified in RFC 3261, RFC 3428, and RFC 4975. This document is targeted as Standards Track because of these updates.
Sean Turner is the document shepherd.
Alexey Melnikov is the responsible Area Director.
# Review and Consensus
The document was presented at IETF100 to the DISPATCH WG, see https://datatracker.ietf.org/meeting/100/materials/slides-100-dispatch-secure-messaging-00. The draft was also discussed on the dispatch list; the result was to suggest AD sponsorship:
In general, the discussion did not indicate major technical flaws. There were some minor comments that have been addressed in version 3. There was some questions about whether the material is still relevant, but there were other comments indicating support. This included a comment to the effect that there is US wireless industry support for the work. (See “Other Points” section for related details.)
# Intellectual Property
I have confirmed with each author that to their direct, personal knowledge any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.
# Other points
This document updates RFCs 3261, 3428, and 4975; the header, abstract, and introduction clearly denote this fact. Note that ID-nits complains about the “RFC” being in the “Updates” line.
* There is one DOWNREF, RFC 5753, but RFC 5753 has been in the DOWNREF registry for a long time. RFC 5753, actually all RFCs which specified EC (Elliptic Curve) algorithms, was Informational because of IPR concerns. Now you’ll note that many protocols are standardizing on EC curves.
* There is one obsolete informational reference but that is by design.
There are no IANA considerations for this document, and that makes sense because it’s not defining any new OIDs (Object Identifiers) for algorithms used in CMS/S/MIME, SIP headers, etc.
Carriers are talking about deployment of the RCS specifications from GSMA, which depends upon SIP MESSAGE and MSRP. This specification provides end-to-end protection for both of those messaging protocols. Without this specification (or one something like it), then will not be an opportunity for end-to-end protections. At least one industry association is looking into the infrastructure needed to support the deployment of these end-to-end security capabilities.