RE: [Sip] Re: REFER security

["Arunachalam Venkatraman" <arunvenk@cisco.com>]

Is it possible for a sniffer to use the INVITE/200 exchange between A & B to
construct such a INVITE to B that replaces the call from A to B? Since there
are no pre-shared secrets, this appears to be a possibility.


-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
Jonathan Rosenberg
Sent: Sunday, March 17, 2002 7:01 PM
To: Rohan Mahy
Cc: William Marshall; sip@ietf.org
Subject: Re: [Sip] Re: REFER security




Rohan Mahy wrote:
>
> On Thu, 14 Mar 2002, William Marshall wrote:
> > The issue that I raised with REFER security during its last-call
> period
> > last year was the inability of the transfer-target to authenticate
> > the Referred-By header with the transferor.  While there may be
> > an authenticated relationship between the transferee and the
> transferor
> > (established by an INVITE, and used by the REFER), and an
> authenticated
> > relationship between the transferee and the transfer-target
> (established by
> > the REFER-initiated INVITE), there is no way for the transfer-target
> > (i.e. UAS in the second INVITE) to verify that the transferor really
> > did send a REFER to the UAC.
>
> Then you are discussing the security of cc-transfer, not the security of
> REFER.  This doesn't mean we don't need a solution, but figuring out how
> to trust a header in an INVITE doesn't exactly seem like a job for the
> document that defines REFER.

Certainly, more things than cc-transfer would benefit from a capability
like this. I think the general problem is a mechanism for A to indicate
to B a piece of information (a sip fragment or full sip mesage) which is
signed by a third party. Such a mechanism is arguably orthogonal to both
REFER and cc-transfer. If it existed as a standalone specification, it
would probably be handled as a MAY kind of reference in REFER, with more
details provided in the cc-transfer spec.

One way to accomplish it is with S/MIME. A request can contain fragments
with third party signatures. In fact, S/MIME with self-signed certs
works REALLY well for cc-transfer. Consider the scenario where A calls
B. A provides a self-signed cert in the INVITE, as does B in the 200 OK.
Now, they are in a call. A sends a REFER to C. This REFER has a BIG
Refer-To URI for B that contains, as a URI parameter, an SMIME body that
is a signature over the To, From, Call-ID of the dialog between A and B.
In the triggered INVITE from C, this signed body is included. When B
receives the triggetred INVITE, it accepts it (remember, it has a
Replaces header) only if its signed with the same key provided by A for
that dialog.

The benefit of this approach is that it doesn't require any pre-shared
secrets, no PKI, and allows for excellent assurance that the dialog is
being replaced by a triggered REFER from the peer in the dialog.

More details needed, but thats the general idea.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip