SIP K. Ono
Internet-Draft S. Tachimoto
Expires: January 10, 2006 NTT Corporation
July 9, 2005
End-to-middle Security in the Session Initiation Protocol (SIP)
draft-ietf-sip-e2m-sec-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 January 10, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Some services provided by intermediaries depend on their ability to
inspect a message body in the Session Initiation Protocol (SIP).
When sensitive information is included in the message body, a SIP
User Agent (UA) needs to protect it from other intermediaries than
those that the UA agreed to disclose it to. This document proposes a
mechanism for securing information passed between an end user and
intermediaries using S/MIME. It also proposes mechanisms for a UA to
discover intermediaries which need to inspect an S/MIME-secured
Ono & Tachimoto Expires January 10, 2006 [Page 1]
Internet-Draft End-to-middle security in SIP July 2005
message body, or to receive the message body with data integrity.
Conventions used in this document
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-secured Message Body . . . . . . . . . . . 3
2.1 S/MIME-secured Message Body for Confidentiality . . . . . 3
2.2 S/MIME-secured Message Body for Data Integrity . . . . . . 4
3. Indicating the Target Content . . . . . . . . . . . . . . . 5
4. Discovering the Security Policies of Proxy Servers . . . . . 5
5. Behavior of UAs and Proxy Servers . . . . . . . . . . . . . 7
5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 8
6. Proxy-Required-Body Header Field Use . . . . . . . . . . . . 9
7. Message Examples . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Message Examples of End-to-Middle Confidentiality . . . . 10
7.2 Message Examples of End-to-Middle Integrity . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . 16
8.1 Impersonating a Proxy Server . . . . . . . . . . . . . . . 16
8.2 Tampering with a Message Body . . . . . . . . . . . . . . 16
8.3 Tampering with the Label of the Target Content . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1 Normative References . . . . . . . . . . . . . . . . . . 17
11.2 Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20
Ono & Tachimoto Expires January 10, 2006 [Page 2]
Internet-Draft End-to-middle security in SIP July 2005
1. Introduction
When a UA requires services provided by intermediaries that depend on
the message body in request/response messages, end-to-end
confidentiality currently has to be disabled. This problem is
pointed out in Section 23 of [2]. Since such intermediaries are not
always adjacent to the UA, this situation requires security between
the UA and the intermediaries for the message body. We call this
"end-to-middle security", where by "end" we mean a UA and by "middle"
we mean an intermediary, typically a proxy server.
End-to-middle security, as well as end-to-end security, consists of
peer authentication, data integrity, and data confidentiality. Peer
authentication is required to achieve data integrity and data
confidentiality respectively. The mechanisms of end-to-middle peer
authentication are established with pre-existing mechanisms such as
HTTP Digest authentication [7]. Therefore, this document focuses on
mechanisms for providing data confidentiality and integrity for end-
to-middle security to meet the requirements discussed in [3].
The proposed mechanisms are based on S/MIME [4], since the major
requirement is to have little impact on standardized end-to-end
security mechanisms, the way of handling S/MIME-secure messages. The
mechanisms consist of generating S/MIME-secured message body and
indicating the target message body for a proxy server selected by the
UA. In addition, this document describes a mechanism for a UA to
discover the intermediary which needs to inspect an S/MIME-secured
message body, or to receive the message body with data integrity.
2. Generating S/MIME-secured Message Body
2.1 S/MIME-secured Message Body for Confidentiality
For end-to-middle confidentiality, a UA MUST generate S/MIME CMS [5]
EnvelopedData. Prior to generating it, a UA needs to identify the
target proxy servers and obtain their credentials, such as their
public key certificates or shared secrets. One method is shown in
Section 4.
The structure of the S/MIME CMS EnvelopedData contains encrypted data
specified in the "encryptedContentInfo" field and its recipient list
specified in the "recipientInfos" field. The encrypted data is
encrypted with a content-encryption-key (CEK) and the recipient list
contains the CEKs encrypted with different key-encryption-keys
(KEKs), one for each recipient. The KEKs are either the public keys
of each recipient or the shared keys between the UA and each
recipient.
Ono & Tachimoto Expires January 10, 2006 [Page 3]
Internet-Draft End-to-middle security in SIP July 2005
If the encrypted data is destined for a proxy server, the recipient
list MUST contain only the proxy server. If the same encrypted data
is destined for multiple proxy servers, or is shared with the user
agent server (UAS) and proxy servers, the recipient list MUST be
addressed to the proxy servers, or the UAS and the proxy servers. If
there are multiple pieces encrypted data destined for each proxy
server, the recipient list in each piece of encrypted data MUST
contain the relevant proxy server. If a piece of encrypted data is
destined for a proxy server and another piece of encrypted data for
the UAS, the recipient of each piece of encrypted data MUST be each
entity respectively. In order to concatenate more than one CMS
EnvelopedData, the user agent client (UAC) MUST generate a multipart
MIME body.
For example, a UA uses this mechanism when keying materials, such as
keys used for Secure RTP (SRTP), are included in the SDP[8].
Although a proxy server needs to view SDP (i.e., for a firewall
traversal service), the UA does not want to show the keying materials
to the proxy server. In this case, one CMS EnvelopedData contains
the SDP, that includes keying materials of the SRTP stream, encrypted
for the UA. The other CMS EnvelopedData contains the SDP, that does
not include the keying materials, encrypted for the proxy server.
As described in [2], proxy servers are prohibited from deleting any
message body. Even if a UAC send a piece of encrypted data only to a
proxy server, the UAS receives it and cannot decrypt it. In order to
avoid unnecessary error conditions in the UAS, the UAC MUST set the
value "optional" in the handling parameter of the "Content-
Disposition" MIME header for the message body. If the multipart MIME
body consists of encrypted MIME bodies with the value "optional", the
"Content-Disposition" MIME header of the multipart MIME body MUST
also contain the value "optional" in the handling parameter. If the
multipart MIME body contains a body with the value "required" and
another body with the value "optional", the multipart MIME body MUST
have either the value "required" in the handling parameter of the
"Content-Disposition" MIME header, or no handling parameter, since
the default value is "required" as specified in [2]. The UAS SHOULD
NOT try to decrypt encrypted data that has the value "optional".
2.2 S/MIME-secured Message Body for Data Integrity
For end-to-middle data integrity, a UA SHOULD generate either S/MIME
CMS SignedData. A UA MAY generate a signature in the SIP Identity
[9] header, if the UA has its own public and private key. These
mechanisms allow any entity to verify the data integrity, if it is
able to access the UA's public key. This is why the same mechanisms
can be used in both end-to-middle and end-to-end data integrity.
Ono & Tachimoto Expires January 10, 2006 [Page 4]
Internet-Draft End-to-middle security in SIP July 2005
Note: There are other mechanisms which can provide data integrity,
such as S/MIME CMS AuthenticatedData, which requires that a UA
obtains the credential of the recipient, that is a proxy server,
in advance. However, this is not used in [2] and require a
mechanism to securely transmit the credential from the proxy
server to the UA. Thus, this document does not describe the use
of S/MIME CMS AuthenticatedData.
3. Indicating the Target Content
A UA needs a way to indicate content that it expects to be viewed by
a proxy server, in order for the proxy server to easily determine
whether to process a MIME body and if so, which part. To meet this
requirement, the UA SHOULD set a label to indicate the proxy server
and its target content using a new SIP header, "Proxy-Required-Body".
This header consists of one or more proxy servers' hostnames and one
or more "content-id" parameter(s) pointing to the "Content-ID" MIME
header placed in the target body.
Note: There were three other options to label a body: a new SIP
parameter to an existing SIP header, a new MIME header, or a new
parameter to an existing MIME header.
1) Using a new parameter to Route header. Since a proxy server
views this header when forwarding a request message, it seems to
be a reasonable option. However, it cannot work with strict
routing.
2) Using a new MIME header, "Content-Target", as proposed in a
previous version of this draft. Since this option is not
necessary as a generic mechanism of MIME, it is not preferred.
3) Using a new MIME parameter to "Content-Disposition". The same
reason as above.
If a UA needs to label the encrypted data, it SHOULD set the "Proxy-
Required-Body" SIP header that contains the address of the proxy
server and "content-id" parameter indicating the target S/MIME CMS
EnvelopedData.
If a UA needs to label the signed data, it SHOULD set the "Proxy-
Required-Body" SIP header that contains the address of the server and
"content-id" parameter indicating the S/MIME CMS SignedData. Note
that the signature for part of a MIME body alone is meaningless in
providing data integrity.
4. Discovering the Security Policies of Proxy Servers
A discovery mechanism for security policies of proxy servers is
needed when a UA does not statically know which proxy servers or
domains have such policies. Security policies require disclosure of
Ono & Tachimoto Expires January 10, 2006 [Page 5]
Internet-Draft End-to-middle security in SIP July 2005
data and/or verification in order to provide some services which
needs UA's compliance.
There are two ways in which a UA can learn the policies of the proxy
servers. One is by receiving an error response. A UAC can learn the
policies in this way. However, it is not applicable to the UAS
because there is no way to react a response message. Alternatively,
a policy server can provide a UAC and the UAS a package mentioning
proxy's policy as described in [10]. When a proxy server needs to
inspect the message body contained in the response, it needs to learn
the policies from a policy server before sending the response.
When the proxy server receives a request that can not be accepted due
to its condition, the proxy server MUST reject with an error
response. If the request contains encrypted data and the proxy
server cannot view the message body that has to be viewed in order to
proceed, the proxy server MUST reject with a 493 (Undecipherable)
error response. The proxy's public key certificate and Content-Type
to be viewed SHOULD be contained with the error response. The proxy
public key certificate SHOULD be set as an "application/pkix-cert"
body. The required Content-Type SHOULD be set in the Warning header
with a new warn-code, 380.
If a digital signature is not attached to the message body in the
request and the proxy server requires the integrity check, the proxy
server MUST reject with a 495 (Signature Required) error response.
This error response does not contain signature required Content-Type,
since the attached signature to the whole body is always required.
When a proxy server requires both disclosure and an integrity check
of the message body in a request message and the message satisfies
neither, the proxy server SHOULD send one error response at a time.
When a proxy server cannot decrypt the message body in a request
message and does not see if the signature is placed inside, a proxy
server SHOULD send an error response only for requesting disclosure.
After receiving a request message including encrypted data destined
for the proxy server, it finds out whether the message has a
signature attached and SHOULD send an error response for requesting
signature when the message lacks it.
Note: A 495 (Signature Required) response is not only generated by
a proxy server, but also by the UAS.
This discovery mechanism requires two more messages' exchange for an
error condition per each proxy server in the signaling path in order
to establish a session between UAs. Since this causes a delay in
session establishment, it is desirable that the UAs learn the
security policies of the proxy servers in advance.
Ono & Tachimoto Expires January 10, 2006 [Page 6]
Internet-Draft End-to-middle security in SIP July 2005
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 a logging service
for instant messages exists in a signaling path as shown in Figure 1.
+-----+ +-----+ +-----+ +-----+
| C |-----| C |-----| [C] |-----| C |
+-----+ +-----+ +-----+ +-----+
UA #1 Proxy #1 Proxy #2 UA #2
w/Logging function
C : Content that UA #1 allows the entities to inspect
[C]: Content that UA #1 prevents the entity from inspecting
Figure 1: Deployment example
5.1 UAC Behavior
When a UAC sends a MESSAGE [11] request including encrypted message
content for end-to-end and end-to-middle confidentiality, it MUST use
S/MIME CMS EnvelopedData. If UA #1 is unaware of the services
provided by Proxy #1 that requires inspecting the message body, UA #1
will MAY get a 493 (Undecipherable) error response and the public key
of Proxy #1. After getting the error response, UA #1 MUST use S/MIME
CMS EnvelopedData body for UA #2 and Proxy #1. UA #1 SHOULD specify
the hostname of Proxy #1 and Content-ID of the S/MIME CMS
EnvelopedData to be decrypted by Proxy #1 in the "Proxy-Required-
Body" SIP header.
When a UAC sends a request message of which message body needs end-
to-middle integrity, it SHOULD use S/MIME CMS SignedData to attach a
digital signature. If UA #1 does not know the service of Proxy #1
that requires verifying the message body, UA #1 MAY get a 495
(Signature Required) error response. After getting the error
response, UA #1 SHOULD generate the CMS SignedData to attach a
signature by computing with its own private key. UA #1 SHOULD
specify the hostname of Proxy #1 and Content-ID of the CMS SignedData
to be validated by Proxy #1 in the "Proxy-Required-Body" SIP header.
When a UAC sends a request and needs both end-to-middle
confidentiality and integrity for the message body, it SHOULD first
attach a digital signature, and then encrypted the message body. In
this example, UA #1 SHOULD generate S/MIME CMS SignedData for the
contents, and then generate S/MIME CMS EnvelovedData body to encrypt
the CMS SignedData. UA#1 SHOULD specify the hostname of Proxy#1 and
Content-IDs of the CMS SignedData and the CMS EnvelopedData destined
Ono & Tachimoto Expires January 10, 2006 [Page 7]
Internet-Draft End-to-middle security in SIP July 2005
for Proxy #1 in the "Proxy-Required-Body".
When a UAC generates S/MIME CMS EnvelopedData, the UAC MAY use the
CEK reuse mechanism [12][13]. The CEK reuse mechanism has a benefit
that enables UAs to efficiently encrypt/decrypt data in subsequent
messages. The UAC MAY use 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, it generates CMS
EnvelopedData with the type "KEKRecipientInfo" of "RecipientInfo"
attribute.
5.2 UAS Behavior
When the UAS receives a request that uses S/MIME, it first decrypts
and/or validates the S/MIME bodies as usual. In particular, when the
CMS EnvelopedData body of the request contains the "unprotectedAttrs"
attribute specifying reuse of the CEK, the UAS MAY keep the CEK with
the identifier specified in the "unprotectedAttrs" attribute.
When the UAS responds with a 200 OK, the same type of S/MIME CMS data
is RECOMMENDED to be used. For example, if the UAS receives an
INVITE request in which the SDP is encrypted by using the CMS
EnvelopedData, it is RECOMMENDED to respond with a 200 OK response in
which the SDP is encrypted by using the CMS EnvelopedData body. If
the UAS receives an INVITE request which is attached a digital
signature to the SDP by using the CMS SignedData, it is RECOMMENDED
to respond with a 200 OK response which is attached a signature to
the SDP by using the CMS SignedData. In the above example, however,
a 200 OK response to the MESSAGE request does not need to use the
same type of S/MIME CMS data since the response does not contain any
MIME body.
Even when the UAS receives a request that does not use S/MIME, the
UAS sometimes needs end-to-end and end-to-middle confidentiality for
the message body and/or headers in a response. In this case, the UAS
MUST use CMS EnvelopedData to encrypt it. When the UAS sends a
response and needs end-to-end and end-to-middle integrity for the
message body and/or headers, it SHOULD use CMS SignedData to attach a
digital signature. This is not different from how a UAC operates as
described in Section 5.1.
5.3 Proxy Behavior
When a proxy server supporting this mechanism receives a message, it
MUST inspect the "Proxy-Required-Body" header. If the header
includes the processing server's own hostname, the proxy server MUST
inspect the body specified by the Content-ID. When the specified
body is CMS EnvelopedData, the proxy server MUST inspect it and try
Ono & Tachimoto Expires January 10, 2006 [Page 8]
Internet-Draft End-to-middle security in SIP July 2005
to decrypt the "recipientInfos" field. If the header does not
include the server's own name, nor the header exists, the proxy
server MAY view the message body.
If there is a piece of encrypted data for the proxy, the proxy server
will succeed in decryption using the "recipientInfos" field. If the
proxy server fails to decrypt the message body that is required to
view, it MUST respond with a 493 (Undecipherable) response if it is a
request, otherwise any existing dialog MUST be terminated.
If the proxy server succeeds in this decryption, it MAY inspect the
"unprotectedAttrs" field of the CMS EnvelopedData body. If the
attribute gives the key's identifier, the proxy server MAY keep the
CEK with its identifier until the lifetime of the CEK expires. If it
receives subsequent messages within the lifetime, it MAY try to
decrypt the type "KEKRecipientInfo" of the "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 fails, the proxy server SHOULD reject the subsequent
procedure and respond with a 495 (Signature Required) response if the
message is a request, otherwise any existing dialog MAY be
terminated.
When the proxy server forwards the request, it modifies the routing
headers as it normally does, but does not modify the message body.
The proxy server MAY delete the "Proxy-Required-Body" header that
contains its own hostname.
When a provider operating the proxy server does not allow any
information related to its security policies to be revealed to the
proxy server serving the recipient UA, the proxy server deletes the
"Proxy-Required-Body" header. However, when a request message is
transmitted to the proxy server via a proxy server operated by
another provider, there is no way to conceal the header from the
other proxy servers.
If a proxy does not support this mechanism and receives a message
with the "Proxy-Required-Body" header, the proxy MUST ignore the
header and operate as usual.
6. Proxy-Required-Body Header Field Use
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [6]. The new header "Proxy-
Required-Body" is defined as a SIP header.
Ono & Tachimoto Expires January 10, 2006 [Page 9]
Internet-Draft End-to-middle security in SIP July 2005
Proxy-Required-Body = "Proxy-Required-Body" HCOLON required-proxy
SEMI target-body
required-proxy = host
target-body = cid-param *(COMMA cid-param)
cid-param = "cid" EQUAL content-id
content-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT
dot-atom = atom *( "." atom )
atom = 1*( alphanum / "-" / "!" / "%" / "*" /
"_" / "+" / "'" / "`" / "~" )
Information about the use of headers in relation to SIP methods and
proxy processing is summarized in Table 1.
Header field where proxy ACK BYE CAN INV OPT REG
--------------------------------------------------------------
Proxy-Required-Body R dr - o - o o o
Proxy-Required-Body 100-699 dr - o - o o o
Header field where proxy SUB NOT PRK IFO UPD MSG
--------------------------------------------------------------
Proxy-Required-Body R dr o o - o o o
Proxy-Required-Body 100-699 dr o o - o o o
Table 1: Summary of header field use
The "where" column gives the request and response types in which
the header field can be used. The values in the "where" column
are as follows:
* R: The header field may appear in requests
* 100-699: A numeral range indicates response codes with which
the header field can be used.
The "proxy" column gives the operations a proxy may perform on the
header field:
* d: A proxy can delete a header field value.
* r: A proxy must be able to read the header field, so it cannot
be encrypted.
The next columns relate to the presence of a header field in a
method:
* o: The header field is optional.
* -: The header field is not applicable.
7. Message Examples
The following examples illustrate the use of the mechanism defined in
the previous sections.
7.1 Message Examples of End-to-Middle Confidentiality
In the following example, a UAC needs message content in a MESSAGE
Ono & Tachimoto Expires January 10, 2006 [Page 10]
Internet-Draft End-to-middle security in SIP July 2005
request to be confidential and it allows a proxy server to view the
message body. It also needs to reuse the CEK in the subsequent
request messages. Even though the Content-Length has no digit, the
appropriate length is to be set. In the example message 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
Proxy-Required-Body: ss1.atlanta.example.com;
cid=1234@atlanta.example.com
Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: binary
Content-ID: 1234@atlanta.example.com
Content-Disposition: attachment;filename=smime.p7m;handling=required
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 *
******************************************************************
If the proxy server successfully views the message body, the UAC
receives a 200 OK from the UAS normally. However, if a proxy server
fails to view the message body, the UAC receives a 493
Ono & Tachimoto Expires January 10, 2006 [Page 11]
Internet-Draft End-to-middle security in SIP July 2005
(Undecipherable) error response from the proxy server, as follows:
493 Undecipherable alice@atlanta.example.com <--
ss1.atlanta.example.com
SIP/2.0 493 Undeciperable
Warning: 380 ss1.atlanta.example.com "Required to view 'text/plain'"
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 MESSAGE
Content-Type: application/pkix-cert
Content-Length: ...
<certificate>
In the following example, a UA needs the SDP in an INVITE request to
be confidential and it allows a proxy server to view the SDP. It
also needs to reuse the CEK of the encrypted data in the subsequent
request messages.
Ono & Tachimoto Expires January 10, 2006 [Page 12]
Internet-Draft End-to-middle security in SIP July 2005
INVITE alice@atlanta.example.com --> ss1.atlanta.example.com
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Date: Fri, 20 June 2003 13:02:03 GMT
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Proxy-Required-Body: ss1.atlanta.example.com;
cid=1234@atlanta.example.com
Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: binary
Content-ID: 1234@atlanta.example.com
Content-Disposition: attachment;filename=smime.p7m;handling=required
Content-Length: ...
******************************************************************
* (encryptedContentInfo) *
* Content-Type: application/sdp *
* Content-Length: 151 *
* *
* v=0 *
* o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com*
* s=- *
* c=IN IP4 192.0.2.101 *
* t=0 0 *
* m=audio 49172 RTP/AVP 0 *
* a=rtpmap:0 PCMU/8000 *
* *
* (recipientInfos) *
* RecipientInfo[0] for ss1.atlanta.example.com public key *
* RecipientInfo[1] for Bob's public key *
* *
* (unprotectedAttrs) *
* CEKReference *
******************************************************************
When the proxy server successfully views the SDP, and the UAS
responds with a 200 OK. The 200 OK is to be encrypted as follows:
Ono & Tachimoto Expires January 10, 2006 [Page 13]
Internet-Draft End-to-middle security in SIP July 2005
200 OK alice@atlanta.example.com <-- ss1.atlanta.example.com
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: binary
Content-ID: 1234@atlanta.example.com
******************************************************************
* (encryptedContentInfo) *
* Content-Type: application/sdp *
* Content-Length: 147 *
* *
* v=0 *
* o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com*
* s=- *
* c=IN IP4 192.0.2.201 *
* t=0 0 *
* m=audio 3456 RTP/AVP 0 *
* a=rtpmap:0 PCMU/8000 *
* *
* (recipientInfos) *
* RecipientInfo[0] for Alice's public key *
******************************************************************
7.2 Message Examples of End-to-Middle Integrity
In the following example, a UA needs the integrity of message content
in a MESSAGE request to be validated by a proxy server before it
views message content. Even though the Content-Length has no digit,
the appropriate length is to be set.
Ono & Tachimoto Expires January 10, 2006 [Page 14]
Internet-Draft End-to-middle security in SIP July 2005
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
Proxy-Required-Body: ss1.atlanta.example.com;
cid=1234@atlanta.example.com
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-ID:1234@atlanta.example.com
Content-Disposition: attachment;
filename=smime.p7s;handling=required
[binary data]
--boundary1--
If the proxy server successfully validates the integrity of the
message body, the UAC normally receives a 200 OK from the UAS.
However, if a proxy server does not receive a signature for the whole
message body, the UAC receives a 495 (Signature Required) error
response from the proxy server, as follows:
Ono & Tachimoto Expires January 10, 2006 [Page 15]
Internet-Draft End-to-middle security in SIP July 2005
495 Signature Required alice@atlanta.example.com <--
ss1.atlanta.example.com
SIP/2.0 495 Signature Required
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 MESSAGE
Content-Length: 0
8. Security Considerations
8.1 Impersonating a Proxy Server
In the discovery mechanism in Section 4, a UA receives a 493
(Undecipherable) error response with the public key certificate of
the proxy server requesting the disclosure of the message body. The
public key certificate in the error response is vulnerable to be
forged by a malicious user.
To make sure that the response is sent by a proper proxy server, a UA
needs to authenticate the response. Since the UA is not always
adjacent to the proxy server, the UA cannot directly authenticate the
proxy server by security mechanisms of the transport layer or the
below. A UA SHOULD verify the chains to a trusted certificate
authority of the public key certificate.
8.2 Tampering with a Message Body
This document describes a mechanism to encrypt data for multiple
recipients, such as multiple proxy servers, or a recipient UA and
proxy servers. A piece of encrypted data is decipherable and
vulnerable to tampering by proxy servers at the previous hops.
In order to prevent such tampering, the UA SHOULD protect the data
integrity before encryption, when the encrypted data is meant to be
shared with multiple proxy servers, or to be shared with the UAS and
selected proxy servers. The UA SHOULD generate S/MIME CMS SignedData
and then SHOULD generate the EnvelopedData to encrypt attached data
with a digital signature. The recipient entity SHOULD verify the
signature to see if the encrypted data has been modified after
decryption by an entity listed in the "recipientInfos" field.
Ono & Tachimoto Expires January 10, 2006 [Page 16]
Internet-Draft End-to-middle security in SIP July 2005
8.3 Tampering with the Label of the Target Content
This document also describes a new SIP header for labeling a message
body for a proxy server. If a malicious user or proxy server
modified/added/deleted the label, the specified message body is not
inspected by the specified proxy server, and some services requiring
its content can not be provided. Or a proxy server will conduct an
unnecessary processing on message bodies such as unpacking MIME
structure, and/or signature verification. This is a possible cause
for a Denial-of-Services attack to a proxy server.
To prevent such attacks, data integrity for the label is needed. UAs
and proxy servers SHOULD use TLS mechanism to communicate with each
other. Since a proxy server trusted to provide SIP routing is
basically trusted to process SIP headers other than those related to
routing, hop-by-hop security is reasonable to protect the label. In
order to further protect the integrity of the label, UAs MAY generate
a "message/sipfrag" body and attach a digital signature for the whole
body.
9. IANA Considerations
This document defines a new SIP header, "Proxy-Required-Body", of
which the syntax is shown in Section 6. This document also defines a
new SIP response-code, 495 "Signature Required", and a new Warn-code,
380 "Required to view Content-Type", as described in Section 4.
10. Acknowledgments
Thanks to Rohan Mahy and Cullen Jennings for their initial support of
this concept and to many people for useful comments, especially Jon
Peterson, Jonathan Rosenberg, Eric Burger, and Russ Housely.
11. References
11.1 Normative 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-06 (work in progress),
March 2005.
Ono & Tachimoto Expires January 10, 2006 [Page 17]
Internet-Draft End-to-middle security in SIP July 2005
[4] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[5] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
11.2 Informative References
[7] 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.
[8] Andreasen, F., Baugher, M., and D. Wing, "Session Description
Protocol Security Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-11 (work in progress),
June 2005.
[9] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-05 (work in progress), May 2005.
[10] Hilt, V., Camarillo, G., and J. Rosenberg, "Session Initiation
Protocol (SIP) Session Policies - Document Format and Session-
Independent Delivery Mechanism",
draft-ietf-sipping-session-indep-policy-02 (work in progress),
February 2005.
[11] Campbell, Ed., B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[12] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption
Keys", RFC 3185, October 2001.
[13] Ono, K. and S. Tachimoto, "Key reuse in S/MIME for SIP",
draft-ono-sipping-keyreuse-smime-00 (work in progress),
February 2004.
[14] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002.
Ono & Tachimoto Expires January 10, 2006 [Page 18]
Internet-Draft End-to-middle security in SIP July 2005
Authors' Addresses
Kumiko Ono
Network Service Systems Laboratories, NTT Corporation
Musashino-shi, Tokyo 180-8585
Japan
Email: ono.kumiko@lab.ntt.co.jp
Shinya Tachimoto
Network Service Systems Laboratories, NTT Corporation
Musashino-shi, Tokyo 180-8585
Japan
Email: tachimoto.shinya@lab.ntt.co.jp
Ono & Tachimoto Expires January 10, 2006 [Page 19]
Internet-Draft End-to-middle security in SIP July 2005
Intellectual Property Statement
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-ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ono & Tachimoto Expires January 10, 2006 [Page 20]
