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

[Mark Baugher <mbaugher at cisco.com>]

Gonzalo,
  I think Security Descriptions is probably the way to go when you 
replace k= and I think we're agreed that you need to replace k=.  I'd 
like to hear any opinions my co-authors might have but this sounds like 
a Security Descriptions usage.

Mark
On Feb 23, 2005, at 1:46 AM, Gonzalo Camarillo wrote:

> Mark,
>
> >   This sounds okay to me but there are a few additional things to 
> > consider.  What if you want to change to a different cryptographic 
> > hashing algorithm than SHA-1?  Is there any chance that the 
> > application might need to offer some alternatives and allow these to 
> > be negotiated?  Have you considered using SDP Security Descriptions 
> > in place of k= for this purpose?
>
> Yes, having a way to negotiate different hashing algorithms is 
> something that we may want to add to BFCP. We could add to the "DIGEST 
> TLV Required" error response a placeholder for different algorithm 
> identifiers. This way, a client would obtain the algorithms supported 
> by the server on reception of the same response that would carry the 
> nonce.
>
> So, I do not see any problem with adding this feature to the protocol. 
> However, the MMUSIC draft also defines a nonce attribute. The idea is 
> that a client can obtain the first nonce directly in the SDP. This 
> way, the server does not need to challenge the first message from the 
> client only to provide a nonce.
>
> But if the purpose of the challenge is not only to provide a nonce, 
> but also to provide a list of algorithms, either we get rid of the SDP 
> nonce attribute and forget about the optimization, or we include the 
> list of algorithms in the SDP as well. If we decide to include it, the 
> 'crypto' algorithm defined in SDP Security Descriptions could carry 
> the list of algorithms.
>
> So, the options are:
>
> 1) The client can only discover the algorithms supported by the server 
> using BFCP. We use the SDP 'k' line
>
> 2) SDP is used to provide the client with an initial nonce and the 
> list of agorithms supported by the server. We use SDP Security 
> Descriptions. We would need to define a new transport (the only one 
> defined so far is SRTP) and define tags for the crypto suites 
> applicable to BFCP
>
>
> My proposal would be to go for 2)
>
> Comments?
>
> Gonzalo

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