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). 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.
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.
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'shome 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, ata 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'llneed 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 thatapplies to RTPSEC. -dthanks, 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 someonepull that authentication and authorization 'back' into the originating network. The trouble with such an approach is howyou'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. -dregards, 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