Subject: [Sip] Comments on 3pcc

From: "Sriram Parameswar"<[email-masked]>
Date: Wed, 15 May 2002 18:47:34 -0500

Hi All,

Additional comments/nits on the 3pcc :

1) Call Flow - Figure 7: ACK missing after (7)-the 200 OK to A.

2) Figure 11 uses the c=0 mid call - I assume that this is the "blackhole
SDP" (c= line has an IP address 0.0.0.0). The offer-answer draft allows the
use of this type of SDP only in the initial offer quote "However, it can be
useful in an initial offer when the offerer knows it wants to use a
particular set of media streams and formats, but doesn't know the addresses
and ports at the time of the offer." which is not the case here. Should we
consider having the controller sending the Called Party an INVITE with a
a=inactive SDP attribute for every media stream involved?

3) Figure 8 - is it valid for Party A to offer early media when the INVITE
came in with no media lines?? 

4) Fig 11: The RTP session (10) should be shown bi-directional.

5) Section 9.2 - Change "This is an instantiation of Flow II" to read "This
is an instantiation of Flow I". Remove the need for HTTP and have the Media
Server send BYE when its done.

6) Security question on section 11: Given that 3pcc will be used for things
like 'click-to-call, when I am browsing the web, how will I configure my UA
to have credentials of potentially arbitrary controllers on the Internet.
Using Certificates is definitely a better recommendation here.

7) General nits:
	* section 4.2 "generatea" to "generates"
	* section 4.3 "A thid flow" to "A third flow"
	* section 4.4 "manipuldations" to "manipulations"
	* section 6 "participant instead A call" to "participant instead. A
call"
	* section 8 "Third aty" to "Third party"

Regards,

Sriram
__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 May 2002 11:10:07 -0400

Thanks for your comments. Responses inline.

> 1) Call Flow - Figure 7: ACK missing after (7)-the 200 OK to A.

Fixed.

> 
> 2) Figure 11 uses the c=0 mid call - I assume that this is the
> "blackhole SDP" (c= line has an IP address 0.0.0.0). 

Yes. 

> The offer-answer
> draft allows the use of this type of SDP only in the initial offer quote
> "However, it can be useful in an initial offer when the offerer knows it
> wants to use a particular set of media streams and formats, but doesn't
> know the addresses and ports at the time of the offer." which is not the
> case here. Should we consider having the controller sending the Called
> Party an INVITE with a a=inactive SDP attribute for every media stream
> involved?

No, since it would still end up sending RTCP, which is not what you
want. c=0.0.0.0 is the right thing here. The text in offer/answer is not
normative; it doesn't forbid its use in other cases. 

> 
> 3) Figure 8 - is it valid for Party A to offer early media when the
> INVITE came in with no media lines??

It wants to use early media, but can't. Thats why it returns the 183
with no media lines. When the UPDATE comes, it will be able to provide
session information for the actual early media. 

> 4) Fig 11: The RTP session (10) should be shown bi-directional.

Yeah, my tool doesn't do bidirectional arrows.... I'll use .....

> 
> 5) Section 9.2 - Change "This is an instantiation of Flow II" to read
> "This is an instantiation of Flow I".

Fixed.

> Remove the need for HTTP and have
> the Media Server send BYE when its done.

I made this change as well, as per my other note.

> 
> 6) Security question on section 11: Given that 3pcc will be used for
> things like 'click-to-call, when I am browsing the web, how will I
> configure my UA to have credentials of potentially arbitrary controllers
> on the Internet. Using Certificates is definitely a better
> recommendation here.

I must admit that the security considerations section is weak and needs
some more work. Generally, the problem is that anything where a third
party involved is inherently more complex. Add that to the fact that end
user authentication, even for first person calls, is quite hard, and its
a nasty problem.

It might make more sense to consider the problem as a few sub-cases:

Case A: For many applications, the controller and one of the parties in
the call are within the same administrative domain. A classic example is
click-to-dial. The controller and the customer service rep are both
within the domain of the company provided the c2d service. As such, it
is not unreasonable for the controller to actually possess a client cert
authenticating itself as sip:[email-masked], which is the
same thing it would put into the From field of the INVITE to the end
user. No shared secrets are needed, and no special configuration at the
end user's machine. Thus, there is a pretty good story here. 

Case B: The controller is an independent entity from either of the
parties in the call. I agree its unreasonable to expect that the end
users will have shared secrets with the controller, but it depends on
the application. I think that ultimately, the identity work being
carried out right now might help here. Effectively, this is a case where
a trusted third party is trying to deliver a call to some user B, with
an identity it asserted (that of user A). In this case, the identity of
user A is not determined through sip authentication, but rather, through
the fact that this is a 3pcc call and the controller vouches for the
fact that the other party is who the controller asserts it to be.
Actually, I think this fits very nicely into the identity work. The best
I can do here, to avoid dependencies, is to speak generally about
asserted identities.

So, here is the new text I propose for the security considerations
section:

\section{Security Considerations}

\subsection{Identity}

The principal security consideration with third party call control is
identity. When the
controller initiates the call, what identity does it place in the From
field of the INVITE? The controller could indicate that the call is
from itself (From: sip:[email-masked]), but the call is really
from some user, and is just facilitated by the controller. This
impacts on how the call is authenticated by the end users.

There are many cases, and the right one depends on the application of
3pcc. In one common scenario, the controller is acting on behalf of
one of the participants in the call. A typical example is
click-to-dial, where the controller and the customer service
representative are run by the same administrative domain. Indeed, for
the purposes of identification, the controller can legitimately claim
to be the customer service representative. In this scenario, it would
be appropriate for the INVITE to the end user to contain a From field
identifying the customer service rep, and authenticate the request
using S/MIME signed by the key of the customer service rep (which is
held by the controller). 

In other situations, there is no real relationship between the
controller and the participants in the call. In these situations,
ideally the controller would have a means to assert that the call is
from a particular identity (which could be one of the participants, or
even a third party, depending on the application), and to validate
that assertion with a signature using the key of the controller.

\subsection{End-to-End Encryption and Integrity}

With third party call control, the controller is actually one of the
participants as far as the SIP dialog is concerened. Therefore,
encryption and integrity of the SIP messages, as provided by S/MIME,
will occur between participants and the controller, rather than
directly between participants. 

>         * section 6 "participant instead A call" to "participant
> instead. A call"

All fixed.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip