Subject: RE: [MMUSIC] draft-ietf-mmusic-kmgmt-ext-04.txt

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Mon, 6 May 2002 11:48:00 +0200

> 
> Hi Fredrik,
> 
> I believe the question we have to answer is: when other
> mechanisms/algorithms are introduced in the future, the 
> parameters they
> will have to use, will be very similar to the ones defined for MIKEY?

My answer to that is: No (the main reason to define/use a different key 
management protocol is that it has different properties, therefore it 
will most likely also have very different parameters).

Fredrik

> 
> If this is so, defining a human-readable framework in SDP might make
> sense. If not, the current opaque approach would be sensible.
> 
> Regards,
> 
> Gonzalo
> 
> "Fredrik Lindholm (ERA)" wrote:
> > 
> > We recently submitted a new version of the
> > draft-ietf-mmusic-kmgmt-ext. In this version
> > many of the comments raised in Minneapolis
> > and at the mailing list are addressed.
> > 
> > The open issue is still, how to include the
> > key management data. The main problem is
> > whether to extract the key management
> > protocol's (KMP) parameters from the KMP data
> > and insert these in SDP/RTSP as separate
> > attribute fields or whether to treat the KMP
> > data as one single value.
> > 
> > The two approaches can be visualized as:
> >    a=key-mgmt:MyKeyMgmt algorithm=aes key=... mac=...
> > and
> >    a=key-mgmt:MyKeyMgmt HsdjhsUYUdsjqiHSD...
> > (Similar header is then also defined for RTSP)
> > 
> > The first approach might be appealing as almost
> > each attribute is "human readable" and can be
> > parsed by SDP. However, we believe that there
> > are too many disadvantages with the first
> > approach compared to the second.
> > 
> > We have tried to summarize the main problems
> > (as we currently see it) with using the first
> > approach. These are:
> > * When a new attribute/parameter is added to the
> >   KMP, this must be registered not only in the
> >   KMP, but also in SDP and RTSP. I.e., changes
> >   propagate through several protocols.
> > * When adding another KMP, one need to map the
> >   payloads normally used by the KMP to both SDP
> >   and RTSP values.
> > * It can increase the bandwidth consumption (how
> >   much will of course depend on how the KMP
> >   encoded the data normally).
> > 
> > We believe these problems are serious enough to
> > motivate the use of the second approach, i.e.,
> > include the KMP data as one single value.
> > 
> > Fredrik
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland                   http://www.hut.fi/~gonzalo
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic