SIPPING WG R. Mahy Internet-Draft Cisco Systems, Inc. Expires: December 27, 2003 June 28, 2003 Discussion of suitability: S/MIME instead of Digest Authentication in the Session Initiation Protocol (SIP) draft-mahy-sipping-smime-vs-digest-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 27, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Digest authentication (as defined in RFC2617) is used in SIP (RFC3261) for user authentication, and less frequently for message integrity of MIME bodies carried in SIP. Various members of the IETF security community have periodically suggested that Digest should be deprecated in favor of the SIP use of S/MIME (RFC2633), support for which was recently introduced in RFC3261. The author seeks clarity from the IETF security community on behalf of the SIP community about the feasibility and possible benefits of using S/MIME instead of Digest in one or both of these applications. Mahy Expires December 27, 2003 [Page 1] Internet-Draft SMIME vs. Digest in SIP June 2003 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. User Authentication . . . . . . . . . . . . . . . . . . . . . 3 3. Body Integrity . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Issues with Shared Keys . . . . . . . . . . . . . . . . . . . 6 5. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Administrative Issues . . . . . . . . . . . . . . . . . . . . 7 7. Implementation Issues . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 Normative References . . . . . . . . . . . . . . . . . . . . . 8 Informational References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Mahy Expires December 27, 2003 [Page 2] Internet-Draft SMIME vs. Digest in SIP June 2003 1. Overview SIP [1] is a text-based application protocol that allows two endpoints in the Internet to discover one another in order to exchange context information about a session they would like to share. Common applications for SIP include Internet telephony, instant messaging, video, Internet gaming and other forms of real-time communications. While SIP User Agents can communicate directly, their communication is typically facilitated by intermediaries called proxy servers or B2BUAs (Back to Back User Agents). Digest authentication (as defined in RFC2617 [2]) is used in SIP for user authentication, and less frequently for message integrity of MIME bodies carried in SIP. In SIP any number of intermediaries can request Digest authentication, in addition to the final recipient User Agent. Various members of the IETF security community have periodically suggested that Digest should be deprecated in favor of the SIP use of S/MIME [3], support for which was recently introduced in RFC3261 [1]. The author seeks clarity from the IETF security community on behalf of the SIP community about the feasibility and possible benefits of using S/MIME instead of Digest in one or both of these applications, and raises some issues to encourage that discussion. In the process of these discussions, the S/MIME community has also recommended some changes or clarifications to SIP specifications and implementations. 1. Since SIP is an 8-bit clean transport, use of binary Content-Transfer-Encoding was suggested (see also [10]). 2. Since SIP has request-response model, and supports negotiations, attached signatures may be used much more safely than in Internet mail and lead to a more straightforward MIME encoding than using detached signatures. 2. User Authentication Digest authentication in SIP is used primarily for user authentication. In SIP, both User Agents and any number of intermediaries can request authentication. SIP messages which are signed with S/MIME provide a suitable form of authentication for end-to-end communication, but there is currently no way to "direct" an S/MIME body to an intermediary, nor is there an existing MIME body which obviously conveys the correct semantics (a signed assertion of Mahy Expires December 27, 2003 [Page 3] Internet-Draft SMIME vs. Digest in SIP June 2003 identity) to intermediaries. It seems feasible to add a new token to the existing SIP Authorization and Proxy-Authorization header to convey this information, but it is unclear to what extent this is a benefit over Digest. Guidance is sought from the security community as to which parameters would be required to make such an assertion secure. Note the following example Authorization header from RFC3261: Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" Conceivably a similar assertion of identity could be made using syntax similar to the following, where cid is a pointer to a Content-ID header that identifies the correct body which appears later in the message. Note that From, Date, and Call-ID headers are typically included in the signed portion of the SIP message to prevent replay. INVITE sip:alice@atlanta.com SIP/2.0 To: From: ;tag=xyz Call-ID: pdq798 Date: Thu, 21 Feb 2002 13:02:03 GMT Proxy-Authorization: SMIME realm="biloxi.com", cid="1234@atlanta.com", qop="auth" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=foo Content-ID: <1234@atlanta.com> Content-Length: ... --foo Content-Type: message/sipfrag Content-Length: ... From: ;tag=xyz Call-ID: pdq798 Date: Thu, 21 Feb 2002 13:02:03 GMT Proxy-Authorization: SMIME username="bob", realm="biloxi.com", Mahy Expires December 27, 2003 [Page 4] Internet-Draft SMIME vs. Digest in SIP June 2003 cid="1234@atlanta.com", qop="auth" --foo Content-Type: application/pkcs7-signature Content-Length: ... Content-Transfer-Encoding: ...raw 8-bit binary SignedData goes here.. --foo-- Alternatively, attached signatures could be used for more efficiency: INVITE sip:alice@atlanta.com SIP/2.0 To: From: ;tag=xyz Call-ID: pdq798 Date: Thu, 21 Feb 2002 13:02:03 GMT Proxy-Authorization: SMIME realm="biloxi.com", cid="1234@atlanta.com", qop="auth" Content-Type: application/pkcs7-mime;smime-type=signedData Content-ID: <1234@atlanta.com> Content-Length: ... ....(raw 8-bit binary SignedData with attached Data)............... . . . From: ;tag=xyz . . Call-ID: pdq798 . . Date: Thu, 21 Feb 2002 13:02:03 GMT . . Proxy-Authorization: SMIME username="bob", realm="biloxi.com", . . cid="1234@atlanta.com", qop="auth" . . . ................................................................... 3. Body Integrity Digest allows for message integrity of bodies between SIP User Agents or from a SIP User Agent to a SIP intermediary. Again, while RFC 3261 already defines a mechanism to sign a message body from one SIP User Agent to another, in order to "address" an S/MIME signature towards a SIP intermediary some additional (probably minor) specification is necessary within SIP, as MIME bodies in SIP are typically not processed by intermediaries. Similarly a signed authorization header (possibly identified with qop="auth-int") could be used to provide a "pointer" to a signed message body. Note that support for detached signatures may be desirable if multiple intermediaries all wish to sign the same body. Currently SIP prohibits proxy servers for modifying or adding bodies. Mahy Expires December 27, 2003 [Page 5] Internet-Draft SMIME vs. Digest in SIP June 2003 This restriction would need to be relaxed in order to facilitate a number of proposed security enhancements to SIP. (Ironically this restriction was included in the specification to make deployment of end-to-end security easier.) This topic is discussed in more detail in [11]. 4. Issues with Shared Keys Many SIP deployments currently rely on the use of a shared secret between SIP User Agents and SIP registration and proxy servers. Because of the user mobility aspect of SIP (users may use a variety of devices on an adhoc basis) it is frequently impractical to expect that a user will have access to his or her private key on each device he or she uses throughout the day. (Some proposals, including [9], show promise but require a critical mass of implementation before they are practical.) While self-signed device certificates and true user certificates are becoming more available on common SIP User Agents (for example, SIP telephones, some handheld organizers, software for desktop computers), shared secret authentication for some subset of a user's devices is likely to remain the norm for the immediate future. The authors note that S/MIME supports only a very limited subset of the content types defined in CMS (RFC3369 [4]). CMS defines multiple content types. Of these, only the Data, SignedData, and EnvelopedData content types are currently used for S/MIME. In particular, S/MIME does not support AuthenticatedData. RFC3211 [12] (now included in and obsoleted by RFC3369) defined the PasswordRecipientInfo type which can be used to allow peers to generate CMS EnvelopedData when the parties involved posses a shared secret, but posses no public keys. Although it is unclear to the author of this document if CMS AuthenticatedData supports the PasswordRecipientInfo type, the syntax of CMS is internally consistent with representing that option in the AuthenticatedData content type. Unfortunately the AuthenticatedData service is not supported by S/ MIME, and the SignedData service supported by S/MIME does not use the RecipientInfo type. As such, S/MIME does not include an obvious mechanism to sign, digest, or hash data using only a secret key. Clearly, S/MIME cannot replace Digest when shared keys are used, without additional elaboration or specification. Note that merely generating self-signed certificates is not sufficient. These self-signed certificates would need to be enrolled or bound using the shared secret. One proposal from the S/MIME community is for SIP to use CMS Mahy Expires December 27, 2003 [Page 6] Internet-Draft SMIME vs. Digest in SIP June 2003 AuthenticatedData directly, however there is some debate about which MIME type to use,and if an appropriate S/MIME or CMS profile is available for non-email uses (including SIP and recently XMPP). One option is to add all the CMS data types to the list of smime-types in the application/pkcs7-mime MIME type, but this has raised general questions of scope, such as whether the proper title for RFC2633 [3] is "How to do secure MIME with CMS" or "How to do secure messaging with MIME and CMS". 5. Anonymity SIP is frequently used to "introduce" two parties who may have little or no prior knowledge of each other. In fact SIP can arrange a session between a pair of mutually anonymous parties. It is an important consideration when including certificates in messages that these do not leak potentially private information. For more details about Privacy in SIP please consult [6]. 6. Administrative Issues At the time of this writing there are several outstanding dependencies in various S/MIME normative references. S/MIME version 3 (RFC2633) references RFC2630 [13], a version of the CMS specification which is obsoleted by RFC3369 and RFC3370 [5]. In addition, the SIP community would like to use AES as its baseline encryption algorithm. SMIME support for AES [7] depends on an upcoming 3.1 revision of SMIME. Timely submission of S/MIME v3.1 [8] would likely encourage better adoption of S/MIME by the SIP community. 7. Implementation Issues Open-source implementations have significantly lowered the barrier for reusing certain technologies. For example, OpenSSL was very successful in increasing the adoption of TLS [14]. Likewise for S/ MIME, the SIP community solicits comments about the availability, quality, and functionality of open-source S/MIME implementations. A few implementations discovered in a cursory search by the author include the Getronics S/MIME Freeware Library [15], Peter Gutmann's cryptlib [16], OpenSSL [17], and Mozilla Network Security Services [18]. The SIP community seeks implementations which support AuthenticatedData, key wrap, attached signature, and AES. 8. Security Considerations This entire document discusses security issues. 9. IANA Considerations Mahy Expires December 27, 2003 [Page 7] Internet-Draft SMIME vs. Digest in SIP June 2003 This document raises no issues significant to IANA. 10. Acknowledgments Thanks to Eric Rescorla and Jon Peterson for discussions which led to this document, and to Jim Schaad for his numerous helpful suggestions. 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] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [3] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [4] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002. [5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [6] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", draft-ietf-sip-privacy-general-01 (work in progress), June 2002. [7] Schaad, J., "Use of the AES Encryption Algorithm in CMS", draft-ietf-smime-aes-alg-07 (work in progress), May 2003. [8] Ramsdell, B., "S/MIME Version 3.1 Message Specification", draft-ietf-smime-rfc2633bis-04 (work in progress), June 2003. Informational References [9] Jennings, C., "Certificate Discover for SIP", draft-jennings-sipping-certs-00 (work in progress), February 2003. [10] Jennings, C., "Recommendations for using MIME body parts in SIP", draft-jennings-sip-mime-00 (work in progress), June 2003. [11] Barnes, M., "A Mechanism to Secure SIP Identity headers inserted by Intermediaries", Mahy Expires December 27, 2003 [Page 8] Internet-Draft SMIME vs. Digest in SIP June 2003 draft-barnes-sipping-sec-inserted-info-00 (work in progress), June 2003. [12] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, December 2001. [13] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [14] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. URIs [15] [16] [17] [18] Author's Address Rohan Mahy Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA EMail: rohan@cisco.com Mahy Expires December 27, 2003 [Page 9] Internet-Draft SMIME vs. Digest in SIP June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Mahy Expires December 27, 2003 [Page 10] Internet-Draft SMIME vs. Digest in SIP June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mahy Expires December 27, 2003 [Page 11]