The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)
draft-ietf-avtcore-aria-srtp-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-10-10
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-09-22
|
11 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-09-05
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-09-05
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
2017-09-04
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-09-01
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-09-01
|
11 | (System) | IANA Action state changed to In Progress from Waiting on ADs |
2017-08-29
|
11 | (System) | RFC Editor state changed to IANA from EDIT |
2017-08-10
|
11 | (System) | RFC Editor state changed to EDIT |
2017-08-10
|
11 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-08-10
|
11 | (System) | Announcement was received by RFC Editor |
2017-08-10
|
11 | (System) | IANA Action state changed to Waiting on ADs from In Progress |
2017-08-10
|
11 | (System) | IANA Action state changed to In Progress |
2017-08-10
|
11 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2017-08-10
|
11 | Cindy Morgan | IESG has approved the document |
2017-08-10
|
11 | Cindy Morgan | Closed "Approve" ballot |
2017-08-10
|
11 | Ben Campbell | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2017-08-10
|
11 | Ben Campbell | Ballot approval text was generated |
2017-08-08
|
11 | Amy Vezza | Changed consensus to Yes from Unknown |
2017-08-08
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-08-08
|
11 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-11.txt |
2017-08-08
|
11 | (System) | New version approved |
2017-08-08
|
11 | (System) | Request for posting confirmation emailed to previous authors: Woo-Hwan Kim , Je Park , Daesung Kwon , Dong-Chan Kim , Jungkeun Lee |
2017-08-08
|
11 | Woo-Hwan Kim | Uploaded new revision |
2017-08-03
|
10 | Amy Vezza | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2017-08-02
|
10 | Kathleen Moriarty | [Ballot comment] Although this is not a discuss, I think updated text would be very helpful on the following two issues. I agree with the … [Ballot comment] Although this is not a discuss, I think updated text would be very helpful on the following two issues. I agree with the SecDir reviewer that there should be more text around the short tag length in the security considerations section. I don't see a response to that post though. For SHA-1, a reference to RFC6194 for the security considerations for SHA-1message digest algorithms would be helpful. Thank you! |
2017-08-02
|
10 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-08-02
|
10 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-08-02
|
10 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-08-02
|
10 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-08-01
|
10 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-08-01
|
10 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-08-01
|
10 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2017-08-01
|
10 | Alexey Melnikov | [Ballot comment] +1 regarding SHA-1 |
2017-08-01
|
10 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2017-07-31
|
10 | Mirja Kühlewind | [Ballot comment] This actually looks more like a document that we would rather typically publish by the ISE (as it is describing a method employed … [Ballot comment] This actually looks more like a document that we would rather typically publish by the ISE (as it is describing a method employed by one specific entity only). I do not object to it publication as informational and I do understand that this mostly due to the registration the in the MIKEY registry, however, i would like to note that IESG Approval would have been another option for this registration. |
2017-07-31
|
10 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-07-29
|
10 | Warren Kumari | [Ballot comment] I agree with most of Ben Laurie's SecDir comments, and Ben's questions on SHA-1, but will leave it to the Sec ADs to … [Ballot comment] I agree with most of Ben Laurie's SecDir comments, and Ben's questions on SHA-1, but will leave it to the Sec ADs to evaluate. |
2017-07-29
|
10 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2017-07-29
|
10 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2017-07-16
|
10 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2017-07-12
|
10 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2017-07-10
|
10 | Ben Campbell | Notification list changed to Roni Even <roni.even@huawei.com> |
2017-07-10
|
10 | Ben Campbell | Document shepherd changed to Roni Even |
2017-07-07
|
10 | Ben Campbell | [Ballot comment] I think it would be wise to add a paragraph to the security considerations to call out the dependency on SHA1. A mention … [Ballot comment] I think it would be wise to add a paragraph to the security considerations to call out the dependency on SHA1. A mention of what would need to happen to migrate to newer hash functions could also be helpful. |
2017-07-07
|
10 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2017-07-07
|
10 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2017-07-07
|
10 | Ben Campbell | Ballot has been issued |
2017-07-07
|
10 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2017-07-07
|
10 | Ben Campbell | Created "Approve" ballot |
2017-07-07
|
10 | Ben Campbell | Ballot writeup was changed |
2017-07-07
|
10 | Ben Campbell | Ballot approval text was generated |
2017-07-06
|
10 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour. |
2017-06-30
|
10 | Ben Campbell | Placed on agenda for telechat - 2017-08-03 |
2017-06-30
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-06-30
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-06-30
|
10 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-10.txt |
2017-06-30
|
10 | (System) | New version approved |
2017-06-30
|
10 | (System) | Request for posting confirmation emailed to previous authors: avtcore-chairs@ietf.org, Je-Hong Park , Woo-Hwan Kim , Jungkeun Lee , Daesung Kwon |
2017-06-30
|
10 | Woo-Hwan Kim | Uploaded new revision |
2017-06-29
|
09 | Ben Campbell | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2017-06-29
|
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Ben Laurie. |
2017-06-29
|
09 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2017-06-26
|
09 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2017-06-26
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-avtcore-aria-srtp-09.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-avtcore-aria-srtp-09.txt. If any part of this review is inaccurate, please let us know. The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the DTLS-SRTP Protection Profiles registry located on the Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP) registry page located at: https://www.iana.org/assignments/srtp-protection/ the following eight profiles are to be registered: Value Profile Reference -----------------------+------------------------------+------------- [ TBD-at-Registration ] SRTP_ARIA_128_CTR_HMAC_SHA1_80 [ RFC-to-be ] [ TBD-at-Registration ] SRTP_ARIA_128_CTR_HMAC_SHA1_32 [ RFC-to-be ] [ TBD-at-Registration ] SRTP_ARIA_192_CTR_HMAC_SHA1_80 [ RFC-to-be ] [ TBD-at-Registration ] SRTP_ARIA_192_CTR_HMAC_SHA1_32 [ RFC-to-be ] [ TBD-at-Registration ] SRTP_ARIA_256_CTR_HMAC_SHA1_80 [ RFC-to-be ] [ TBD-at-Registration ] SRTP_ARIA_256_CTR_HMAC_SHA1_32 [ RFC-to-be ] [ TBD-at-Registration ] SRTP_AEAD_ARIA_128_GCM [ RFC-to-be ] [ TBD-at-Registration ] SRTP_AEAD_ARIA_256_GCM [ RFC-to-be ] Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. Second, in the Encryption algorithm (Value 0) subregistry of the MIKEY Security Protocol Parameters registry on the timedia Internet KEYing (MIKEY) Payload Name Spaces registry page located at: https://www.iana.org/assignments/mikey-payloads/ the following algorithms are to be registered as follows: Value: [ TBD-at-registration ] SRTP encr alg: ARIA-CTR Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] SRTP encr alg: ARIA-GCM Reference: [ RFC-to-be ] IANA Question --> In section 6.2 of the current document the authors state that IANA is "to add the below three encryption algorithms to the "MIKEY Security Protocol Parameters SRTP Type 0 (Encryption algorithm)" -- however, only two are listed. Is there one missing from the document or is the text in section 6.2 incorrect? Third, in the SRTP Pseudo Random Function (Value 5) subregistry also in the MIKEY Security Protocol Parameters registry on the timedia Internet KEYing (MIKEY) Payload Name Spaces registry page located at: https://www.iana.org/assignments/mikey-payloads/ the following function is to be added: Value: [ RFC-to-be ] SRTP PRF: ARIA-CTR Reference: [ RFC-to-be ] The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2017-06-24
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ben Laurie |
2017-06-24
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ben Laurie |
2017-06-22
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2017-06-22
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2017-06-15
|
09 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: avtcore-chairs@ietf.org, ben@nostrum.com, roni.even@mail01.huawei.com, draft-ietf-avtcore-aria-srtp@ietf.org, avt@ietf.org Reply-To: ietf@ietf.org … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: avtcore-chairs@ietf.org, ben@nostrum.com, roni.even@mail01.huawei.com, draft-ietf-avtcore-aria-srtp@ietf.org, avt@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)) to Informational RFC The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)' as Informational RFC A previous version of this draft was last-called as a proposed standard. Due to last call an IESG feedback, the working group made the following changes: -- Changed status to informational -- Removed the registrations for SDP security descriptions. -- Removed the short authentication tag (GCM_8) modes -- Some tweaks on key lifetimes 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 2017-06-29. 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. Abstract This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR, GCM) and a SRTP Key Derivation Function for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and MIKEY parameter sets for the use with ARIA. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-06-15
|
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-06-15
|
09 | Ben Campbell | Last call was requested |
2017-06-15
|
09 | Ben Campbell | IESG state changed to Last Call Requested from Waiting for Writeup |
2017-06-15
|
09 | Ben Campbell | Last call announcement was changed |
2017-06-15
|
09 | Ben Campbell | Last call announcement was generated |
2017-06-15
|
09 | Ben Campbell | Ballot approval text was generated |
2017-06-14
|
09 | Ben Campbell | Ballot approval text was generated |
2017-06-14
|
09 | Ben Campbell | Ballot writeup was changed |
2017-05-27
|
09 | Roni Even | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Write-up for draft-ietf-avtcore-aria-srtp-09 (1) What type of RFC is … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Write-up for draft-ietf-avtcore-aria-srtp-09 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational (2) 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 This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR, GCM) and a SRTP Key Derivation Function for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and MIKEY parameter sets for the use with ARIA. Working Group Summary The primarily thing to note has been the limited interest in this work. Document Quality The document has been reviewed by a small group of persons beyond the authors themselves. Where only one have any significant security expertise (Dan Wing). From an RTP perspective the review situation is better where Colin Perkins, Jonathan Lennox and Shepherd has reviewed it. There exist a number of implementations of the ARIA cipher in SRTP. These are even certified by Telecommunications Technology Association of Korea: http://test.tta.or.kr/research/result/index.jsp?team_cd=N&pageNum=2 And looking at specific products like: http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=987 http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=971 One can see (using Google translate) that they are listed as supporting ARIA. Shepherd notes that this likely means that the cipher and one form of key-management has been implemented. Personnel Roni Even is the Document Shepherd and Ben Campbell is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has previously reviewed the document prior to WG last call. For the writeup the shepherd has re-reviewed the document while checking each point on the checklist manually that aren't caught by ID-nits. ID-nits and IPR disclosure checked. Questions to the authors. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document objective is to describe how to use ARIA is SRTP and MIKEY. No independent verification has been reported on the test vectors. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No need for any review. The document was reviewed by EKR as part of the security review; his comments were about the document being standard track, it is now Informational. (6) Describe any specific concerns or issues that the Document Shepherd has 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. This is clearly a document with narrow interest. At the same time I don't see how IETF can refuse to do national adaptations. But method of working and also registry constraints may need to be considered to simplify other national registrations in the future. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, the shepherd have received confirmation from all authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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? It represent a consensus among few individuals. There was a concern about the document being standard track and since the registration procedure can be met using Informational document, this change was made after the IESG LC (10) 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 publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None, ID-nits reports some potential warnings that has been verified to be false. With the exception of the normative reference to a non IETF document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? Yes, to a WG draft (draft-ietf-avtcore-srtp-aes-gcm) that is now RFC7714, the change can be done by the RFC editor (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Significant parts of the document discusses various crypto suites that are being registered. Thus checking that consistency is reasonably straight forward. The IANA section part that is a bit tricky is MIKEY's. As it has its own system for dealing with the SRTP crypto transform configuration. The shepherd believes he does understand this well enough to be able to verify registration in the right registries. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries created. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language present. |
2017-05-22
|
09 | Roni Even | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Write-up for draft-ietf-avtcore-aria-srtp-09 (1) What type of RFC is … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Write-up for draft-ietf-avtcore-aria-srtp-09 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational (2) 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 This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR, GCM) and a SRTP Key Derivation Function for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and MIKEY parameter sets for the use with ARIA. Working Group Summary The primarily thing to note has been the limited interest in this work. Document Quality The document has been reviewed by a small group of persons beyond the authors themselves. Where only one have any significant security expertise (Dan Wing). From an RTP perspective the review situation is better where Colin Perkins, Jonathan Lennox and Shepherd has reviewed it. There exist a number of implementations of the ARIA cipher in SRTP. These are even certified by Telecommunications Technology Association of Korea: http://test.tta.or.kr/research/result/index.jsp?team_cd=N&pageNum=2 And looking at specific products like: http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=987 http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=971 One can see (using Google translate) that they are listed as supporting ARIA. Shepherd notes that this likely means that the cipher and one form of key-management has been implemented. Personnel Roni Even is the Document Shepherd and Ben Campbell is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has previously reviewed the document prior to WG last call. For the writeup the shepherd has re-reviewed the document while checking each point on the checklist manually that aren't caught by ID-nits. ID-nits and IPR disclosure checked. Questions to the authors. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document objective is to describe how to use ARIA is SRTP and MIKEY. No independent verification has been reported on the test vectors. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Security, someone knowing AES-GCM block ciphers should take a look on this. The document was reviewed by EKR whose comments were about the document being standard track, it is now Informational. (6) Describe any specific concerns or issues that the Document Shepherd has 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. This is clearly a document with narrow interest. At the same time I don't see how IETF can refuse to do national adaptations. But method of working and also registry constraints may need to be considered to simplify other national registrations in the future. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, the shepherd have received confirmation from all authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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? It represent a consensus among few individuals. There was a concern about the document being standard track and since the registration procedure can be met using Informational document, this change was made after the IESG LC (10) 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 publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None, ID-nits reports some potential warnings that has been verified to be false. With the exception of the normative reference to a non IETF document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? Yes, to a WG draft (draft-ietf-avtcore-srtp-aes-gcm) that is now RFC7714, the change can be done by the RFC editor (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Significant parts of the document discusses various crypto suites that are being registered. Thus checking that consistency is reasonably straight forward. The IANA section part that is a bit tricky is MIKEY's. As it has its own system for dealing with the SRTP crypto transform configuration. The shepherd believes he does understand this well enough to be able to verify registration in the right registries. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries created. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language present. |
2016-10-20
|
09 | Ben Campbell | Intended Status changed to Informational from Proposed Standard |
2016-07-14
|
09 | Roni Even | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Write-up for draft-ietf-avtcore-aria-srtp-09 (1) What type of RFC is … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Write-up for draft-ietf-avtcore-aria-srtp-09 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational (2) 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 This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR, GCM) and a SRTP Key Derivation Function for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and MIKEY parameter sets for the use with ARIA. Working Group Summary The primarily thing to note has been the limited interest in this work. Document Quality The document has been reviewed by a small group of persons beyond the authors themselves. Where only one have any significant security expertise (Dan Wing). From an RTP perspective the review situation is better where Colin Perkins, Jonathan Lennox and Shepherd has reviewed it. There exist a number of implementations of the ARIA cipher in SRTP. These are even certified by Telecommunications Technology Association of Korea: http://test.tta.or.kr/research/result/index.jsp?team_cd=N&pageNum=2 And looking at specific products like: http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=987 http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=971 One can see (using Google translate) that they are listed as supporting ARIA. Shepherd notes that this likely means that the cipher and one form of key-management has been implemented. Personnel Roni Even is the Document Shepherd and Ben Campbell is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has previously reviewed the document prior to WG last call. For the writeup the shepherd has re-reviewed the document while checking each point on the checklist manually that aren't caught by ID-nits. ID-nits and IPR disclosure checked. Questions to the authors. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, a significant concern regarding security aspects of this document. The RTP aspects are sufficiently reviewed. Also, no independent verification has been reported on the test vectors. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Security, someone knowing AES-GCM block ciphers should take a look on this. (6) Describe any specific concerns or issues that the Document Shepherd has 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. This is clearly a document with narrow interest. At the same time I don't see how IETF can refuse to do national adaptations. But method of working and also registry constraints may need to be considered to simplify other national registrations in the future. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, the shepherd have received confirmation from all authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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? It represent a consensus among few individuals. There was a concern about the document being standard track and since the registration procedure can be met using Informational document, this change was made after the IESG LC (10) 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 publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None, ID-nits reports some potential warnings that has been verified to be false. With the exception of the normative reference to a non IETF document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? Yes, to a WG draft (draft-ietf-avtcore-srtp-aes-gcm) that is now RFC7714, the change can be done by the RFC editor (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Significant parts of the document discusses various crypto suites that are being registered. Thus checking that consistency is reasonably straight forward. The IANA section part that is a bit tricky is MIKEY's. As it has its own system for dealing with the SRTP crypto transform configuration. The shepherd believes he does understand this well enough to be able to verify registration in the right registries. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries created. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language present. |
2016-07-14
|
09 | Roni Even | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. Write-up for draft-ietf-avtcore-aria-srtp-09 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational (2) 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 This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR, GCM) and a SRTP Key Derivation Function for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and MIKEY parameter sets for the use with ARIA. Working Group Summary The primarily thing to note has been the limited interest in this work. Document Quality The document has been reviewed by a small group of persons beyond the authors themselves. Where only one have any significant security expertise (Dan Wing). From an RTP perspective the review situation is better where Colin Perkins, Jonathan Lennox and Shepherd has reviewed it. There exist a number of implementations of the ARIA cipher in SRTP. These are even certified by Telecommunications Technology Association of Korea: http://test.tta.or.kr/research/result/index.jsp?team_cd=N&pageNum=2 And looking at specific products like: http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=987 http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=971 One can see (using Google translate) that they are listed as supporting ARIA. Shepherd notes that this likely means that the cipher and one form of key-management has been implemented. Personnel Roni Even is the Document Shepherd and Ben Campbell is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has previously reviewed the document prior to WG last call. For the writeup the shepherd has re-reviewed the document while checking each point on the checklist manually that aren't caught by ID-nits. ID-nits and IPR disclosure checked. Questions to the authors. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, a significant concern regarding security aspects of this document. The RTP aspects are sufficiently reviewed. Also, no independent verification has been reported on the test vectors. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Security, someone knowing AES-GCM block ciphers should take a look on this. (6) Describe any specific concerns or issues that the Document Shepherd has 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. This is clearly a document with narrow interest. At the same time I don't see how IETF can refuse to do national adaptations. But method of working and also registry constraints may need to be considered to simplify other national registrations in the future. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, the shepherd have received confirmation from all authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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? It represent a consensus among few individuals. There was a concern about the document being standard track and since the registration procedure can be met using Informational document, this change was made after the IESG LC (10) 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 publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None, ID-nits reports some potential warnings that has been verified to be false. With the exception of the normative reference to a non IETF document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? Yes, to a WG draft (draft-ietf-avtcore-srtp-aes-gcm) that is now RFC7714, the change can be done by the RFC editor (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Significant parts of the document discusses various crypto suites that are being registered. Thus checking that consistency is reasonably straight forward. The IANA section part that is a bit tricky is MIKEY's. As it has its own system for dealing with the SRTP crypto transform configuration. The shepherd believes he does understand this well enough to be able to verify registration in the right registries. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries created. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language present. |
2015-11-25
|
09 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-09.txt |
2015-10-14
|
08 | (System) | Notify list changed from avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org to (None) |
2015-05-29
|
08 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-08.txt |
2015-03-25
|
07 | Cindy Morgan | Shepherding AD changed to Ben Campbell |
2014-10-02
|
07 | Alexey Melnikov | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Alexey Melnikov. |
2014-09-22
|
07 | Woo-Hwan Kim | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2014-09-22
|
07 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-07.txt |
2014-09-18
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Ben Laurie. |
2014-09-13
|
06 | Jouni Korhonen | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jouni Korhonen. |
2014-09-11
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2014-09-08
|
06 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2014-09-08
|
06 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-avtcore-aria-srtp-06. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-avtcore-aria-srtp-06. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: NOTE: the IESG-designated expert for DTLS-SRTP Protection Profiles (http://www.iana.org/assignments/srtp-protection) has sent objections to the IESG mailing list and to avt@ietf.org. IANA cannot register DTLS-SRTP Protection Profiles without expert approval. IANA understands that, upon approval of this document, there are four actions that IANA must complete. First, in the SRTP Crypto Suite Registrations registry under the Session Description Protocol (SDP) Security Descriptions heading at: http://www.iana.org/assignments/sdp-security-descriptions/ The following Crypto Suite Names will be added to the registry, all with a reference of [ RFC-to-be ]: ARIA_128_CTR_HMAC_SHA1_80 ARIA_128_CTR_HMAC_SHA1_32 ARIA_192_CTR_HMAC_SHA1_80 ARIA_192_CTR_HMAC_SHA1_32 ARIA_256_CTR_HMAC_SHA1_80 ARIA_256_CTR_HMAC_SHA1_32 AEAD_ARIA_128_GCM AEAD_ARIA_256_GCM AEAD_ARIA_128_GCM_8 AEAD_ARIA_256_GCM_8 AEAD_ARIA_128_GCM_12 AEAD_ARIA_256_GCM_12 AEAD_ARIA_128_CCM AEAD_ARIA_256_CCM AEAD_ARIA_128_CCM_8 AEAD_ARIA_256_CCM_8 AEAD_ARIA_128_CCM_12 AEAD_ARIA_256_CCM_12 IANA requests that the authors, or the RFC Editor, change the URL in section 5.1 of the document from: http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xml#sdp-security-descriptions-3 to: http://www.iana.org/assignments/sdp-security-descriptions/ Second, in the DTLS-SRTP Protection Profiles registry under the Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP) heading at http://www.iana.org/assignments/srtp-protection/ The following new profiles will be added, pending expert approval: Value: [ TBD-at-registration ] Profile: ARIA_128_CTR_HMAC_SHA1_80 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: ARIA_128_CTR_HMAC_SHA1_32 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: ARIA_192_CTR_HMAC_SHA1_80 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: ARIA_192_CTR_HMAC_SHA1_32 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: ARIA_256_CTR_HMAC_SHA1_80 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: ARIA_256_CTR_HMAC_SHA1_32 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_128_GCM Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_256_GCM Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_128_GCM_8 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_256_GCM_8 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_128_GCM_12 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_256_GCM_12 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_128_CCM Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_256_CCM Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_128_CCM_8 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_256_CCM_8 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_128_CCM_12 Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Profile: AEAD_ARIA_256_CCM_12 Reference: [ RFC-to-be ] IANA requests that the authors, or the RFC Editor, change the URL in section 5.2 of the document from: http://www.iana.org/assignments/srtp-protection/srtp-protection.xml#srtp-protection-1 to: http://www.iana.org/assignments/srtp-protection/ Third, in the Encryption algorithm (Value 0) subregistry under the Multimedia Internet KEYing (Mikey) Payload Name Spaces heading at http://www.iana.org/assignments/mikey-payloads/ three new algorithms are to be registered as follows: Value: [ TBD-at-registration ] SRTP encr alg: ARIA-CTR Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] SRTP encr alg: ARIA-CCM Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] SRTP encr alg: ARIA-GCM Reference: [ RFC-to-be ] IANA requests that the authors, or the RFC Editor, change the URL in section 5.3 of the document from: http://www.iana.org/assignments/mikey-payloads/mikey-payloads.xml#mikey-payloads-26 to: http://www.iana.org/assignments/mikey-payloads/ Fourth, in the MIKEY Security Protocol Parameters SRTP Type 5 (Pseudo Random Function) subregistry also located under the Multimedia Internet KEYing (Mikey) Payload Name Spaces heading at http://www.iana.org/assignments/mikey-payloads/ one new pseudo random function is to be registered as follows: Value: [ TBD-at-registration ] SRTP PRF: ARIA-CTR Reference: [ RFC=to-be ] IANA understands that these four actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2014-09-04
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ben Laurie |
2014-09-04
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ben Laurie |
2014-09-01
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2014-09-01
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2014-08-28
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2014-08-28
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2014-08-28
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-08-28
|
06 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (The ARIA Algorithm and Its … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)) to Proposed Standard The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)' as 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 2014-09-11. 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. Abstract This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the RTP Control Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-08-28
|
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-08-28
|
06 | Alissa Cooper | Last call was requested |
2014-08-28
|
06 | Alissa Cooper | Ballot approval text was generated |
2014-08-28
|
06 | Alissa Cooper | Ballot writeup was generated |
2014-08-28
|
06 | Alissa Cooper | IESG state changed to Last Call Requested from AD Evaluation::External Party |
2014-08-28
|
06 | Alissa Cooper | Last call announcement was generated |
2014-08-27
|
06 | Roni Even | Document shepherd changed to Roni Even |
2014-03-05
|
06 | Amy Vezza | Shepherding AD changed to Alissa Cooper |
2013-11-24
|
06 | Richard Barnes | Waiting to go to LC together with draft-ietf-avtcore-srtp-aes-gcm. |
2013-11-24
|
06 | Richard Barnes | State changed to AD Evaluation::External Party from Publication Requested |
2013-11-20
|
06 | Magnus Westerlund | IETF WG state changed to Submitted to IESG for Publication |
2013-11-20
|
06 | Magnus Westerlund | IESG state changed to Publication Requested |
2013-11-20
|
06 | Magnus Westerlund | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. Write-up for draft-ietf-avtcore-aria-srtp-06 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) 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 This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the RTP Control Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. ARIA is a Korean National standard cipher. Working Group Summary The primarily thing to note has been the limited interest in this work. Document Quality The document has been reviewed by a small group of persons beyond the authors themselves. Where only one have any significant security expertise (Dan Wing). From an RTP perspective the review situation is better where Colin Perkins, Jonathan Lennox and Shepherd has reviewed it. There exist a number of implementations of the ARIA cipher in SRTP. These are even certified by Telecommunications Technology Association of Korea: http://test.tta.or.kr/research/result/index.jsp?team_cd=N&pageNum=2 And looking at specific products like: http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=987 http://test.tta.or.kr/research/result/network.jsp?team_cd=N&num=971 One can see (using Google translate) that they are listed as supporting ARIA. Shepherd notes that this likely means that the cipher and one form of key-management has been implemented. Personnel Magnus Westerlund is the Document Shepherd and Richard Barnes the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has previously reviewed the document prior to WG last call. For the writeup the shepherd has re-reviewed the document while checking each point on the checklist manually that aren't caught by ID-nits. ID-nits and IPR disclosure checked. Questions to the authors. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, a significant concern regarding security aspects of this document. The RTP aspects are sufficiently reviewed. Also, no independent verification has been reported on the test vectors. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Security, someone knowing ARIA and AES-GCM block ciphers should take a look on this. (6) Describe any specific concerns or issues that the Document Shepherd has 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. This is clearly a document with narrow interest. At the same time I don't see how IETF can refuse to do national adaptations. But method of working and also registry constraints may need to be considered to simplify other national registrations in the future. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, the shepherd have received confirmation from all authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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? It represent a consensus among few individuals. (10) 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 publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None, ID-nits reports some potential warnings that has been verified to be false. With the exception of the normative reference to a non IETF document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? Yes, to a WG draft (draft-ietf-avtcore-srtp-aes-gcm) that already has been publication requested. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Yes, RFC5794. Not in downref registry. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Significant parts of the document discusses various crypto suites that are being registered. Thus checking that consistency is reasonably straight forward. The IANA section part that is a bit tricky is MIKEY's. As it has its own system for dealing with the SRTP crypto transform configuration. The shepherd believes he does understand this well enough to be able to verify registration in the right registries. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries created. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language present. |
2013-11-20
|
06 | Magnus Westerlund | State Change Notice email list changed to avtcore-chairs@tools.ietf.org, draft-ietf-avtcore-aria-srtp@tools.ietf.org |
2013-11-20
|
06 | Magnus Westerlund | Responsible AD changed to Richard Barnes |
2013-11-20
|
06 | Magnus Westerlund | Working group state set to Submitted to IESG for Publication |
2013-11-20
|
06 | Magnus Westerlund | IESG state set to Publication Requested |
2013-11-20
|
06 | Magnus Westerlund | IESG process started in state Publication Requested |
2013-11-20
|
06 | Magnus Westerlund | All issues around the write-up has been resolved. |
2013-11-20
|
06 | Magnus Westerlund | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2013-11-20
|
06 | Magnus Westerlund | Changed document writeup |
2013-11-20
|
06 | Magnus Westerlund | Changed document writeup |
2013-11-20
|
06 | Magnus Westerlund | Intended Status changed to Proposed Standard from None |
2013-11-19
|
06 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-06.txt |
2013-11-17
|
05 | Magnus Westerlund | Changed document writeup |
2013-10-31
|
05 | Magnus Westerlund | Write-up found issues needing to be addressed. Also waiting for IPR confirmation. |
2013-10-31
|
05 | Magnus Westerlund | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2013-10-31
|
05 | Magnus Westerlund | Changed document writeup |
2013-10-25
|
05 | Magnus Westerlund | Write-up needs to be completed. |
2013-10-25
|
05 | Magnus Westerlund | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2013-10-25
|
05 | Magnus Westerlund | Annotation tag Doc Shepherd Follow-up Underway set. |
2013-09-24
|
05 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-05.txt |
2013-08-26
|
04 | Magnus Westerlund | Started WG last call to run until 16th of September. |
2013-08-26
|
04 | Magnus Westerlund | IETF WG state changed to In WG Last Call from WG Document |
2013-08-26
|
04 | Magnus Westerlund | Annotation tag Revised I-D Needed - Issue raised by WG cleared. |
2013-08-23
|
04 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-04.txt |
2013-08-15
|
03 | Magnus Westerlund | Two minor issues outstanding. Otherwise shepherd thinks this is ready for WG last call. In WG last call a crypto knowledge reviewer will be needed … Two minor issues outstanding. Otherwise shepherd thinks this is ready for WG last call. In WG last call a crypto knowledge reviewer will be needed to help verify correctness. |
2013-06-26
|
03 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-03.txt |
2013-06-05
|
02 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-02.txt |
2013-05-28
|
01 | Magnus Westerlund | Annotation tag Revised I-D Needed - Issue raised by WG set. |
2012-12-03
|
01 | Magnus Westerlund | Magnus Westerlund provided comments on draft the 8th of May. Revised ID needed. |
2012-12-03
|
01 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-01.txt |
2012-05-22
|
00 | Magnus Westerlund | Changed shepherd to Magnus Westerlund |
2012-05-15
|
00 | Woo-Hwan Kim | New version available: draft-ietf-avtcore-aria-srtp-00.txt |