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

["Igoe, Kevin M." <[e-mail]>]

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.

 

 

 

 

 

 

> -----Original Message-----

> From: Magnus Westerlund [mailto:[e-mail]]

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

> To: Glen Zorn

> Cc: Igoe, Kevin M.; [e-mail]

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

> 

> Glen and Kevin

> 

> Please see inline.

> 

> On 2011-06-01 15:12, Glen Zorn wrote:

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

> 

> >

> >>

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

> 

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

> 

> >

> >>

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

> 

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

> 

> >

> >>

> >>>

> >>>>

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

> 

> 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

> 

> ----------------------------------------------------------------------

> Multimedia Technologies, Ericsson Research EAB/TVM

> ----------------------------------------------------------------------

> Ericsson AB                | Phone  [phone]

> Färögatan 6                | Mobile [phone]

> SE-164 80 Stockholm, Sweden| mailto: [e-mail]

> ----------------------------------------------------------------------