One document matched: draft-barnes-sipping-sec-inserted-info-00.txt
Internet Draft M. Barnes
Document: draft-barnes-sipping-sec-inserted-info-00.txt Nortel
Category: Standards Track
Expires: December 2003 June 2003
A Mechanism to Secure SIP Identity headers 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 defines a standard mechanism for securing SIP headers that
are inserted into requests and responses. The fundamental
requirements, for securing the headers inserted by an intermediary
routing or retargeting a request or response, are summarized. The
solution is directed towards headers that contain identity related
information, such as Record-Route, Via, and History-Info. The
proposed solution defines an Authenticated Inserted Identity Header
Body based on S/MIME to secure the headers. This mechanism is
optional, however, the use of it enhances the overall security of SIP
by ensuring the integrity of the inserted headers.
Table of Contents
1. Requirements Summary...........................................3
Barnes Expires û December 2003 [Page 1]
SIP Secure Identity Header Insertion June 2003
3. Authenticated Inserted Identity Header Body Description........3
4. Example of a Request with an AIIHB.............................5
6. Receiving an AIIHB.............................................6
5. AIIHB in Responses.............................................6
7. Encryption of Header information...............................6
8. Interactions with AIB..........................................7
9. Security Considerations........................................7
10. IANA Considerations...........................................7
Normative References..............................................7
Informative References............................................8
Overview
This draft proposes a general mechanism to secure headers inserted by
an intermediary routing or retargeting a request. RFC 3261 [1]
describes the security services required for the SIP protocol. 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.
The primary difference between the problem discussed in this document
and the problem domain of [2] is that the header information is being
inserted by an entity routing or retargeting a Request, resulting in
a slightly different problem than the basic SIP header or Identity
problem. The area of primary concern is the Request-URIs, since they
can reflect some aspect of a user's identity and service routing and
are essentially carried in and captured by the Record-Route [1] and
History-Info [8] headers. Another objective of this solution is to
ensure that the information carried in these headers is protected
from being accessed or manipulated by non-authorized entities.
Integrity of inserted headers is important in that end applications
making use of the header information could make false or misleading
decisions about the routing and handling of a request or response
based upon this information. This solution proposes the definition of
an Authenticated Inserted Header Identity Body (AIIHB) in a manner
similar to that defined for the Authenticated Identity Body defined
in [2] to protect the header Information from being manipulated by a
rogue application. The AIIHB provides reference integrity of the
headers, inserted into a request or response, which can assert
identity information about the intermediaries routing and/or
retargeting the request or response.
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].
Barnes Expires - December 2003 [Page 2]
SIP Secure Identity Header Insertion June 2003
1. Requirements Summary
The following summarizes the fundamental requirements for which this
solution is proposed:
1) REQ-1: Ability for an entity receiving a request or response
containing the header(s) inserted by an intermediary to determine
whether any of the previously added header(s) have been altered.
2) REQ-2: Ability for an entity receiving a request or response
containing the header(s) inserted by an intermediary to authenticate
the identity represented by the header(s).
2. Discussion of AIIHB as the proposed Solution
Initial consideration of AIIHB as the proposed solution to meet the
requirements resulted in the following area of concern:
There can be significant overhead in the use of S/MIME. This is
especially highlighted for the History-Info scenario [11], since
each entity adding a History-Info header would need to validate
the information in the other History-Info headers already in the
message prior to adding the new header. The entirety of the
History-Info headers must then be re-signed.
However, the benefits of the AIIHB proposal were deemed to outweigh
the value of considering other alternatives:
1. The use of AIIHB fully meets the requirements.
2. The use of S/MIME is already an option for SIP implementations,
thus the AIIHB proposal should minimize the impact of its
implementation.
3. AIIHB complements the use of AIB.
It should also be noted that there are systems where there is deemed
to be a level of trust amongst the intermediaries as discussed in
[10], thus the use of AIIHB for those systems would be optional.
3. Authenticated Inserted Identity Header Body Description
This solution option is modeled after the Authenticated Identity Body
(AIB) format as defined in [2], which provides reference integrity of
the headers in a request which can assert identity information about
the originator of the request. The primary difference between the
proposal in this document and [2] is that the header information is
being inserted by an entity routing or retargeting a Request,
resulting in a slightly different problem than the basic SIP header
or Identity problem. However, it is entirely consistent with the AIB
Barnes Expires - December 2003 [Page 3]
SIP Secure Identity Header Insertion June 2003
model whereby the network intermediary performs the role of an
'authentication service'.
The following summarizes the differences between the requirements for
headers inserted by intermediaries and the headers described in [2],
which must be considered in defining the AIIHB:
1. The authenticated identity body relates to a header field which is
inserted by an intermediary rather than the From field of the
Request.
2. The authenticated identity is being requested to be authenticated
by the intermediary which is inserting the header in the
request/response and NOT by the user associated with the identity
contained in the header.
3. There may be multiple instances of the same header in a message.
An AIIHB is a MIME body of type 'message/sipfrag' ([5]). This body
MUST have a Content-Disposition disposition-type of 'aiihb', a new
value defined in this document specifically for authenticated
inserted header identity bodies. The Content-Disposition header
SHOULD also contain a 'handling' parameter indicating that this MIME
body is optional (i.e. if this mechanism is not supported by the user
agent server, it can still attempt to process the request).
AIIHBs using the 'message/sipfrag' MIME type MUST contain the
following headers when providing identity for an INVITE request:
From, Call-ID and the Identity related header(s) for which AIIHB is
providing reference integrity. AIIHBs MAY also contain the To and
CSeq headers.
An example of the AIIHB format for an INVITE is:
Content-Type: message/sipfrag
Content-Disposition: aiihb; handling=optional
Record-Route: <sip:UserA@nortelnetworks.com>
From: BigGuy <sip:User1@here.com>
To: LittleGuy <sip:UserA@nortelnetworks.com>
Call-Id: 12345600@here.com
History-Info: <sip:UserA@ims.nortelnetworks.com?Reason=SIP;
cause=302;text="Moved Temporarily">; index=1
Unsigned AIIHBs MUST NOT be honored by any recipients. After the
AIIHB has been signed, it SHOULD be added it to any existing MIME
bodies in the request (such as SDP), if necessary by transitioning
the outermost MIME body to a 'multipart/mixed' format.
Barnes Expires - December 2003 [Page 4]
SIP Secure Identity Header Insertion June 2003
4. Example of a Request with an AIIHB
The following shows a full SIP INVITE request with an AIB:
INVITE sip:UserA@ims.nortelnetworks.com SIP/2.0
Via: SIP/2.0/UDPims.nortelnetworks.com:5060;branch=1
Via: SIP/2.0/UDP here.com:5060
Record-Route: <sip:UserA@nortelnetworks.com>
From: BigGuy <sip:User1@here.com>
To: LittleGuy <sip:UserA@nortelnetworks.com>
Call-Id: 12345600@here.com
CSeq: 1 INVITE
History-Info: <sip:UserA@ims.nortelnetworks.com>; index=1
Contact: BigGuy <sip:User1@here.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: <appropriate value>
--boundary42
Content-Type: message/sipfrag
Content-Disposition: aiihb; handling=optional
Record-Route: <sip:UserA@nortelnetworks.com>
From: BigGuy <sip:User1@here.com>
To: LittleGuy <sip:UserA@nortelnetworks.com>
Call-Id: 12345600@here.com
History-Info: <sip:UserA@ims.nortelnetworks.com?Reason=SIP;
cause=302;text="Moved Temporarily">; index=1
--boundary42
Barnes Expires - December 2003 [Page 5]
SIP Secure Identity Header Insertion June 2003
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42--
--unique-boundary-1ù
[Editor's note: The above example needs validating as it was quickly
cut and pasted from several examples in other drafts and thus it's
extremely likely that it has inaccuracies.]
6. Receiving an AIIHB
Only entities which need to make use of the information for which
AIIHB is providing reference integrity need to verify the AIIHB.
When an entity receives a request containing an AIIHB, if it does not
need to make use of any of the information which is contained in the
AIIHB, then it can just forward the AIIHB 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
AIIHB, both by the addition of a History-Info entry and some guidance
for applications wanting to make us of the information.]
5. AIIHB in Responses
The focus of AIIHB is the security of headers inserted in Requests
that might influence behavior and subsequent responses to those
requests. Thus, new AIIHB information is not included in responses,
but rather MAY be forwarded in the response, depending the
recommendations for that header.
[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.]
7. Encryption of Header information
Barnes Expires - December 2003 [Page 6]
SIP Secure Identity Header Insertion June 2003
As with the AIB, the security of the AIIHB is predicated on the
secure distribution of the key.
When an AIIHB is encrypted, the AIIHB SHOULD always be encrypted
before it is signed. Note that this means that the recipients of the
request, even if they are unable to inspect the AIIHB, will still be
able to see who signed that body (although it will not necessarily be
obvious that the body contains an AIIHB).
8. Interactions with AIB
It could be suggested that in the case of an AIB added by the
originator of the request that the information carried in the AIB
would be redundant and unnecessary in the AIIHB. However, it is the
inclusion of this information also in the AIIHB that provides greater
assurance that the inserted Headers are indeed valid. This also
removes the need for the intermediary that is protecting these
headers to verify the AIB, which would be required if they were
depended upon.
When a user agent receives a request containing both an AIB and an
AIIHB, it should first validate the AIIHB as described in section 6
to ensure the hop by hop integrity of the message prior to validating
the AIB as described in [2].
9. Security Considerations
This document RECOMMENDs the inclusion of the From, Call-ID and the
Identity related header(s) headers in AIIHBs. If these headers are
omitted, some important security properties of AIIHB are lost.
The use of AIIHB to capture inserted headers improves the overall
security of SIP. For example, the capturing of the History-Info
header information in a secure manner using the AIIHB 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.
10. IANA Considerations
This document defines a new MIME Content-Disposition disposition-type
value of 'aiihb'. This value is reserved for MIME bodies that
contain an authenticated inserted header, as described in section 3.
Normative References
Barnes Expires - December 2003 [Page 7]
SIP Secure Identity Header Insertion June 2003
[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.
[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", draft-iab-sec-cons-03.txt, Work in
Progress, February 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-
00.txt, Work in Progress, June 2003.
Acknowledgements
Barnes Expires - December 2003 [Page 8]
SIP Secure Identity Header Insertion June 2003
Author's Address
Mary Barnes
Nortel Networks
2380 Performance Drive
Richardson, TX USA 75022
Phone: 1-972-684-5432
Email: mbarnes@nortelnetworks.com
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 - December 2003 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 03:51:48 |