One document matched: draft-barnes-sipping-sec-inserted-info-02.txt
Differences from draft-barnes-sipping-sec-inserted-info-01.txt
Internet Draft M. Barnes
Document: draft-barnes-sipping-sec-inserted-info-02.txt Nortel
Category: Informational
Expires: April 22, 2005 Oct. 22 2004
A Mechanism to Secure SIP information inserted by Intermediaries
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 April 22nd, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This draft discusses a standard mechanism for securing information in
SIP requests and responses, inserted by intermediaries, which may be
used by other intermediaries or the endpoints as the basis for
services. The requirements are based on the need for a general
middle-to-middle and middle-to-end security mechanism applicable to
both headers and message bodies. This mechanism is optional,
however, the use of it enhances the overall security of SIP by
ensuring the integrity of the information inserted by an
intermediary.
Barnes Expires û April 2005 [Page 1]
SIP Secure Header Insertion October 2004
Table of Contents
1. Background.....................................................3
2. Requirements Summary...........................................5
3. Solution Considerations and Options............................6
3.1 SIP Identity...............................................6
3.2 Adding Message Bodies......................................7
4. Detailed Solution Description..................................7
5. Examples.......................................................7
6. Receiving Secured Information in a Request.....................7
7. Secured Information in Responses...............................8
8. Security Considerations........................................8
Informative References............................................8
Full Copyright Statement..........................................9
Overview
This draft proposes a standard mechanism for securing information, in
SIP Requests and Responses, inserted by intermediaries. One of the
security concerns are headers, or message bodies, containing
information which can reflect some aspect of a user's identity and
service routing, such as the Request-URIs contained in the History-
Info header [SIPHISTI], thus confidentiality is an objective. Another
security objective is to ensure that the information carried in these
headers is protected from being accessed or manipulated by non-
authorized entities. Integrity of information inserted by
intermediaries is important in that end applications making use of
the information could make false or misleading decisions about the
routing and handling of a request or response based upon this
information.
[RFC 3261] describes the security services required for the SIP
protocol in terms of addressing the end-to-end and hop-by-hop (TLS)
security requirements.
As identified in the End-to-Middle Security requirements [SIPE2MRQ],
the model whereby there are trusted and partially-trusted (in terms
of SIP routing only) intermediaries involved in the routing and
forwarding of a request means that TLS would not be suitable. The
End-to-Middle proposal addresses the requirements for an end-to-
middle solution to handle the problem of securing information in a
Request sent by a SIP UA that may be needed by an intermediary under
this model.
This draft complements the End-to-Middle proposal by addressing the
middle-to-middle problem of securing information added to a SIP
Request or Response by an intermediary, used by another intermediary.
It also addresses the middle-to-end security problem of ensuring the
Barnes Expires - April 2005 [Page 2]
SIP Secure Header Insertion October 2004
integrity of the information added by an intermediary, received by a
SIP UA.
Section 1 summarizes the background of the problem to be solved with
some examples scenarios.
Section 2 identifies the requirements.
Section 3 discusses some considerations for the solution options,
with the remaining sections expected to detail the solution once the
requirements are agreed.
1. Background
The following provides some the scenarios under which a Middle-to-
Middle (m2m) and Middle-to-End (m2e) security model would be
applicable. One of the fundamental considerations for these
scenarios is that the User trusts a Proxy to provide a service and
add information through whatever mechanisms are established for the
authorization of that service on the users behalf (e.g. Local Policy
or configuration, Require header, Supported header, Session Policy
[SIPSPCRQ], etc.). Thus, it is within the scope of this service
authorization mechanism that the policy to secure any information
added to a Request would be specified (i.e. authorization of the
service implies authorization to secure the information).
This first scenario involves User#1 in a Visited network, where there
is no expectation of services beyond fundamental routing. UA1
includes a Header field, such as History-Info, in the Request, which
Proxy#1 uses. The security for this can be provided by the End-to-
Middle proposal. However, Proxy#1, who is trusted by the UA makes a
change to that header and adds another header prior to forwarding the
request. Since, Proxy#1 does not know whether Proxy#2 is authorized
to alter the information, but the information is needed at UA2, it
must be secured such that any manipulation of the information could
be detected by UA#2.
Visited network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+ +-----+
User#1 -->| | H1 |---->| * |---->| H1' | | | | H1'|
| | | | | | | H2 |---->| * |---->| H2 |
| +-----+ +-----+ | +-----+ +-----+ +-----+
| UA#1 Proxy A | Proxy#1 Proxy#2 UA#2
Barnes Expires - April 2005 [Page 3]
SIP Secure Header Insertion October 2004
+---------------------+
H1: Header added initially by UA#1 which is protected by e2m
security
H1': Proxy#1 modifies H1 (after validating based on e2m security)
H2 : Added by Proxy#1 (secured along with H1' using m2e security)
*: Headers are forwarded in the Request, but are not manipulated.
Figure 1: Middle-to-End Request
This second scenario (Figure 2) involves User#2 in a Visited network,
where there is no expectation of services beyond fundamental routing.
UA1 includes a Header field, such as History-Info, in the Request,
which Proxy#1 uses. The security for this can be provided by the End-
to-Middle proposal. However, Proxy#1, who is trusted by the UA,
makes a change to that header (H1) and adds another header (H2) prior
to forwarding the request. Proxy#1 secures the information prior to
sending to Proxy#2. Proxy#2 retargets the request to UA#3 (for
example, based upon a response from UA#2 and internal routing
decisions). Proxy#2 does not know whether Proxy#3 is authorized to
alter the information, but the information may be needed at UA#3, so
the information must be secured such that any unauthorized
manipulation of the information could be detected by UA#3.
Visited network
+---------------------+ Proxy#1 Proxy#2
| +-----+ +-----+ | +-----+ +-----+ +-----+
User#2 -->| | H1 |---->| * |---->| H1' |---->| H1' |---->| H1'|
| | | | | | | H2 | | H2' |<----| H2 |
| | | | | | | | | H3 | +-----+
| +-----+ +-----+ | +-----+ +-----+ UA#2
| UA#1 Proxy A | |
+---------------------+ v
+-----+ +-----+
| |---->| H1'|
| * |<----| H2'|
| | | H3 |
+-----+ +-----+
Proxy#3 UA#3
H1: Header added initially by UA#1 which is protected by e2m
security
H1': Proxy#1 modifies H1 (after validating using e2m security model)
H2 : Added by Proxy#1. Secures along with H1' using m2m model.
H2': Proxy#2 modifies H2 (after validating using m2m model) based
on the response From UA#2.
H3: Added by Proxy#2 based upon information in H2' and/or H1'.
Barnes Expires - April 2005 [Page 4]
SIP Secure Header Insertion October 2004
Secured along with H1'and H2' using m2m/m2e.
*: Headers are forwarded in the Request/Responses, but not accessed.
Figure 2: Middle-to-Middle Request
From detailing the scenarios, it becomes apparent that the security
resembles a transitive model, with each trusted intermediary involved
effectively vouching for the previous intermediary, and the
information being validated at each of the trusted intermediaries.
Thus, the end UA need only needs the keys/certificates necessary to
validate the information received from the last intermediary and not
for each intermediary involved in manipulating the Request. This
minimizes the amount of security certificates/keys needed by each
intermediary and UA.
2. Requirements Summary
The following summarizes the fundamental requirements for middle-to-
middle and middle-to-end security of information (headers or message
bodies) inserted by intermediaries:
1) REQ-1: An entity, receiving a request or response containing
information inserted by an intermediary, which makes use of the
information, MUST be able to validate the integrity of
information to ensure it has not been altered. Thus, implying the
following detailed requirements:
REQ-1a: The entity (intermediary or UAs) SHOULD be able to
determine whether a header or message body has been secured.
REQ-1b: A mechanism MUST be defined such that the entity MAY
validate the integrity of the information.
2) REQ-2: Intermediaries adding information to the requests and
responses SHOULD secure the information prior to forwarding the
request or response. Thus, implying the following detailed
requirements:
REQ-2a: A mechanism MUST be defined such that the entities MAY
secure the information in a manner whereby only trusted entities
are able to access the information.
3) REQ-3: SHOULD work with existing SIP security mechanisms,
including end-to-end encryption and TLS.
4) REQ-4: SHOULD work with End-to-Middle security mechanisms.
Barnes Expires - April 2005 [Page 5]
SIP Secure Header Insertion October 2004
5) REQ-5: SHOULD have no impact on intermediaries that don't make use
of or add information to the requests and responses.
3. Solution Considerations and Options
[Editor's note: This section is currently preliminary, but is
intended to capture some of the relevant discussion of options from
IETF-60 around the applicability of the updated Identity proposal and
the adding message bodies proposal.]
3.1 SIP Identity
As mentioned previously, the SIP Identity [SIPATHID] solution
provides end-to-end security of identity related information. It
proposes a way to distribute cryptographically-secure authenticated
identities. The end-to-end security appears to make it an
unacceptable alternative for securing identity related information
inserted by intermediaries. However, consideration and application
of some fundamental SIP functionality (per [RFC3261]) can make it a
much more attractive option. Following along the lines of the current
specification in [RFC 3261] on determining request targets, which
specifies that retargeting is only applicable if the Request-URI
reflects a domain for which the element is responsible, per the
following excerpt from [RFC3261]
"If the domain of the Request-URI indicates a domain this element
is not responsible for, the Request-URI MUST be placed into the
target set as the only target, and the element MUST proceed to the
task of Request Forwarding".
the current specification is sufficient in that it provides
flexibility in implementation, while still ensuring that retargeting
occurs only in specific situations. In the scenarios where a request
has been retargeted and the domain to which it is being forwarded is
not one for which the forwarding intermediary is responsible, any
request that has been retargeted MUST be redirected back to the
originating UAC. This will then allow the UAC to secure the
information added by the intermediary end-to-end, thus using basic
SIP functionality to obviate the need for any new functionality at
the intermediaries.
This proposal does seem to put a large burden on points of inter-
working and the UAC, rather than the intermediary and it may be
difficult to make backwards compatible. However, it should be
recognized that this scenario in the case of History-Info is a corner
case and not the most likely one involving History-Info, thus impact
is likely less than perceived. However, the impact on the current
SIP identity related headers would be a bit higher. The most
Barnes Expires - April 2005 [Page 6]
SIP Secure Header Insertion October 2004
important advantage of this approach is that it obviates the need for
intermediary involvement and a transitive trust model.
3.2 Adding Message Bodies
Another proposal [SIPADDBD] proposes to "relax" the restriction that
proxies cannot add message bodies to allow securing of information
added by intermediaries. This would provide a general purpose
mechanism, thus avoiding the requirement to define P-headers for
cases where this functionality is useful.
This proposal doesn't entirely resolve the "robust" security problem
for History-Info, as another intermediary needs to unpack the
information in order to access the index per the transitive model
introduced in section 1. However, this approach does facilitate
inter-working in terms of standardizing the approach, so that
alternative proprietary implementations would no longer be needed to
cover the scenarios.
4. Detailed Solution Description
[Editor's note: Once there is agreement on the proposed solution,
this will be detailed]
5. Examples
[Editor's note: Once there is agreement on the proposed solution,
this will be detailed]
6. Receiving Secured Information in a Request
Only entities making use of the information that has been secured
need to verify the secured information.
When an entity receives a request containing secured information, if
it does not need to make use of any of the information which is
contained in the message, then it can just forward the secured
information in the request.
[Editor's note: This obviously needs additional detail around the
processing by an entity that wants to make us of the the secured
information, and some guidance for applications wanting to make us of
the information.]
Barnes Expires - April 2005 [Page 7]
SIP Secure Header Insertion October 2004
7. Secured Information in Responses
The focus is the security of information in Requests that might
influence behavior and subsequent responses to those requests. Thus,
new secured information is not included in responses, but rather MAY
be forwarded in the response, depending on the recommendations for
that information.
[Editor's note: This obviously needs additional detail, particularly
around the processing by an entity that wants to make us of the
information in the responses and how the integrity is maintained and
validated.]
8. Security Considerations
Securing information inserted by intermediaries improves the overall
security of SIP. For example, the capturing of the History-Info
header information in a secure manner provides an additional means
(without requiring signed keys for all the involved entities) for the
original requestor to be assured that the request was properly
retargeted.
Informative References
[RFC3261] J. Rosenberg et al, "SIP: Session initiation protocol," RFC
3261, June, 2002.
[SIPATHID] J. Peterson, "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-
identity-03.txt, Work in Progress, September 2004.
[SIPBDADD] R. Mahy, "SIP Body Addition", draft-mahy-sipping-body-add-
00.txt, July, 2004.
[SIPE2MRQ] K. Ono, S. Tachimoto, "Requirements for End-to-Middle
Security for the Session Initiation Protocol", draft-ietf-sipping-
e2m-sec-reqs-04.txt, Work in Progress, October, 2004.
[SIPHISTI] M. Barnes, "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", draft-ietf-sip-
history-info-04.txt, Work in Progress, October 2004.
[SIPSPCRQ] J. Rosenberg, "Requirements for Session Policy for the
Session Initiation Protocol (SIP)", draft-ietf-sipping-session-
policy-req-02 (work in progress), July 2004.
Barnes Expires - April 2005 [Page 8]
SIP Secure Header Insertion October 2004
Acknowledgements
The author would like to thank Kumiko Ono, Cyrus Shaoul and Gonzalo
Camarillo for their discussion and support of this topic. Also,
thanks to Rohan Mahy for not liking the initial AIIHB proposal.
Author's Address
Mary Barnes
Nortel Networks
2380 Performance Drive
Richardson, TX USA 75082
Phone: 1-972-684-5432
Email: mary.barnes@nortelnetworks.com
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
IETF Documents can be found in BCP 78 and 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 which may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Barnes Expires - April 2005 [Page 9]
SIP Secure Header Insertion October 2004
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.
Barnes Expires - April 2005 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 09:01:06 |