One document matched: draft-ietf-sip-e2m-sec-04.txt
Differences from draft-ietf-sip-e2m-sec-03.txt
SIP K. Ono
Internet-Draft Columbia University
Expires: June 4, 2007 S. Tachimoto
NTT Corporation
December 1, 2006
End-to-middle Security in the Session Initiation Protocol (SIP)
draft-ietf-sip-e2m-sec-04
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 June 4, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 June 4, 2007 [Page 1]
Internet-Draft End-to-middle security in SIP December 2006
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-Required-Body Header . . . . . . . . . . . . . . . . . . 15
7. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Message Examples of End-to-Middle Confidentiality . . . . 16
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 . . . . . . . . . . . . . . 24
8.3. Tampering with the Label of the Target Content . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. 'Proxy-Required-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 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Ono & Tachimoto Expires June 4, 2007 [Page 2]
Internet-Draft End-to-middle security in SIP December 2006
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 June 4, 2007 [Page 3]
Internet-Draft End-to-middle security in SIP December 2006
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 June 4, 2007 [Page 4]
Internet-Draft End-to-middle security in SIP December 2006
+-----------------------------------------------------------+
| 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. 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 June 4, 2007 [Page 5]
Internet-Draft End-to-middle security in SIP December 2006
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. The signature in the
SIP identity mechanism provides the data integrity of the whole
message body after encryption. A UA MAY also generate the signature
in the SIP identity, instead of generating CMS SignedData.
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.
3. Indicating the Target Proxy and Content
A UA needs 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 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 a proxy server's hostname
and one or more "content-id" parameter(s) pointing to the
"Content-ID" MIME header [11] placed in the target body.
If a UA needs to request multiple proxy servers to view the same
message body, it SHOULD set multiple "Proxy-Required-Body" headers
that contain the same "content-id" parameter. If a UA needs to
request a proxy server to view multiple body parts that are nested,
it MUST set the "content-id" parameter of the outer body first and
that of the inner body next in the "Proxy-Required-Body" header.
Note: This label does not indicate what kind of content is
expected to be viewed by a proxy server. 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.
This "cid" indication for encypted data is useful for a proxy server
to limit the target data to decrypt. However, the "cid" indication
for signed data is usually useless because the signed data is always
protecting the whole message 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.
Therefore, when a UA knows that the proxy server does the integrity
check of the message body as it service or its security policy, a UA
Ono & Tachimoto Expires June 4, 2007 [Page 6]
Internet-Draft End-to-middle security in SIP December 2006
MAY omit to set a indication using the "Proxy-Required-Body" header
for signed data.
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 this indication
specifying 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.
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 doesn't support this mechanism, the UA
doesn't 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.
Note: Is "Proxy-Required-Body" an appropriate name? "Proxy-
Allowed-Body" was suggested as the naming for this header. Since
the intension of the header is to request, not just permit, the
proxy server to view the message body when indicated, "Proxy-
Required-Body" is to be more appropriate.
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.
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,
Ono & Tachimoto Expires June 4, 2007 [Page 7]
Internet-Draft End-to-middle security in SIP December 2006
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 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 new error response, 496
(Proxy Undecipherable). The proxy's public key certificate and
Content-Type to be viewed SHOULD be contained with the error
response. The proxy's public key certificate SHOULD be set as an
"application/pkix-cert" [6] MIME body.
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.
Until the previous version, 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
Ono & Tachimoto Expires June 4, 2007 [Page 8]
Internet-Draft End-to-middle security in SIP December 2006
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
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.
Ono & Tachimoto Expires June 4, 2007 [Page 9]
Internet-Draft End-to-middle security in SIP December 2006
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-Required-
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
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 acknowledges that the proxy server requires the
disclosure of a specific message body. If the error response
contains no Warning header, the UAC acknowledges 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 SHOULD set the "Proxy-Required-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
Ono & Tachimoto Expires June 4, 2007 [Page 10]
Internet-Draft End-to-middle security in SIP December 2006
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-Required-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 error response, the UAC acknowledges 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
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 SHOULD specify the hostname of the proxy
server and the Content-ID of the CMS EnvelopedData destined for the
proxy server in the "Proxy-Required-Body". The UAC also MAY specify
the Content-ID of the CMS SignedData following the Content-ID of the
CMS EnvelopedData in the header.
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.
Ono & Tachimoto Expires June 4, 2007 [Page 11]
Internet-Draft End-to-middle security in SIP December 2006
+-------------------------------------------------------------+
| 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.
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 acknowledge 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-Required-
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
Ono & Tachimoto Expires June 4, 2007 [Page 12]
Internet-Draft End-to-middle security in SIP December 2006
+-------------------------------------------------------------+
| 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 supporting this mechanism receives a message,
it MUST inspect the "Proxy-Required-Body" header(s). If the header
includes the host name of the proxy server , the proxy server MUST
inspect the body indicated by the "content-id" parameter. If
multiple "content-id" 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.
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.
Ono & Tachimoto Expires June 4, 2007 [Page 13]
Internet-Draft End-to-middle security in SIP December 2006
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
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-
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
other proxy server, the proxy server MAY deletes the "Proxy-
Required-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.
Ono & Tachimoto Expires June 4, 2007 [Page 14]
Internet-Draft End-to-middle security in SIP December 2006
6. Proxy-Required-Body Header
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [7]. The new header "Proxy-
Required-Body" is defined as a SIP header.
Proxy-Required-Body = "Proxy-Required-Body" HCOLON required-proxy
SEMI target-body *(SEMI generic-param)
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 REF
-----------------------------------------------------------------
Proxy-Required-Body R dr o o - o o o o
Proxy-Required-Body 100-699 dr - o - o o o o
Header field where proxy SUB NOT PRK IFO UPD MSG PUB
-----------------------------------------------------------------
Proxy-Required-Body R dr o o o o o o o
Proxy-Required-Body 100-699 dr o 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.
Ono & Tachimoto Expires June 4, 2007 [Page 15]
Internet-Draft End-to-middle security in SIP December 2006
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
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.
Ono & Tachimoto Expires June 4, 2007 [Page 16]
Internet-Draft End-to-middle security in SIP December 2006
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:
******************************************************************
* (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
with a 200 OK. The 200 OK is to be encrypted as follows:
Ono & Tachimoto Expires June 4, 2007 [Page 17]
Internet-Draft End-to-middle security in SIP December 2006
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
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
Ono & Tachimoto Expires June 4, 2007 [Page 18]
Internet-Draft End-to-middle security in SIP December 2006
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,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 *
* *
* (encryptedContentInfo) *
* Content-Type: application/sdp *
Ono & Tachimoto Expires June 4, 2007 [Page 19]
Internet-Draft End-to-middle security in SIP December 2006
* 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>
In the following example, UA #1 needs message content in a MESSAGE
Ono & Tachimoto Expires June 4, 2007 [Page 20]
Internet-Draft End-to-middle security in SIP December 2006
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-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: ...
******************************************************************
* (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 June 4, 2007 [Page 21]
Internet-Draft End-to-middle security in SIP December 2006
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 June 4, 2007 [Page 22]
Internet-Draft End-to-middle security in SIP December 2006
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 June 4, 2007 [Page 23]
Internet-Draft End-to-middle security in SIP December 2006
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 is sent by a proper proxy server,
a UA MUST authenticate the responder. Although the UA does not know
what name is a proper proxy server, the UA MUST check if the common
name of the public key certificate attached with the response
corresponds to the proxy's name in the domain where the UA connects
to, or the domain where the recipients connect to. Additionally, a
UA MUST verify the identifier of the proxy server, chains to a
trusted certificate authority of the public key certificate and the
certificate revocation list [8]. If a UA fails to check the
correspondence and/or the verification, the public key certificate is
presumably replaced or forged by a malicious user.
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.
Ono & Tachimoto Expires June 4, 2007 [Page 24]
Internet-Draft End-to-middle security in SIP December 2006
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.
8.3. Tampering with the Label of the Target Content
This document describes a mechanism to discover the security policy
of proxy servers and to obtain their public key certificates. A
malicious user could send encrypted data to load S/MIME processing on
proxy servers. To prevent such unnecessary processing, user
authentication for the outbound proxy, or proxy authentication for
inter-proxy is needed.
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-Required-Body' Header
This section includes the registration information for the 'Proxy-
Required-Body' header which is described in Section 6 of this
document.
Ono & Tachimoto Expires June 4, 2007 [Page 25]
Internet-Draft End-to-middle security in SIP December 2006
Header Name: Proxy-Required-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 -03.
Added text mentioning CMS Digest-Data.
Added text related the order of sign and enryption 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.
Ono & Tachimoto Expires June 4, 2007 [Page 26]
Internet-Draft End-to-middle security in SIP December 2006
o Added generic-params to the "Proxy-Requried-Body" header for
supporting extension parameters.
o Added REFER and PUBLISH methods in the table.
o Clarified a new paramenter 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-Required-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
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.
Ono & Tachimoto Expires June 4, 2007 [Page 27]
Internet-Draft End-to-middle security in SIP December 2006
[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.
[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),
Ono & Tachimoto Expires June 4, 2007 [Page 28]
Internet-Draft End-to-middle security in SIP December 2006
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.
Ono & Tachimoto Expires June 4, 2007 [Page 29]
Internet-Draft End-to-middle security in SIP December 2006
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 June 4, 2007 [Page 30]
Internet-Draft End-to-middle security in SIP December 2006
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 (2006). 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 June 4, 2007 [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-23 09:33:58 |