[XCON] Re: [MMUSIC] BFCP: SDP usage and k=

[Mark Baugher <mbaugher at cisco.com>]

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:

> On Sat, 12 Feb 2005, Mark Baugher wrote:
>
> > 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?
>
> 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

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

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
> the public key can be exchanged clear text and the voice encrypted with
> the endpoint secret key and the remote endpoint public key?

Both sets of solutions use public key cryptography, at least as an  
option.
draft-ietf-sipping certs uses S/MIME.
> 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.

draft-ietf-mmusic-sdescriptions does this.  MIKEY does it differently.
> 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.

Since you're the service provider, the vendor might suggest which
of the standards they plan to offer for sale.
> 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.

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
> > <>
> Nathan Stratton                                   BroadVoice, Inc.
> nathan at robotics.net                                 Talk IS Cheap
> http://www.robotics.net                            
> http://www.broadvoice.com
>
> > Mark

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon