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
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
