Network Working GroupS. Kanno
Internet-DraftNTT Software Corporation
Intended status: Standards TrackM. Kanda
Expires: October 8, 2009Nippon Telegraph and Telephone
 Corporation
 April 06, 2009


The Camellia Algorithm and Its Use wiht the Secure Real-time Transport Protocol(SRTP)
draft-avt-kanno-srtp-camellia-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 8, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document describes the use of the Camellia block cipher algorithm in 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).



1.  Introduction

This document describes the use of the Camellia [RFC3713] (Matsui, M., Nakajima, J., and S. Moriai, “A Description of the Camellia Encryption Algorithm,” April 2004.) block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) [RFC3711] (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) for providing confidentiality for the Real-time Transport Protocol (RTP) [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP) [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.).



1.1.  Camellia

Camellia is a symmetric cipher with a Feistel structure. Camellia was developed jointly by NTT and Mitsubishi Electric Corporation in 2000. It was designed to withstand all known cryptanalytic attacks, and it has been scrutinized by worldwide cryptographic experts. Camellia is suitable for implementation in software and hardware, offering encryption speed in software and hardware implementations that is comparable to Advanced Encryption Standard (AES) [FIPS.197.2001] (National Institute of Standards and Technology, “Advanced Encryption Standard (AES),” November 2001.).

Camellia supports 128-bit block size and 128-, 192-, and 256-bit key lengths, i.e., the same interface specifications as the AES. Therefore, it is easy to implement Camellia based algorithms by replacing the AES block of AES based algorithms with a Camellia block.

Camellia already has been adopted by the IETF and other international standardization organizations; in particular, the IETF has published specifications for the use of Camellia with IPsec [RFC4312] (Kato, A., Moriai, S., and M. Kanda, “The Camellia Cipher Algorithm and Its Use With IPsec,” December 2005.), TLS [RFC4132] (Moriai, S., Kato, A., and M. Kanda, “Addition of Camellia Cipher Suites to Transport Layer Security (TLS),” July 2005.), S/MIME [RFC3657] (Moriai, S. and A. Kato, “Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS),” January 2004.) and XML Security [RFC4051] (Eastlake, D., “Additional XML Security Uniform Resource Identifiers (URIs),” April 2005.). Camellia is one of the three ISO/IEC international standard [ISO/IEC 18033‑3] (International Organization for Standardization, “Information technology - Security techniques - Encryption algorithms - Part 3: Block ciphers,” July 2005.) 128-bit block ciphers (Camellia, AES, and SEED). Camellia was selected as a recommended cryptographic primitive by the EU NESSIE (New European Schemes for Signatures, Integrity and Encryption) project [NESSIE] (, “The NESSIE project (New European Schemes for Signatures, Integrity and Encryption),” .) and was included in the list of cryptographic techniques for Japanese e-Government systems that was selected by the Japanese CRYPTREC (Cryptography Research and Evaluation Committees) [CRYPTREC] (Information-technology Promotion Agency (IPA), “Cryptography Research and Evaluation Committees,” .).

Since optimized source code is provided under several open source licenses [open source license] (, “Camellia open source software,” .), Camellia is also adopted by several open source projects (OpenSSL, GnuTLS, FreeBSD, and Linux). Camellia is also adopted by Mozilla and Camellia is ready for use with Firefox 3.0 released in June 2008.

The algorithm specification and object identifiers are described in [RFC3713] (Matsui, M., Nakajima, J., and S. Moriai, “A Description of the Camellia Encryption Algorithm,” April 2004.).

The Camellia web site [Camellia web site] (, “Camellia web site,” .) contains a wealth of information about Camellia, including detailed specification, security analysis, performance figures, reference implementation, optimized implementation, test vectors(TV), and intellectual property information.



1.2.  Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that appear in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



2.  Camellia Algorithm Suites for SRTP

All symmetric block cipher algorithms share common characteristics and valuables, including mode, key size, weak keys, and block size. Camellia algorithm is specified as well as AES, those relations are following:

    a) Camellia-CTR comply with [RFC3711]
    b) Camellia-GCM/CCM comply with [AES-GCM/CCM]



3.  Default and mandatory-to-implement Transforms

The default transforms also are mandatory-to-implement transforms in SRTP. Of course, "mandatory-to-implement" does not imply "mandatory- to-use". Table 1 summarizes the pre-defined transforms. The default values below are valid for the pre-defined transforms.


                        man.-to-impl.  optional            default
   encryption           Camellia-CTR   Camellia-CCM, -GCM  Camellia-CTR
   message integrity    HMAC-SHA1      Camellia-CCM, -GCM  HMAC-SHA1
   key derivation (PRF) Camellia-CTR            -          Camellia-CTR

