[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.