SIPPING WG R. Mahy Internet-Draft Cisco Systems, Inc. Expires: April 1, 2003 Oct 2002 Discussion of suitability: S/MIME instead of Digest Authentication in the Session Initiation Protocol (SIP) draft-mahy-sipping-smime-vs-digest-00.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 April 1, 2003. Copyright Notice Copyright (C) The Internet Society (2002). 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 April 1, 2003 [Page 1] Internet-Draft SMIME vs. Digest in SIP Oct 2002 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. User Authentication . . . . . . . . . . . . . . . . . . . . . 3 3. Body Integrity . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Issues with Shared Keys . . . . . . . . . . . . . . . . . . . 5 5. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Administrative Issues . . . . . . . . . . . . . . . . . . . . 6 7. Implementation Issues . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 Normative References . . . . . . . . . . . . . . . . . . . . . 7 Informational References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Mahy Expires April 1, 2003 [Page 2] Internet-Draft SMIME vs. Digest in SIP Oct 2002 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. 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 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: Mahy Expires April 1, 2003 [Page 3] Internet-Draft SMIME vs. Digest in SIP Oct 2002 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", 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-- Mahy Expires April 1, 2003 [Page 4] Internet-Draft SMIME vs. Digest in SIP Oct 2002 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. 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. 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 [9] (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. Mahy Expires April 1, 2003 [Page 5] Internet-Draft SMIME vs. Digest in SIP Oct 2002 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. 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 [10], 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 [11]. 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 [12], OpenSSL [13], and Mozilla Network Security Services [14]. 8. Security Considerations This entire document discusses security issues. 9. IANA Considerations This document raises no issues significant to IANA. 10. Acknowledgments Thanks to Eric Rescorla and Jon Peterson for discussions which led to this document. Mahy Expires April 1, 2003 [Page 6] Internet-Draft SMIME vs. Digest in SIP Oct 2002 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] Housley, R. and J. Schaad, "Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS", draft-ietf-smime-aes-alg-04 (work in progress), February 2002. [8] Ramsdell, B., "S/MIME Version 3.1 Message Specification", draft- ietf-smime-rfc2633bis-01 (work in progress), July 2002. Informational References [9] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, December 2001. [10] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [11] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. URIs [12] [13] Mahy Expires April 1, 2003 [Page 7] Internet-Draft SMIME vs. Digest in SIP Oct 2002 [14] Author's Address Rohan Mahy Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA EMail: rohan@cisco.com Mahy Expires April 1, 2003 [Page 8] Internet-Draft SMIME vs. Digest in SIP Oct 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 assigns. 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 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 April 1, 2003 [Page 9]