Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-03.txt

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Aug 2013 09:11:25 +0200

Authors and WG,

I have reviewed this new version. Thanks for addressing my issue. During
this review I only noticed a small number of minor issues.

Note, I have not verified in any way the test vectors. Nor am I certain
that I can spot any fact error regarding the crypto-algorithms. What I
have done is reviewed the draft consistency and correctness in their
actions to IANA and towards SRTP.

1. Section 5.3:

                              +--------------------------------------+
                              | Encryption | Encryption | AEAD Auth. |
                              | Algorithm  | Key Length | Tag Length |
                              +======================================+
    SRTP_ARIA_128_CTR_HMAC_80 |  ARIA-CTR  | 16 octets  |  80 bits   |
    SRTP_ARIA_128_CTR_HMAC_32 |  ARIA-CTR  | 16 octets  |  32 bits   |
    SRTP_ARIA_192_CTR_HMAC_80 |  ARIA-CTR  | 24 octets  |  80 bits   |
    SRTP_ARIA_192_CTR_HMAC_32 |  ARIA-CTR  | 24 octets  |  32 bits   |
    SRTP_ARIA_256_CTR_HMAC_80 |  ARIA-CTR  | 32 octets  |  80 bits   |
    SRTP_ARIA_256_CTR_HMAC_32 |  ARIA-CTR  | 32 octets  |  32 bits   |

Kim, et al.             Expires December 29, 2013              [Page 18]

Internet-Draft           ARIA Algorithm for SRTP               June 2013

    SRTP_AEAD_ARIA_128_GCM    |  ARIA-GCM  | 16 octets  | 128 bits   |
    SRTP_AEAD_ARIA_128_CCM    |  ARIA-CCM  | 16 octets  | 128 bits   |
    SRTP_AEAD_ARIA_128_GCM_12 |  ARIA-GCM  | 16 octets  |  96 bits   |
    SRTP_AEAD_ARIA_128_CCM_12 |  ARIA-CCM  | 16 octets  |  96 bits   |
    SRTP_AEAD_ARIA_128_GCM_8  |  ARIA-GCM  | 16 octets  |  64 bits   |
    SRTP_AEAD_ARIA_128_CCM_8  |  ARIA-CCM  | 16 octets  |  64 bits   |
    SRTP_AEAD_ARIA_256_GCM    |  ARIA-GCM  | 32 octets  | 128 bits   |
    SRTP_AEAD_ARIA_256_CCM    |  ARIA-CCM  | 32 octets  | 128 bits   |
    SRTP_AEAD_ARIA_256_GCM_12 |  ARIA-GCM  | 32 octets  |  96 bits   |
    SRTP_AEAD_ARIA_256_CCM_12 |  ARIA-CCM  | 32 octets  |  96 bits   |
    SRTP_AEAD_ARIA_256_GCM_8  |  ARIA-GCM  | 32 octets  |  64 bits   |
    SRTP_AEAD_ARIA_256_CCM_8  |  ARIA-CCM  | 32 octets  |  64 bits   |
                              +======================================+

           Figure 1: Mapping MIKEY parameters to AEAD algorithm

Shouldn't you split this into two tables as the last column and legend
are wrong for the first ARIA CTR + SHA-1 HMAC suits which are not AEAD
suites? That way you can use the correct labels on the last column for
auth tag lengths and in the legend.

2. Section A.2. and A.3

In section A.1 I do understand the structure for the test vectors. They
contain both just the Encrypted part and the full RTP header + payload +
ROC that authentication is calculated over, and then the resulting output.

However in A.2 and A.3 where there are AEAD algorithms I am bit
surprised over the split in Encrypted RTP payload and Authentication
tag. Due to AEAD shouldn't the relevant unit to test as input be the
full SRTP packet which contains both the encrypted and the data that is
just authenticated including the AEAD output in the payload location?

You might need a bit more explanation what the test vectors really are
so that one can correctly use them to verify ones implementation.

Next Steps:

Please address the above issues.

I personally think this is ready for going forward to WG last call when
the above is addressed. However, in that last call we will need to get a
review from someone that has sufficient crypto knowledge to be reduce
the risk for any such error making it through. Thus I intended to make
the WG last call's completion dependent on getting such a review.

Cheers

Magnus

On 2013-06-27 07:43, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.
> 
> 	Title           : The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)
> 	Author(s)       : Woo-Hwan Kim
>                           Jungkeun Lee
>                           Dong-Chan Kim
>                           Je-Hong Park
>                           Daesung Kwon
> 	Filename        : draft-ietf-avtcore-aria-srtp-03.txt
> 	Pages           : 32
> 	Date            : 2013-06-26
> 
> Abstract:
>    This document describes 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 Real-time Transport Control
>    Protocol (RTCP).  It details three modes of operation (CTR, CCM, GCM)
>    and a SRTP Key Derivation Function for ARIA.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-avtcore-aria-srtp-03
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-aria-srtp-03
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

Magnus Westerlund

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

---

From: Woo-Hwan Kim <[email-masked]>
Date: Fri, 23 Aug 2013 14:33:16 +0900

1. I agree to your comment and I'll divide the table into two tables, one
for 'Mapping MIKEY parameters to ARIA-CTR with HMAC algorithm' and
the other for 'Mapping MIKEY parameters to AEAD algorithm'.

2. As your comments, the encrypted payload should contain the tag in AEAD.
I'll revise the draft sooner.

Thank you for your effort and time.

Sincerely,
Woo-Hwan Kim