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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Jun 2011 10:09:47 +0200

On 2011-05-31 14:24, Igoe, Kevin M. wrote:
> Magnus:
> 
>   Thanks for your input.  We'll put this under avtcore per your request.
> As to allowing keying methods other than DTLS, we have no objections
> (obviously) to non-Suite B implementations using them, but in an
> effort to maximize interoperability betwixt Suite B SRTP implementations
> policy dictates that only DTLS keying will be allowed in Suite B mode.
> If another keying methods is used, it is by definition not Suite B compliant.

Ok, so SuiteB also contains beyond the crypto algorithms also usage
rules that affects key management. Are these rulse also forbidding use
cases like Broadcast or multicast where using DTLS-SRTP is in fact
impossible?

> 
> If you think it would be helpful, we could mention the existence of the MIKEY 
> and Security description keying mechanisms, but only with the caveat that their 
> use is forbidden when running in Suite B mode.

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?

Independent I think you need to make it clear in the document that
SuiteB does contain these policy rules.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Glen Zorn <[email-masked]>
Date: Wed, 01 Jun 2011 17:26:53 +0700

On 6/1/2011 3:09 PM, Magnus Westerlund wrote:

...

> compatible, but not policy compatible?

My understanding is that Suite B is all about policy & packaging; no new
algorithms are defined (thankfully!).

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

...

---

From: Glen Zorn <[email-masked]>
Date: Wed, 01 Jun 2011 17:56:04 +0700

On 5/31/2011 3:53 PM, Magnus Westerlund wrote:

> Hi,
> 
> If I understand this document correctly there are actually three pieces
> to it:
> 
> - The SuiteB Crypto algorithms for SRTP
> - The SuiteB specific DTLS-SRTP procedures
> - Registration of DTLS-SRTP protection profiles
> 
> Thus in light of this document and also the ARIA SRTP registration I
> think we should discuss how to handle SRTP crypto algorithms and their
> connection to the keying mechanisms.
> 
> SRTP has at least three different IETF define ways to be keyed:
> - DTLS-SRTP [RFC5764]
> - MIKEY [3830]
> - Security Descriptions [RFC 4568]
> 
> And to my understanding they are all used somewhere.
> 
>>From my perspective as WG chair I wonder if shouldn't require anyone
> that creates a new crypto suit for SRTP to also create the suite
> profiles / identifiers for all of these three keying mechanisms?
> 
> Opinions?

I think that that is wholly unnecessary; however, if the WG wants to do
so, I have no problem with doing it.

...

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Jun 2011 13:32:42 +0200

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

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

Cheers

Magnus Westerlund

---

From: "Peck, Michael A" <[email-masked]>
Date: Wed, 1 Jun 2011 08:35:52 -0400

Magnus, Glen,

Thanks for your comments.  Replies below.

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

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.

>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

>_______________________________________________
>Audio/Video Transport Core Maintenance
>[email-masked]
>https://www.ietf.org/mailman/listinfo/avt

---

From: Glen Zorn <[email-masked]>
Date: Wed, 01 Jun 2011 20:12:56 +0700

> I am uncertain if there is differences between the PRF for the RFC 6188

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

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

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

> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Jun 2011 15:57:21 +0200

Glen and Kevin

Please see inline.

> cryptosuite is being defined, regardless of whether or not the PRF is

Yes, I agree with that assessment. It is a new crypto suite, I missed
the CM vesus GCM difference. I am also not a cryptographer.

But the procedural point here is that they SuiteB does define a not
previous existing definitions of combinations of crypto operations in
the SRTP context.

> but what does it have to do with this draft?

Lets separate the issues here. The first one is if they need to go
through the WG. I think to be strictly correct they are not required to
go through the WG. The only procedural point they are strictly required
to meet are the one of the DTLS protection profiles, which is
specification required. So NSA could based on a NIST specification with
all these details that are in the draft request IANA to register the
DTLS protection profile identifiers.

I do however hope they are here for getting a bit of IETF review of it
and the potential benefit in visibility for the profiles by having an
RFC. So assuming that they want an RFC:

The draft is defining procedures for SRTP crypto transforms that doesn't
exist before. If someone like to reuse those for other key management
systems like Mikey or Security Descriptions they need something to
reference. It would be preferable that this is published as an RFC. And
maybe we should discuss intended status also.

I also don't think I have said anything that they can't get it done. I
have only raised a few things that I think the WG should discuss. And
the reason for that is the following charter text for this WG:

The AVTCORE working group will coordinate closely with the Security Area
while working on maintenance and enhancements to the SRTP Profile.

I would claim that new crypto suits are "enhancements" to SRTP and thus
falls under the this charter item if they want to publish an RFC.

There is an downside to a large amount of crypto suits as it hurts
interoperability. At the same time I think we need to be very permitting
against different nations desire to define how their national standards
are used in SRTP.

> unauthenticated protocol.

I fully understand that there are security concerns here also. And it
depends on the whole combination in the system if it meets the security
requirements one has. From that perspective I am understanding why
SuiteB defines DTLS only.

