One document matched: draft-liang-msec-mikey-xtr-00.txt
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, <draft-ietf-msec-mikey-ecc-00>.
[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]
| PAFTECH AB 2003-2026 | 2026-04-24 08:48:05 |