Subject: Re: [AVT] Store and Forward - looking for more feedback (draft-mattsson-srtp-store-and-forward-03)

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Sep 2009 18:12:26 -0700

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.

* 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).

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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
> 
>

---

From: Roni Even <[email-masked]>
Date: Wed, 09 Sep 2009 08:29:15 +0300

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

> From: Dan Wing [mailto:[email-masked]]
> 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)
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Sep 2009 08:06:58 -0700

> From: Roni Even [mailto:[email-masked]] 
> Sent: Tuesday, September 08, 2009 10:29 PM
> To: 'Dan Wing'; 'IETF AVT WG'
> Subject: RE: [AVT] Store and Forward - looking for more 
> feedback (draft-mattsson-srtp-store-and-forward-03)
> 
> 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. 

I think both points are easily resolved.  To my first point,
there is not a proposal on the table for how to accomplish
the same store-and-forward (including replay protection) using
S/MIME to send the SRTP key.  So this means we don't have a 
viable way of doing this for all SIP messages.  I know I don't
have the energy to work on it; but perhaps someone else does?

To my second point, it should be an hour or two to write text
describing the requirements of a key management protocol (should
someone want one) and to explain that loading public keys
manually (into a phone's contact list) would be awkard, but
works.

-d

> > My top-level concerns with 
> draft-mattsson-srtp-store-and-forward-03 /

---

From: Rolf Blom <[email-masked]>
Date: Tue, 15 Sep 2009 13:48:27 +0200

Hi Dan, Roni

Thanks for the comments, Please see some answers below.

/Rolf

Roni Even wrote:

Hi Dan,
Thanks for the feedback.

Regards
Roni Even
AVT co-chair

-----Original Message-----
From: Dan Wing [mailto:[email-masked]]
Sent: Wednesday, September 09, 2009 4:12 AM
To: 'Roni Even'; 'IETF AVT WG'
Subject: RE: [AVT] Store and Forward - looking for more feedback

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.

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

-d

-----Original Message-----

Hi,

Thanks

Roni Even

AVT co-chair

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
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.