RE: Plan for moving forward

["Dan Wing" <dwing@xxxxxxxxx>]

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