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

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


On 6/12/2007 7:55 PM, Dan Wing wrote:



-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti@xxxxxxxxxxxx] Sent: Tuesday, June 12, 2007 7:00 PM 
To: Dan Wing
Cc: 'Eric Rescorla'; 'Jonathan Rosenberg'; 'Hannes Tschofenig'; 'Francois Audet'; ietf-rtpsec@xxxxxxx; 'Sam Hartman'; 'Tim Polk'; jon.peterson@xxxxxxxxxxx Subject: Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)] 

Hmm, interesting choice of words.
All I was saying was that there is a class of applications that we should be able to optimize for. Skipping client authentication during secure tunnel establishment and using a legacy method inside the secure tunnel is a mode of operation allowed elsewhere in the IETF (e.g., TTLS, PEAP, IKEv2-EAP). 

But we don't have a legacy method to authenticate an RTP endpoint
or an SRTP endpoint.
I was considering sending a PIN entered by the user, transmitted via RTP (RFC 2833), a legacy method.
However, we seem to be not allowing that with DTLS-SRTP. We mandate the client to authenticate using self-signed certs. There are use cases where that client authentication has a purpose. Elsewhere it is wasteful. Is there "harm" due to that additional requirement? I am saying why does one have to fight that battle in making a case to other standards organizations in adopting IETF protocols. I can think of simple counter arguments: do what is necessary and nothing more.
That's reasonable. But it is an optimization that saves ~600 bytes
Ah, the luxury! This reminds me of the time when a few of us were given a budget of 40 octets after some serious kicking and screaming :). Different context for sure. 

I would be happy to save some bytes during a VoIP call setup too.
or so? Or are you just trying to allow one side to ignore the certificate sent by the other (that is, don't verify it matches 
the associated a=fingerprint).
I am also looking to save any computational expense on the client (mobile phone) side, contextual of course. The client will need to verify the server's credentials. 


And as others have stated, it complicates things to optimize this.
You are well aware of the risks in complicating security protocols.


Yes, but we have the expertise too, thankfully.
Anyway, I will sign-off here on this. I am beginning to get the sense that we all understand the use case and its applicability. 

thanks Dan,
Lakshminath
The only argument against that I see so far is that DTLS-SRTP is the chosen protocol and the chosen protocol must not be changed. 

Every requirement needs justification.

-d



regards,
Lakshminath

On 6/12/2007 5:28 PM, Dan Wing wrote:
I was talking about the GETS use case. My understanding is that IEPREP is considering that use case although I did not find a call flow to point to (I don't know for sure, could someone verify that?). Perhaps others in this list may have ready references.
IEPREP's existing work excludes cross-domain authentication and authorization. In any event, I don't see how GETS/IEPREP is harmed, in any way, if the UAC is really owned by Alice Waters 
(chef at a good restaurant here in California) but, due to the
recent earthquake, a nice gentleman from FEMA is using Alice's
home phone and provides authentication to an IEPREP-capable system (whatever it is) and gets authorization to make a high-bandwidth multimedia call to someone in another city, at 
a time where mere mortals aren't able to acquire sufficient
bandwidth or SIP signaling (or whatever) to make a similar
call.

You must believe there is some potential harm with IEPREP
and the network asserting that Alice's phone was involved.
I don't see the harm.  If you still feel there is harm, we'll
need more details -- I don't see the harm and I don't see a requirement that falls out of IEPREP or a GETS use case that 
applies to RTPSEC.

-d



thanks,
Lakshminath

On 6/12/2007 4:14 PM, Dan Wing wrote:
The use case where someone dials a number and proves 
their identity

using a PIN?  One thing you mentioned at the bottom of your first
email http://www.imc.org/ietf-rtpsec/mail-archive/msg00751.html is
that "priority call placement use case is similar"; however, it
isn't -- IEPREP isn't requiring someone to connect to a remote
gateway, prove their identity to that remote gateway, and someone
pull that authentication and authorization 'back' into the originating network. The trouble with such an approach is how 
you'd get the access to perform that connection to that remote
resource in order to initiate that authorization in the first
place -- the phone system is overloaded and the more components
of it you involve the more likely you'll find overload.
and Dan was making a case for it too earlier today. 
In my email related to directionality?  That was only an idea
to avoid the SDP for directionality.

-d


regards,
Lakshminath

On 6/12/2007 12:46 PM, Eric Rescorla wrote:

At Tue, 12 Jun 2007 12:39:47 -0700,
Lakshminath Dondeti wrote:

Right.  So, why not do it?
Because it involves a number of changes in the DTLS 
model (having

one message happen out of band, having one clienthello elicit
multiple serverhellos, etc.) and nobody has described a 
compelling

reason to do this.

-Ekr