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

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Thu, 4 Apr 2002 10:15:15 +0200

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

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

Fredrik

>
>
> Colin
> 
> 
> 
> 
> 
> --> "Fredrik Lindholm (ERA)" writes:
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:[email-masked]]
> >>
> >> --> "Fredrik Lindholm" writes:
> ><snip...>
> >> >
> >> >To conclude our own thoughts, we believe that it is better 
> >> from a modularity
> >> >perspective to actually use the "blob" approach, as it 
> will give the
> >> >smallest impact on both the key management protocol and SDP.
> >> 
> >> I'm not sure I agree, although you make a number of good 
> >> points. How does
> >> the "blob" compare to an approach in the style of "a=fmtp" 
> >> though? Generic
> >> SDP attribute, with each key management protocol defining 
> >> parameters to be
> >> used within it? Fits the SDP model better, allows the key 
> >> management to use
> >> the SDP parser to find its parameters, yet doesn't limit the 
> >> protocol to a
> >> single key management scheme.
> >> 
> >
> >Using the SDP parser is not something I would recommend. 
> >First of all, the key management protocols (almost all) 
> >have already a built in parser (so it is there, and 
> >something similar must still be in place to verify that 
> >the attributes are of valid types etc.). Secondly, the 
> >protocol is generally defined in a way that the MAC/
> >Signature, protecting the data that are sent, are 
> >computed over the entire key management message (which 
> >is built up by a set of pre-defined payloads). 
> >
> >If you then would like to split the key management message 
> >into sub parts and provide these as some values in SDP, the 
> >key management protocol still have to create the set of 
> >payloads and compute the MAC, before it can be split into 
> >subparts. When an SDP message arrives, the SDP parser must 
> >first parse the set of attributes, send it to the key 
> >management, which then must merge these together into 
> >payloads in order to be able to verify the MAC/Signature. 
> >This is not very good from a security point of view, as 
> >you would like to verify the MAC/Signature as soon as 
> >possible. I think this approach would create too much double 
> >work unless the parameter is more or less a "blob". 
> >
> >I think the approach we have chosen are very equal to the 
> >"fmtp", or? The only description of fmtp that I found said: 
> >"This attribute allows parameters that are specific to a 
> >particular format to be conveyed in a way that SDP doesn't 
> >have to understand them.". As I see it, we have almost the 
> >exact same approach, except that we have it spread out on 
> >three different lines. 
> >
> >a=fmtp:<format> <format specific parameters>
> >
> >To compare:
> >
> >a=keymgmt-prot:<proto> // this is equal to <format>
> >a=keymgmt-data:<data>  // this is equal to the format specific data
> >a=keymgmt-auth:<data>  // this is equal/subpart to/of the 
> format specific data
> >
> >So we could of course think of merging these into one line 
> >and define: 
> >a=keymgmt:<proto> <keymgmt specific data>
> >
> >and using a similar description to fmtp: 
> >
> >This attribute allows parameters that are specific to a 
> >particular key management protocol to be conveyed in a way 
> >that SDP doesn't have to understand them. Key management 
> >specific parameters may be any set of parameters required 
> >to be conveyed by SDP and given unchanged to the key 
> >management protocol that will use this format.
> >
> >If we use this approach, I'll guess we don't have to worry 
> >that much about the "blob" thing, as each key management 
> >protocol in practice can choose either way that is 
> >appropriate. 
> >
> >Fredrik
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 05 Apr 2002 16:29:48 -0500

>(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?

>a new attribute each time you like to change/replace another 

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?

Colin