Multicast Security J. Liang Internet-Draft University of Science and Intended status: Standards Track Technology Beijing Expires: April 4, 2007 S. Lai H. Deng Hitachi (China) Oct 2006 XTR algorithm for MIKEY draft-liang-msec-mikey-xtr-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 4, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Liang, et al. Expires April 4, 2007 [Page 1] Internet-Draft XTR algorithm for MIKEY Oct 2006 Abstract This document proposes extensions to the encryption and digital signature methods described for use in MIKEY, employing a new method of public cryptographic algorithm called Efficient and Compact Subgroup Trace Representation (XTR stands for ECSTR). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The public key algorithm . . . . . . . . . . . . . . . . . . . 5 3.1. The limits of public key algorithm . . . . . . . . . . . . 5 3.2. Overview of the cryptographic algorithm . . . . . . . . . 5 3.3. XTR algorithm steps . . . . . . . . . . . . . . . . . . . 6 3.4. XTR-DH key exchange . . . . . . . . . . . . . . . . . . . 7 4. XTR-DH data payload (DH) . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Liang, et al. Expires April 4, 2007 [Page 2] Internet-Draft XTR algorithm for MIKEY Oct 2006 1. Introduction This document describes additional algorithms for use in MIKEY. RFC3830 [MIKEY] defines three methods of key exchange during establishment of a TGK. They are the pre-shared key, public key and Diffie-Hellman methods. As the Diffie-Hellman method and the Elliptic curve cryptography Diffie-Hellman method still have the heavy computation and communication problems in their application, there is a need for a new method. XTR is the new method to represent elements of a subgroup of a multiplicative group of a finite field. Application of XTR in cryptographic protocols leads to substantial savings both in communication and computational overhead without compromising security. This document describes and explains the techniques and properties that are relevant for the XTR cryptographic system and its implementation. Liang, et al. Expires April 4, 2007 [Page 3] Internet-Draft XTR algorithm for MIKEY Oct 2006 2. Scenarios MIKEY is mainly intended to be used for peer-to-peer, simple one-to- many, and small-size (interactive) groups. One of the main multimedia scenarios considered when designing MIKEY has been the conversational multimedia scenario, where users may interact and communicate in real-time. peer-to-peer/ many-to-many many-to-many simple one-to-many (distributed) (centralized) ++++ ++++ ++++ ++++ ++++ |. | |A | |B | |A |---- ----|B | --| ++++ | |----------| | | | \ / | | ++++ / ++|. | ++++ ++++ ++++ (S) ++++ |A |---------| ++++ \ / | | | \ ++|B | \ / | ++++ \-----| | \ ++++ / ++++ ++++ \|C |/ |C | | | | | ++++ ++++ Figure 1: Examples of the scenarios Liang, et al. Expires April 4, 2007 [Page 4] Internet-Draft XTR algorithm for MIKEY Oct 2006 3. The public key algorithm This section describes in detail the algorithm and its implementation. 3.1. The limits of public key algorithm Note that by using the DH method as in RFC3830 , the two involved parties will generate a unique unpredictable random key. Therefore, it is not possible to use this DH method to establish a group TEK (as the different parties in the group would end up with different TEKs). It is not the intention of the DH method to work in this scenario, but to be a good alternative in the special peer-to-peer case. 3.2. Overview of the cryptographic algorithm The Diffie-Hellman (DH) key agreement protocol was the first published practical solution to the key distribution problem, allowing two parties that have never met to establish a shared secret key by exchanging information over an open channel. In the basic DH scheme the two parties agree upon a generator g of the multiplicative group GF(p)* of a prime field GF(p) and they each send a random power of g to the other party. Assuming both parties know p and g, each party transmits about log2(p) bits to the other party. As the Internet draft [ECC algorithms for MIKEY] specified, elliptical curve Diffie-Hellman(ECDH) can be used in the MIKEY Diffie-Hellman method. A greatly improved version of the method from that achieves the same communication advantage at a much lower computational cost. The new method is referred as XTR, for Efficient and Compact Subgroup Trace Representation. XTR can be used in conjunction with any cryptographic protocol that is based on the use of subgroups and leads to substantial savings in communication and computational overhead. Furthermore, XTR key generation is very simple. It's proved that using XTR in cryptographic protocols does not affect their security. Full exponentiation in XTR is faster than full scalar multiplication in an Elliptic Curve Cryptosystem (ECC) over a 170-bit prime field, and thus substantially faster than full exponentiation in either RSA or traditional subgroup discrete logarithm systems of equivalent security. XTR keys are much smaller than RSA keys of comparable security. ECC keys allow a smaller representation than XTR keys, but in many circumstances (e.g. storage) ECC and XTR key sizes are comparable. However, XTR is not affected by the uncertainty still marring ECC, which is the unfortunate parameter choices that happen Liang, et al. Expires April 4, 2007 [Page 5] Internet-Draft XTR algorithm for MIKEY Oct 2006 to render the system less secure. Key selection for XTR is very fast compared to RSA, and orders of magnitude easier and faster than for ECC. As a result XTR may be regarded as the best of two worlds, RSA and ECC. It is an excellent alternative to either RSA or ECC in applications such as SSL/TLS (Secure Sockets Layer, Transport Layer Security), public key smartcards, WAP/WTLS (Wireless Application Protocol, Wireless Transport Layer Security), IPSEC/IKE (Internet Protocol Security, Internet Key Exchange), and SET (Secure Electronic Transaction). As elliptical curve Diffie-Hellman(ECDH) can be used in the MIKEY Diffie-Hellman method. Due to the similar property of ECC and XTR algorithms, XTR Diffie-Hellman (XTR-DH) can be used in the MIKEY Diffie-Hellman method too; we specify this mode in this document. 3.3. XTR algorithm steps A.K. Lenstra, E.R. Verheul, proposed the paper of XTR public key system in Crypto'2000. They have given a detailed arithmetic-proven description of this algorithm. Listed below is a brief summary. The detailed theory of key data generation can be refered in XTR public key system. Suppose that Alice and Bob who both have access to the XTR public key data p, q, Tr(g) want to agree on a shared secret key K. This can be done using the following XTR version of the Diffie-Hellman protocol: 1. Alice selects at random a belongs [2,q-3], uses Algorithm of Sa(x)=(x^(a-1),x^a,x^(a+1)) to compute Sa(Tr(g)) = (Tr(g^(a-1)); Tr(g^a); Tr(g^(a+1))) and sends Tr(g^a) to Bob. 2. Bob receives Tr(g^a) from Alice, selects at random b belongs [2,q-3], uses Algorithm of Sb(x)=(x^(b-1),x^b,x^(b+1)) to compute Sb(Tr(g)) = (Tr(g^(b-1)); Tr(g^b); Tr(g^(b+1))) and sends Tr(g^b) to Alice. 3. Alice receives Tr(g^b) from Bob, uses Algorithm of Sa(x)=(x^(a- 1),x^a,x^(a+1)) to compute Sa(Tr(g^b)) = (Tr(g^((a-1)b)); Tr(g^ab); Tr(g^((a+1)b))) and determines K based on Tr(g^ab). Liang, et al. Expires April 4, 2007 [Page 6] Internet-Draft XTR algorithm for MIKEY Oct 2006 4. Bob uses Algorithm of Sb(x)=(x^(b-1),x^b,x^(b+1)) to compute Sb(Tr(g^a)) = (Tr(g^a(b-1)); Tr(g^ab); Tr(g^a(b+1))) and determines K based on Tr(g^ab). The following section defines the method of transporting/establishing a TGK: with the use of a XTR version of Diffie-Hellman(DH) key exchange. In the following , we assume unicast communication for simplicity. In addition to the TGK, a random nonce, denoted RAND, is also transported. The TGK and RAND values are then used to derive TEKs. A timestamp is also sent to avoid replay attacks. In the XTR version of Diffie-Hellman method, the actual TGK is derived from the Diffie-Hellman values exchanged between the peers. The communication and computational overhead of XTR-DH are both about one third of traditional implementations of the Diffie-Hellman protocol that are based on subgroups of multiplicative groups of finite fields, and that achieve the same level of security such as providing perfect forward secrecy(PFS) and flexibility . 3.4. XTR-DH key exchange The following general notation is used: HDR: The general MIKEY header, which includes MIKEY CSB related data (e.g., CSB ID) and information mapping to the specific security protocol used. T: The timestamp, used mainly to prevent replay attacks. IDx: The identity of entity x (IDi=Initiator, IDr=Responder). RAND: Random/pseudo-random byte-string, which is always included in the first message from the Initiator. RAND is used as a freshness value for the key generation. It is not included in update messages of a CSB. SP: Liang, et al. Expires April 4, 2007 [Page 7] Internet-Draft XTR algorithm for MIKEY Oct 2006 The security policies for the data security protocol. XTR-DHx: There is one different payload from RFC3830 [MIKEY]. The DH value exchanged between initiator and responder(XTR-DHi=Initiator, XTR- DHr=Responder). Initiator Responder I_MESSAGE = HDR, T, RAND, [IDi|CERTi],[IDr] {SP}, XTR-DHi, SIGNi ----> R_MESSAGE = <---- HDR, T, [IDr|CERTr], IDi, XTR-DHr, XTR-DHi, SIGNr Figure 2: Examples of the scenarios The main objective of the Initiator message is to, in a secure way, provide the Responder with its XTR-DH value Tr(g^a), where a MUST be randomly/pseudo-randomly and secretly chosen, and a set of security protocol parameters. The SIGNi is a signature covering the Initiator MIKEY message, I_MESSAGE, using the Initiator signature key. The main objective of the Responder message is to, in a secure way, provide the Initiator with the Responder value Tr(g^b), where b MUST be randomly/ pseudo-randomly and secretly chosen. The timestamp that is included in the answer is the same as the one included in the Initiator message. The SIGNr is a signature covering the Responder MIKEY message, R_MESSAGE, using the Responder signature key. The XTR group parameters (e.g. p, q, Tr(g)) are chosen by the Initiator and signaled to the Responder. Both parties calculate the TGK, Tr(gab) from the exchanged DH-values. The ID fields and certificate SHOULD be included, but they MAY be left out when it can be expected that the peer already knows the other party's ID (or can obtain the certificate in some other manner). Liang, et al. Expires April 4, 2007 [Page 8] Internet-Draft XTR algorithm for MIKEY Oct 2006 4. XTR-DH data payload (DH) The XTR-DH data payload carries the DH-value and indicates the DH- group used. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! DH-Group ! DH-value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Reserv! KV ! KV data (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload (8 bits): identifies the payload that is added after this payload. * DH-Group (8 bits): identifies the DH group used. * DH-value (variable length): the public DH-value (the length is implicit from the group used). * KV (4 bits): indicates the type of key validity period specified. This may be done by using an SPI (alternatively an MKI in SRTP) or by providing an interval in which the key is valid (e.g., in the latter case, for SRTP this will be the index range where the key is valid). Liang, et al. Expires April 4, 2007 [Page 9] Internet-Draft XTR algorithm for MIKEY Oct 2006 5. Security Considerations This document specifies a substitution of key-generation algorithm derived from MIKEY. Both the key lifetime, key scope in the hierarchy MUST comply with Multimedia Internet Key framework [RFC3830]. When the key-generation solutions are based on the hierarchy proposed in this document, they MUST also meet the security requirements present in Diffie-Hellman Key Agreement Method [RFC2631]. Liang, et al. Expires April 4, 2007 [Page 10] Internet-Draft XTR algorithm for MIKEY Oct 2006 6. IANA Considerations This specification requires additional parameter sets be defined for use in MIKEY when XTR cryptographic methods are used. These are listed in Section 3.4. It is requested that these be added to the namespaces for the DH- Group field in table 6.4 of RFC3830, which that document requests shall be managed by the IANA. Liang, et al. Expires April 4, 2007 [Page 11] Internet-Draft XTR algorithm for MIKEY Oct 2006 7. References 7.1. Normative References [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. 7.2. Informative References [draft] Milne, A., Blaser, M., and D. Brown, "ECC Algorithms for MIKEY", June 2005, . [paper] Lenstra, A. and E. Verheul, "The XTR public key system", 2005. Liang, et al. Expires April 4, 2007 [Page 12] Internet-Draft XTR algorithm for MIKEY Oct 2006 Authors' Addresses Jing Liang University of Science and Technology Beijing No.7 Building Room 748 Xue Yuan Lu Hai Dian District Beijing 100083 China Email: liangjingjing826@gmail.com Shouwen Lai Hitachi (China) Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: hdeng@hitachi.cn Hui Deng Hitachi (China) Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: hdeng@hitachi.cn Liang, et al. Expires April 4, 2007 [Page 13] Internet-Draft XTR algorithm for MIKEY Oct 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Liang, et al. Expires April 4, 2007 [Page 14]