[XCON] Re: [MMUSIC] BFCP: SDP usage and k=
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[XCON] Re: [MMUSIC] BFCP: SDP usage and k=
On Feb 12, 2005, at 1:01 PM, Nathan Allen Stratton wrote:
...
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.
My understanding of mmusic-kmgmt-ext-13 is that it is open to using
many
different key management protocols. I however am in the dark as to what
the draft use of mikey is, I think based on RFC 7311 it is AES, but I
am
not sure.
The specification that we're discussing makes no mention of MIKEY or
the kmgmt I-D. k= is a much different approach than kmgmt. If the
authors were to replace k= with something more expressive, then I'd
expect that they would use sdescriptions.
The question that I have raised and that I don't think has been
answered is whether k= is sufficient for carrying a digest key. The
authors could choose to use MIKEY/kmgmt or they could use
sdescriptions. Maybe k= meets the application requirements. I don't
know, which is why I asked the question: Is there a need to specify the
algorithm with the key?
Mark
Mark
<>
Nathan Stratton BroadVoice, Inc.
nathan at robotics.net Talk IS Cheap
http://www.robotics.net
http://www.broadvoice.com
_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.