[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Store and Forward - looking for more feedback (draft-mattsson-srtp-store-and-forward-03)
> -----Original Message-----
> From: Rolf Blom [mailto:rolf.j.blom at ericsson.com]
> Sent: Tuesday, September 15, 2009 4:48 AM
> To: Roni Even
> Cc: 'Dan Wing'; 'IETF AVT WG'
> Subject: Re: [AVT] Store and Forward - looking for more
> feedback (draft-mattsson-srtp-store-and-forward-03)
>
> Hi Dan, Roni
>
> Thanks for the comments, Please see some answers below.
>
> /Rolf
>
> Roni Even wrote:
>
> Hi Dan,
> Thanks for the feedback.
> On the first point, this can be discussed if we decide
> that AVT would like
> to take this work as part of the charter update.
>
> Regards
> Roni Even
> AVT co-chair
>
>
>
>
> -----Original Message-----
> From: Dan Wing [mailto:dwing at cisco.com]
> Sent: Wednesday, September 09, 2009 4:12 AM
> To: 'Roni Even'; 'IETF AVT WG'
> Subject: RE: [AVT] Store and Forward - looking
> for more feedback
> (draft-mattsson-srtp-store-and-forward-03)
>
> My top-level concerns with
> draft-mattsson-srtp-store-and-forward-03 /
> draft-naslund-srtp-saf-02
>
> * from an RAI perspective, the mechanism only
> works for SRTP.
> (This is probably fine from AVT's perspective.)
> That is, it does not provide privacy of other
> messages that
> an operator might store and forward, such as
> SIP MESSAGEs.
> A mechanism using S/MIME could provide decryption keys
> and replay protection that would be decipherable only by
> the intended recipient, for any sort SIP method and for
> SRTP-encrypted media.
>
> I expect this is an AD-level issue to consider.
>
>
> It is correct that the SRTP SaF only works for RTP, as the
> intention was to have a profile that can work with streaming
> media. There may very well be a need to have mechanisms that
> work for non-streaming media, but we believe that is out of
> scope for this work.
>
>
> * The draft needs to describe how key management is
> performed. Specifically, the calling party needs a
> mechanism to obtain the called party's public key; I
> don't know how to build a device that does that --
> what protocol do I use? Security Descriptions wouldn't
> be suitable. DTLS-SRTP wouldn't be suitable, either (as
> the actual called party is offline [or refusing
> to answer],
> otherwise you wouldn't be leaving them voicemail!). I
> think this means I need MIKEY-RSA-R, but I
> don't know how
> that would work when the called party is
> offline. So that
> leaves me guessing there is some other protocol that I
> need to implement, or that I load the public keys into
> my contact list (which means we don't need an on-the-
> wire protocol to obtain the called party's public key).
>
>
> We have followed the same model as for SRTP, to keep the key
> management separated. However, we could very well add some
> key management considerations into the draft and clarify the
> requirements on the key management protocol. An example of a
> key management protocol that would work is MIKEY (using one
> of the key push mechanisms).
Can you add that to the draft? My purpose is simple: I want
text in the draft so that when a customer says "wow, that store-
and-forward SRTP looks great. Which products have it?" we
can quickly say "only our XYZ product supports the type of keying
required by Section X.Y of the store-and-forward RFC." Otherwise
it's a half-hour-long discussion of (unstated) keying requirements
to accomplish store-and-forward SRTP.
-d
>
>
> -d
>
>
>
>
> -----Original Message-----
> From: avt-bounces at ietf.org
> [mailto:avt-bounces at ietf.org] On
> Behalf Of Roni Even
> Sent: Monday, August 10, 2009 2:57 AM
> To: 'IETF AVT WG'
> Subject: [AVT] Store and Forward -
> looking for more feedback
>
> Hi,
>
> Store and forward was first presented
> in IETF 72 (Dublin)
> since then there was progress in the
> individual drafts but
> the AVT chairs are not sure how to
> continue with the work.
>
> We had a presentation on the current
> status in IETF 75 but
> there were not many comments. The
> people that commented on
> the mailing list were not in the room.
>
>
>
> The AVT chairs would like to get
> feedback on this work so
> that they can form an opinion about how
> to go forward with this work.
>
> Since it has been active for a year it
> looks like we will
> need to decide if there is enough
> support for having this
> work as a WG item or look at other directions
>
>
>
> Thanks
>
> Roni Even
>
> AVT co-chair
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>
>
>
> --
> Rolf Blom, Ph.D. Expert, Mobile Communications Security,
> Ericsson Research
> Postal address: Ericsson AB, SE-164 80 STOCKHOLM, Sweden
> Tel: +46 10 713 17 07, GSM: +46 70 757 2092, Fax: +46 8 757 01 35
>
>
> This communication is confidential and intended solely for the
> addressee(s). Any unauthorized review, use, disclosure or distribution
> is prohibited. If you believe this message has been sent to you
> in error, please notify the sender by replying to this transmission
> and delete the message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to datacorruption,
> interruption, unauthorized amendment, tampering and viruses, and
> we only send and receive e-mails on the basis that we are not
> liable for any such corruption, interception, amendment, tampering
> or viruses or any consequences thereof.
>