MIPSHOP Z. Cao Internet-Draft Peking University Intended status: Standards Track P. Yang Expires: April 4, 2007 H. Deng Hitachi (China) Oct 2006 Integrating Identity Based Cryptosystem with Cryptographically Generated Address in Mobile IPv6 draft-cao-mipshop-ibc-cga-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). Cao, et al. Expires April 4, 2007 [Page 1] Internet-Draft IBC CGA Oct 2006 Abstract This document specifies a mechanism to address the address ownership problem as well as the trust relationship between different nodes in the mobile IPv6 network. A mechanism integrating the Identity Based Cryptosystem with Cryptographically Generated Address is utilized to do the job. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IBC CGA Parameters . . . . . . . . . . . . . . . . . . . . . . 6 5. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Cao, et al. Expires April 4, 2007 [Page 2] Internet-Draft IBC CGA Oct 2006 1. Introduction Cryptographically Generated Addresses (CGA) [RFC3972] are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The protection works without a certification authority or any security infrastructure. A signed message from the CGA only guarantees that somebody owns this certain IPv6 address and the very message is coming from the address owner. But the receiver can never tell whether it trust the owner of this IPv6 address without any kind of certification authority. The main problem of Public Key Infrastructure (PKI) are that it may result in a long chain of certifications and the strong responsibility of the certification authority (CA) has scared many potential customers. The Identity Based Cryptosystem (IBC) is a good substitution for PKI. It was first proposed by Shamir in 1984 [Shamir], and the first fully practical and secure identity-based public key encryption scheme was presented by D. Boneh and M. Franklin in [IBC]. Since then, a rapid development of Identity based cryptosystem has taken place. In this document, we propose a mechanism integrating the IBC and CGA. The proposed mechanism solves the problem of: o Address Ownership problem: to assert that the address is owned by somebody and the message is coming from the address owner from the merit of CGA; o Trust relationship problem: with Identity based cryptosystem, the message receiver makes sure that the message is coming from an entity trusted by a third party (the Key Distribution Center, KDC). Cao, et al. Expires April 4, 2007 [Page 3] Internet-Draft IBC CGA Oct 2006 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. The following new terminology and abbreviations are introduced in this document and all the other general mobility related terms as defined in [IBC] Identity Based Cryptosystem (IBC) An Identity Based Cryptosystem is a cryptosystem in which the public key is retrieved from an identity of the entity, and the private key is securely distributed by the Key Distribution Center. Key Distribution Center (KDC) The Key Distribution Center (KDC) receives the registration request from any valid entity, and distributes the corresponding private key to the entity. IBC-ID An identity used by the entity in the IBC system. Examples of IBC-ID include email address, IP address, or any valid identity used by the entity. Cao, et al. Expires April 4, 2007 [Page 4] Internet-Draft IBC CGA Oct 2006 3. Overview For message senders, the procedure of using the proposed IBC-CGA scheme can be summarized as follows: 1 The mobile node registers on the Key Distribution Center and gets a IBC-ID and correspondering private key and public key; 2 The mobile node configures a CGA address using the procedure specified in [RFC3972]; 3 The mobile node signs the message using its private key in the Identity base cryptosystem; 4 The mobile node sends the message out with the IBC-CGA parameters containing its IBC-ID. The message sender asserts its ownership of the CGA IPv6 address by IBC signature and that it is an entity trusted by the Key Distribution Center. For message receivers, the procedure of using the proposed IBC-CGA scheme to assert the address ownership problem and trust relationship problem can be summarized as follows: 1 The receiving mobile node gets the IBC-ID of the sender from the IBC-CGA parameter data structure; 2 The receiving mobile node gets the public key of the sender using the method specified in any specific IBC scheme; 3 The receiving mobile node verifies the validity of the CGA address using the procedure specified in [RFC3972]; 4 The receiving mobile node verifies the signature of the message using corresponding public key of the sender. If all the validations come out successful, the receiving mobile node is sure that the message is coming from the owner of the certain IPv6 address and the sender is a trusted entity. Cao, et al. Expires April 4, 2007 [Page 5] Internet-Draft IBC CGA Oct 2006 4. IBC CGA Parameters In [RFC3972], each CGA is associated with a CGA parameter data structure. But in Identity Based Cryptosystem, the public key can be retrieved through the IBC-ID, so the IBC CGA parameters MAY only contain the IBC Identity which is shown in Figure 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Modifier (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subnet Prefix (8 octets) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Collision Count| | +-+-+-+-+-+-+-+-+ | | | ~ IBC Identity (variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Extension Fields (optional, variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IBC CGA Parameters Cao, et al. Expires April 4, 2007 [Page 6] Internet-Draft IBC CGA Oct 2006 5. Comparison A comparison between PKI, CGA, IBC and the proposed IBC-CGA scheme is present in Figure 2. Note that the Certificate Authority (CA) in IBC and IBC-CGA is weakened to be the Key Distribution Center (KDC). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + | | | | + + | PKI | CGA | IBC | IBC-CGA + + | | | | + +----------------------------------------------------------+ + CA | Strong | none | weak | weak + + | | | (KDC) | (KDC) + +----------------------------------------------------------+ + Authenti-| signature | signature | signature | signature + + city | | | | + +----------------------------------------------------------+ +Trust re- | rooted in | none | rooted in | rooted in + +lationship| CA | | KDC | KDC + +----------------------------------------------------------+ +Address | none | yes | none | yes + +ownership | | | | + +----------------------------------------------------------+ +Perfor- | low | ok | ok | ok + +mance | | | | + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Figure 2: Comparison between different schemes Cao, et al. Expires April 4, 2007 [Page 7] Internet-Draft IBC CGA Oct 2006 6. Security Considerations The main contribution of CGA is that it solves the address ownership problem without the help of a certification authority or any security infrastructure. The receiver of a signed message from the CGA can tell that the message is from the address owner who owns the public key in the CGA parameter data structure. But unfortunately, CGA does not address the trust relationship problem, that is, the receiver of the signed message from the CGA cannot tell whether the address owner is a trusted entity. Attackers may self-configure a public and private key pair and then configure a CGA address. If those attackers send messages to any entity in the networks, the challenged entity will be cheated into communication with the attackers. To establish trust relationship between network entities, this document proposes a signature mechanism integrating Identity Based Cryptosystem with CGA. In this scheme, every entity MUST register an IBC-Identity on the Key Distribution Center and get its public and private keys. The CGA address is computed from the public key in the IBC scheme and the message is signed with private key in the IBC scheme. With this IBC-CGA scheme, the receiver of the message can tell that the address owner of the CGA address is an entity trusted by the KDC. Compared with PKI, our IBC-CGA scheme does not introduce a long chain of certifications and is more efficient and light- weighted. Cao, et al. Expires April 4, 2007 [Page 8] Internet-Draft IBC CGA Oct 2006 7. IANA Considerations This specification does not request the creation of any new parameter registries, nor does it require any other IANA assignments. Cao, et al. Expires April 4, 2007 [Page 9] Internet-Draft IBC CGA Oct 2006 8. References 8.1. Normative References [IBC] Boneh, D. and M. Franklin, "Identity-Based Encryption from the Weil Pairing". [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. 8.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [Shamir] Shamir, A., "Identity-Based Cryptosystems and Signature Schemes", 1984. Cao, et al. Expires April 4, 2007 [Page 10] Internet-Draft IBC CGA Oct 2006 Authors' Addresses Zhen Cao Peking University No.1 Science Building Room 1534 5 Yi He Yuan Lu Hai Dian District Beijing 100871 China Email: caozhen@pku.edu.cn Peng Yang Hitachi (China) Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: pyang@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 Cao, et al. Expires April 4, 2007 [Page 11] Internet-Draft IBC CGA 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). Cao, et al. Expires April 4, 2007 [Page 12]