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

["Peck, Michael A" <[e-mail]>]

Magnus, Glen,

Thanks for your comments.  Replies below.

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Magnus Westerlund
>Sent: Wednesday, June 01, 2011 7:33 AM
>To: Glen Zorn
>Cc: [e-mail]; Igoe, Kevin M.
>Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft
>
>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.
>
>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.
>
>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.

The Suite B Profile does not define its own SRTP crypto suites, key derivation, TLS cipher suites, or authentication mechanism but instead makes use of definitions in existing RFCs or other Internet-Drafts. The Suite B Profile describes the Suite B compliant use of all of these to promote interoperability.  (The Suite B profiles of other protocols follow a similar pattern.)

RFC 6188 is not used by our draft (RFC 6188 defines AES-192 and AES-256 SRTP crypto suites using counter mode.  We do not use counter mode or AES-192 in this profile.  We use AES-128 and AES-256 in GCM mode.)

The Suite B Profile makes use of AES-GCM.  As described in section 7 and 8 of our draft, the SRTP crypto suites and DTLS-SRTP SRTP Protection Profiles used by the Suite B Profile are defined in draft-ietf-avt-srtp-aes-gcm.

As described in section 9 of our draft (and in draft-ietf-avt-srtp-aes-gcm), the AES Counter Mode based key derivation function from RFC3711 is used.

>
>>
>>>
>>> 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. The stress on the quoted
>sentence are "these" where "these" referring to forcing usage of DTLS.

This profile specifies the use of DTLS-SRTP as the key management mechanism.
In response to Magnus's other email, I don't think that broadcast and multicast SRTP are forbidden, but rather are just out of scope for this document.

Thanks
Mike Peck

>
>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]
>----------------------------------------------------------------------
>
>_______________________________________________
>Audio/Video Transport Core Maintenance
>[e-mail]
>https://www.ietf.org/mailman/listinfo/avt