Table 1: Mandatory-to-implement, optional and default transforms in SRTP and SRTCP.



4.  Security Considerations

At the time of writing this document, there are no known weak keys for Camellia. Also, No security problem has been found on Camellia. Camellia is secure against all known attacks including Differential cryptanalysis, linear cryptanalysis, and related key attacks.

The security considerations in RFC 5289 [RFC3711] (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) and Draft of AES-GCM and AES-CCM for SRTP [AES‑GCM/CCM] (McGrew, D., “AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP),” October 2008.) apply to this document as well.



5.  IANA Considerations

RFC 4568 [RFC4568] (Andreasen, F., Baugher, M., and D. Wing, “Session Description Protocol (SDP) Security Descriptions for Media Streams,” July 2006.) defines SRTP "crypto suites"; also, [AES‑GCM/CCM] (McGrew, D., “AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP),” October 2008.) defines a crypto suite corresponds to a particular AEAD algorithm in SRTP. In order to allow SDP to signal the use of the algorithms defined in this document, IANA will register the following crypto suites into the subregistry for SRTP crypto suites under the SRTP transport of the SDP Security Descriptions:

      srtp-crypto-suite-ext = "CAMELLIA_CM_128_HMAC_SHA1_80" /
                              "CAMELLIA_CM_128_HMAC_SHA1_32" /
                              "AEAD_CAMELLIA_128_GCM"        /
                              "AEAD_CAMELLIA_256_GCM"        /
                              "AEAD_CAMELLIA_128_GCM_8"      /
                              "AEAD_CAMELLIA_256_GCM_8"      /
                              "AEAD_CAMELLIA_128_GCM_12"     /
                              "AEAD_CAMELLIA_256_GCM_12"     /
                              "AEAD_CAMELLIA_128_CCM"        /
                              "AEAD_CAMELLIA_256_CCM"        /
                              srtp-crypto-suite-ext


6.  Test Vectors

TBD.



7.  References



7.1. Normative References

[AES-GCM/CCM] McGrew, D., “AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP),” draft-mcgrew-srtp-aes-gcm-00 (work in progress), October 2008.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” STD 64, RFC 3550, July 2003 (TXT, PS, PDF).
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” RFC 3711, March 2004 (TXT).
[RFC3713] Matsui, M., Nakajima, J., and S. Moriai, “A Description of the Camellia Encryption Algorithm,” RFC 3713, April 2004 (TXT).
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, “Session Description Protocol (SDP) Security Descriptions for Media Streams,” RFC 4568, July 2006 (TXT).


7.2. Informative References

[CRYPTREC] Information-technology Promotion Agency (IPA), “Cryptography Research and Evaluation Committees” (HTML).
[Camellia web site] Camellia web site.”
[FIPS.197.2001] National Institute of Standards and Technology, “Advanced Encryption Standard (AES),” FIPS PUB 197, November 2001.
[ISO/IEC 18033-3] International Organization for Standardization, “Information technology - Security techniques - Encryption algorithms - Part 3: Block ciphers,” ISO/IEC 18033-3, July 2005.
[NESSIE] The NESSIE project (New European Schemes for Signatures, Integrity and Encryption).”
[RFC3657] Moriai, S. and A. Kato, “Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS),” RFC 3657, January 2004 (TXT).
[RFC4051] Eastlake, D., “Additional XML Security Uniform Resource Identifiers (URIs),” RFC 4051, April 2005 (TXT).
[RFC4132] Moriai, S., Kato, A., and M. Kanda, “Addition of Camellia Cipher Suites to Transport Layer Security (TLS),” RFC 4132, July 2005 (TXT).
[RFC4312] Kato, A., Moriai, S., and M. Kanda, “The Camellia Cipher Algorithm and Its Use With IPsec,” RFC 4312, December 2005 (TXT).
[open source license] Camellia open source software.”


Authors' Addresses

  Satoru Kanno
  NTT Software Corporation
Phone:  +81-45-212-7577
Fax:  +81-45-212-9800
Email:  kanno-s@po.ntts.co.jp
  
  Masayuki Kanda
  Nippon Telegraph and Telephone Corporation
Phone:  +81-422-59-3456
Fax:  +81-422-59-4015
Email:  kanda.masayuki@lab.ntt.co.jp