RE: Posting in support for Protcol X, Y, or Z

["Dan Wing" <dwing@xxxxxxxxx>]

> > >>I also strongly think that we need to support middleboxes in the 
> > >>network, which may need to decrypt the media. The usage of 
> > >>a solution 
> > >>which supports ONLY end-to-end is going to be very limited.
> > > 
> > >We have that captured in requirement R22 of
> > >draft-wing-media-security-requirements-01.txt:
> > > 
> > >    "R22:   A solution SHOULD support media recording."
> > > 
> > >Does draft-wing-sipping-srtp-key-00.txt meet that requirement, from
> > >your perspective?
> > 
> > Does that requirement cover transcoders, media mixers and 
> > SBCs, which
> > may terminate the media, meaning that the media will be 
> > de-encrypted,
> > and forwarded possibly using another format/codec?
> 
> Somewhat; it would depend on how each end authenticates it is talking
> to the correct device.  For example, if I was using RFC4474 and using
> DTLS-SRTP, a transcoder under the control of my enterprise could be
> invoked _before the RFC4474 signature was created_, and my enterprise
> would attest the call is coming from me (which it is, through their
> transcoder).  I expect ZRTP would fail SAS validation in this similar
> situation.  I don't know what MIKEYv2 would do.

I misspoke -- that is but one way to do it.

With draft-wing-media-security-requirements, the endpoint could 
(somehow) get a transcoder to do the transcoding, and then give the
transcoder the keys necessary to transcode.  I say "somehow" because
I don't know how the endpoint would do that -- perhaps using a media
control protocol of some flavor (mediactrl working group's output?
H.248/MEGACO?).

-d



> Can you write up the specific requirement so it can be included in 
> the update to draft-wing-media-security-requirements?
> 
> -d