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

["Dan Wing" <dwing@xxxxxxxxx>]

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

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

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

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