Subject: Re: [MSEC] multicast scenario for SRTP-DTLS Key Transport

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 06 Mar 2008 22:38:02 -0800

It would be interesting to have a discussion between Dan's draft and 
GDOI-SRTP.  Any takers?  A first step might be for authors to review 
each others' drafts.

I would like to add this also to the agenda, but an initial discussion 
on the list would help manage the time at the f2f meeting better.

regards,
Lakshminath

On 2/15/2008 4:12 PM, Dan Wing wrote:
> I just posted a new version of "Datagram TLS Secure RTP (DTLS-SRTP) Key
> Transport" with a new scenario that I expect will interest the MSEC working
> group, "Point to Multipoint using Multicast", 
> http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-01.txt#secti
> on-3.2
> 
> I had presented -00 to AVT at IETF-70 in Vancouver and have asked for agenda
> time to present -01 to AVT in Philadelphia.
> 
> If there is interest and agenda time I can present the idea to the MSEC
> working group in Philadelphia to describe how I forsee DTLS-SRTP Key Transport
> could work with multicast SRTP.
> 
> Comments welcome.
> 
> -d
> 
> _______________________________________________
> MSEC mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/msec
> 
_______________________________________________
MSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/msec

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 06 Mar 2008 22:38:02 -0800

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 09 Mar 2008 15:21:21 -0700

Hi Dan,

Thanks for sharing this work with MSEC.  The draft is very good for an 
-01-.  Many thanks for your hard work.

To start off, I should say, we have considered group keying in the 
context of TLS in MSEC a long while ago.  Before I ramble, I should say 
that it has been a while ( we discussed the topic, so my recollection 
and especially my terminology may not be precise.

The idea was that TLS can be used to establish the secure channel of 
Phase 1 (in lieu of IKE Main Mode/Quick Mode).  Phase 2 would then be 
similar, irrespective of what protocol was used in Phase 1.  Now, I 
understand and would make a case for reusing payloads of the protocol 
used in Phase 1, in Phase 2 as well.  To that end, there will be 
differences, but schematically there shouldn't be.

More recently, I was thinking about how to optimize and documented some 
of those thoughts in GKDP; there are some security and/or policy 
negotiation tradeoffs however.  Specifically, one could claim that a 
group member may ask to join a group with ID, GID, for which the GCKS or 
an equivalent entity would then provide the group security policy, if 
the member agrees to the policy, it could then ask for the keys.  One 
could make an argument to keep the group security policy secret, 
although, I would say that there is no real need to keep the policy 
secret in most general use cases.

Some comments on your draft (including nits):

On the use of the word DTLS peer: I guess this is one of those 
terminology things that we have to go back and forth on with regard to 
TLS.  TLS itself of course has the notion of client and server; in the 
context of SRTP, point-to-point security context establishment, it makes 
sense to use the word peer instead of client and server; however, in the 
context of group keying, the asymmetric roles are again quite 
meaningful.  Specifically, group policy and the keys are always sent by 
the key server.  There is also no negotiation of group policy.  To that 
end, in Page 10, there is a note about no changes to crypto parameters 
and that a new handshake is needed for that.  It is plausible that I 
don't have the context right, could you explain this please?

Next, I am not sure I understand the notion of new_srtp_key and 
your_new_srtp_key.  Perhaps some reworking of terminology might be 
useful here.

Would a multicast key update be possible with this?  If the idea is to 
be able to support rekeying at the time of membership changes, that 
might scale better.

Would key management for multiple streams be a possibility?  Similarly, 
would it be possible to offload key management to a separate entity?  In 
those cases, it might make sense to be able to identity the stream, 
session or more generally, the secure group for which the keys are being 
transported.

Perhaps it might make sense to call the extension, TLS Key transport 
extension to make it as general as possible.  Thoughts?  Is there any 
reason to scope it to DTLS or SRTP?

In Figure 9, I am not sure I understand the symmetry.  In each instance 
of a secure group, isn't there a single server (let's set aside the 
cases of use of subordinate group controllers or redundant servers etc) 
with all other entities within the group being clients?  I guess the 
symmetry is to state that in the use case of a mixer, each entity is a 
"sender."  If so, I am making a case for making the protocol more generic.

I don't recall the following about TLS.  Can the key management session 
continue after Finished?  I will also check when I have connectivity and 
probably respond again.

In Section 6, how effective is transport address matching?  More 
specifically, how hard is it to spoof the transport address in addition 
to using the sender's key?  The solution is in effect a poor man's 
mechanism for source authentication.  I am just curious contextually how 
powerful it is.

All, I invite you to participate in this discussion.  I am going to ask 
Dan to present a comparative analysis or summarize the shortcuts that he 
has thought of compared to GDOI-SRTP instead of a tutorial presentation. 
  Needless to say, please read the draft prior to the meeting.  Please 
don't expect a tutorial at the meeting.  Unfortunately, we don't have 
time for a tutorial and to make progress.

thanks,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 09 Mar 2008 15:21:21 -0700

Hi Dan,

thanks,
Lakshminath