Re: [MMUSIC] BFCP: SDP usage and k=

[Mark Baugher <[e-mail]>]

On Feb 8, 2005, at 2:54 PM, Adam Roach wrote:

> [as XCON chair]
>
> I am copying the MMUSIC mailing list on this message, since I believe 
> there may be individuals in MMUSIC who are willing and able to assist 
> in a decision that the XCON working group must make. Fundamentally, 
> though, I believe this is an XCON issue, so I believe any ensuing 
> discussion should take place on the XCON mailing list.
>
> Currently, the SDP document for BFCP 
> (draft-ietf-mmusic-sdp-bfcp-00.txt) talks about using the k= line for 
> calculation of DIGEST TLV values.

I glanced at the usage of k= in this I-D, which says that it encodes a 
shared secret.  But where does it specify what kind of shared secret?  
What algorithm is used for computing the digest?  I did not study the 
draft and may be missing something.  If it is completely specified then 
it avoids the general problem that we found with k= in the past, namely 
that there is no way to identify the transform to be used and pass 
additional cryptographic and session parameters that practically always 
need to be communicated with a cryptographic key.  If 
draft-ietf-mmusic-sdp-bfcp-00.txt does not have these problems and k= 
signals all needed information, then there may be no problem.

Mark
>
> During review of sdp-new (not sdp-ng -- but the 2327bis document), the 
> IESG commented that the use of k= for key exchange is not a sufficient 
> solution for key exchange; the resultant change to the SDP document is 
> as follows:
>
>>   If transported over a secure and trusted channel, the session
>>   description protocol MAY be used to convey encryption keys.  A 
>> simple
>>   mechanism for key exchange is provided by the key field ("k=")
>>   although this is primarily supported for compatibility with older
>>   implementations and its use is NOT RECOMMENDED.  Work is in progress
>>   to define new key exchange mechanisms for use with SDP [26][27] and
>>   it is expected that new applications will use those mechanisms.
>>
>
> Given this NOT RECOMMENDED strength provision, XCON needs to consider 
> whether we continue to use the k= field as described, or if we need to 
> instead use draft-ietf-mmusic-kmgmt-ext (which is just about to be 
> ready for IESG review) or some similar mechanism.
>
> If we decide to continue to use k=, then the BFCP SDP document needs 
> to justify that decision. Questions to answer include:
>
>    * Why is the k= mechanism sufficient for floor control despite its
>      use being NOT RECOMMENDED?
>
>    * In what ways does floor control or our usage of the k= line differ
>      from other media that we have grounds for contravening the
>      recommendations of sdp-new?
>
>    * Are there specific reasons that the draft-ietf-mmusic-kmgmt-ext is
>      not appropriate for BFCP?
>
>
> One notable difference is that BFCP does not use this key to encrypt 
> the actual floor control; it uses it for shared secret exchange for 
> the purposes of digest authentication. It may well be that using k= 
> for this purpose (that is, keys used for purposes other than stream 
> encryption) is sufficiently outside the traditional meaning of k= that 
> we should instead choose (e.g.) an a= attribute for digest key 
> exchange.
>
> Follow ups to the XCON working group only, please.
>
> /a
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic
>

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