RE: Additional use cases? (Re: Plan for moving forward)

["Francois Audet" <audet@xxxxxxxxxx>]

I agree with Eric.

More on the "it doesn't matter who is the caller" stuff:

On the RFC 4474 side, RFC 4474 allows for the sender of the request
to provide the identity assertion. Yes, indeed, this is the calling
party.

There is no "response" identity. However, the callee may send its own
request in 
the reverse direction to provide it's own identity, as per 
draft-ietf-sip-connected-identity-05.txt. 

In other words, in SIP also there is no implied "direction" to this,
even if 
technically, the origin of the protocol used a client/server model (as
in,
request/response).

I think we'll have to write up a "high level" description on how these
pieces
fit together.

> -----Original Message-----
> From: owner-ietf-rtpsec@xxxxxxxxxxxx 
> [mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] On Behalf Of Eric Rescorla
> Sent: Thursday, June 07, 2007 06:28
> To: Lakshminath Dondeti
> Cc: Dan Wing; ietf-rtpsec@xxxxxxx; 'Sam Hartman'; 'Tim Polk'; 
> jon.peterson@xxxxxxxxxxx
> Subject: Re: Additional use cases? (Re: Plan for moving forward)
> 
> 
> At Wed, 06 Jun 2007 22:41:34 -0700,
> Lakshminath Dondeti wrote:
> > I guess I talked about the generic case a few times, so let's start 
> > with an example.  Consider the use case of using calling cards
> > 
> > Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
> > (Calling card Server).
> > 
> > Case 1: Uma registers Alice as an authorized phone with Bob.  The 
> > current model of DTLS-SRTP works (although it reverses the 
> > client-server relationship).
> 
> Why does this reverse the client-server relationship?
> 
> 1. DTLS-SRTP requires that both sides have certificates, but 
> EITHER side can have a self-signed cert or a third-party 
> cert. This is true no matter which side is client or server. 
> 
> 2. The client-server relationship in DTLS-SRTP is actually 
> independent of who is the caller. It's controlled by 
> passive/active attributes in the SDP. In general, it's 
> attractive for the answerer to be the client, purely for the 
> performance reason that if you're not using ICE you want the 
> ClientHello to be sent immediately to minimize RTTs.
> [With ICE, the performance issues are more complicated and 
> depend on which side is controlling and whether you are doing 
> aggressive or regular nomination].
> 
> 
> > Case 2: Alice is any SIP Phone and Uma makes a call using 
> it.  Uma may 
> > accept Bob's identity asserted through the SIP infrastructure, but 
> > wants to authenticate via a secure channel established with Bob 
> > authenticated and Uma will authenticate by sending calling card 
> > information (username, password, or just password) as DTMF tones in 
> > the media path.  (Note: Uma may not necessarily trust Bob's 
> identity 
> > asserted through the SIP
> > infrastructure.)
> >
> > Case 3: Bob's identity is asserted in the media path and Uma enters 
> > the calling card information as DTMF tones in the media path.
> >
> > In other contexts, the terms user-identity and device-identity have 
> > also been used.
> > 
> > Note that priority call placement use case is similar.
> 
> I don't understand why you think that any of these cases 
> presents a problem. 
> 
> You just do the ordinary SIP-Identity + DTLS-SRTP handshake, 
> which are all about protecting the signalling channel and 
> binding it to the media and then you pass the DTMF or 
> whatever in the media. This works fine.
> 
> -Ekr
> 
> 
>