One document matched: draft-barnes-sipping-sec-inserted-info-01.txt
Differences from draft-barnes-sipping-sec-inserted-info-00.txt
Internet Draft M. Barnes
Document: draft-barnes-sipping-sec-inserted-info-01.txt Nortel
Category: Standards Track
Expires: April 2004 October 2003
A Mechanism to Secure SIP information inserted by Intermediaries
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This draft proposes 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. Thus, the requirements and proposed solution are intended
as 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.
Table of Contents
1. Background.....................................................3
2. Requirements Summary...........................................5
Barnes Expires û April 2004 [Page 1]
SIP Secure Header Insertion October 2003
3. Solution Considerations and Options............................6
4. Detailed Solution Description..................................6
5. Examples.......................................................6
6. Receiving Secured Information in a Request.....................6
7. Secured Information in Responses...............................7
8. Security Considerations........................................7
9. IANA Considerations............................................7
Normative References..............................................7
Informative References............................................8
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 [11], 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 [1] describes the security services required for the SIP
protocol in terms of addressing the end-to-end and hop-by-hop (TLS)
security requirements.
The SIP Authenticated Identity Body (AIB) Format [2] provides an
additional security mechanism, which provides reference integrity of
the headers in a request, which can assert identity information about
the originator of the request. While some of the information to be
secured by the proposal in this draft may also be deemed to reveal
information about the originator of the request (e.g. History-Info),
the general problem is different, since the information is inserted
by an intermediary and not by a SIP UA.
As identified in the End-to-Middle Security proposal [12], 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
Barnes Expires - April 2004 [Page 2]
SIP Secure Header Insertion October 2003
Request or Response by an intermediary, used by another intermediary.
It also addresses the middle-to-end security problem of ensuring the
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.
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 [7].
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 is trusting 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 [13], 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.
Barnes Expires - April 2004 [Page 3]
SIP Secure Header Insertion October 2003
Visited network
+---------------------+
| +-----+ +-----+ | +-----+ +-----+ +-----+
User#1 -->| | H1 |---->| * |---->| H1' | | | | H1'|
| | | | | | | H2 |---->| * |---->| H2 |
| +-----+ +-----+ | +-----+ +-----+ +-----+
| UA#1 Proxy A | Proxy#1 Proxy#2 UA#2
+---------------------+
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
Barnes Expires - April 2004 [Page 4]
SIP Secure Header Insertion October 2003
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'.
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:
Barnes Expires - April 2004 [Page 5]
SIP Secure Header Insertion October 2003
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.
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: Once there is agreement on the requirements and
scenarios, this can be detailed]
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 normative 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 2004 [Page 6]
SIP Secure Header Insertion October 2003
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 normative 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.
9. IANA Considerations
Normative References
[1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261,
June, 2002.
[2] J. Peterson, " SIP Authenticated Identity Body (AIB) Format",
draft-ietf-sip-authid-body-01.txt, Work in Progress, February, 2003.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[4] J. Peterson, "Enhancements for Authenticated Identity Management
in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-
01.txt, Work in Progress, February 2003.
[5] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
September 2002.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
2045, November 1996.
Barnes Expires - April 2004 [Page 7]
SIP Secure Header Insertion October 2003
[7] R. Troost, S. Dorner, K. Moore, "Communicating Presentation
Information in Internet Messages: The Content-Disposition Header
Field", RFC 2183, August 1997.
Informative References
[8] M. Barnes, M. Watson, C. Jennings, J. Peterson, "SIP Generic
Request History Capability û Requirements", draft-ietf-sipping-req-
history-04.txt, Work in Progress, June 2003.
[9] E. Rescorla, B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", RFC 3552, July 2003.
[10] C. Jennings, J. Peterson, M. Watson, "Private Extensions to the
Session Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks", RFC 3325, November 2002.
[11] M. Barnes, "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", draft-ietf-sip-history-info-
01.txt, Work in Progress, October 2003.
[12] K. Ono, S. Tachimoto, "End-to-middle security in the Session
Initiation Protocol", draft-ono-sipping-end2middle-security-00.txt,
Work in Progress, June 2003.
[13] Rosenberg, J., "Requirements for Session Policy for the Session
Initiation Protocol (SIP)", draft-ietf-sipping-session-policy-req-00
(work in progress), June 2003.
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 (it
was really yucky).
Author's Address
Mary Barnes
Nortel Networks
2380 Performance Drive
Richardson, TX USA 75082
Phone: 1-972-684-5432
Email: mary.barnes@nortelnetworks.com
Barnes Expires - April 2004 [Page 8]
SIP Secure Header Insertion October 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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
assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Barnes Expires - April 2004 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 08:56:08 |