SIP K. Ono
Internet-Draft Columbia University
Expires: January 8, 2008 S. Tachimoto
NTT Corporation
July 7, 2007
End-to-middle Security in the Session Initiation Protocol (SIP)
draft-ietf-sip-e2m-sec-06
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 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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
Ono & Tachimoto Expires January 8, 2008 [Page 1]
Internet-Draft End-to-middle security in SIP July 2007
discover intermediaries which need to inspect an S/MIME-secured
message body, or to receive the message body with data integrity
This specification is approved at the proposed standards level due to
the IANA registration requirements. Is is of sufficient quality for
that level, however, the use of this mechanism in this specification
are considered experimental.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 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 . . . . . . 5
2.3. S/MIME-secured Message Body for Confidentiality and
Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6
3. Indicating the Target Proxy and Content . . . . . . . . . . . 6
4. Discovering the Security Policies of Proxy Servers . . . . . . 7
4.1. Discovery with Error Responses . . . . . . . . . . . . . . 8
5. Behavior of UAs and Proxy Servers . . . . . . . . . . . . . . 10
5.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 13
6. Proxy-Inspect-Body Header . . . . . . . . . . . . . . . . . . 15
7. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Message Examples of End-to-Middle Confidentiality . . . . 17
7.2. Message Examples of End-to-Middle Integrity . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Impersonating a Proxy Server . . . . . . . . . . . . . . . 24
8.2. Tampering with a Message Body . . . . . . . . . . . . . . 25
8.3. Tampering with the Label of the Target Content . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. 'Proxy-Inspect-Body' Header . . . . . . . . . . . . . . . 25
9.2. '495 Signature Required' Response Code . . . . . . . . . . 26
9.3. '496 Proxy Undecipherable' Response Code . . . . . . . . . 26
9.4. '380 Required to View Content-Type' Warn-code . . . . . . 26
10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Ono & Tachimoto Expires January 8, 2008 [Page 2]
Internet-Draft End-to-middle security in SIP July 2007
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 [1]. 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 [9]. Therefore, this document focuses on
mechanisms for providing data confidentiality and integrity for end-
to-middle security to meet the requirements discussed in [2].
The proposed mechanisms are based on S/MIME [3], since the major
requirement is to have little impact on standardized end-to-end
security mechanisms defined in [1], the way of handling S/MIME-secure
messages. The mechanisms consist of generating an S/MIME-secured
message body and indicating the target message body is for a specific
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.
1.1. 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 [4].
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 which contains encrypted data. Prior to generating it,
a UA needs to identify contents to be encrypted, 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
Ono & Tachimoto Expires January 8, 2008 [Page 3]
Internet-Draft End-to-middle security in SIP July 2007
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.
If the encrypted data is destined for one or more than one proxy
server(s), the recipient list MUST contain only the proxy server(s).
If the same encrypted data is shared with the user agent server (UAS)
and proxy servers, the recipient list (the "recipientInfos" field)
MUST be addressed to the UAS and the proxy servers (e.g., Proxy #1
and Proxy #2), as shown in Figure 1.
+-----------------------------------------------------------+
| The "recipientInfos" field |
|+---------------------------------------------------------+|
|| CEK encrypted with UAS's KEK ||
|+---------------------------------------------------------+|
|| CEK encrypted with Proxy #1's KEK ||
|+---------------------------------------------------------+|
|| CEK encrypted with Proxy #2's KEK ||
|+---------------------------------------------------------+|
| The "encryptedContentInfo" field |
|+---------------------------------------------------------+|
|| Content encrypted with CEK to be shared with recipients ||
|+---------------------------------------------------------+|
+-----------------------------------------------------------+
Figure 1: An Example Structure of EnvelopedData for Sharing
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, as shown in Figure 2. In order to concatenate
more than one CMS EnvelopedData, the user agent client (UAC) MUST
generate a "multipart/mixed" MIME body.
Ono & Tachimoto Expires January 8, 2008 [Page 4]
Internet-Draft End-to-middle security in SIP July 2007
+-----------------------------------------------------------+
| The "recipientInfos" field |
|+---------------------------------------------------------+|
|| CEK #1 encrypted with proxy's KEK ||
|+---------------------------------------------------------+|
| The "encryptedContentInfo" field |
|+---------------------------------------------------------+|
|| Content encrypted with CEK #1 for proxy ||
|+---------------------------------------------------------+|
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| The "recipientInfos" field |
|+---------------------------------------------------------+|
|| CEK #2 encrypted with UAS's KEK ||
|+---------------------------------------------------------+|
| The "encryptedContentInfo" field |
|+---------------------------------------------------------+|
|| Content encrypted with CEK #2 for UAS ||
|+---------------------------------------------------------+|
+-----------------------------------------------------------+
Figure 2: An Example Structure of EnvelopedData not for Sharing
2.2. S/MIME-secured Message Body for Data Integrity
For end-to-middle data integrity, a UA SHOULD generate S/MIME CMS
SignedData to attach a digital signature for the target data. If
this is not done, then as an alternative, a UA MAY generate the
signature in the SIP Identity [10] mechanism. Generating the
signature requires the generator, i.e., the UA, has its own public
and private key pair that the UA is not required to have. 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.
Note: There are other mechanisms which could provide data
integrity, such as S/MIME CMS AuthenticatedData, or CMS
DigestedData as defined in [5]. However, S/MIME CMS
AuthenticatedData requires that a UA obtains the credential of the
recipient proxy server in advance. Thus, it requires a mechanism
to securely transmit the credential from the proxy server to the
UA. On the other hand, S/MIME CMS DigestedData does not require
such mechanism. However, anybody can generate the digest data for
a message. Then, it does not offer the data integrity from the
originator. Additionally, neither of them is used in [1].
Therefore, a UA MUST NOT use either of S/MIME CMS
AuthenticatedData or CMS DigestedData for interoperability.
Ono & Tachimoto Expires January 8, 2008 [Page 5]
Internet-Draft End-to-middle security in SIP July 2007
2.3. S/MIME-secured Message Body for Confidentiality and Data Integrity
Both for end-to-middle confidentiality and the data integrity, a UA
SHOULD first generate the signature as CMS SignedData, and encrypt
the message containing the signature inside. Alternatively, a UA MAY
generate the signature in the SIP identity which is set outside. As
the third alternative, a UA MAY first encrypt the message, and attach
the signature as CMS SignedData as defined in [1].
There are two ways to encrypt and sign data: encrypt data after
signing, and encrypt data before signing. It is more secure to
encrypt data after signing than attaching a signature after
encryption, generally because the signature outside is easily
detachable. If the proxy server does not accept any message
without the SIP identity, encrypting data before signing is secure
enough.
3. Indicating the Target Proxy and Content
A UA need a way to indicate the content which is expected 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 MUST set a label to indicate the proxy
server and its target content using a new SIP header, "Proxy-Inspect-
Body" for encrypted data. The UA MAY omit to set the "Proxy-Inspect-
Body" header for signed data. This header consists of a proxy
server's hostname and one or more "cid" parameter(s) pointing to the
"Content-ID" MIME header [11] placed in the target body.
This indication is useful for encrypted data, but less for signed
data. The hostname field for encrypted data is useful for a proxy
server to determine if the proxy server is destined to view the body.
The "cid" parameter(s) for encrypted data is useful for a proxy
server to specify the target part of a "multi-part/mixed" body to
decrypt. On the contrary, the "cid" parameter for signed data always
indicates the whole message body, since the signed data is always
protecting the whole body. Additionally, since any entities can
verify the signed data, the hostname indication for singed data is
also less useful than the indication for encrypted data.
If a UA needs to request multiple proxy servers to view the same
message body, it MUST set multiple "Proxy-Inspect-Body" headers that
contain the same "cid" parameter. If a UA needs to request a proxy
server to view multiple body parts that are nested, it MUST set the
"cid" parameter of the outer body first and that of the inner body
next in the "Proxy-Inspect-Body" header.
Ono & Tachimoto Expires January 8, 2008 [Page 6]
Internet-Draft End-to-middle security in SIP July 2007
Note: The "cid" parameter indicates which part of the body is
expected to be viewed by a proxy server, not what kind of content.
If the message body is encrypted, the proxy server needs to
decrypt it to see if the message body contains a necessary
Content-Type, such as application/sdp.
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.
When a proxy server receives a message with the "Proxy-Inspect-Body"
containing its hostname, the proxy server MUST try decrypting the
content if the content is CMS EnvelopedData, or MUST validate the
signature if the content is CMS SignedData. If it fails to decrypt
or to validate, it MUST respond with an error code as described in
Section 5.3.
When a proxy server receives a message missing the "Proxy-Inspect-
Body" header containing its hostname, the proxy server misses viewing
the message body. If the proxy server needs to avoid such failure
for their own services, the proxy server MAY attempt to view the
message body, regardless of the hostname field. No error code is
defined to inform the UA that the indication was missing.
A UA has no way to get any specific acknowledgment of this
indication. If a UA indicates a proxy server that is not along the
signaling path, or that does not support this mechanism, the UA does
not have any error response. The UA can only acknowledge the proxy
server's behavior or compliance through the service which requires
proxy server's inspection of the message body fails.
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
data and/or verification in order to provide some services which
needs UA's compliance.
Ono & Tachimoto Expires January 8, 2008 [Page 7]
Internet-Draft End-to-middle security in SIP July 2007
A proxy security policy includes specification of the MIME types of
message bodies that the proxy inspects as part of providing service.
For each of these MIME types, if the proxy is unable to examine the
corresponding message body, the proxy's security policy MAY require
the proxy to reject the message with an error. Any message body for
which an error results when the proxy cannot view the message body is
called a proxy required message body (PRMB). The goal of security
policy discovery is for the UA to learn the set of proxy required
message bodies (PRMBs) for each proxy involved in the call, so that
it can make those PRMBs visible to the proxies that require them.
Configuration of proxy security policy, including selection of the
MIME types that correspond to PRMBs is the responsibility of the
proxy administrator.
There are two ways in which a UA can learn the policies of the proxy
servers. One is by receiving an error response from the proxy
servers. The error response shows the violation of the policies,
then a UAC can learn them. 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 [12]. 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. This
document covers only the former.
4.1. Discovery with Error Responses
When the proxy server receives a request that does not satisfy the
proxy's security policy, the proxy server MUST reject the request
with an error response. The security policy may be violated because
a PRMB cannot be viewed, or because a PRMB is not present in the
message.
If the request contains encrypted data that the proxy cannot decrypt,
the proxy MUST assume that any missing PRMB is within the encrypted
data and MUST reject the message with a new error response, 496
(Proxy Undecipherable). The proxy's public key certificate and the
Content-Type of the PRMB SHOULD be included in the error response.
If more than one PRMB is missing, the proxy MAY use the Content-Type
of any missing PRMB in the error response. The proxy's public key
certificate SHOULD be set as an "application/pkix-cert" [6] MIME body
in the error response.
If the proxy is able to decrypt all of the encrypted data in the
request, but a PRMB is missing, the proxy MUST behave as if a a
completely unencrypted request had been sent without the PRMB. If
the message is a request, it MAY be rejected with a 403
(Forbidden) response. If it is a response, any existing dialog
Ono & Tachimoto Expires January 8, 2008 [Page 8]
Internet-Draft End-to-middle security in SIP July 2007
MAY be terminated.
The Content-Type that the proxy server needs to view MUST be set in
the Warning header with a new warn-code, 380, except when the proxy
server needs to view the whole body. If no Warning header specifying
Content-Type is set, it indicates that the proxy server needs to view
the whole body, not specific content. For example, when the proxy
server needs to view a SDP, the following Warning header:
Warning: 380 example.com "Required to View Content-Type
'application/sdp'"
If the proxy server requires to view SDP and several sensitive
headers that are hidden in tunneling encryption data as described in
Section 23.4.3 of [1], the proxy server MAY respond with the Warning
header containing 'message/sip'. Instead of specifying Content-Type,
the proxy server MAY respond with no Warning header in order to
require to view the whole body including sensitive headers.
When a UAC receives a 496 (Proxy Undecipherable) response, the UAC
MUST check the respondent's name in the public key certificate and
the target Content-Type that the proxy server wants to view in the
Warning header, if they exist.
In a previous version of this document, 493 (Undecipherable) error
response had been proposed to be shared by the UAS and a proxy
server. However, the reactions requesting the UAC are different,
as pointed out in the SIP mailing list. On receiving the error
response from the UAS, the UAC should totally renew
"recipientInfos" by encrypted CEK with the KEK obtained from the
error response. On the other hand, on receiving the error
response from the proxy server, the UAC first should analyze the
feature of the message body and the proxy-requiring Content-Type
obtained from the Warning header. If the UAC decides to share the
message body with the UAS and the proxy server, the UAC will reuse
the "recipientInfos" of the previous request and add encrypted CEK
with the proxy's KEK obtained from the error response to it. If
the UAC decides to send two parts of the message body separately,
the UAC will add the EnvelopedData that contains a message body
for the proxy into the EnvelopedData in the previous request and
construct a "multipart/mixed" MIME body.
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.
When the attached signature just to the whole body is required, this
error response MUST contain no Warning header to specify Content-Type
that is required signature. When the attached signature to tunneling
Ono & Tachimoto Expires January 8, 2008 [Page 9]
Internet-Draft End-to-middle security in SIP July 2007
SIP message is required as described in Section 23.4 of [1], this
error response MAY contain the Warning header with 380 warn-code,
specifying 'message/sip', or 'message/sipfrag' Content-Type. The
proxy server MAY attach the signature to a "message/sipfrag" [13]
body, in order to set the name of the proxy server in the error
response.
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.
When a UA receives the 495 error response and the confidentiality is
needed, the UA MUST recognize the error requiring the signature for
the data prior to the encryption.
This discovery mechanism requires two more message 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.
5. Behavior of UAs and Proxy Servers
We describe here the behavior of UAs and proxy servers that implement
end-to-middle security.
5.1. UAC Behavior
When a UAC sends a SIP request, such as an INVITE request including
encrypted message body for end-to-middle confidentiality, it MUST
generate S/MIME CMS EnvelopedData, and SHOULD specify the hostname of
destined proxy server and Content-ID of the S/MIME CMS EnvelopedData
which is to be decrypted by the proxy server in the "Proxy-Inspect-
Body" header.
If the UAC decides to share the message body with the UAS and the
proxy server that requires the inspection of the message body, the
UAC MUST list encrypted CEK with the proxy server's KEK and encrypted
CEK with the UAS's KEK at the "recipientInfos" of the CMS
EnvelopedData. If the UAC decides to set the message body
Ono & Tachimoto Expires January 8, 2008 [Page 10]
Internet-Draft End-to-middle security in SIP July 2007
separately, the UAC MUST structure a "multipart/mixed" body that
contains two CMS EnvelopedData: one encrypted for the UAS and another
encrypted for the proxy server. The UAC MUST set the value
"optional" in the handling parameter of the "Content-Disposition"
MIME header for the EnvelopedData destined for Proxy #1, in order to
avoid unnecessary error conditions in the UAS. The "multipart/mixed"
MIME body MUST have either the value "required" in the handling
parameter or no handling parameter, since the default value is
"required" as specified in [1].
If the UAC sends a SIP request including encrypted body just for end-
to-end, being unaware of the service provided by the proxy server
that requires the inspection of the message body, the UAC will get a
496 (Proxy Undecipherable) error response with the public key of the
proxy server. The error response MAY contain the Warning header
requiring the disclosure of a specific content, or no Warning header.
By obtaining the error response that the Warning header specifies
content, the UAC learns that the proxy server requires the disclosure
of a specific message body. If the error response contains no
Warning header, the UAC learns the proxy server require the
disclosure of the whole message body. If the UAC decides to meet the
requirement of the proxy server, the UAC MUST generates CMS
EnvelopedData and MUST set the "Proxy-Inspect-Body" header as
described above. If the UAC decides to share the message body with
the UAS and the proxy server, the UAC MUST update the
"recipientInfos" of the previous request by adding encrypted CEK with
the proxy server's KEK obtained from the error response. If the UAC
decides to set the message body separately for the proxy server, the
UAC MUST structure a "multipart/mixed" body by adding the CMS
EnvelopedData for the proxy server.
When the UAC sends a SIP request of which message body needs end-to-
middle integrity, it SHOULD generate S/MIME CMS SignedData to attach
a digital signature. The UAC MAY specify the hostname of the proxy
server and Content-ID of the CMS SignedData to be validated in the
"Proxy-Inspect-Body" SIP header.
If the UAC sends a SIP request without the signature, being unaware
of the proxy server's service that requires the verification of the
message body, the UAC will get a 495 (Signature Required) error
response with no Warning header requiring Content-Type.
By obtaining the 495 error response, the UAC learns that an entity in
the signaling path, such as the proxy server, requires the signature
of the whole message body. If the UAC decides to meet the
requirement and has its own public key, the UAC MUST generate the CMS
SignedData to attach a signature by computing with its own private
Ono & Tachimoto Expires January 8, 2008 [Page 11]
Internet-Draft End-to-middle security in SIP July 2007
key.
When the UAC sends a request and needs both end-to-middle
confidentiality and integrity for the message body, it SHOULD first
generate S/MIME CMS SignedData to attach the digital signature for
the content, and then generate S/MIME EnvelopedData to encrypt the
CMS SignedData. The UAC MUST specify the hostname of the proxy
server and the Content-ID of the CMS EnvelopedData destined for the
proxy server in the "Proxy-Inspect-Body". The UAC also MAY specify
the Content-ID of the CMS SignedData following the Content-ID of the
CMS EnvelopedData in the header.
For example, if the UAC needs the confidentiality of the SDP, and it
knows that the destined proxy server needs to view the both SDPs in a
request and the response, the UAC MAY use the CEK reuse mechanism
[14][15]. The UAC indicates the identifier of the CEK to be reused
at the "unprotectedAttrs" field of the CMS EnvelopedData in an INVITE
request as showed in Figure 3.
+-------------------------------------------------------------+
| The "recipientInfos" field |
|+-----------------------------------------------------------+|
|| CEK encrypted with UAC's KEK ||
|+-----------------------------------------------------------+|
|| CEK encrypted with destined server's KEK ||
|+-----------------------------------------------------------+|
| The "encryptedContentInfo" field |
|+-----------------------------------------------------------+|
|| Content encrypted with CEK #1 to be shared with recipients||
|+-----------------------------------------------------------+|
| The "unprotectedAttrs" field |
|+-----------------------------------------------------------+|
|| Identifier of CEK #1 ||
|+-----------------------------------------------------------+|
+-------------------------------------------------------------+
Figure 3: EnvelopedData with CEK reuse in a request
5.2. UAS Behavior
When the UAS receives a request that contains a MIME body, the UAS
inspects the MIME body depending on the value of the handling
parameter in "Content-Disposition" header. If the MIME body
structures S/MIME, the UAS first decrypts and/or validates it as
usual. If the decryption and/or the validation is successful, the
UAS responds with a 200 OK. If the 200 OK response contains a MIME
body, the UAS is RECOMMENDED to construct the same S/MIME structure
with the request.
Ono & Tachimoto Expires January 8, 2008 [Page 12]
Internet-Draft End-to-middle security in SIP July 2007
When the CMS EnvelopedData body of the request, destined for the UAS,
contains the "unprotectedAttrs" attribute specifying the identifier
of the CEK, the UAS MAY learn that the UAC is requesting to reuse the
CEK for the disclosure of the message body in the subsequent requests
or responses. By checking the "Proxy-Inspect-Body" header in the
receiving request, the UAS MAY know the destined proxy server and the
Content-Type to be disclosed. If the UAS accepts the disclosure, it
MAY keep the CEK with the identifier specified in the
"unprotectedAttrs" attribute. If the UAS receives an INVITE message
specifying the CEK reuse, the UAS MAY reuse the CEK (CEK #1) to
encrypt a new CEK (CEK #2) for encrypting the message body in the
response as showed in Figure 4
+-------------------------------------------------------------+
| The "recipientInfos" field |
|+-----------------------------------------------------------+|
|| CEK #2 encrypted with CEK #1 ||
|+-----------------------------------------------------------+|
| The "encryptedContentInfo" field |
|+-----------------------------------------------------------+|
|| Content encrypted with CEK #2 to be shared with recipients||
|+-----------------------------------------------------------+|
+-------------------------------------------------------------+
Figure 4: EnvelopedData with CEK reuse in a response
Even when the UAS receives a request that does not use S/MIME, the
UAS sometimes needs end-to-middle confidentiality for the message
body in a response, for example, the SDP offer/answer in a 200
response and ACK request. The behavior for generating S/MIME CMS
data is the same as how the UAC operates as described in Section 5.1,
while the behavior for discovering the security policies of destined
proxy server can not be not supported.
5.3. Proxy Behavior
When the proxy server implementing and activating this mechanism
receives a message, it MUST inspect the "Proxy-Inspect-Body"
header(s). If the header includes the host name of the proxy server
, the proxy server MUST inspect the body indicated by the "cid"
parameter. If multiple "cid" parameters exist in the header, the
proxy server MUST inspect the bodies in order. Even if the header
does not include the hostname of the proxy server, nor the header
exists, the proxy server MAY view the message body following its own
security policies.
Ono & Tachimoto Expires January 8, 2008 [Page 13]
Internet-Draft End-to-middle security in SIP July 2007
The proxy server MAY activate this mechanism user by user. When
the proxy server receives a message from a user for whom the proxy
server does not activate this, the proxy server ignores the
"Proxy-Inspect-Body" header(s) and does not view the message body.
When the indicated body is CMS EnvelopedData, the proxy server MUST
try to decrypt the "recipientInfos" field. If there is a piece of
encrypted data for the proxy server, the proxy server will succeed in
obtaining the CEK to decrypt the encrypted content at the
"encryptedContentInfo" field.
If the proxy server fails to decrypt the message body that is
required to view, it MUST respond with a 496 (Proxy Undecipherable)
response, if it is a request, otherwise any existing dialog MUST be
terminated. If the proxy server requires the disclosure of a
specific content, the 496 response MUST include the Warning header,
containing "Required to view 'Content-Type'". If the proxy server
requires the disclosure of the whole message body, it MUST respond
without the Warning header containing Content-Type.
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 indicated content contains CMS SignedData body, the proxy
server MUST validate the digital signature. If the verification
fails, the proxy server SHOULD reject the subsequent procedure. It
MAY respond with a 403 (Forbidden) response if the message is a
request, otherwise any existing dialog MAY be terminated.
When the proxy server needs validate the data integrity of the
content but the indicated body does not contain CMS SignedData body,
the proxy server MUST respond with a 495 (Signature Required)
response if the message is a request, otherwise any existing dialog
MAY be terminated. A 495 response MAY contain no Warning header
requiring Content-Type to be attached a signature.
When the proxy server needs to validate the data integrity of the
content and view it, but the indicated content is the CMS
EnvelopedData, the proxy server does not see if the signature exists
inside. First, the proxy server tries to decrypt the CMS
EnvelopedData. If the decryption fails, the proxy server MUST
respond with 496 (Proxy Undecipherable) that contains its own public
key and no Warning header requiring a specific Content-Type. After
Ono & Tachimoto Expires January 8, 2008 [Page 14]
Internet-Draft End-to-middle security in SIP July 2007
getting decipherable data, the proxy server inspects the content and
validate the signature, if it exists. If the signature for the whole
body does not exist, the proxy server MUST respond with 495
(Signature Required) that contains no Warning header requiring a
specific Content-Type. If the encrypted data is attached with the
signature outside, the proxy server MAY first validate the signature,
instead of checking the existence of the signature inside.
When the proxy server forwards the request, it MAY delete the "Proxy-
Inspect-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
other proxy server, the proxy server MAY deletes the "Proxy-
Inspect-Body" header. However, there is no way to conceal the
header from the other proxy servers which exist between a UAC and
the proxy server.
6. Proxy-Inspect-Body Header
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [7]. The new header "Proxy-
Inspect-Body" is defined as a SIP header.
Proxy-Inspect-Body = "Proxy-Inspect-Body" HCOLON inspecting-proxy
SEMI target-body *(SEMI generic-param)
inspecting-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 REF
-----------------------------------------------------------------
Proxy-Inspect-Body R dr o o - o o o o
Proxy-Inspect-Body 100-699 dr - o - o o o o
Header field where proxy SUB NOT PRK IFO UPD MSG PUB
-----------------------------------------------------------------
Proxy-Inspect-Body R dr o o o o o o o
Proxy-Inspect-Body 100-699 dr o o - o o o o
Ono & Tachimoto Expires January 8, 2008 [Page 15]
Internet-Draft End-to-middle security in SIP July 2007
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
We describe here the message examples in a model in which a proxy
server that provides a firewall traversal service for voice and
video, and a logging service for instant messages exists in a
signaling path as shown in Figure 7. The instant messages assumes to
use MESSAGE [16] requests.
+-----+ +-----+ +-----+ +-----+
| C |-----| C |---------------| [C] |-----| C |
+-----+ +-----+ +-----+ +-----+
UA #1 Proxy #1 Proxy #2 UA #2
w/Firewall traversal
and logging functions
C : Content that UA #1 allows the entities to inspect
[C]: Content that UA #1 prevents the entity from inspecting
Figure 7: Configuration example
In the message examples, the text with the box of asterisks ("*") is
encrypted. Although the Content-Length has no digit, the appropriate
length is to be set. The hostname and username for each entity are:
UA #1: alice@atlanta.example.com
UA #2: bob@biloxi.example.com
Proxy #1: ss1.atlanta.example.com
Proxy #2: ss1.biloxi.example.com
Ono & Tachimoto Expires January 8, 2008 [Page 16]
Internet-Draft End-to-middle security in SIP July 2007
7.1. Message Examples of End-to-Middle Confidentiality
In the following example, UA #1 needs the SDP in an INVITE request to
be confidential and it allows a proxy server to view the SDP.
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-Inspect-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:
******************************************************************
* (recipientInfos) *
* RecipientInfo[0] for ss1.atlanta.example.com public key *
* RecipientInfo[1] for Bob's public key *
* *
* (encryptedContentInfo) *
* Content-Type: application/sdp *
* Content-Length: *
* *
* 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 *
* *
******************************************************************
When Proxy #1 and UA #2 successfully views the SDP, UA #2 responds
Ono & Tachimoto Expires January 8, 2008 [Page 17]
Internet-Draft End-to-middle security in SIP July 2007
with a 200 OK. The 200 OK is to be encrypted as follows:
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
Content-Length:
******************************************************************
* (recipientInfos) *
* RecipientInfo[0] for Alice's public key *
* *
* (encryptedContentInfo) *
* Content-Type: application/sdp *
* Content-Length: *
* *
* 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 *
******************************************************************
When keying materials, such as keys used for Secure RTP (SRTP), are
included in the SDP [17], UA #1 does not want to show the keying
materials to Proxy #1, although Proxy #1 needs to view the SDP for
the firewall traversal service. In this case, UA #1 sets two SDP
separately; one contains the keying materials for UA #2 and another
does not for Proxy #1 as follows:
INVITE alice@atlanta.example.com --> ss1.atlanta.example.com
INVITE sip:bob@biloxi.example.com SIP/2.0
Ono & Tachimoto Expires January 8, 2008 [Page 18]
Internet-Draft End-to-middle security in SIP July 2007
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-Inspect-Body: ss1.atlanta.example.com;
cid=1234@atlanta.example.com,cid=3333@atlanta.example.com
Content-Type: multipart/mixed; boundary=boundary1
Content-Transfer-Encoding: binary
Content-ID: 1234@atlanta.example.com
Content-Disposition: attachment;filename=smime.p7m;handling=required
Content-Length:
--boundary1
Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-ID: 3333@atlanta.example.com
Content-Disposition: attachment;filename=smime.p7m;handling=required
******************************************************************
* (recipientInfos) *
* RecipientInfo[0] for ss1.atlanta.example.com public key *
* *
* (encryptedContentInfo) *
* Content-Type: application/sdp *
* Content-Length: *
* *
* 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/SAVP 0 *
* *
******************************************************************
--boundary1
Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-ID: 4444@atlanta.example.com
Content-Disposition: attachment;filename=smime.p7m;handling=optional
******************************************************************
* (recipientInfos) *
* RecipientInfo[0] for Bob's public key *
* *
Ono & Tachimoto Expires January 8, 2008 [Page 19]
Internet-Draft End-to-middle security in SIP July 2007
* (encryptedContentInfo) *
* Content-Type: application/sdp *
* Content-Length: *
* *
* 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/SAVP 0 *
* a=crypto:1 AES_CM_128_HMAC_SHA1_32 *
* inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 *
* *
******************************************************************
--boundary1--
For firewall traversal service, Proxy #1 does not care about the
information only for UA #2. Even if UA #1 sets different port
information for UA #2 and Proxy #1 separately on purpose, the
firewall traversal service for UA #1 will just fail.
However, if Proxy #1 provides a call admission control using codec
information in SDP, Proxy #1 might care about the information for UA
#2. Proxy #1 wants to view the SDP destined not only for itself, but
also the SDP destined for UA #2 in order to confirm that both of the
codec information are the same. In other words, Proxy #1 needs to
police if UA #1 does not attempt to use a different codec that
requires more bandwidth. As a result, Proxy #1 will require
disclosure of all the message body by setting no Warning header
requiring Content-Type as follows:
496 Proxy Undecipherable alice@atlanta.example.com <--
ss1.atlanta.example.com
SIP/2.0 496 Proxy Undeciperable
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
Content-Type: application/pkix-cert
Content-Length:
<certificate>
Ono & Tachimoto Expires January 8, 2008 [Page 20]
Internet-Draft End-to-middle security in SIP July 2007
In the following example, UA #1 needs message content in a MESSAGE
request to be confidential and it allows Proxy #1 to view the message
body.
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-Inspect-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: ...
******************************************************************
* (recipientInfos) *
* RecipientInfo[0] for ss1.atlanta.example.com public key *
* RecipientInfo[1] for Bob's public key *
* *
* (encryptedContentInfo) *
* Content-Type: text/plain *
* Content-Length: ... *
* *
* Hello. *
* This is confidential. *
* *
******************************************************************
If Proxy #1 and UA #2 successfully view the message body, UA #1
receives a 200 OK from UA #2 normally. However, if Proxy #1 fails to
view the message body, UA #1 receives a 496 (Proxy Undecipherable)
error response from Proxy #1, as follows:
Ono & Tachimoto Expires January 8, 2008 [Page 21]
Internet-Draft End-to-middle security in SIP July 2007
496 Proxy Undecipherable alice@atlanta.example.com <--
ss1.atlanta.example.com
SIP/2.0 496 Proxy 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>
7.2. Message Examples of End-to-Middle Integrity
In the following example, UA #1 needs the integrity of message
content in a MESSAGE request to be validated by Proxy #1 before it
views message content.
Ono & Tachimoto Expires January 8, 2008 [Page 22]
Internet-Draft End-to-middle security in SIP July 2007
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-ID:1234@atlanta.example.com
Content-Disposition: attachment;
filename=smime.p7s;handling=required
[binary data]
--boundary1--
If Proxy #1 successfully validates the integrity of the message body
and UA #2 receive it, UA #1 normally receives a 200 OK from UA #2. if
Proxy #1 does not receive a signature for the whole message body, UA
#1 receives a 495 (Signature Required) error response from UA #1, as
follows:
Ono & Tachimoto Expires January 8, 2008 [Page 23]
Internet-Draft End-to-middle security in SIP July 2007
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
The discovery mechanism in Section 4 relies on error responses, such
as 495 (Signature Required) and 496 (Proxy Undecipherable). As for
the 495 response, the responder is not critical from the security
perspective, since it does not require any kind of downgrading
security, but upgrading security by attaching the signature that can
be validated by any entities. On the other hand, the 496 response is
critical and vulnerable to be forged by a malicious user, since it is
attached with the public key certificate that requires the disclosure
of the whole or the partial message body to the UA.
To make sure that the 496 response contains the public key
certificate of a proper proxy server, UA MUST see if the common name
of the public key certificate is equal to the name of a proper proxy
server. UA MUST recognize the name of legitimate proxies by the
domain part of the SIP URIs of the UA and recipient, the name of
configured outbound proxy and pre-configuration. That is, UA MUST be
pre-configured with the domain name of a third party, if there are a
third party proxy which offers some service viewing the message body.
Additionally, a UA MUST verify whether the public key certificate is
valid and not revoked as specified in [8]. If it is invalid and
revoked, the UA MUST NOT retry to send the message with data
encrypted by the public key.
If a malicious user sends the public key certificate of the proper
proxy server, it would not be a problem as long as the malicious user
does not know the corresponding private key, since the malicious user
will fail to decrypt the data the user sent.
Ono & Tachimoto Expires January 8, 2008 [Page 24]
Internet-Draft End-to-middle security in SIP July 2007
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 MUST verify the
signature to see if the encrypted data has been modified after
decryption by an entity listed in the "recipientInfos" field.
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 in the
middle modified/added/deleted the label, the specified message body
will be 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 requests requests to register a SIP header, two SIP
response codes, and a SIP warn-code in the SIP parameters IANA
registry.
9.1. 'Proxy-Inspect-Body' Header
This section includes the registration information for the 'Proxy-
Inspect-Body' header which is described in Section 6 of this
document.
Ono & Tachimoto Expires January 8, 2008 [Page 25]
Internet-Draft End-to-middle security in SIP July 2007
Header Name: Proxy-Inspect-Body
Compact Form: (none)
9.2. '495 Signature Required' Response Code
This section includes the registration information for the '495
Signature Required' response code which is described in Section 4 of
this document.
Response Code Number: 495
Default Response Phrase: Signature Required
9.3. '496 Proxy Undecipherable' Response Code
This section includes the registration information for the '496 Proxy
Undecipherable' response code which is described in Section 4 of this
document.
Response Code Number: 496
Default Response Phrase: Proxy Undecipherable Code
9.4. '380 Required to View Content-Type' Warn-code
This section includes the registration information for the '380
Required to view Content-Type' warn-code which is described in
Section 4 of this document.
Warning Code Number: 380
Default Warning Phrase: Required to View Content-Type
10. Changes
Changed from -05.
o Fixed the misuse of "acknowledge", to "learn" in Section 5.1 and
5.2.
o Clarified how to recognize legitimate proxy name in Section 8.1.
o Fixed the problem condition in Section 8.1.
Changed from -04.
o Changed the header name "Proxy-Required-Body" to "Proxy-Inspect-
Body".
o Changed the constraint for labeling encrypted data from "SHOULD"
to "MUST".
o Changed the constraint for verifying certificate at the recipient
from "SHOULD" to "MUST" in Section 8.2.
o Removed the necessity of authentication in Section 8.3.
o Added text for clarification.
Changed from -03.
Ono & Tachimoto Expires January 8, 2008 [Page 26]
Internet-Draft End-to-middle security in SIP July 2007
Added text mentioning CMS Digest-Data.
Added text related the order of sign and encryption in Section
2.3.
Added an example of Warning header in Section 4.1.
Added how to support SIP tunneling sign and encryption in Section
4.1.
Removed examples from the Section 5 "Behavior of UA and Proxy
Servers". Then, merged them to Section 7 "Message Examples".
Added message examples with multipart/mixed structure.
Referred to RFC3280 to validate certificated in Section 8.1.
Added the necessity of authentication in Section 8.3
Changes from -02.
o Added text in the abstract.
o Fixed the order of CMS data fields in the examples.
o Modified the default response phrase for the 496 response code for
the consistency with that of the 493 response code.
o Added generic-params to the "Proxy-Required-Body" header for
supporting extension parameters.
o Added REFER and PUBLISH methods in the table.
o Clarified a new parameter and responses in the section of IANA
consideration.
Changes from -01.
o Changed an author's contact address.
Changes from -00.
o Added several figures that show the abstract of the structure of
EnvelopedData.
o Changed a error response that Proxy sends back in decryption
failure from 493 (Undecipherable) to 496 (Proxy Indecipherable), a
new one.
o Changed the constraint of indicating CMS SignedData for a UA, from
SHOULD to MAY/NOT RECOMMENDED.
o Added the way that Proxy requires the disclosure for the whole
body.
o Added the way that Proxy sets its own name to a 495 response.
o Corrected the applicability of the "Proxy-Inspect-Body" for ACK
and PRACK.
o Removed the parameters for the CEK reuse from the message
examples.
o Added text for detecting forged error response at impersonating
proxy server in Security Consideration.
11. Acknowledgments
Thanks to Rohan Mahy and Cullen Jennings for their initial support of
Ono & Tachimoto Expires January 8, 2008 [Page 27]
Internet-Draft End-to-middle security in SIP July 2007
this concept and to many people for useful comments, especially Jon
Peterson, Jonathan Rosenberg, Eric Burger, Russ Housely, Marjou
Xavier, and Eric Rescorla.
12. References
12.1. 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] Ono, K. and S. Tachimoto, "Requirements for End-to-Middle
Security for the Session Initiation Protocol (SIP)", RFC 4189,
October 2005.
[3] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling", RFC 3850,
July 2004.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[5] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[6] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", RFC 2585,
May 1999.
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
12.2. Informative References
[9] 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.
[10] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
Ono & Tachimoto Expires January 8, 2008 [Page 28]
Internet-Draft End-to-middle security in SIP July 2007
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[12] 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.
[13] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002.
[14] Farrell, S. and S. Turner, "Reuse of CMS Content Encryption
Keys", RFC 3185, October 2001.
[15] Ono, K. and S. Tachimoto, "Key reuse in S/MIME for SIP",
draft-ono-sipping-keyreuse-smime-00 (work in progress),
February 2004.
[16] Campbell, Ed., B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[17] 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.
Authors' Addresses
Kumiko Ono
Columbia University
Department of Computer Science
New York, NY 10027
USA
Email: kumiko@cs.columbia.edu
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 8, 2008 [Page 29]
Internet-Draft End-to-middle security in SIP July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Ono & Tachimoto Expires January 8, 2008 [Page 30]
