Internet DRAFT - draft-cao-mipshop-ibc-cga
draft-cao-mipshop-ibc-cga
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]
