Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft

[Glen Zorn <[e-mail]>]

On 6/1/2011 6:32 PM, Magnus Westerlund wrote:

> On 2011-06-01 12:26, Glen Zorn wrote:
>> On 6/1/2011 3:09 PM, Magnus Westerlund wrote:
>>
>> ...
>>
>>> My immediate reaction is if one can define profiles that are not SuiteB
>>> but use the same encryption and authentication algorithm so they are bit
>>> compatible, but not policy compatible?
>>
>> My understanding is that Suite B is all about policy & packaging; no new
>> algorithms are defined (thankfully!).
> 
> I am not certain about that. RFC 6188 appears to define the crypto part
> matching SuiteB requirement for SRTP, but not the authentication
> algorithm, thus from an SRTP perspective there appear to be new stuff in
> here.
> 
> I am uncertain if there is differences between the PRF for the RFC 6188
> and the SuiteB draft.

I think that they are the same, though the draft under discussion could
use a bit more discussion a la 6188.

> 
> So, this specification clearly brings new combinations of encryption and
> authentication and might in fact be a completely new crypto suite if the
> PRF is different with RFC 6188.

[disclaimer: I am _not_ a cryptographer!]
RFC 6188 specifies the use of AES-CM (AKA AES-CTR) with 192- and 256-bit
keys for the encryption of data, but the draft in question specifies the
use of AES-GCM with 128- and 256-bit keys.  My understanding is that CM
& GCM are significantly different; in addition, 6188 uses HMAC-SHA1 for
authentication, while the use of AES-GCM obviates the need for a
separate authentication function.  So it appears to me that a new
cryptosuite is being defined, regardless of whether or not the PRF is
identical...

> 
> The question I have to the WG is if it is worth handling the actual SRTP
> crypto transform defintion from the actual profiles and the additional
> requirements on key management. Thus allowing the usage of the crypto
> transforms themselves outside of a SuiteB context, which clearly can't
> be called SuiteB but which for example is AES-256 with SHA-256 in SRTP
> and some other key management.

Maybe I'm just dull, but I'm still not getting the point.  It looks to
me as if the authors are just stating what it will take to get an SRTP
implementation approved for US government usage in certain situations.
Why would you want to tell them that they can't?  Further (if my
presumption is correct), why is it necessary for the document to go
through this WG at all, given the intended status of Informational?  If
avtcore wants to specify a million different ciphersuites that's fine,
but what does it have to do with this draft?

> 
>>
>>>
>>> Independent I think you need to make it clear in the document that
>>> SuiteB does contain these policy rules.
>>
>> I don't really understand this comment: the very first sentence of the
>> Abstract says The United States government has published guidelines for
>> "NSA Suite B Cryptography", which defines cryptographic algorithm policy
>> for national security applications.
>> ^^^^^^
>>
>> I don't know how it could be made much clearer or more obvious.
>>
>> ...
> 
> What I meant is the fact that SuiteB key management is not allowed to
> use Security Descriptions nor MIKEY per policy. 

I'm not sure that it is solely a matter of policy; does MIKEY have a
profile that uses elliptic-curve cryptography?  IIRC, that was
intentionally omitted due to IPR concerns.  Furthermore, SDP is an
unauthenticated protocol.

> The stress on the quoted
> sentence are "these" where "these" referring to forcing usage of DTLS.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> 
>