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

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Wed, 3 Apr 2002 10:44:08 +0200

> -----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: Wed, 03 Apr 2002 18:46:12 -0500

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. 

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?

Colin

---

From: Stephen Casner <[email-masked]>
Date: Wed, 3 Apr 2002 20:21:24 -0800 (PST)

> when non-MIKEY speakers won't understand the attribute in either case?

Well, it seems a bit dangerous to insert the namespace of key
management protocols into the SDP attribute namespace.

							-- Steve

---

From: Mark Baugher <[email-masked]>
Date: Thu, 04 Apr 2002 09:22:05 -0800

Steve

>management protocols into the SDP attribute namespace.

I'm not certain which alternative, if either, you are arguing for
or against.  Frankly, the nuance of difference between the
two alternatives escapes me.

Mark

---

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

>management protocols into the SDP attribute namespace.

Only if there are likely to be many key management protocols used.

Colin