Internet DRAFT - draft-polk-sipping-e2e-sec-assurance
draft-polk-sipping-e2e-sec-assurance
SIPPING Working Group James Polk
Internet-Draft Cisco Systems
Expires: Jan 11th, 2006 July 11th, 2005
Requirements for Assured End-to-End Signaling Security
within the Session Initiation Protocol
draft-polk-sipping-e2e-sec-assurance-00
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 January 11th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Session Initiation Protocol (SIP) has existing mechanisms for
securing its signaling messages. SIP has several transport
layers it works across: TCP, UDP, SCTP, and TLS over TCP. There
currently is no mechanism to ensure that if TLS over TCP is chosen
by the originating UAC, the messaging will remain encrypted on a
hop-by-hop basis to the destination UAS. This document discusses
this scenario, providing the requirements for such to exist, and
offering pieces of a possible solution for this set of requirements.
Polk Expires January 11, 2006 [Page 1]
Internet-Draft SIP E2E Assured Signaling Security Jan 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions used in this document . . . . . . . . . . . . 3
2. Rationale for E2E Signaling Security . . . . . . . . . . . . 4
3. Requirements for E2E Security in Signaling . . . . . . . . . 4
4. High Level Offering at a Solution . . . . . . . . . . . . . . 5
4.1 Step 1 to High Level Offering . . . . . . . . . . . . . . 5
4.2 Step 2 to High Level Offering . . . . . . . . . . . . . . 6
4.3 Rejection Response from Intermediary . . . . . . . . . . 7
5. Diagrams for Discussion . . . . . . . . . . . . . . . . . . . 7
5.1 Diagram for Discussion Involving 3 Domains . . . . . . . 7
5.2 Diagram for Discussion Involving >3 Domains . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1 Normative References . . . . . . . . . . . . . . . . . . 9
8.2 Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10
1. Introduction
The Session Initiation Protocol (SIP) has many mechanisms for
securing its signaling messages. SIP also has several transport
layers it works across: TCP, UDP, SCTP, and TLS over TCP. According
to RFC 3261 [RFC3261], these transport layers can change per SIP
element hop through an infrastructure. Most of the time, this is a
valuable capability, as SIP elements would know best (or at least
better) which transport layer is more appropriate given the level
of service that element wants or needs to provide than the UAC
would. However, there can be cases in which a user agent wants to
ensure its messages are transmitted with end-to-end security even if
they require a hop-by-hop nature for message routing and other
services to be offered by the underlying infrastructure in place.
Currently this is not possible within SIP. SIP does have the ability
to encrypt message bodies using S/MIME, but this does not address
encrypting message headers from source to destination. SIP
necessitates hop-by-hop view and modifications to certain headers to
succeed.
In this hop-by-hop nature of SIP, a UAC can have a false sense of
security if it originates a transaction using TLS (or IPsec for that
matter) and the first hop Proxy (or any SIP intermediary along the
path) changes the transport layer from TLS to merely UDP, TCP or
SCTP. SIP intermediaries have no means to inform the UAC of this
change even if one wanted to.
At the same time, if the last hop proxy/intermediary changes
transport layers to TLS - whether the UAC initiated TLS or not - the
Polk Expires January 11, 2006 [Page 2]
Internet-Draft SIP E2E Assured Signaling Security Jan 2006
UAS implicitly believes the entire messaging path was secure - when
in fact the only known hop that was secure was the last hop towards
the UAS.
This document should not address cases in which the UAC did not
transmit over TLS initially, even if as the results of a 407 (Proxy
Authentication Required) challenge adjusting the transport layer to
TLS from one of the other offerings; as that challenge is intended
to provide integrity protection of the authorization header to that
specific Proxy, and not beyond. This should only apply to SIP
messages from UACs that initiate TLS by the user's choice/
configuration for that flow of messages.
This document cannot account for SIP elements that wish to lie about
the security status of a message. That said, this document can
provide the necessary indications for an agreement to exist between
two or more entities that the transit element or receiver did indeed
comply with the agreement for securing the signaling when the
message was processed.
This document discusses the requirements for such a security
assurance to the user agent client (UAC) of a SIP message flow that
its messages remained encrypted on a hop-by-hop basis to the
destination user agent server (UAS).
Although this document frequently discusses securing SIP signaling
messages as using TLS (because RFC3261 made its implementation
mandatory for SIP), IPsec is another optional means of securing SIP
messaging hop-by-hop. To keep from repeating the two options over
and over again, for the most part, TLS will be written from now on -
even though either is functionally the same in this document's
context.
[RFC3261] provides the means for hop-by-hop encryption, but also the
ability to change the transport layers per hop. There are strong
hints at maintaining TLS (a SIPS URI) if it is received along a
message path. This document wants to make sure that is more robust.
[RFC3329] provided the agreement of security only between the UAC
and its first hop proxy.
[RFC3840] provides a means for a UAC to convey its preference for
message handling, but did not cover other than to state the SIPS URI
should be used if the UAC does not want caller preferences to be
viewed by any element other than the SIP Server. This effort does
(pretty much) that, and it should be discussed as to whether this is
an extension of the caller prefs efforts, or is independent of it.
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
Polk Expires January 11, 2006 [Page 3]
Internet-Draft SIP E2E Assured Signaling Security Jan 2006
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in [RFC2119].
2. Rationale for E2E Signaling Security
User's (through their user agents) should not implicitly trust that
just because the first hop was secured using TLS (or IPsec), the
message remained secure from unwanted observation from that SIP hop
element to the destination SIP element. Nothing written here can or
should prevent jurisdictions from viewing what the local law allows
them to view within the messages, but this document can take the
assurance a user has for secure communications one step further
towards this theme:
"If I encrypted a SIP message, I want to know if it remained
encrypted in transit (between SIP elements) all the way to who I
wanted to contact with that message. If it did not, I want to
know it did not."
If, by chance, the first and last hops a message took were encrypted
along its path, there is no means to know if a message was in
cleartext in between those two SIP intermediaries.
3. Requirements for E2E Security in Signaling
Here is a set of requirements for consideration to achieve the goal
of informing the UAC that a message sent by it was processed
successfully by a SIP intermediary along the SIP path to the
destination UAS and the transport layer was changed from TLS to
something else not secure:
Req#1 - a user agent client that sets the transport layer of a SIP
message to TLS over TCP MUST be assured that message
arrived at the destination user agent server using TLS over
TCP
Req#2 - there MUST be a means within a SIP message to indicate "TLS
over TCP is mandatory" in the processing of the message
towards the next SIP element
Req#3 - this indication that "TLS over TCP is mandatory" within a
SIP message MUST be readable, MAY be added, but MUST NOT be
modified in message processing by SIP intermediaries
Req#4 - whenever this "TLS over TCP is mandatory" requirement in a
SIP message cannot be met, a rejection indication MUST be
sent conveying this rejection. The rejection indication
SHOULD convey exactly why the message is being rejected.
Polk Expires January 11, 2006 [Page 4]
Internet-Draft SIP E2E Assured Signaling Security Jan 2006
NOTE to Req#4 - the author is not sure what to do if this indication
was added by an intermediary in the path of the message and a
SIP element further downstream cannot or will not support the
indication. Does the intermediary swallow the message and
formulate another one the downstream element can support? Or,
does the injecting intermediary react with a new SIP request
message not mandating TLS?
As this document was written fairly quickly, with little time to
coordinate with others within the SIP community, additional
requirements can be added and the above modified based on
discussions within the WG.
4. High Level Offering at a Solution
Here is a list of steps that can be taken to satisfy the
requirements listed above as is. If those requirements change,
whether through modification or addition, this offered (high level)
solution will have to change as well.
Obviously, discussion is necessary on this general idea.
4.1 Step 1 to High Level Offering
An obvious means for identifying a certain mandatory handling of SIP
messages is through the use of the Proxy-Require header. Since
there is no current value to indicate end-to-end signaling security,
one would have to be created. For example:
Proxy-Require: e2e-sec
This would satisfy Req#2 above which calls for an indication within
the SIP message that it is to be treated in a certain way. This
header/option-tag indicates to the receiving SIP element to
continue with the transport layer security which was received from
the previous hop SIP element.
The Proxy-Require header is visible to the processing of SIP
intermediaries, satisfying Req#3 above. This header and option-tag
MUST be readable by SIP intermediaries. The header (or option-tag)
MAY be added by any SIP intermediary to a message it does not exist
in. This header and its option-tag MUST NOT be modified or
deleted by any SIP intermediary during processing and transmission.
This satisfies Req#4 from above.
If the UAC wants to inform the destination UAS it originated TLS
over TCP for this message, SIPFRAG [RFC3420] SHOULD be used to hide
this fact from all intermediaries that may modify or delete the
Proxy-Require and/or Require header, including its option-tag(s).
NOTE - The author is not sure how to address the likelihood that the
Polk Expires January 11, 2006 [Page 5]
Internet-Draft SIP E2E Assured Signaling Security Jan 2006
Proxy-Require header (meant for Proxies only) will not satisfy
all SIP intermediaries, and that the additional "Require"
header will have to also be present in the SIP message from the
UAC to satisfy B2BUAs and BCs in the signaling path. This
appears to be redundant, yet perhaps necessary.
4.2 Step 2 to High Level Offering
Although this may meet with some amount of controversy, one means of
providing the necessary indications per hop back to the UAC is to
create implicit subscriptions based on the Proxy-Require header
option-tag: "e2e-sec" just being in the Request message.
This would mandate that each SIP intermediary compliant with this
specification send a one-time NOTIFY to the UAC that it complied
with the request that the message be forwarded as requested
(encrypted) for that hop it controlled.
The UAC would be aware of these NOTIFY messages coming and create a
state table, waiting for the successful Response to the Request
message it sent. If could be possible that these NOTIFY messages
are sent to a remote server from the UAC and a combined single
NOTIFY is sent to the UAC from this server the UAC trusts.
The tuple within the NOTIFY with the same Call-ID, to and from and
tags from the original Request message should suffice as
identification to the UAC which Request message these NOTIFY
messages are associated to.
The subscription need not be long lasting - therefore it is not
foreseen it should last longer than it takes the SIP intermediary to
complete the NOTIFY transaction.
Either the UAC could implicitly trust all the NOTIFY messages that
were sent, or there could be a means of the UAS for informing the
UAC which intermediaries the message transited. This could be
accomplished as part of the XML of the NOTIFY message from the UAS
to the UAC, or it could be part of a new header that lists all the
SIP intermediaries the UAS is aware of from the VIA headers in the
Request message. The UAS could take all the intermediary's URIs and
build this new header's header values (similar to a Route header)
and return that in a 200 OK of the original transaction. An example
could be:
Hop-Record: server1.atlanta.example.com,
server10.atlanta.example.com,
bigbox3.biloxi.example.com
for the 3 Proxies the original SIP Request traversed from the VIA
headers received by the UAS. No order is likely necessary.
Polk Expires January 11, 2006 [Page 6]
Internet-Draft SIP E2E Assured Signaling Security Jan 2006
This listing of the SIP elements by URI in the 200 OK would give the
UAC receiving such a message the necessary information to match
against all the tuple matching NOTIFY messages it received for that
Request message and compare to see if all the SIP element URIs had
positive indications indicated in their NOTIFY message to that UAC.
If the list matched, the UAC can know as best as possible that the
original Request message transited to the UAS encrypted all the way.
If the list doesn't match, it will know that something went wrong -
but that the UAS still received the request message.
If the list contained in this new header in the 200 OK matches the
list of received NOTIFY messages from SIP intermediaries, this
satisfies Req#1 above.
NOTE - The author doesn't know what to do about this list of
intermediaries in the 200 OK being inconsistent with the list
of NOTIFY respondents, divulging that there are more SIP
elements that were present in the UAS's response. This
c/should lead the UAC to conclude there are intermediaries
acting as B2BUAs or BCs between it and the UAS. This is
topology information the UAC might not have the privilege to
know otherwise. This is a potential security risk with this
solution.
4.3 Rejection Response from Intermediary
Section 8.1.3.5 of [RFC3261] states clearly that the proper
rejection indication to an unsupported extension to SIP is a 420
(Bad Extension) Response accompanied with an Unsupported Header
listing all extensions not supported by that SIP element; this
includes Proxy-Require and Require header option-tags. This
satisfies Req#4 above.
5. Diagrams for Discussion
For early discussions of the document, please consider the following
two layer 7 diagrams for those discussions:
5.1 Diagram for Discussion Involving 3 Domains
____________ _____________________ ____________
| | | | | |
| UAC -- PS1 --- PS2 --- PS3 --- PS4 --- PS5 -- UAS |
|____________| |_____________________| |____________|
Domain 1 Domain 2 Domain 3
Figure 1. 3 Domain Diagram
- Alice is the user of the UAC.
Polk Expires January 11, 2006 [Page 7]
Internet-Draft SIP E2E Assured Signaling Security Jan 2006
- Bob is the user of the UAS.
- PS1 is the outbound Proxy for the UAC.
- PS5 is the inbound Proxy for the UAS.
- PS2, PS3 and PS4 are within the same domain (separate from
PS1 and PS5
5.2 Diagram for Discussion Involving >3 Domains
Consider the following layer 7 diagram for discussion:
____________ _____ _____ _____ ____________
| | | | | | | | | |
| UAC -- PS1 --- PS2 --- PS3 --- PS4 --- PS5 -- UAS |
|____________| |_____| |_____| |_____| |____________|
Domain 1 Domain 2 ^ Domain 4 Domain 5
Domain 3
Figure 2. 5 Domain Diagram
- Alice is the user of the UAC.
- Bob is the user of the UAS.
- PS1 is the outbound Proxy for the UAC.
- PS5 is the inbound Proxy for the UAS.
- PS2, PS3 and PS4 are each in separate domains (and separate
from PS1 and PS5)
6. IANA Considerations
This document makes no request of the IANA at this time.
If this document progresses further to the SIP WG for extensions to
the SIP protocol as is, the Proxy-Require and Require header
option-tag "e2e-sec" and the header "hop-record" (with no option-
tags) will be called out here for registration.
Modifications to this document will modify this section.
7. Security Considerations
This document attempts to address a security hole within the SIP
architecture, but probably opens up more security holes in its
present form.
Providing the possibility of a topology view of an infrastructure
between a UAC and UAS could reveal SIP elements that would otherwise
know be known to that endpoint. This could be of concern to the
UAC's home network administrators.
Part of the High Level solution offered here creates implicit
Polk Expires January 11, 2006 [Page 8]
Internet-Draft SIP E2E Assured Signaling Security Jan 2006
subscriptions back to a UAC that doesn't have a relationship with
each SIP intermediary along a message path. Asking that each
intermediary send a NOTIFY message back to the UAC opens up a means
of both:
- overloading the UAC with NOTIFY message (although there will not
be that many packets send overall)
- provides each intermediary a target endsystem to send packets to
The latter of the two above could lead to abuse (a point of attack)
or a security hole.
8. References
8.1 Normative References
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag",
RFC 3420, November 2002.
8.2 Informative References
[RFC3329] J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka,
"Security Mechanism Agreement for the Session Initiation
Protocol (SIP)", RFC 3329, January 2003
[RFC3840] J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol", RFC
3840, August 2004
Author's Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Fax: none
Email: jmpolk@cisco.com
Polk Expires January 11, 2006 [Page 9]
Internet-Draft SIP E2E Assured Signaling Security Jan 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 (2005). 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.
Polk Expires October 29, 2005 [Page 10]
