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

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Tue, 9 Apr 2002 11:28:11 +0200

> 
> --> "Fredrik Lindholm (ERA)" writes:
> ...
> >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 
message will probably expand with a factor between 2 and 5 (compared 
to a base64 encoded MIKEY message). Another problem with this would 
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).

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

Fredrik

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 11 Apr 2002 20:58:16 -0400

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

>to a base64 encoded MIKEY message). Another problem with this would 

This may be an issue, certainly. 

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

>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

---

From: Joerg Ott <[email-masked]>
Date: Sat, 13 Apr 2002 17:45:02 +0200

Since we have talked about potential further key management protocols:
the draft talks about this but does not specify how to negotiate the
key management protocol:

Let's assume (without stating consent here) that we use the following
notation:

m=audio ...
a=key-mgmt:mikey data=SJKHkdakhjfkjDSY083u...

In this case, how do I specify that I am support two different schemes:
"mikey" and "magic"?

Is this going to be a single m= line

m=audio ...
a=key-mgmt:mikey data=SJKHkdakhjfkjDSY083u...
a=key-mgmt:magic data=jhas84hjkH9hjkSaDH38...

which means that the key-mgmt attributes implicitly carries the
semantics that the intersection of the algorithms is constructed
and, in the offer/answer case, the answerer picks the one to use.

Or, do I allow only exactly one key-mgmt attribute per m= line
or session, use two a number media lines and group those somehow?

Or shall only one be allowed at all and the initiator may need to
try one by one?  

In either case, the spec needs to specify whether the initiator
what the intended outcome is.  I assume that non-availability
of the requested key management protocol at the receiver will lead
to a rejection of the offer?  Or is "none" an acceptable outcome?
This also needs to be specified.

Of course, making the key management negotiable brings up the
issues of bidding down attacks that we had in the context of SIP
security.

Regardless of the syntactical representation, this problem needs
to be addressed.

Joerg