Subject: [MMUSIC] Key delivery to BFCP clients

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 21 Feb 2005 15:27:51 +0200

Folks,

the following draft proposes that BFCP floor control servers use the SDP
'k' line to deliver a key to BFCP clients.

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bfcp-00.txt

However, SDPnew states the following on the use of the 'k' line:

    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.

SDPnew lists as alternatives to the 'k' line MIKEY and the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-09.txt

This draft allows a server to send crypto stuff (e.g., algorithm to be
used) in addition to the key.

The thing is that BFCP clients will not use the key received in the SDP
to encrypt traffic and therefore, they do not need any additional crypto
stuff. They will use it to perform a digest-based authentication. That
is, they will compute a hash of a BFCP message and the key and send it
to the server to prove that the client sending the BFCP message is the
same as the one that received the SDP session description.

So, the key received in the SDP is used as a digest password. We need to
figure out how to transport this password from the server to the client.
The choices are:

1) we use the 'k' line and explain why the considerations against its
use do not apply in this case.

2) we define a new SDP parameter to carry shared secrets, as opposed to
encryption keys, in SDP.

My proposal is to go for 1). Any comments or objections?

Thanks,

Gonzalo

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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 23 Feb 2005 21:33:03 -0800

Flemming,

On Feb 23, 2005, at 1:13 PM, Flemming Andreasen wrote:
...
> using eithe sdescriptions or kmgmt for this seems like an overkill.
>
> Given that we already have a "k=" attribute defined that seems to 
> satisfy the requirements we have here,

I don't believe that k= satisfied the requirements of keying any 
application and that's why it is being deprecated.  Take SHA-1 for 
example, k= lacks any means to declare what type of key is being used 
and the first key is SHA-1.  But SHA-1 should probably not be the only 
hash function available since it now has reportedly been broken.

Mark
> I don't see any particular reason to come up with another BFCP 
> specific parameter either, but I don't feel strongly about it. If we 
> do use the "k=" field, it should probably be clarified which of the 
> four forms can be used (just "base64" I presume ?). I would also 
> suggest, that the "k=" line can only be used at the session level in 
> case the SDP contains BFCP media streams only, or (simpler and 
> preferred) only allow it to be used at the media layer for BFCP.
>
> -- Flemming
>
>
>
>> Thanks,
>>
>> Gonzalo
>>
>>
>>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 23 Feb 2005 16:13:35 -0500

> My proposal is to go for 1). Any comments or objections?
I've only skimmed BFCP, so let me know if I missed anything here, but as 
I understand it, BFCP defines all the parameters associated with the 
cipher and has no options that can be either negotiated or advertised to 
the party that needs to authenticate; all configuration is fixed based 
on the BFCP specification itself. If so, the only thing you need to 
convey is the key to use, and, as you note, we have at least three 
existing options that can be used for that, namely sdescriptions, kmgmt, 
and the "k=" line. Given that :
1) we are looking at something that is completely BFCP specific,
2) both sdescriptions and kmgmt only provide a framework and you would 
need to define specific profiles for use with BFCP (which would use very 
little of their general capabilities)

Given that we already have a "k=" attribute defined that seems to 
satisfy the requirements we have here, I don't see any particular reason 
to come up with another BFCP specific parameter either, but I don't feel 
strongly about it. If we do use the "k=" field, it should probably be 
clarified which of the four forms can be used (just "base64" I presume 
?). I would also suggest, that the "k=" line can only be used at the 
session level in case the SDP contains BFCP media streams only, or 
(simpler and preferred) only allow it to be used at the media layer for 
BFCP.

-- Flemming

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 24 Feb 2005 09:37:43 +0200

Hi,

given that we have agreed to build support for different hashing
algorithms in BFCP (see email thread in XCON), the 'k' line will not
meet our requirements anymore. I believe we will go for Security
Descriptions.

Thanks,

Gonzalo

Mark Baugher wrote:
>  and the first key is SHA-1.  But SHA-1 should probably not be the 
> only hash function available since it now has reportedly been broken.
> 
> 
> 
> Mark
> 
>> specific parameter either, but I don't feel strongly about it. If 
>> we do use the "k=" field, it should probably be clarified which of 
>> the four forms can be used (just "base64" I presume ?). I would 
>> also suggest, that the "k=" line can only be used at the session 
>> level in case the SDP contains BFCP media streams only, or (simpler
>>  and preferred) only allow it to be used at the media layer for 
>> BFCP.
>> 
>> -- Flemming
>> 
>> 
>> 
>> 
>>> Thanks,
>>> 
>>> Gonzalo
>>> 
>>> 
>>> 
>>> _______________________________________________ mmusic mailing 
>>> list [email-masked] 
>> _______________________________________________ mmusic mailing list
>>  [email-masked] https://www1.ietf.org/mailman/listinfo/mmusic
>> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 24 Feb 2005 10:42:40 -0500

> meet our requirements anymore. I believe we will go for Security

OK. I presume the offer will then contain one or more hashing algorithms 
and associated data, and the answerer will choose one of them. One 
problem we found when doing sdescriptions here was the race between the 
answer coming back, and a media packet that was secured according to 
parameters provided in the answer. Security preconditions have been 
defined to address that, but they add to overall session setup delay. If 
you have the option of making the BFCP digest attributes self-contained 
inasmuch as they can completely identify which of the offered options 
was actually chosen, you can avoid this race.

-- Flemming

>>> case the SDP contains BFCP media streams only, or (simpler
>>>  and preferred) only allow it to be used at the media layer for BFCP.
>>>
>>> -- Flemming
>>>
>>>
>>>
>>>
>>>> Thanks,
>>>>
>>>> Gonzalo
>>>>
>>>>
>>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 Feb 2005 09:05:15 +0200

Hi Flemming,

yes, the BFCP attribute carrying the digest will be self-contained. It 
will carry the actual digest plus an algorithm identifier.

Thanks,

Gonzalo