[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Posting in support for Protcol X, Y, or Z
> > >>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?
> Can you write up the specific requirement so it can be included in
> the update to draft-wing-media-security-requirements?