Hi, folks,
Forgive me as newbbie. Which RFC(s) and draft(s) address the
mechanism(s) of
sending calling card info (such as usernames, passwods) as DTMF
tones in the
media path and its security mechanims? much appreciated,
Best Regards,
e
On 6/7/07, Lakshminath Dondeti <ldondeti@xxxxxxxxxxxx > wrote:
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
>