SIPPING K. Ono
Internet-Draft S. Tachimoto
Expires: November 15, 2004 NTT Corporation
May 17, 2004
End-to-middle Security in the Session Initiation Protocol(SIP)
draft-ono-sipping-end2middle-security-02
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 November 15, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Some services provided the intermediaries depend on the ability to
inspect the message bodies in the Session Initiation Protocol (SIP).
When sensitive information is included in them, a SIP User Agent
needs to protect it from all intermediaries except the certain
selected intermediaries. This document proposes a mechanism for
securing information passed between an end user and a selected
intermediary using S/MIME. This also proposes a mechanism for the
discovery of an intermediary that needs to inspect an S/MIME-secured
message body.
Conventions used in this document
Ono & Tachimoto Expires November 15, 2004 [Page 1]
Internet-Draft End-to-middle security in SIP May 2004
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Generating S/MIME CMS Data . . . . . . . . . . . . . . . . . . 3
3. Indicating the Target Content . . . . . . . . . . . . . . . . 4
4. Discovery of the Proxy Server's Policies . . . . . . . . . . . 5
5. Behavior of UAs and Proxy Servers . . . . . . . . . . . . . . 6
5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Content-Target Header Field Use . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Request Example for End-to-Middle Confidentiality . . . . . . 8
7.2 Request Example for End-to-Middle Integrity . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Ono & Tachimoto Expires November 15, 2004 [Page 2]
Internet-Draft End-to-middle security in SIP May 2004
1. Introduction
When a SIP [2] UA requires services that are provided by
intermediaries depending on the message bodies in request/response
messages, end-to-end confidentiality will currently have to be
disabled to take advantage of the services. This problem is pointed
out in Section 23 of [2]. Since such an intermediary is not always
adjacent to the UA, this situation requires security between the UA
and the intermediary for the message bodies. We call this
"end-to-middle security", where by "end" we mean a UA and by "middle"
we mean a specific intermediary, typically a proxy server.
This document describes proposed mechanisms to provide data
confidentiality and integrity for end-to-middle security to meet the
requirements discussed in [3]. Since the major requirement is to have
little impact on the standardized end-to-end security mechanisms, the
proposed mechanisms are based on S/MIME [4]. The mechanisms consist
of generating S/MIME CMS [5] data and indicating target message body
for a selected proxy server. In addition, it also includes a
mechanism for the discovery of selected proxy servers.
2. Generating S/MIME CMS Data
For end-to-middle confidentiality, a UAC MUST be able to generate S/
MIME CMS EnvelopedData, whose recipients are specified in the
"recipientInfos" field. The structure of the S/MIME CMS EnvelopedData
contains data encrypted with a content-encryption-key (CEK) and the
CEK encrypted with different key-encryption-keys (KEKs), one for each
recipient as specified in [5]. The KEKs are the public keys of each
recipient or the shared keys between the UAC and each recipient.
If the data is encrypted only for a selected proxy server, the
recipients contain only the proxy server. If there is encrypted data
for destined for different proxy servers, the recipient list of each
encrypted piece of data will contain the targeted proxy servers. The
UAC MUST generate a multipart MIME body to contain the encrypted
data. When the message body including the encrypted data is
transmitted to a UAS, the UAS will be unable to decrypt it. The UAC
MUST set the value "optional" in the handling parameter of the
Content-Disposition MIME header for the message body in order to
avoid causing unneeded error condition in the UAS.
Open Issue: Is it necessary that a multipart MIME body contains
the handling parameter of Content-Disposition header? How should
it be set when the multipart MIME body contains a body with the
value "required" and another body with the value "optional"?
If the encrypted data is meant to be shared with the UAS and selected
proxy servers, the recipients SHOULD be addressed to the UAS and
Ono & Tachimoto Expires November 15, 2004 [Page 3]
Internet-Draft End-to-middle security in SIP May 2004
selected proxy servers. The UAS SHOULD decrypt the message body
including the encrypted data. The UAC SHOULD set the value "required"
in the handling parameter of the Content-Disposition MIME header for
the message body. If the handling parameter is not set, the default
behavior is the same as setting the value "required" as specified in
[2]
If an encrypted piece of data is destined for a selected proxy server
and another encrypted data is for the UAS, the recipient of each
encrypted data is each entity. In this case, the UAC MUST generate
them part of a multipart MIME body.
For example, UAs use this method when keying materials, such keys for
use by Secure RTP (SRTP), are included in the SDP[6]. One CMS
EnvelopedData body contains SDP that includes keying materials of an
SRTP stream only for the UA. The other EnvelopedData body contains an
SDP that does not include the keying materials of an SRTP stream only
for a selected proxy server that needs to view SDP (i.e.: for a
firewall traversal service).
For end-to-end data integrity, UAs use S/MIME CMS SignedData body
that can be validated by any entity. Therefore no new CMS SignedData
generating mechanism is required for end-to-middle data integrity.
Note: Even when the handling parameter is set to the value
"optional", the UAS SHOULD validate the signature of whole MIME
body, since Content-Disposition might be modified by a malicious
entity.
3. Indicating the Target Content
UAs needs a way to indicate the target of the content in order that a
proxy server can easily determine whether to process S/MIME bodies
and if so, which one. The UA SHOULD set a new "Content-Target" MIME
header to label the target message body for a selected proxy server.
When UAs label the encrypted data, the UA SHOULD set the
"Content-Target" MIME header of the S/MIME CMS EnvelopedData. When
UAs label the data with signature, the UA SHOULD set the
"Content-Target" MIME header of the S/MIME CMS SignedData. When proxy
servers receive a message, the proxy server SHOULD inspect the
"Content-Target" MIME header.
UAs SHOULD generate a digital signature of whole message body
including the "Content-Target" MIME header in order to protect the
indication. The proxy server SHOULD validate the signature of whole
message body to check the integrity of the indication, even when the
"Content-Target" MIME header is not set to whole message body.
This method of indicating the target has less of an impact on proxy
Ono & Tachimoto Expires November 15, 2004 [Page 4]
Internet-Draft End-to-middle security in SIP May 2004
servers that do not support end-to-middle security because these
proxy servers do not inspect the MIME header anyway. Also there is
less of an impact on UAs that do not support this MIME header,
because the UAs will ignore irrelevant MIME headers.
Note: In the last version of this proposal, we used a new
parameter in "Content-Disposition" MIME header. As pointed out,
the semantic of the header is ambiguous. A new MIME header is
better.
Note: There is an alternative option, the use of a new SIP header.
This proposed mechanism puts more load on proxy servers to
determine the necessity of MIME body handling than using a new SIP
header would. However, the proxy can view the indicated MIME body
more effectively than using a new SIP header. Also, the validation
cost for integrity protection of these headers reduces the merit
on using a new SIP header. For the integrity protection of SIP
headers, a message body that is application/sipfrag [7] needed. In
addition, using a new SIP header could have a negative impact on
intermediary proxy servers that do not support end-to-middle
security, causing unnecessary processing load. We feel that this
MIME header mechanism is not as simple, but it is equally
effective.
4. Discovery of the Proxy Server's Policies
A discovery mechanism for proxy server's policies is needed when UAs
do not know the policies of the proxy server in a signaling path and
the proxy server has its own policy for providing some services.
When the proxy server receives a request in which it cannot view some
data that must be read in order to proceed or the proxy server
receives a request whose sending policy cannot be accepted, the proxy
MUST send a response with an error code. If the request is in plain
text, the error code SHOULD be 403 (Forbidden) accompanied with a
required Content-Type, such as "application/sdp". If the request is
in plain text and the digital signature of it is required for an
integrity check, the error code SHOULD be 403 (Forbidden) accompanied
with a required Content-Type that is "multipart/signed".
Open Issue: How does the error message indicate the Content-Type
to be attached with a signature? Can these Content-Type be nested
such as "Content-Type: multipart/signed" for "Content-Type:
application/sdp"? Is it better to define a new error code for
requiring a signature attachment?
If the request contains encrypted data, the error code SHOULD be 493
(Undecipherable), accompanied with a proxy's public key certificate
and required Content-Type.
Open Issue: Instead of 493, SHOULD it be 403 that is the same as
for requiring a signature attachment? When proxy servers require
both of disclosure and the integrity check, how will it be
Ono & Tachimoto Expires November 15, 2004 [Page 5]
Internet-Draft End-to-middle security in SIP May 2004
described?
When the UAC receives one of the above error codes, the UAC needs to
authenticate the proxy server. Therefore, the error code SHOULD
contain the digital signature of the proxy server.
In the worst case, this discovery mechanism requires two messages for
each proxy server in the signaling path to establish a session
between the UAs. In addition, it requires validation procedures using
the digital signatures for all proxy servers. Since this causes a
increase in the delay before session establishment, it is recommended
that UAs learn in advance the policies of as many proxy servers as
they can.
Open Issue: How does this mechanism apply in the case when a proxy
server needs to inspect the message body contained in the
response? This might be happen when the SDP offer/answer is done
with 200/ACK messages.
5. Behavior of UAs and Proxy Servers
We describe here an example of the behavior of UAs and proxy servers
in a model in which a proxy server that provides logging services for
instant messages exists in a message path as shown in Figure 1.
+-----+ +-----+ +-----+ +-----+
| C |-----| C |-----| * |-----| C |
+-----+ +-----+ +-----+ +-----+
UA #1 Proxy #1 Proxy #2 UA #2
w/Logging function
C: Content that UA #1 allows the entity to inspect
*: Content that UA #1 prevents the entity from inspecting
Figure 1: Deployment example
5.1 UAC Behavior
When a UAC sends an MESSAGE [8] request including encrypted message
content for end-to-end and end-to-middle confidentiality, it MUST use
S/MIME CMS EnvelopedData to encrypt them. In this example, UA #1 is
assumed to know the services and the public key of Proxy #1. UA #1
MUST use CMS EnvelopedData for UA #2 and Proxy #1. UA #1 SHOULD
specify Proxy #1 in the "Content-Target" MIME header of the message
body to be decrypted.
When the UAC sends a request and needs end-to-end and end-to-middle
integrity for the message body, it MUST use S/MIME CMS SignedData to
Ono & Tachimoto Expires November 15, 2004 [Page 6]
Internet-Draft End-to-middle security in SIP May 2004
attach a digital signature. In this example, UA #1 MUST use the CMS
SignedData of the contents. UA #1 SHOULD specify Proxy #1 in the
"Content-Target" MIME header of the signature to be validated.
When the UAC sends multiple requests to the UAS, the CEK reuse
mechanism is beneficial that UAs efficiently encrypt/decrypt data.
The CEK reuse mechanism is described in [9][10]. the UAC SHOULD uses
the "unprotectedAttrs" field to stipulate reuse of the CEK and
indicate its identifier. When the UAC reuses the CEK in the previous
request as the KEK, the UAC generate CMS EnvelopedData with the type
"KEKRecipientInfo" of "RecipientInfo" attribute.
5.2 UAS Behavior
When a UAS sends a response for the request with this mechanism,
using the same type of S/MIME CMS data is recommended. For example,
if the UAS receives an INVITE request in which the SDP is encrypted
by using CMS EnvelopedData body, the response is RECOMMENDED to be a
"200 OK" containing the encrypted SDP based on CMS EnvelopedData
body. In the above example, however, the response of the MESSAGE
request does not need to use the same type of S/MIME CMS data, since
the response does not contain the message content.
In particular, when the CMS EnvelopedData body of the request
contains the "unprotectedAttrs" attribute specifying reuse of the
CEK, the UAS SHOULD keep the CEK with the identifier specified in the
"unprotectedAttrs" attribute.
When the UAS receives a request that uses S/MIME, it decrypts and/or
validates the S/MIME bodies as usual.
Even when the UAS receives the request without this mechanism, UAS
MAY need end-to-end and end-to-middle confidentiality of the message
bodies and/or headers in the response. In this case, the UAS MUST use
CMS EnvelopedData to encrypt them. When the UAS sends a response and
needs end-to-end and end-to-middle integrity of the message bodies
and/or headers, it MUST use CMS SignedData to attach a digital
signature. This is the same way the UAC normally performs with this
mechanism.
5.3 Proxy Behavior
When a proxy supporting this mechanism receives a message, the proxy
server MUST inspect the "Content-Target" MIME header. If the MIME
header includes the processing server's own name, the proxy server
MUST inspect the specified body.
When the specified body is CMS EnvelopedData, the proxy server MUST
Ono & Tachimoto Expires November 15, 2004 [Page 7]
Internet-Draft End-to-middle security in SIP May 2004
inspect it and try to decrypt the "recipientInfos" field. If the
proxy server fails to decrypt that, it SHOULD cancel the subsequent
procedure and respond with a 493 (Undecipherable) response if it is a
request, or any existing dialog MAY be terminated. If the proxy
server succeeds in this decryption, it MUST inspect the
"unprotectedAttrs" field of the CMS EnvelopedData. If the attribute
gives the key's identifier, the proxy server MUST keep the CEK with
its identifier until the lifetime of the CEK is expired. When it
receives subsequent messages within the lifetime, it MUST try to
decrypt the type "KEKRecipientInfo" of "RecipientInfo" attribute by
using this CEK.
When the specified content is CMS SignedData body, the proxy server
MUST inspect it and validate the digital signature. If the
verification is failed, the proxy server SHOULD reject the subsequent
procedure and respond with a 403 (Forbidden) response if the message
is a request, or any existing dialog MAY be terminated.
When the proxy server forwards the request, it modifies the routing
headers normally. It does not need to modify the S/MIME body.
If a proxy does not support this mechanism and receives a message
with the "Content-Target" MIME header, the proxy MUST ignore the
header and perform as usual.
6. Content-Target Header Field Use
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [11]. The new header
"Content-Target" is defined as a MIME header.
Content-Target = "Content-Target" HCOLON target-entity
target-entity = proxy-uri *(COMMA proxy-uri)
proxy-uri = ( name-addr / addr-spec )
7. Examples
The following examples illustrate the use of the mechanisms defined
in the previous sections.
7.1 Request Example for End-to-Middle Confidentiality
In the following example, a UA needs the message content in a MESSAGE
request to be confidential and the UA allows a selected proxy server
to view the message content. The UA also needs to protect the label
of the target content. In addition, the UA needs to reuse the CEK in
the subsequent request messages. In the example encrypted message
Ono & Tachimoto Expires November 15, 2004 [Page 8]
Internet-Draft End-to-middle security in SIP May 2004
below, the text with the box of asterisks ("*") is encrypted:
MESSAGE alice@atlanta.example.com --> ss1.atlanta.example.com
MESSAGE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <sip:ss1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 MESSAGE
Date: Fri, 20 June 2003 13:02:03 GMT
Content-Type: multipart/signed;protocol="application/pkcs7-signature";
micalg=sha1;boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: binary
Content-Disposition: attachment;filename=smime.p7m
Content-Target: ss1.atlanta.example.com
Content-Length: ...
******************************************************************
* (encryptedContentInfo) *
* Content-Type: text/plain *
* Content-Length: ... *
* *
* Hello. *
* This is confidential. *
* *
* (recipientInfos) *
* RecipientInfo[0] for ss1.atlanta.example.com public key *
* RecipientInfo[1] for bob's public key *
* *
* (unprotectedAttrs) *
* CEKReference *
******************************************************************
--boundary1--
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=smime.p7s;handling=required
Ono & Tachimoto Expires November 15, 2004 [Page 9]
Internet-Draft End-to-middle security in SIP May 2004
[binary data]
--boundary1--
7.2 Request Example for End-to-Middle Integrity
In the following example, a UA needs the integrity of the message
content in a MESSAGE request to be validated by a selected proxy
server. The UA also needs to protect the label of the target content.
MESSAGE alice@atlanta.example.com --> ss1.atlanta.example.com
MESSAGE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <sip:ss1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 MESSAGE
Date: Fri, 20 June 2003 13:02:03 GMT
Content-Type: multipart/signed;protocol="application/pkcs7-signature";
micalg=sha1;boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: text/plain
Content-Length: ...
Hello.
This is protected with the signature.
--boundary1--
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: binary
Content-Target: ss1.atlanta.example.com
Content-Disposition: attachment; filename=smime.p7s;handling=required
[binary data]
--boundary1--
Ono & Tachimoto Expires November 15, 2004 [Page 10]
Internet-Draft End-to-middle security in SIP May 2004
8. Security Considerations
TBD.
9. IANA Considerations
This document requires a new "Content-Target" MIME header.
10. Acknowledgments
Thanks to Rohan Mahy and Cullen Jennings for their initial support of
this concept, and to Jon Peterson for his helpful comments. Jonathan
Rosenberg gave us a useful comment.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] 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.
[3] Ono, K. and S. Tachimoto, "Requirements for end-to-middle
security in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-e2m-sec-reqs-02 (work in progress), May
2004.
[4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1992.
[5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
1999.
[6] Andreasen, F., Baugher, M. and D. Wing, "Session Description
Protocol Security Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-03.txt (work in progress),
February 2004.
[7] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002.
[8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[9] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption
Keys", RFC 3185, October 2001.
Ono & Tachimoto Expires November 15, 2004 [Page 11]
Internet-Draft End-to-middle security in SIP May 2004
[10] Ono, K. and S. Tachimoto, "Key reuse in S/MIME for SIP",
draft-ono-sipping-keyreuse-smime-00 (work in progress),
February 2004.
[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Authors' Addresses
Kumiko Ono
Network Service Systems Laboratories
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-shi, Tokyo 180-8585
Japan
EMail: ono.kumiko@lab.ntt.co.jp
Shinya Tachimoto
Network Service Systems Laboratories
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-shi, Tokyo 180-8585
Japan
EMail: tachimoto.shinya@lab.ntt.co.jp
Ono & Tachimoto Expires November 15, 2004 [Page 12]
Internet-Draft End-to-middle security in SIP May 2004
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 (2004). 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
Ono & Tachimoto Expires November 15, 2004 [Page 13]
Internet-Draft End-to-middle security in SIP May 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ono & Tachimoto Expires November 15, 2004 [Page 14]