[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On 6/7/2007 5:11 PM, Francois Audet wrote:

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.
But I am saying the calling party may want the called party to authenticate first. 



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).
At the DTLS level, there is an implied direction in that client authentication is optional and server authentication is mandatory. 



I think we'll have to write up a "high level" description on how these
pieces
fit together.
As I noted earlier, we can allow the use case I am talking about. The most efficient option I have seen so far is to allow the caller to send ClientHello along with the SIP INVITE message. We can support it through other options too, but those are inefficient options. 

Lakshminath




-----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