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

["Dan Wing" <dwing@xxxxxxxxx>]

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