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

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Mon, 15 Apr 2002 17:16:42 +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.

Good point. I think that the best approach will be that the offerer 
include only one key mgmt suggestion in the first offer. If the 
answerer does not support the suggested protocol, it should in its 
response, indicate the protocols supported by including a key mgmt 
attribute with the name of the protocol(s) supported (but no data 
in it). I will include these kind of considerations in the next 
version of the draft. 

Fredrik

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 15 Apr 2002 17:53:09 -0400

>in it). I will include these kind of considerations in the next 

Right, but doing this gets us into difficulties with the underlying state
machine. What would have been an offer-answer with a set of key exchange
protocols specified in the initial offer, now needs multiple round-trips. 

Colin