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

From: Colin Perkins <[email-masked]>
Date: Tue, 02 Apr 2002 18:22:46 -0500

--> "Fredrik Lindholm" writes:
>To follow up the discussion at today's session, we have tried to
>summarize our view of the pros and cons of placing the key
>management data as a "blob" in SDP compared to splitting the
>key management data into several fields. We do not claim that
>this is an objective analysis, but a start of some discussion.
>
>Advantages and disadvantages with the key management data
>as a "blob":
>- It does not conform to the "normal" SDP way that every parameter
>  is readable and understandable by SDP.
>+ The defined attributes do not depend on a specific key management
>  protocol, i.e. it is possible to replace one key management protocol with
>  another.
>+ (hopefully) no more extensions need to be done to SDP in the future
>+ It is easier from a message processing point of view. From a high-level
>  view, the "blob" is extracted and sent to the key management "function",
>  which will answer Accepted/ Rejected. This also implies that the key
>  management can be more modular and does not have to be built into the
>  SDP implementation.
>+ Small impact on the current SDP implementation.
>
>Advantages and disadvantages with the key management data split
>into several fields:
>+ Fits into the SDP model
>- The fields MUST be defined with only one key management protocol
>  in mind.
>- If the key management protocol is changed, or another key management
>  protocol is used, the SDP attributes may have to be updated (as well as the
>  SDP implementation).
>- Larger impact on the current SDP implementation
>- Harder to analyze (and interop test) the key management protocol itself,
>  as it will be very dependent on SDP (or RTSP).
>
>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.

Colin

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

---

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

If you get a deja vu experience reading this mail, it is 
probably because I tried to send it once before (but as I 
interpreted it, it did not reach its destination).

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

---

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Fri, 12 Apr 2002 08:22:48 +0200

> >> ...
> >> >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?
> >> 
> >> 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. 
> > 
> >I still vote for the use of the opaque approach. A new reason is due 
> >to the re-counting I did of how many parameters we would need to 
> >define in SDP (for MIKEY), which is 31 + (#SRTP parameters needed). 
> >I.e. this would result in "quite a few" new attributes. The MIKEY 
> 
> ...which have to be defined anyway. The only difference is 
> that they are
> defined as parameters to an SDP attribute, rather than binary 
> parameters 
> to MIKEY.

That's not really true. You would need to define these parameters 
to RTSP as well. And if there appears the need of using MIKEY in 
other protocols, we would then need to re-define all parameters 
again. 

> 
> >message will probably expand with a factor between 2 and 5 (compared 
> >to a base64 encoded MIKEY message). Another problem with this would 
> 
> This may be an issue, certainly. 
> 
> >of course be that if a payload would be added (e.g. support a new 
> >security protocol) would require a change in SDP (as new parameters 
> >might be introduced by the new security protocol).
> 
> It would require the addition of a new parameter to the SDP attribute
> registry, true. However the alternative is adding a new 
> parameter to a 
> MIKEY registry, so I don't see the gain.

No, one new parameters would impact not only SDP, but RTSP as well 
(and any other protocol that MIKEY might use for transport). That's 
why MIKEY needs its own registry space (I would claim that holds for 
any key management protocol).

Fredrik

> 
> >Unless you oppose completely, I would like to go on with the opaque 
> >approach. I do not expect that the number of key management 
> protocols 
> >that will use the attribute exceeds 4 in the near future (as I only 
> >see 3 alternatives right now). So the question is then, 
> whether to use 
> >the a=mikey:<opaque-data> or to use the a=key-mgmt:mikey 
> <opaque-data>. 
> 
> Probably the latter, if we go with this approach. 
> 
> Colin
>