Please understand that the main case I try to avoid is that we get
unnecessarily many crypto suit definitions when in a SuiteB and "foobar"
specification both uses AES-256 CGM and SHA-256 authentication but in
fact has different definitions of everything that has to do with SRTP
except the underlying crypto algorithms. I rather see that foobar can
reuse most aspect of it and just have its own variations for certain
aspects.

cheers

Magnus Westerlund

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Wed, 1 Jun 2011 14:58:51 -0400

Our intent wasn't to break new ground by introducing a new primitives (GCM)

and DTLS) into SRTP, but rather to follow in the footsteps of an existing  work: 

For GCM we have:

-------------------------------------------------------------------------

Network Working Group                                          D. McGrew

Internet Draft                                       Cisco Systems, Inc.

Intended Status: Informational                          January 26, 2011

Expires: July 30, 2011

    AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)

                      draft-ietf-avt-srtp-aes-gcm-01

Abstract

   This document defines how AES-GCM, AES-CCM, and other Authenticated

   Encryption with Associated Data (AEAD) algorithms, can be used to

   provide confidentiality and data authentication mechanisms in the

   SRTP protocol.

-------------------------------------------------------------------------

(This had an earlier incarnation as draft-mcgrew-srtp-aes-gcm-01, but this

draft eventually expired.)

For DTLS we have:

-------------------------------------------------------------------------

Internet Engineering Task Force (IETF)                         D. McGrew

Request for Comments: 5764                                 Cisco Systems

Category: Standards Track                                    E. Rescorla

ISSN: 2070-1721                                               RTFM, Inc.

                                                                May 2010

  Datagram Transport Layer Security (DTLS) Extension to Establish Keys

           for the Secure Real-time Transport Protocol (SRTP)

Abstract

   This document describes a Datagram Transport Layer Security (DTLS)

   extension to establish keys for Secure RTP (SRTP) and Secure RTP

   Control Protocol (SRTCP) flows.  DTLS keying happens on the media

   path, independent of any out-of-band signalling channel present.

---------------------------------------------------------------------

There is an existing Suite B for TLS (currently undergoing a "bis"):

---------------------------------------------------------------------

Network Working Group                                          M. Salter

Request for Comments: 5430                      National Security Agency

Category: Informational                                      E. Rescorla

                                                       Network Resonance

                                                              R. Housley

                                                          Vigil Security

                                                              March 2009

           Suite B Profile for Transport Layer Security (TLS)

Status of This Memo

   This memo provides information for the Internet community.  It does

   not specify an Internet standard of any kind.  Distribution of this

   memo is unlimited.

 

We wish only to show how to put these three documents together to get

Suite B for DTLS-SRTP.

Do you still think we should go thru avtcore?

P.S.  Thanks for looking at this, we've gotten next to no feedback.

 

> From: Magnus Westerlund [mailto:[email-masked]]

> Sent: Wednesday, June 01, 2011 9:57 AM

> Cc: Igoe, Kevin M.; [email-masked]

> >> So, this specification clearly brings new combinations of encryption

> and

> >> authentication and might in fact be a completely new crypto suite if

> the

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

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

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

> > through this WG at all, given the intended status of Informational?

> If

> > avtcore wants to specify a million different ciphersuites that's

> fine,

> The draft is defining procedures for SRTP crypto transforms that

> doesn't

> The AVTCORE working group will coordinate closely with the Security

> Area

> interoperability. At the same time I think we need to be very

> permitting

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

> >> What I meant is the fact that SuiteB key management is not allowed

> to

> unnecessarily many crypto suit definitions when in a SuiteB and

> "foobar"

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Jun 2011 17:28:46 +0200

Hi Igor,

I have now actually reviewed your document in a bit more detail. And I
am sorry for having confused the matter a bit. I didn't quite understand
the purpose of this document initially. But it is clear to me now that
your draft doesn't define new components to SRTP.

My understanding is that it really only specifies the DTLS-SRTP
protection profile and acceptable procedures to meet the suite-B
requirements when it comes to the DTLS procedures.

Thus I don't think it is necessary for us to have it as a WG item.
Although I think it would be good that you inform the WG on the progress
and let us know about any ongoing last calls.

Do you plan to continue to publish this as an individual submission
directly to the Area Director, or find a WG home for it?

As an suggestion for how to improve the document, I note that you appear
to be lacking an IANA consideration section. You need such a one to
request that the 4 specified DTLS-SRTP protection profiles are registered.

Best Regards

Magnus

-- 

Magnus Westerlund

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Fri, 10 Jun 2011 11:33:49 -0400

Thanks for sparing the time to review this.  At this late date we'll
keep going as an individual submission.  With a bit of luck this 
will be finished before the snow flies.

> Sent: Friday, June 10, 2011 11:29 AM
> To: Igoe, Kevin M.
> Cc: Glen Zorn; [email-masked]
> ----
> ----
> ----
> >                                                                 May
> 2010
> >                                                        Network
> Resonance
> >                                                               R.
> Housley
> >                                                           Vigil
> Security
> >                                                               March
> 2009
> -