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

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




Apologies for letting my frustration get the better of me over the weekend folks.

Thanks for your note Dan. I have been busy over the past few days and hence the delay in responding to you.

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

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.

regards,
Lakshminath

On 6/4/2007 11:08 PM, Dan Wing wrote:
On 6/2/2007 10:36 AM, Eric Rescorla wrote:
At Sat, 2 Jun 2007 10:29:56 -0700,
Totally agree. I'm just saying that we ought to think of the authentication as happening in the signalling and being transferred into the media. We should try to avoid having authentication mechanisms which authenticate only the media and not the signalling.
Why? If we apply this to other use cases, this is akin to saying that we ought to tie access authentication to end-to-end secure communication.
What other uses cases?

This group is about keying secure RTP sessions that are set up via SIP. In that context, SIP is the layer at which identities
are meaningful and end-to-end secure communication is about
leveraging those identities into the provision of secure media.
Hmmm, that's one model. But, why do those two layers have to be tied so strongly?

Because the media layer needs the signaling layer, or else it
doesn't exist.

The signaling layer (SIP, RTSP, what have you) is necessary for
the media layer.  There isn't any way to create a media layer
without signaling -- you need to signal your transport address (without it, you can't get media).
I can see the point that in case of SIP, communicating parties may choose to use identities asserted in the signaling path.
I'm not sure what you mean by "asserted". The identities or only relevant in the signalling path. What's needed here is that
the media path setup makes sure you're talking to the same entities.
There may be an identity relevant within the local domain and another end-to-end.

Ok, I can see that.  I could be 001234 locally (employee number)
and dwing@xxxxxxxxx end-to-end.

The sense I am getting is that we will just have to establish DTLS-SRTP session using the SIP-level identity and then use other means to prove the second identity. It looks like we will also have to live with arbitrary notions of client-server relationships in each session.

Can you throw a use-case bone over the wall for everyone to chew on?

-d