The Use of AES-192 and AES-256 in Secure RTP
RFC 6188

[Ballot comment]
Please consider the nit and editorial comments from the Gen-ART Review
  by Richard Barnes on 10-Dec-2010:
  >
  > [Section3] In the first sentence, should "AES_CM PRF" be changed
  > to "AES_CM_PRF"?
  >
  > [Section3.1] Do you want to say explicitly that stronger KDFs MAY
  > be used?  That you could use the AES_256_CM KDF with AES_192_CM as
  > the bulk encryption algorithm, or use either 192 or 256 with 128?

[Ballot discuss]
The Gen-ART Review by Richard Barnes on 10-Dec-2010 raises a question
  that deserves a response.  I have not see a response to the question.
  >
  > The Suite B specifications require the use of SHA-256 and SHA-384 as
  > hash functions for SECRET and TOP SECRET, respectively.  Given that
  > Suite B compatibility is listed as an objective of this document, it
  > seems like there should be a cryptosuite that would use Suite B hash
  > algorithms as well as encryption algorithms.

[Ballot comment]
#1) Support Russ' and Tim's discusses.

#2) Section 3:

  In
  this note, the AES-192 counter mode PRF and AES-256 counter mode PRF
  are and are denoted as AES_192_CM_PRF and AES_256_CM_PRF
  respectively.

extra words "are and"?

#3) Section 3.1 (similar to Russ's 2nd comment): Should the rationale include a MUST?  For example:

  The cryptographic strength of the key derivation function MUST
  meet or exceed the cryptographic strength of the encryption method.

[Ballot discuss]
I don't think SHA-1 is part of any Suite B specifications.  Because of this, it's unclear to me that you should hint that by implementing this RFC an implementation would be considered Suite B compliant.

[Ballot comment]
Please note Hilarie Orman's secdir review.

(1) In particular, she notes:

The block counter "b_c" is two octets, but the "default key lifetime"
is 2^31.  Is this perhaps the "maximum" key lifetime?  Should
implementors introduce an internal counter to keep track of the
history of key usage (across sessions?)?  Perhaps earlier documents
explain this?

Should implementers use the rollover counter (ROC) from RFC 3711
in combination with b_c, or is there another mechanism that the
authors had in mind?

(2)  You might consider moving the rationale to the front of the section
as an alternative to Hilarie's suggestions on section 3.1,

[Ballot discuss]
Tables 2 and 4 appear to have a cut-and-paste error: in each case, the SRTCP
authentication tag length is 80 bits instead of the 32 bit length indicated by the
cryptosuite name.  (If the tag length *is* correct we have a different problem: the
SRTCP cryptosuites would then have four names but only two distinct cryptosuites.)

A brief note regarding the maximum key lifetime for AES counter mode, or a pointer
to a previous RFC with that discussion should probably be added to the security
considerations.

[Ballot discuss]
Tables 2 and 4 appear to have a cut-and-paste error: in each case, the SRTCP authentication tag length is 80 bits
instead of the 32 bit length indicated by the cryptosuite name.  (If the tag length *is* correct we have a different
problem: the SRTCP cryptosuites would then have four names but only two distinct cryptosuites.)

A brief note regarding the maximum key lifetime for AES counter mode, or a pointer to a previous RFC with that
discussion should probably be added to the security considerations.

[Ballot comment]
Please note Hilarie Orman's secdir review.

In particular, she notes:

The block counter "b_c" is two octets, but the "default key lifetime"
is 2^31.  Is this perhaps the "maximum" key lifetime?  Should
implementors introduce an internal counter to keep track of the
history of key usage (across sessions?)?  Perhaps earlier documents
explain this?

Should implementers use the rollover counter (ROC) from RFC 3711
in combination with b_c, or is there another mechanism that the
authors had in mind?

[Ballot discuss]
Tables 2 and 4 appear to have a cut-and-paste error: in each case, the SRTCP authentication tag length is 80 bits
instead of the 32 bit length indicated by the cryptosuite name.  (If the tag length *is* correct we have a different problem:
the SRTCP cryptosuites would then have four names but only two distinct cryptosuites.)

A brief note regarding the maximum key lifetime for AES counter mode, or a pointer to a previous RFC with that
discussion should probably be added to the security considerations.

[Ballot comment]
Please consider the nit and editorial comments from the Gen-ART Review
  by Richard Barnes on 10-Dec-2010:
  >
  > [Section3] In the first sentence, should "AES_CM PRF" be changed
  > to "AES_CM_PRF"?
  >
  > [Section3.1] Do you want to say explicitly that stronger KDFs MAY
  > be used?  That you could use the AES_256_CM KDF with AES_192_CM as
  > the bulk encryption algorithm, or use either 192 or 256 with 128?

[Ballot discuss]
The Gen-ART Review by Richard Barnes on 10-Dec-2010 raises a question
  that deserves a response.  I have not see a response to the question.
  >
  > The Suite B specifications require the use of SHA-256 and SHA-384 as
  > hash functions for SECRET and TOP SECRET, respectively.  Given that
  > Suite B compatibility is listed as an objective of this document, it
  > seems like there should be a cryptosuite that would use Suite B hash
  > algorithms as well as encryption algorithms.

