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

From: "Elisabetta Carrara (ERA)" <[email-masked]>
Date: Tue, 16 Apr 2002 17:26:20 +0200

Hi Colin

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: den 15 april 2002 23:53
> To: Fredrik Lindholm (ERA)
> Cc: 'Joerg Ott'; [email-masked]; Elisabetta Carrara (ERA)
> Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion 
> 
> 
> --> "Fredrik Lindholm (ERA)" writes:
> >
> >> 
> >> 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. 
> 
> 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
> 

ok, we see. It is not a problem for us to place the set of 
key management protocols in the offer if so is wanted, 
however we did not want to do that because of the impact it has, 
e.g. the size of the SIP message (note also, a certain fraction of 
the key management data can't be efficiently compressed).
Hence, if you want the set approach, we would add a recommendation
on the inclusion of only one key management protocol in the offer.

cheers
/E

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 16 Apr 2002 11:42:23 -0400

--> "Elisabetta Carrara (ERA)" writes:
...
>on the inclusion of only one key management protocol in the offer.

I don't know the correct approach, since I don't know the operation of the
key exchange protocols. Is it sensible to enumerate multiple protocols? Or
is it better to send one, and figure out how to restart the negotiation if
that is unsuitable? 

Colin

---

From: Mark Baugher <[email-masked]>
Date: Tue, 16 Apr 2002 09:15:23 -0700

>is it better to send one, and figure out how to restart the negotiation if

I think the latter.  The former is yet to be invented AFAIK.

Mark