Network Working Group R. Sparks
Internet-Draft dynamicsoft
Expires: October 2, 2002 April 3, 2002
Securing REFER - Options discussed at IETF53
draft-sparks-sip-sec-options-00
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 October 2, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo documents and expands on the discussion on securing REFER
at the IETF53 SIP meeting. It explores several possible solution
mechanisms with rough discussion of the pros and cons of each. This
memo proposes futher development of an S/MIME based solution.
Sparks Expires October 2, 2002 [Page 1]
Internet-Draft Securing REFER - Options April 2002
Table of Contents
1. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Where Should The Problem be Solved? . . . . . . . . . . . . . 4
3. Possible Mechanisms . . . . . . . . . . . . . . . . . . . . . 5
3.1 Remove Referred-By . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Use Referred-By Generic Parameters . . . . . . . . . . . . . . 5
3.3 Reuse HTTP-like Authentication . . . . . . . . . . . . . . . . 5
3.4 Use S/MIME Body Parts . . . . . . . . . . . . . . . . . . . . 7
3.5 Have C Contact A Directly . . . . . . . . . . . . . . . . . . 10
4. Proposed Path Forward . . . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
Sparks Expires October 2, 2002 [Page 2]
Internet-Draft Securing REFER - Options April 2002
1. The Problem
In the simplest REFER scenario, A sends a REFER to B, triggering a
request from B to C. In the current specification of REFER, the
triggered request may contain information from A in the form of a
Referred-By header. When B sends this header to C, B is saying "I'm
sending this request because A asked me to". It is dangerous for C
to use this information in its current form as there is nothing
preventing B from modifying or completely falsifying the information.
---------------------------------------------------------------------
REFER sip:B
Refer-To: sip:C INVITE sip:C
+-+ Referred-By: <sip:A> +-+ Referred-By: <sip:A> +-+
|A|--------------------------------->|B|------------------------------>|C|
+-+ +-+ +-+
Simple REFER Scenario
---------------------------------------------------------------------
If the user or the user-agent at C uses the information in the
Referred-By header as an input to processing the INVITE, B can
provide arbitrary information to influence that processing in a
manner favorable to B.
---------------------------------------------------------------------
INVITE sip:C
+-+ Referred-By: <sip:BossOfC> +-+
|B|----------------------------------------->|C|
+-+ +-+
B Abusing Referred-By
---------------------------------------------------------------------
One expected use of the Referred-By header is presentation of its
content to the user at C, allowing that user to accept or reject an
INVITE based on its value. If B knows the user agent at C will
behave this way, B can place appropriately misleading content in the
Referred-By header. Some examples of misleading content are
o sip:audits@irs.gov
Sparks Expires October 2, 2002 [Page 3]
Internet-Draft Securing REFER - Options April 2002
o sip:unclaimed-prizes@lottery.state.tx.us
Furthermore, by including a Referred-By header, B is making the claim
that it was asked to make this particular request by the party
identified in the Referred-By header. If B knows A and C are in a
call and has captured some of the dialog state for that call, B could
send something along the lines of
INVITE sip:C
Referred-By: <sip:A>
Replaces: 1234@A;to-tag=5678;from-tag=abcd
C has no mechanism to verify that this INVITE was formed at A's
behest.
The problem is that B is making a claim to C about A and C has no
mechanism to verify that the claim has not been falsified. Our
choices are to
o Forbid C from taking action based on that information
o Remove the mechanism that allows B to make claims about A
o Provide a mechanism for C to verify B's claims
Forbidding C from taking action on the information renders the
information useless. It is functionally equivalent to removing the
information except for the extra wasted bytes of transmission.
Removing or protecting the information is explored below.
2. Where Should The Problem be Solved?
If we provide a mechanism to protect the information A passes to C
through B, in what document do we specify that mechanism? The choices
range through:
o Providing a transfer specific mechanism in the transfer draft
o Providing a mechanism in the REFER draft that all clients of REFER
can reuse
o Solving the general problem of passing authorization tokens
through intermediaries
Group consensus appears to be to provide a REFER specific mechanism
in the REFER draft.
Sparks Expires October 2, 2002 [Page 4]
Internet-Draft Securing REFER - Options April 2002
3. Possible Mechanisms
3.1 Remove Referred-By
If we remove the Referred-By header from the REFER specification,
this problem goes away. Without Referred-By, B can not make any
claims about A and C cannot be duped into making bad choices based on
those claims.
There are applications of REFER for which this is satisfactory. In
particular, in many transfer scenarios, C doesn't care who A is or if
an A even exists. Existing telephony systems supporting a transfer
concept do not provide _any_ information about A to C.
On the other hand, there is a desire to provide more functionality
than what existing telephony systems offer. In addition to providing
A's identity to C, several imlementors have envisioned using the
Referred-By contents as a form of authorization token. Application
decisions (such as whether or not to replace a call with another)
would be based on the contents of this header.
3.2 Use Referred-By Generic Parameters
Earlier versions of cc-transfer defined a PGP mechanism for signing
the contents of the Referred-By header. It required including the
Refer-To URL and a timestamp in that header before signing. C used
this information as proof of A's identity and proof of what A asked B
to do. SIP's PGP mechanisms were deprecated, and this capability was
removed from the REFER proposal.
One option is to pursue a variation of this mechanism. The downside
of this approach is having to invent more mechanics than we would
following one of the other approaches.
3.3 Reuse HTTP-like Authentication
We could reuse SIPs DIGEST Authentication to prove A's identity to C.
For this to work, C would need to challenge A using B as an
intermediary. A and C would also have to share a password.
When C receives a request with a Referred-By header, but insufficient
proof of its sender's identity, it can send an error response with a
challenge. For discussion, suppose we defined a new 4xx Authenticate
Referror response and a Refer-Authenticate header. B would forward
this challenge to A in his NOTIFY to A that the REFER failed. A
would then send a second REFER adding a response to the challenge.
The flow might look like this:
Sparks Expires October 2, 2002 [Page 5]
Internet-Draft Securing REFER - Options April 2002
---------------------------------------------------------------------
A B C
| F1 REFER | |
|------------------------------------>| |
| F2 202 Accepted | |
|<------------------------------------| F3 INVITE |
| |--------------------------------->|
| | F4 4xx Authenicate Referror |
| F5 NOTIFY |<---------------------------------|
|<------------------------------------| |
| F6 200 OK | |
|------------------------------------>| |
| F7 REFER | |
|------------------------------------>| |
| F8 202 Accepted | |
|<------------------------------------| F9 INVITE |
| |--------------------------------->|
| | F10 200 OK |
| F11 NOTIFY |<---------------------------------|
|<------------------------------------| F12 ACK |
| F13 200 OK |--------------------------------->|
|------------------------------------>| |
| | |
| | |
Excerpts of messages:
F1 REFER sip:B SIP/2.0
Refer-To: sip:C
Referred-By: <sip:A>
F3 INVITE sip:C SIP/2.0
Referred-By: <sip:A>
F4 SIP/2.0 4xx Authenticate Referror
Refer-Authenticate: DIGEST realm="C",nonce=...
F5 NOTIFY sip:A SIP/2.0
Content-Type: message/sipfrag
4xx Authenticate Referror
Refer-Authenticate: DIGEST realm="C",nonce=...
F7 REFER sip:B SIP/2.0 (Note 1)
Refer-To: sip:C?Authentication=DIGEST realm="C",response="EA42...
Referred-By: <sip:A>
Sparks Expires October 2, 2002 [Page 6]
Internet-Draft Securing REFER - Options April 2002
F9 INVITE sip:C SIP/2.0
Authentication: DIGEST realm"C",response="EA42...
Referred-By: <sip:A>
(Note 1) URI shown improperly escaped for readability
Challenging a REFERred request
---------------------------------------------------------------------
The most obvious disadvantage of this approach is that B is
intrinsically positioned to launch a man-in-the-middle attack.
Careful work would need to go into this mechanism to protect against
malicious B behavior. Some of the things to discuss would be
encoding information about the original request into the challenge
(perhaps by encoding the first Referred-By into the nonce) and use of
the 2617 server authentication tools.
The next biggest disadvantage of this approach is that it proves A's
identity, but does not prove what A asked B to do. Some of the
enhanced digest work could be applied to this problem to improve the
situation.
Again, this approach relies on A and C sharing a password.
3.4 Use S/MIME Body Parts
The S/MIME mechanisms described in bis-09 for providing
authentication and message integrity protection can be extended to
provide proof of A's identity to C along with proof of what A asked B
to do. When A creates a REFER request, A can include a signed body
part containing the Referred-By and Refer-To headers. An example
flow might look like what follows:
---------------------------------------------------------------------
A B C
| F1 REFER | |
| ****************************** | |
| * Enc/Sig of REFER * | |
| * ********************** * | |
| * * Sig of * * | |
| * * Refer-To and * * | |
| * * Referred-By * * | |
| * ********************** * | |
| ****************************** | |
|------------------------------------>| |
Sparks Expires October 2, 2002 [Page 7]
Internet-Draft Securing REFER - Options April 2002
| F2 202 Accepted | |
|<------------------------------------| F3 INVITE |
| | ****************** |
| | * Sig of * |
| | * Refer-To and * |
| | * Referred-By * |
| | ****************** |
| |--------------------------------->|
| | F4 200 OK |
| F5 NOTIFY |<---------------------------------|
|<------------------------------------| F6 ACK |
| F7 200 OK |--------------------------------->|
|------------------------------------>| |
| | |
Excerpts of messages:
F1 REFER sip:B SIP/2.0
...
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
--boundary42
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
*************************************************************************
* Content-Type: message/sip *
* *
* REFER sip:B SIP/2.0 *
* Refer-To: sip:C *
* Referred-By: <sip:A> *
* ... *
* Content-Type: multipart/signed; *
* protocol="application/pkcs7-signature"; *
* micalg=sha1; boundary=boundary159 *
* *
* --boundary159 *
* Content-Type: message/sipfrag *
* *
* REFER sip:B SIP/2.0 *
* Refer-To: sip:C *
* Referred-By: <sip:A> *
* Date: <datestamp> *
* *
* --boundary159 *
* Content-Type: application/pkcs7-signature; name=smime.p7s *
Sparks Expires October 2, 2002 [Page 8]
Internet-Draft Securing REFER - Options April 2002
* Content-Transfer-Encoding: base64 *
* Content-Disposition: attachment; filename=smime.p7s; *
* handling=required *
* *
* <A's signature of the sipfrag> *
* *
* --boundary159 *
*************************************************************************
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
<A's signature of REFER request>
--boundary42-
F2 INVITE sip:C SIP/2.0
...
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary91
--boundary91
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
*************************************************************************
* Content-Type: message/sip *
* *
* INVITE sip:C SIP/2.0 *
* ... *
* Content-Type: multipart/mixed *
* boundary=boundary9215 *
* *
* --boundary9215 *
* Content-Type: application/sdp *
* *
* <B's SDP gos here> *
* *
* --boundary9215 *
* Content-Type: multipart/signed; *
* protocol="application/pkcs7-signature"; *
* micalg=sha1; boundary=boundary159 *
* *
* --boundary159 *
Sparks Expires October 2, 2002 [Page 9]
Internet-Draft Securing REFER - Options April 2002
* Content-Type: message/sipfrag *
* *
* REFER sip:B SIP/2.0 *
* Refer-To: sip:C *
* Referred-By: <sip:A> *
* Date: <datestamp> *
* *
* --boundary159 *
* Content-Type: application/pkcs7-signature; name=smime.p7s *
* Content-Transfer-Encoding: base64 *
* Content-Disposition: attachment; filename=smime.p7s; *
* handling=required *
* *
* <A's signature of the sipfrag> *
* *
* --boundary159 *
* --boundary9215 *
*************************************************************************
Using S/MIME
---------------------------------------------------------------------
This approach uses many fewer (but larger) messages than the DIGEST
challenge approach. It doesn't require A and C to share a secret.
3.5 Have C Contact A Directly
Instead of attempting to protect the information being passed through
B, we could have C contact A directly. We could use normal SIP
mechanisms to authenticate A and invent a new mechanism to ask A to
validate B's request.
Sparks Expires October 2, 2002 [Page 10]
Internet-Draft Securing REFER - Options April 2002
---------------------------------------------------------------------
A B C
| F1 REFER | |
|------------------------------------>| |
| F2 202 Accepted | |
|<------------------------------------| F3 INVITE |
| |--------------------------------->|
| F4 VERIFY |
|<-----------------------------------------------------------------------|
| F5 200 OK |
|----------------------------------------------------------------------->|
| | (alert) |
| | ... |
| | F6 200 OK |
| |<---------------------------------|
| | F6 ACK |
| |--------------------------------->|
Contact A Directly
---------------------------------------------------------------------
The biggest advantage of this approach is removing B as a man-in-the-
middle.
The biggest disadvantage is ensuring that C can reach the correct
instance of A. C can't use A's address of record since that might
not reach right UA for A. C could use the URI A provides in the
Referred-By header, but then A will be responsible for providing a
URI that will be useful to C.
If this path is pursued, the subtleties of C's VERIFY request would
need to be studied. Can C do harm to B by saying "Hey A, B over here
tells me you want me to talk to him - is that OK with you?"
4. Proposed Path Forward
The majority of feedback I've received so far is to flesh out the use
of S/MIME option. There have been a couple of people asking to
pursue the Contact A Directly option, and no vocal support for the
others.
The proposed path forward is to flesh out the S/MIME option with the
assistance of someone from the security area.
Sparks Expires October 2, 2002 [Page 11]
Internet-Draft Securing REFER - Options April 2002
References
Author's Address
Robert J. Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
EMail: rsparks@dynamicsoft.com
Sparks Expires October 2, 2002 [Page 12]
Internet-Draft Securing REFER - Options April 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sparks Expires October 2, 2002 [Page 13]