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

From: Adam Roach <[email-masked]>
Date: Tue, 08 Feb 2005 16:54:50 -0600

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

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Mark Baugher <[email-masked]>
Date: Wed, 9 Feb 2005 08:24:03 -0800

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

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

---

From: Nathan Allen Stratton <[email-masked]>
Date: Sat, 12 Feb 2005 16:01:53 -0500 (EST)

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

><>
Nathan Stratton                                   BroadVoice, Inc.
nathan at robotics.net                                 Talk IS Cheap
http://www.robotics.net                           http://www.broadvoice.com

---

From: Mark Baugher <[email-masked]>
Date: Sat, 12 Feb 2005 13:31:29 -0800

On Feb 12, 2005, at 1:01 PM, Nathan Allen Stratton wrote:
...
> the draft use of mikey is, I think based on RFC 7311 it is AES, but I 

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

---

From: Nathan Allen Stratton <[email-masked]>
Date: Sat, 12 Feb 2005 17:42:24 -0500 (EST)

> know, which is why I asked the question: Is there a need to specify the

I am working with a number of hardware vendors and need to propose what
they implement in their devices. As a service provider I am looking for
someting like the Sipura SRTP implementation. A service provider has a
master cert and builds a private and public cert for each UA device with
name, phone number and exp date. The keys are stored in the user config
and the config is securely loaded into the device.

Ok, so now the fun part, I am just getting into this security game, so
please forgive me if I am totally missing someting. The problem I have
with the Sipura implementation is that they exchange public keys SIP INFO
and don't have plans to make that public so I can't use it between
vendors. So are any of these systems based on public/private keys where
the public key can be exchanged clear text and the voice encrypted with
the endpoint secret key and the remote endpoint public key?

It looks like the AES implementations are build around one key that is
based64 encoded and sent in plain text required TLS or some other trusted
communication between endpoints.

Now if I want to have a few vendors implement a standard sway to support
SRTP I don't see why I would need anything other then SDPnew k=, I would
have them use it to exchange the public keys. However, the two vendors I
am working with will do this, but I am wondering if there is a better way.
It would work with k=, but as you pointed out, other endpoints would have
no clue what algorithm was used to encrypt the keys. It could be the
public key of a RSA key pair or full AES key.

I need a system that is not proprietary and can be used among many vendors,
is based on a master key so that I can decrypt any voice call if required
to by law enforcement.

Any pointers as to what I should have them implement?

---

From: Mark Baugher <[email-masked]>
Date: Sat, 12 Feb 2005 16:31:24 -0800

Nathan
   I don't know if your questions are related to this particular thread  
or not.  If not, then I apologize for going off topic, but I comment  
below.

On Feb 12, 2005, at 2:42 PM, Nathan Allen Stratton wrote:

> master cert and builds a private and public cert

I don't know what a private cert is.  I expect that there is some kind  
of
X.509 certificate in the solution and that the certificate contains the
public key of the subject, e.g. the phone.  I can't guess who the
issuer would be.

> for each UA device with
> vendors.

They may not have plans to make their proprietary solution public, but
they may have plans to migrate to a standard solution when the industry
settles on one.  I think they can use MIKEY with kmgmt, or they can
use sdescriptions[1] with sip certificates[2].

[1]  
(http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-mmusic- 
sdescriptions-09.txt)
[2]  
(http://www1.ietf.org/internet-drafts/draft-ietf-sipping-certs-00.txt)
> So are any of these systems based on public/private keys where

Both sets of solutions use public key cryptography, at least as an  
option.
draft-ietf-sipping certs uses S/MIME.
> communication between endpoints.

draft-ietf-mmusic-sdescriptions does this.  MIKEY does it differently.
> public key of a RSA key pair or full AES key.

Since you're the service provider, the vendor might suggest which
of the standards they plan to offer for sale.
> is based on a master key so that I can decrypt any voice call if  

Most products will be using proprietary solutions for key establishment
since SRTP came out before the standards that key it.  I would expect
that the astute product team will have a roadmap for inter-operable
key establishment.
> Any pointers as to what I should have them implement?

Just the ones I mentioned above.

Mark

---

From: Nathan Allen Stratton <[email-masked]>
Date: Sat, 12 Feb 2005 22:57:33 -0500 (EST)

> or not.  If not, then I apologize for going off topic, but I comment

: )

> of X.509 certificate in the solution and that the certificate contains
> the public key of the subject, e.g. the phone.  I can't guess who the
> issuer would be.

Correct, so what I am looking for is a way to exchange X.509 public certs,
I could just do this with k=, but I think that a key-mgmt-att-field may
make more sense. Since as a service provider I will already have private
keys in the UAs. I just need to worry about exchanging public keys.

> use sdescriptions[1] with sip certificates[2].

So MIKEY is way overkill for what I need, since I am the service provider,
I have the ability to securely load the devices with private and public
keys, I just need a way for the devices to exchange public keys and start
SRTP (I still can't tell if SRTP is compatible with X.509 cert based
encryption).

> of the standards they plan to offer for sale.

Hehe, ya, one would think, but the vendors I am working with are launching
with us as a service provider and then will sell to other service
providers. They are open to doing whatever I need so I want to put them on
the right track of what I would like implemented for SRTP. It needs to be
standards or at least drafts based. I need to be able to build private and
public certs (could be X.509) off my CA. This should give me the ability
to decrypt any voice call on my network if law enforcement requires.

> that the astute product team will have a roadmap for inter-operable

Yep, SNOM looks the closest to standards, based on AES using k= in SDP.
The problem I have with this is that it is totally secure and I as a
service provider can't decrypt streams if required to by law enforcement.
Sipura also has SRTP based on public/private certs loaded by the config
file. However they use SIP INFO to exchange keys and don't plan to open
that to the public.

So now I am back at square one. I could propose something to my vendors
based on X.509 certs and SRTP, but now how to I exchange public keys in a
non proprietary way while still having private keys stored in config files
not exchanged over the connection, thus not requiring TLS or the like.