Subject: RE: [MMUSIC] Key mgmt extensions "blob" discussion

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Mon, 8 Apr 2002 15:13:09 +0200

From: Colin Perkins [mailto:[email-masked]]
> 
> --> "Fredrik Lindholm (ERA)" writes:
> >
> >> 
> >> I think we need to step back, and evaluate what we're trying 
> >> to solve here.
> >> If the key management attributes are to be general purpose, 
> >> and can be used
> >> with a range of key exchange protocols, then I would argue 
> >> that they should
> >> be visible to SDP and have well defined semantics at the SDP 
> >> level. In this
> >> case, I'd expect to see something like:
> >> 
> >> 	a=key-mgnt:mikey algorithm=aes key=... mac=...
> >> 
> >> for an appropriate set of generic key-exchange/authentication 
> >> parameters.
> >> In this case, I'd expect another keying protocol to use 
> >> mostly the same
> >> parameters, and to pick them up from the SDP. 
> >
> >Using almost the same reasons, I would argue the opposite, 
> >as it is very hard to find a set of good attributes that can 
> >be used with a variety of protocols (as the key mgmt protocols 
> >have very different properties). It is also not clear how these 
> >attributes could be used in the key mgmt response, as it might 
> >(in one extreme) be a message where everything are encrypted.
> 
> This is exactly why I don't like the idea of generic key management
> attributes. If there are no common parameters, why try to merge the
> signalling?
> 
> >> If, however, they're opaque and used solely by a particular 
> >> protocol, then
> >> I don't see the advantage of trying to make the attribute 
> >> generic. Why use
> >> 	a=keymgmt-prot:MIKEY
> >> 	a=keymgmt-data:<opaque-data>
> >> instead of
> >> 	a=mikey:<opaque-data>
> >> when non-MIKEY speakers won't understand the attribute in 
> either case?
> >> 
> >
> >>From a MIKEY point of view, I do not care if it is general or 
> >not. However, as other people have expressed interest in 
> >using an attribute like this, I think it might be good to have 
> >something that is generic enough so you don't have to specify 
> >a new attribute if you like to replace MIKEY with something else. 
> >As I pointed out before, the approach we are using seems to be 
> >equal to the "fmtp" approach where SDP does not need to 
> >understand the content and where it is not necessary to create 
> >a new attribute each time you like to change/replace another 
> >key mgmt protocol. 
> 
> For each key exchange protocol, you need to map it onto the offer -
> answer model (or other SDP usage scenario), define the syntax of the 
> keying information, and register the name of the keying protocol.
> 
> With "a=keymgmt-prot:" you have defined a new IANA registry of key
> exchange protocol names, and for each protocol you need to register 
> an entry there and define how it is used. With an SDP attribute for 
> each key exchange protocol, the only difference is that the name is 
> registered in the SDP attribute namespace. The same parameters need
> to be defined.
> 
> I don't see how the generic attributes make this process easier?

This was originally related to Stephen's comment, which apparently 
wasn't a big problem. 

So, is your recommendation then that we should register a unique
a=mikey:<opaque-data> 
attribute (and similar for RTSP?) instead of going on with the 
approach in the current draft? How would you like us to proceed?

Fredrik

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 08 Apr 2002 19:44:49 -0400

...
>approach in the current draft? How would you like us to proceed?

I think it depends on how many key management protocols we're likely to
see. If MIKEY is the only one, then a=mikey: is appropriate. But, if we
expect to have many key exchange protocols, Steve's concerns about name
space pollution are important, and an "a=key-mgmt:mikey <opaque-data>"
attribute may be better (because it establishes a separate namespace for
key exchange protocol names).

However, my main concern is the use of opaque (to SDP) data in the first
place. I'd be much happier if the key exchange could happen as part of a
standard offer/answer within SDP, rather than being tunneled. 

Colin