RE: Group keying and Colin's note

[Xu Chen <chenxu0128@xxxxxxxxxx>]

hi Richard, 

So far as I know, IKE is only used for point to point case. You need
GDOI or MIKEY to do group key management.  I also believe, extend
(D)TLS to do group key management is a possible solution. Group
members first register to GCKS through some kind of Initial session. A
shared rekey session responds for refreshing traffic keys. Data
traffic is securely protected by some common record layer. As an
alternate way, real-time media may exchange over SRTP, just like
DTLS-SRTP. BTW, RFC3740 may be helpful and it gives an architectural
view of group key management. 

Regards,
Xu

> -----Original Message-----
> From: owner-ietf-rtpsec@xxxxxxxxxxxx 
> [mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] On Behalf Of Richard Barnes
> Sent: Wednesday, March 21, 2007 11:17 PM
> To: Lakshminath Dondeti
> Cc: ietf-rtpsec@xxxxxxx
> Subject: Re: Group keying and Colin's note
> 
> 
> I'll pose a question to the TLS experts: From what little I 
> know about msec, they seem to have defined a Domain of 
> Interpretation for ISAKMP that lets IKE do group key 
> management (RFC 3547).  Could an analogous thing be done for [D]TLS?
> 
> --Richard
> 
> 
> Lakshminath Dondeti wrote:
> > 
> > Colin noted that -- I am loosely paraphrasing -- the key
management 
> > requirements related to one to many (as in very many!) 
> communication 
> > are different from those of one to one communication and 
> that he does 
> > not agree with the notion of designing a single protocol 
> handling both 
> > use cases.  (Is that fairly accurate, Colin?  Please do 
> correct me if 
> > my recollection of your comment is incorrect).
> > 
> > It is an interesting topic.  If we want to engage in a 
> nuanced debate 
> > on this, please do let me know, but the simplistic answer is that 
> > there are surprisingly many similarities in bootstrapping 
> group keying 
> > and establishing keys for one to one communication.
> > 
> > Scalable rekeying is a requirement specific to group keying 
> and indeed 
> > that aspect of it is very different.  So, there is no reason to 
> > summarily rule out considering design of a protocol that 
> serves both use
> > cases.   It has been done before [RFC 3830]!
> > 
> > thanks,
> > Lakshminath
> > 
> > 
> 
> 
>