[Ballot comment]
3.1.  Usage Requirements

  When AES_192_CM is used for encryption, AES_192_CM SHOULD be used as

I think the 2nd AES_192_CM should be AES_192_CM_PRF

  the key derivation function, and AES_128_CM MUST NOT be used as the

s/AES_128_CM/AES_128_CM_PRF ?

  key derivation function.

  When AES_256_CM is used for encryption, AES_256_CM SHOULD be used as
  the key derivation function.  Both AES_128_CM and AES_192_CM MUST NOT
  be used as the key derivation function.

Same comments as above.

IANA understands that a single IANA Action is required upon approval of
this document.

In the SRTP Crypto Suite Registrations subregistry of the Session
Description Protocol (SDP) Security Descriptions registry located at:

http://www.iana.org/assignments/sdp-security-descriptions

four new registrations will be added as follows:

Crypto Suite Name Reference
AES_192_CM_HMAC_SHA1_80 [RFC-to-be]
AES_192_CM_HMAC_SHA1_32 [RFC-to-be]
AES_256_CM_HMAC_SHA1_80 [RFC-to-be]
AES_256_CM_HMAC_SHA1_32 [RFC-to-be]

IANA understands this to be the only action required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The use of AES-192 and AES-256 in Secure RTP) to Proposed Standard


The IESG has received a request from the Audio/Video Transport WG (avt)
to consider the following document:
- 'The use of AES-192 and AES-256 in Secure RTP'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-big-aes/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-big-aes/

Shepherd writeup for draft-ietf-avt-srtp-big-aes-05 "The use of AES-192
and AES-256 in Secure RTP" as proposed standard.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd for this document is Keith Drage.

The document shepherd has reviewed the document and believes it is ready for
forwarding to the IESG for publication.

Document history:

- draft-mcgrew-avt-srtp-big-aes-00 was submitted 26th April 2006
and expired 28th October 2006;
- draft-mcgrew-avt-srtp-big-aes-01 was submitted 5th March 2009
and expired 6th September 2009;
[- draft-ietf-avt-srtp-big-aes-00 was submitted 24th August 2006
and expired 15th February 2007];
- draft-ietf-avt-srtp-big-aes-01 was submitted 6th July 2009 and
expired 7th February 2010;
- draft-ietf-avt-srtp-big-aes-02 was submitted 25th October 2009
and expired 28th April 2010;
- draft-ietf-avt-srtp-big-aes-03 was submitted 8th March 2010 and
expired 9th September 2010;
- draft-ietf-avt-srtp-big-aes-04 was submitted 15th September 2010
and expires 19th March 2011.
- draft-ietf-avt-srtp-big-aes-05 was submitted 29th September 2010
and expires 2nd June 2011.

Call for adoption of baseline as WG item was made 10th March 2009.

Working group last calls were held on the document as follows:
- 15th June 2010 to complete 29th June 2010 on -03 version as
proposed standard. Reviews were received from Jonathan Lennox, Glen
Zorn and Cullen Jennings.

Prior to WGLC the document was reviewed by John Mattsson

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has been adequately reviewed (see 1a above)

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

The document has not yet had a full security directorate review.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There are no concerns from the document shepherd perspective with the document.

The AD has asked questions concerning the use case for these extended values.
This has been responded to on the mailing list, essentially identifying that
while existing SRTP mechanisms are considered secure, many contracts are now
calling for the availability of extended keys.

No IPR disclosures have been made against this document.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

The interest in this document has been relatively small, but it has been well
reviewed by experts (and implementation experience has been applied to the
document as well). Note that the document itself contains few implementable
requirements directly, but does need to be taken into account in implementing
the extended keys.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No appeals or areas of conflict or discontent have been identified.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Version 2.12.05 of ID nits identifies no issues.

As a security related document, documents of this scope would normally merit a
security review before publication request. No such review has yet been
performed, although it is believed the document is simple enough to not be
contentious.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document does split normative and informative references. All the normative
references have been reviewed and are correctly allocated as normative
references. None of these normative references constitute a down reference.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

An IANA considerations section is included and the

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The only formal language is contained in the test cases.

The test cases were generated in a semi-automated way, using some hand-
generated inputs and a command-line application that does AES and XOR
operations.  Most importantly, these cases were checked by John
Mattsson of Ericsson, who used completely independent software and a 
different, more automated methodology.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.
    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?
    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

This document describes the use of the Advanced Encryption Standard
(AES) with 192 and 256 bit keys within the Secure RTP protocol.  It
details Counter Mode encryption for SRTP and SRTCP and a new SRTP Key
Derivation Function (KDF) for AES-192 and AES-256.

The document achieved consensus in the AVT working group.

David McGrew, Jonathan Lennox (in the the open-source libsrtp project) and
Philip Zimmermann (in libZRTP) have indicated implementations of this
internet-draft.