SIPPING K. Ono
Internet-Draft S. Tachimoto
Expires: November 9, 2004 NTT Corporation
May 11, 2004
Requirements for End-to-Middle Security for the Session Initiation
Protocol (SIP)
draft-ietf-sipping-e2m-sec-reqs-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 9, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
A SIP User Agent (UA) does not always trust all intermediaries in its
request path to inspect its message bodies and/or headers contained
in its message. The UA might want to protect the message bodies and/
or headers from intermediaries except those that provide services
based on its content. This situation requires a mechanism called
"end-to-middle security" to secure information passed between the UA
and intermediaries, which does not interfere with end-to-end
security. This document defines a set of requirements for a mechanism
to achieve end-to-middle security.
Conventions used in this document
Ono & Tachimoto Expires November 9, 2004 [Page 1]
Internet-Draft End-to-Middle Security Requirements May 2004
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Examples of Models . . . . . . . . . . . . . . . . . . . . . 3
2.2 Service Examples . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Logging Services for Instant Messages . . . . . . . . . . . 5
2.2.2 Non-emergency Call Routing Based on the Location Object . . 5
2.2.3 User Authentication . . . . . . . . . . . . . . . . . . . . 6
2.2.4 SDP-based Services . . . . . . . . . . . . . . . . . . . . . 6
3. Scope of End-to-Middle Security . . . . . . . . . . . . . . 7
4. Requirements for a Solution . . . . . . . . . . . . . . . . 9
4.1 General Requirements . . . . . . . . . . . . . . . . . . . . 9
4.2 Requirements for End-to-Middle Confidentiality . . . . . . . 10
4.3 Requirements for End-to-Middle Integrity . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 Changes from 01.txt . . . . . . . . . . . . . . . . . . . . 12
7.2 Changes from 00.txt . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 16
Ono & Tachimoto Expires November 9, 2004 [Page 2]
Internet-Draft End-to-Middle Security Requirements May 2004
1. Introduction
The Session Initiation Protocol (SIP) [2] supports hop-by-hop
security using Transport Layer Security (TLS) [3] and end-to-end
security using Secure MIME (S/MIME) [4]. These security mechanisms
assume that a SIP UA trusts all proxy servers along its request path
to inspect the message bodies contained in the message, or a SIP UA
does not trust any proxy servers to do so.
However, there is a model where trusted and partially-trusted proxy
servers are mixed along a message path. The partially-trusted proxy
servers are only trusted to provide SIP routing, but these proxy
servers are not trusted by users to inspect its data except routing
headers. A hop-by-hop confidentiality service using TLS is not
suitable for this model. An end-to-end confidentiality service using
S/MIME is also not suitable when the intermediaries provide services
based on reading the message bodies and/or headers. This problem is
described in Section 23 of [2].
In some cases, a UA might want to protect its message bodies and/or
headers from proxy servers along its request path except from those
that provides services based on reading its message bodies and/or
headers. Conversely, a proxy server might want to view the message
bodies and/or headers to sufficiently provide these services. Such
proxy servers are not always the first hop from the UA. This
situation requires a security mechanism to secure message bodies and/
or headers between the UA and the proxy servers, yet disclosing
information to those that need it. We call this "end-to-middle
security".
2. Use Cases
2.1 Examples of Models
We describe here examples of models in which trusted and
partially-trusted proxy servers both exist in a message path. These
situations demonstrate the reasons why end-to-middle security is
required.
In the following example, User #1 does not know the security policies
or services provided by Proxy server #1 (Proxy#1). User #1 sends a
MESSAGE [5] request including S/MIME-encrypted message content for
end-to-end security as shown in Figure 1. Proxy #1 erases the
encrypted data in the request based on its strict security policy
that prohibits the forwarding of unknown data. Or Proxy #1 rejects
the request because it cannot offer a message logging service. For
the MESSAGE request to correctly traverse Proxy #1, the UA will need
to discover if end-to-end confidentiality will conflict with
Ono & Tachimoto Expires November 9, 2004 [Page 3]
Internet-Draft End-to-Middle Security Requirements May 2004
intermediary's services or security policies.
Home network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+
User #1-----| | C |-----| * |-----| * |-----| C |-----User #2
| +-----+ +-----+ | +-----+ +-----+
| UA #1 Proxy #1 | Proxy #2 UA #2
+---------------------+
C: Content that UA #1 allows the entity to inspect
*: Content that UA #1 prevents the entity from inspecting
Figure 1: Deployment example #1
In the second example, Proxy server #1 is the home proxy server of
User #1 using UA #1. User #1 communicates with User #2 through Proxy
#1 and Proxy #2 as shown in Figure 2. Although User #1 already knows
Proxy #1's security policy that requires the inspection of message
contents in the MESSAGE request, User #1 does not know whether Proxy
#2 is trustworthy, and thus wants to protect the message bodies in
the request. UA #1 will need to be able to grant a trusted
intermediary (Proxy #1) to inspect message bodies while preserving
their confidentiality from other intermediaries (Proxy #2).
Even if UA #1's request message authorizes a selected proxy server
(Proxy #1) to inspect the message bodies, UA #1 is unable to
authorize the same proxy server to inspect the message bodies in
subsequent MESSAGE requests or the response from UA #2.
Home network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+
User #1-----| | C |-----| C |-----| * |-----| C |----- User #2
| +-----+ +-----+ | +-----+ +-----+
| UA #1 Proxy #1 | Proxy #2 UA #2
+---------------------+
C: Content that UA #1 needs to disclose
*: Content that UA #1 needs to protect
Figure 2: Deployment example #2
In the third example, User #1 connects UA #1 to a proxy server in a
visited (potentially insecure) network, e.g., a hotspot service or a
roaming service. Since User #1 wants to utilize certain home network
services, UA #1 connects to a home proxy server, Proxy #1. However,
UA #1 must connect to Proxy #1 via the proxy server of the visited
Ono & Tachimoto Expires November 9, 2004 [Page 4]
Internet-Draft End-to-Middle Security Requirements May 2004
network (Proxy A), because User #1 must follow the policy of that
network. Proxy A performs access control based on the destination
addresses of calls. User #1 only trusts Proxy A to route requests,
not to inspect the message bodies the requests contain as shown in
Figure 3. User #1 trusts Proxy #1 both to route requests and to
inspect the message bodies for some purpose.
The same problems as in the second example also exist here.
Visited network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+ +-----+
User #1 -- | | C |-----| * |-----| C |-----| * |-----| C |
| +-----+ +-----+ | +-----+ +-----+ +-----+
| UA #1 Proxy A | Proxy #1 Proxy #2 UA #2
+---------------------+
C: Content that UA #1 needs to disclose
*: Content that UA #1 needs to protect
Figure 3: Deployment example #3
2.2 Service Examples
We describe here several services that require end-to-middle
security.
2.2.1 Logging Services for Instant Messages
Logging Services is provided by the archiving function, which is
located in the proxy server, that logs the message content exchanged
between UAs. When instant message content contains private
information, UACs (User Agent Clients) encrypt the message content
for the UASs (User Agent Servers). Archiving function needs a way to
log the content in a message body in bidirectional MESSAGE requests
with decipherable conditions. The archiving function needs a way to
verify the data integrity of the content before logging. The
archiving function could be located at the originator network and/or
the destination network.
This service might be deployed for financial or health care
applications, where archiving communication is required by policies,
as well as other applications.
2.2.2 Non-emergency Call Routing Based on the Location Object
The Location Object [6] includes private information as well as
Ono & Tachimoto Expires November 9, 2004 [Page 5]
Internet-Draft End-to-Middle Security Requirements May 2004
routing information for some proxy servers. Special proxy servers
have the capability of location-based routing. When UAs want to
employ location-based routing in non-emergency situations, the UAs
need to connect with the proxy servers that have such a capability
and disclose the content in the message body of the INVITE request
that contains the Location Object. However, the Location Object needs
to be protected from other proxy servers through the request path.
The Location Object needs to be verified the integrity before
location-based routing. Sometimes, if the UAC desires it, the
Location Object needs to be transmitted to the UASs.
2.2.3 User Authentication
2.2.3.1 User Authentication using the AIBs
The Authenticated Identity Bodies (AIBs) [7] is a digitally-signed
data that is used as way to identify users. Proxy servers that need
to authenticate a user verify the signature. When the originator
needs anonymity, the user identity in the AIB is encrypted before
being signed. Proxy servers that authenticate the user need to
decrypt the body in order to view the user identity in the AIB. Such
proxy servers can be located at adjacent and/or non-adjacent to the
UA.
The AIB could be included in all request/response messages. The proxy
server needs to view it in request messages in order to authenticate
users. Another proxy server sometimes needs to view it in response
messages for user authentication.
2.2.3.2 User Authentication in HTTP Digest Authentication
User authentication data for HTTP digest authentication includes two
types of information. One is potentially private information, such as
a user name, and another is information that can be used for
"replay-attacks", such as the "response" parameter that is created by
a calculation using a user's password. The user authentication data
can be set in request messages, but not in response messages. This
information needs to be transmitted securely to servers that
authenticate users, located either at adjacent and/or non-adjacent to
the UA.
2.2.4 SDP-based Services
The following example are services based on the Session Description
Protocol (SDP). After a session policy [8] mechanism establised,
these services would employ other header field instead of the SDP.
Note: The SIPPING WG is discussing these services as use cases of
Ono & Tachimoto Expires November 9, 2004 [Page 6]
Internet-Draft End-to-Middle Security Requirements May 2004
session policy. The session policy mechanism extracts information
from the SDP that is to be viewed by proxy servers. With this
mechanism, proxy servers need to view a new SIP header field
instead of the SDP in a message body. However, the extracted
information still includes the address and port information, that
needs to be protected as well as the SDP.
2.2.4.1 Firewall Traversal
A firewall entity that supports the SIP protocol, or a midcom [9]
agent co-located with a proxy server, controls a firewall based on
certain SDP attributes in the SDP offer/answer. The SDP includes the
address and port information for media streams and/or key parameters
of Secure RTP[10]. This requires UAs to encrypt the SDP for recipient
UAs when needed. If the SDP is encrypted for end-to-end
confidentiality, the proxy server operating as a midcom agent will
have no way to provide firewall traversal as it can not inspect the
SDP. Therefore, the proxy server needs to be able to decrypt the SDP.
Also, the proxy server needs to verify the integrity of the SDP. The
firewall entities could be located at the originator network and/or
destination network.
2.2.4.2 SDP-based Call Admission Control (CAC)
The SDP includes bandwidth information that is expected to be used
for Call Admission Control (CAC). The SDP also includes the port
information for media streams and/or key parameters of Secure RTP.
This requires UAs to encrypt the SDP for recipient UAs when needed.
On the other hand, a CAC function, which is located in a proxy
server, needs to view the SDP offer/answer in INVITE/200 messages
and/or UPDATE/200 messages. The 183 response could be used instead of
INVITE-200 response.
Note: Although the SDP offer/answer can be sent in the 200/ACK
messages, it is too late to view the SDP for the first time in the
200 response for admission to create the call. If the CAC function
found that the call is not acceptable and forced the disconnection
of the call, it would cause a "ghost ring".
3. Scope of End-to-Middle Security
End-to-middle security consists of user authentication, data
integrity, and data confidentiality. The above examples mainly
require data confidentiality of end-to-middle security.
Proxy servers usually need to authenticate a user that sends a
Ono & Tachimoto Expires November 9, 2004 [Page 7]
Internet-Draft End-to-Middle Security Requirements May 2004
request message. HTTP digest authentication described in [2] can be
used for user-to-proxy authentication of the request messages. With
sending the "challenge" parameter, proxy servers can ask for UAs to
send the "response" parameter for the authentication. The
authenticating proxy is not limited to the first hop for the UA.
Thus, HTTP digest authentication can be used for end-to-middle
security. To avoid replay attacks, the HTTP digest authentication
needs to be used with a security mechanism that contains
confidentiality.
Additionally, a digital signature obtained from a Public Key
Infrastructure, S/MIME Cryptographic Message Syntax (CMS) SignedData
body [11] and a digital signature within an AIB can be used for the
authentication. Since these mechanisms achieve authentication for
end-to-middle security, the requirements are not discussed in this
document.
Note: An encrypted identity in the AIB for anonymity cannot be
directly used for user-to-proxy authentication, that is,
end-to-middle authentication. With end-to-middle confidentiality,
the AIB for anonymity can be used for end-to-middle
authentication. Therefore, the AIB for anonymity is included in
end-to-middle confidentiality.
As for data integrity, proxy servers require validation of the
content to be used for providing some services. The CMS SignedData
body might be used as a mechanism for end-to-middle security. The CMS
SignedData body can be created with the original data and the
originator's private key, and anyone can verify the data integrity by
using the originator's public key and the certificate. That is, proxy
servers can verify the data integrity whenever they require. Thus,
the CMS SignedData body could be used to implement end-to-middle
security at the same time it is used for end-to-end security.
Currently, there is no way for UAs to request a selected proxy server
to verify a message with the CMS SignedData body. Some new mechanisms
are needed to achieve data integrity for end-to-middle security.
Note: If a malicious proxy server modifies the SignedData body,
end-to-end integrity would collapse. If a malicious proxy server
strips off the signature with the MIME headers of the multipart
MIME, end-to-end integrity would also collapse. In this case, a
recipient UA has no way to verify the data integrity.
This document mainly discusses requirements for data confidentiality
and the integrity of end-to-middle security. Proposed mechanisms are
discussed in [12].
Ono & Tachimoto Expires November 9, 2004 [Page 8]
Internet-Draft End-to-Middle Security Requirements May 2004
4. Requirements for a Solution
We describe here requirements for a solution. The requirements are
mainly applied during the phase of a dialog creation or sending a
MESSAGE method.
4.1 General Requirements
The following are general requirements for end-to-middle
confidentiality and integrity.
REQ-GEN-1: The solution SHOULD have little impact on the way a UA
handles messages with S/MIME bodies.
REQ-GEN-2: It SHOULD have no impact on proxy servers that do not
provide services based on S/MIME bodies in terms of
handling the existing SIP headers.
REQ-GEN-3: It SHOULD have little impact on the standardized mechanism
of proxy servers that provide services based on S/MIME
bodies.
A proxy server is prohibited to add/modify/delete a
message body as described in [2]. A proxy server can
view a message body following the standardized
mechanism, although it is not desirable.
When a proxy server receives an S/MIME message, it
should be able to quickly and easily discover the
necessity to investigate the S/MIME body. This can be
restated as:
+ It SHOULD allow proxy servers to quickly and easily
determine whether to handle S/MIME bodies and, if
so, how and which ones.
REQ-GEN-4: It SHOULD allow a proxy server to notify a UA about the
proxy server's security policy for a request/response
message, as well as what data is needed in order to
provide a service.
This requirement is necessary when the UA does not know
in advance which proxy servers or domains need
disclosing data and/or verification.
Open Issue: Is it necessary for the proxy server to
notify the UAS after receiving a response?
Ono & Tachimoto Expires November 9, 2004 [Page 9]
Internet-Draft End-to-Middle Security Requirements May 2004
4.2 Requirements for End-to-Middle Confidentiality
REQ-CONF-1: The solution MUST be compatible with end-to-end
encryption. The encrypted data can be shared with the end
user and selected proxy servers, if needed.
This requirement is necessary for logging service and
the Location Object.
REQ-CONF-2: It MUST NOT violate end-to-end encryption when the
encrypted data does not need to be shared with any proxy
servers.
This requirement is necessary for SDP-based services.
For example, keying materials for secure RTP (SRTP) in
SDP [10] can be included only in the end-to-end
encryption, if the UA's policy states as such.
Open Issue: It sometimes occurs that a part of the
SDP is for end-to-end encryption and another part
is for end-to-middle encryption. Do we really need
a new Content-Type such as "sdpfrag"?
REQ-CONF-3: It SHOULD allow a UA to discover which proxy servers need
to view data in a request/response message, as well as
what data is needed.
This requirement is necessary when the UA does not
know which proxy servers or domains provide the data
dependent services in advance.
REQ-CONF-4: It SHOULD allow a UA to request selected proxy servers to
view specific message bodies. The request itself SHOULD
be secure.
This requirement is necessary when the data-dependent
service, such as logging service, the Location Object,
or firewall traversal, is provided on demand of users.
For example, the logging service could be provided on
demand of users that needs to log some important
messages.
REQ-CONF-5: It SHOULD allow a UA to request that the recipient UA
disclose information to the proxy server, that requesting
UA is disclosing the information to. The request itself
SHOULD be secure.
This requirement is necessary for logging service for
Ono & Tachimoto Expires November 9, 2004 [Page 10]
Internet-Draft End-to-Middle Security Requirements May 2004
instant messages. Logging function sometimes requires
to archive the bidirectional exchange of messages.
It is not reasonable to expect that the recipient UA
knows the public key certificate of the proxy server
on the originating network. This can be restated as:
+ The solution SHOULD allow a UA to request the
recipient UA to reuse a CEK in subsequent messages
during a dialog.
+ It SHOULD allow a UA to request a selected proxy
server to keep a CEK in a message during a dialog.
The requests themselves SHOULD be secure.
REQ-CONF-6: It MAY allow a UA to notify the recipient UA which proxy
server needs to view data in a request/response in order
to provide the services.
REQ-CONF-7: It MAY allow a UA to notify the recipient UA what data
the proxy server is permitted to view in a request/
response in order to provide the services.
These last two requirements might be needed for
firewall traversal when there is a firewall in the
network connected to a UAS. A UAS needs to notify a
UAC to disclose the SDP in an INVITE message to a
proxy server that controls the firewall in the UAS
network. Such notification might be applied in a
registration phase.
4.3 Requirements for End-to-Middle Integrity
REQ-INT-1: The solution SHOULD work even when the SIP end-to-end
integrity service is enabled.
This requirement is necessary for logging service, the
Location Object, the AIB, and SDP-based services.
REQ-INT-2: It SHOULD allow a UA to discover what data in a request/
response the proxy needs to verify in order to provide the
service.
This requirement is necessary when the UA does not know
what data is used to provide the service in advance.
Ono & Tachimoto Expires November 9, 2004 [Page 11]
Internet-Draft End-to-Middle Security Requirements May 2004
REQ-INT-3: It SHOULD allow a UA to request selected proxy servers to
verify specific message bodies. The request itself SHOULD
be secure.
This requirement is necessary when the data-dependent
service, such as logging service, the Location Object,
or firewall traversal, is provided on demand of users.
For example, logging service could be provided on
demand of users who needs to log some important
messages.
REQ-INT-4: It SHOULD allow a UA to request the recipient UA to send
the verification data of the same information that the
requesting UA is providing to the proxy server. The
request itself SHOULD be secure.
This requirement is necessary for logging service and
the AIB. Logging service sometimes requires to archive
the bidirectional exchange of messages. Mutual
authentication of user-to-user requires to send a
response with the AIB of the recipient UA.
REQ-INT-5: It MAY allow a UA to notify the recipient UA what data the
proxy server needs to verify in a request/response for the
services.
This requirements might be needed for firewall
traversal when a firewall exists in the network
connected to a UAS. A UAS needs to notify a UAC to
disclose the SDP in an INVITE message to a proxy server
that controls the firewall in the UAS network. Such
notification might be applied in a registration phase.
5. Security Considerations
This document presents confidentiality and integrity requirements in
Section 3.
We need to consider how to prevent Denial-of-Service (DoS) attacks on
proxy servers. The end-to-middle security requires additional
processes such as data decryption and/or signature verification to
proxy servers. Enabling end-to-middle security in proxy servers will
increase the likelihood that receiving many messages will slow down
the overall performance of those proxy servers. To avoid this
consequence, proxy servers SHOULD authenticate the originator of the
message before starting the process. [To be done: add some more
requirements for preventing DoS attack.]
Ono & Tachimoto Expires November 9, 2004 [Page 12]
Internet-Draft End-to-Middle Security Requirements May 2004
6. IANA Considerations
This document requires no additional considerations.
7. Changes
7.1 Changes from 01.txt
o Extracted use cases from the Introduction section, and created a
new section to describe the use cases in more detail. The use
cases are also updated.
o Deleted a few "may" words from the "Problem with Existing
Situations" section to avoid confusion with "MAY" as a key word.
o Added the relation between the requirements and the service
examples.
o Deleted the redundant requirements for discovery of the
targeted-middle. The requirement is described only in the "Generic
Requirements", not in the "Requirements for End-to-Middle
Confidentiality/Integrity".
o Changed the 4th requirement of end-to-middle confidentiality from
"MUST" to "SHOULD".
o Changed the 3rd requirement of end-to-middle integrity from "MUST"
to "SHOULD".
o Added some text about DoS attack prevention in the "Security
Consideration" section.
7.2 Changes from 00.txt
o Reworked the subsections in Section 4 to clarify the objectives,
separating end-to-middle confidentiality and integrity.
8. Acknowledgments
Thanks to Rohan Mahy and Cullen Jennings for their initial support of
this concept, and to Jon Peterson, Gonzalo Camarillo, and Sean Olson
for their helpful comments.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Ono & Tachimoto Expires November 9, 2004 [Page 13]
Internet-Draft End-to-Middle Security Requirements May 2004
Levels", RFC 2119, BCP 14, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Allen, C. and T. Dierks, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1992.
[5] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[6] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[7] Peterson, J., "SIP Authenticated Identity Body (AIB) Format",
draft-ietf-sip-authid-body-03.txt (work in progress), May 2004.
[8] Rosenberg, J., "Requirements for Session Policy for the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-session-policy-req-01 (work in progress),
February 2004.
[9] Srisuresh, P., Kuthan, J., Rosenberg, J., Brim, S., Molitor, A.
and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
[10] Andreasen, F., Baugher, M. and D. Wing, "Session Description
Protocol Security Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-03.txt (work in progress),
February 2004.
[11] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
1999.
[12] Ono, K. and S. Tachimoto, "End-to-middle security in the
Session Initiation Protocol(SIP)",
draft-ono-sipping-end2middle-security-01 (work in progress),
Feb. 2004.
Ono & Tachimoto Expires November 9, 2004 [Page 14]
Internet-Draft End-to-Middle Security Requirements May 2004
Authors' Addresses
Kumiko Ono
Network Service Systems Laboratories
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-shi, Tokyo 180-8585
Japan
EMail: ono.kumiko@lab.ntt.co.jp
Shinya Tachimoto
Network Service Systems Laboratories
NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-shi, Tokyo 180-8585
Japan
EMail: tachimoto.shinya@lab.ntt.co.jp
Ono & Tachimoto Expires November 9, 2004 [Page 15]
Internet-Draft End-to-Middle Security Requirements May 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Ono & Tachimoto Expires November 9, 2004 [Page 16]
Internet-Draft End-to-Middle Security Requirements May 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ono & Tachimoto Expires November 9, 2004 [Page 17]
