Internet DRAFT - draft-wei-sidr-cta

draft-wei-sidr-cta






Network Working Group                                        Y. Wei, Ed.
Internet-Draft                                                   S. Duan
Expires: September 3, 2010                                       H. Wang
                                                         ZTE Corporation
                                                           March 2, 2010


       A cryptographically generated issuer name for trust anchor
                         draft-wei-sidr-cta-00

Abstract

   This document proposes an enhanced certificate profile for trust
   anchors, in which the issuer field of the TA certificate is
   cryptographically generated.  In the RPKI architecture, the trust
   anchor uses self-signed certificate.  However, this sort of
   certificate is vulnerable to various attacks.  For example, the
   attackers can easily create its own public-private key pair and
   declaims that the issuer field belongs to him.  This means attackers
   can easily impersonate the trust anchor.  To address it, this
   document adds identity based cryptographic technique to the self-
   signed certificate.  Since the issuer field of the trust anchor's
   certificate is cryptographically generated from the trust anchor's
   public key, the attacker will not be able to create another key pair
   and declaim that the issuer field generated by the trust anchor
   belongs to him.  Therefore, attackers can not impersonate the trust
   anchor.

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.



Wei, et al.             Expires September 3, 2010               [Page 1]

Internet-Draft                     CTA                        March 2010


   This Internet-Draft will expire on September 3, 2010.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.



































Wei, et al.             Expires September 3, 2010               [Page 2]

Internet-Draft                     CTA                        March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  issue name generating  . . . . . . . . . . . . . . . . . . . .  5
     2.1.  IPv6 address generating  . . . . . . . . . . . . . . . . .  5
     2.2.  rfc822Name and IPv4 address generating . . . . . . . . . .  5
   3.  certificate profile consideration  . . . . . . . . . . . . . .  6
     3.1.  publication and validation of the trust anchor's
           certificate  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  X.509 Extension  . . . . . . . . . . . . . . . . . . . . .  6
   4.  security considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10





































Wei, et al.             Expires September 3, 2010               [Page 3]

Internet-Draft                     CTA                        March 2010


1.  Introduction

   With the wide deployment of routing protocols in wired and wireless
   networks, the security issues are increasing.  Among those various
   vulnerabilities discussed in RFC4948[RFC4948], integrity protection
   is most important.  When two routers exchange routing information, an
   attacker between the two communicating routers can easily modify
   routing messages, and therefore, the routers will get wrong routing
   information, which leads to routing failure.

   For inter-domain routing protocols, integrity protection means an
   entity has to verifiably assert that it is the legitimate holder of a
   set of IP addresses or a set of Autonomous System (AS) numbers.
   Based on this requirement, [SIDR-ARCH] defined a resource public key
   infrastructure architecture called RPKI to support improved security
   of Internet routing.  As an initial application of this architecture,
   [SIDR-ARCH] describes how a legitimate holder of IP address space can
   explicitly and verifiably authorize one or more ASes to originate
   routes to that address space.  Such verifiable authorizations could
   be used, for example, to more securely construct BGP route filters.

   In RPKI, each relying party (RP) chooses its own set of trust
   anchors(TAs).  Typically, IANA and/or the five RIRs are obvious
   candidates to be default TAs.  Nonetheless, each RP ultimately
   chooses the set of trust anchors it will use for certificate
   validation.  The RP could then issue certificates under this trust
   anchor to whatever entities in the RPKI it wishes, with the result
   that the certification paths terminating at this locally-installed
   trust anchor will satisfy the RFC 3779 validation requirements.  A
   large ISP that uses private (i.e., RFC 1918) IP address space and
   runs BGP internally will need to create this sort of trust anchor to
   accommodate a CA to which all private (RFC 1918) address space is
   assigned.  The RP could then issue certificates under this CA that
   correspond to the RP's internal use of private address space.

   For the case of the trust anchor, it usually uses a long-lived, self-
   signed certificate, and the security of other certificates issued by
   the trust anchor relies on the trust anchor's certificate.  So the
   certificate of the trust anchor is very important.  However, self-
   signed certificate is vulnerable to various attacks.  For example,
   the attacker may create its own public-private key pair and publish a
   wrong certificate of the trust anchor.  In this case, the attacker
   may issue wrong certificates for other entities instead of the trust
   anchor.

   To address it, this document proposes a enhanced certificate for the
   trust anchor.  Since the trust anchor is identified by the issuer
   name, this document proposes a technique for cryptographically



Wei, et al.             Expires September 3, 2010               [Page 4]

Internet-Draft                     CTA                        March 2010


   generating issuer name.  Therefore, attackers can not declaim that
   the issuer name belongs to him.

















































Wei, et al.             Expires September 3, 2010               [Page 5]

Internet-Draft                     CTA                        March 2010


2.  issue name generating

   In this subsection, we present our issuer name generating technique
   for trust anchor. currently, there are mainly three categories of
   issue names:IPv6 address, IPv4 address and rfc822Name.

2.1.  IPv6 address generating

   For the case of IPv6 adress.  The issuer name is generated as
   follows:

   Step 1.  Generates a 256-bit random number Ni.

   Step 2.  Computes checksalt=HASH2(Ni|0|kIpub), where HASH2 is a one-
   way hash function such as SHA256,etc, KIpub is the public key of the
   trust anchor, and the symbol | means Concatenating.  Take the 112
   leftmost bits of the hash value as checksalt.

   Step 3.  Compares the 16*Sec leftmost bits of checksalt with zero,
   where the Sec is security level (i.e. from the lowest security level
   Sec=0 to the highest security level Sec=7).  If they are all zero (or
   if Sec=0), continue with step 4.  Otherwise, increment the Ni by one
   and go back to step 2.

   Step 4. computes salt=HASH1(Ni|Niprefix|kIpub|keyingmaterials), where
   HASH1 is a one-way hash function such as SHA256,etc, Niprefix is the
   64-bit subnet prefix, keyingmaterials are public key related
   materials, and the symbol | means Concatenating.

   Step 5. takes 64 leftmost bits of seed as NIPi.  Then the trust
   anchor gets its issuer IPi=(Niprefix|NIPi), which is a standard IPv6
   address [RFC3513].

   Step 6.  Performs duplicate address detection if required, as per
   [RFC3971].  If an address collision is detected, the random number Ni
   should be re-generated, and the issuer field generating process
   should be re-done

2.2.  rfc822Name and IPv4 address generating

   To be completed.










Wei, et al.             Expires September 3, 2010               [Page 6]

Internet-Draft                     CTA                        March 2010


3.  certificate profile consideration

3.1.  publication and validation of the trust anchor's certificate

   After generating IPi, the trust anchor uses it in its own
   certificate.  This certificate is published in the same way as
   defined in [SIDR-TA].

   Before a relying party can use an RTA Trust Anchor Object, the
   relying party must first validate the object.  The validation process
   includes two parts: one is described in [SIDR-TA].  The other part is
   the issuer name verification.  The relying party performs the same
   steps as described in section 2 of this document.  Only when the two
   parts of the validation process succeed, can the relying party use
   the trust anchor object.

3.2.  X.509 Extension

   Each cryptographically generated issuer name is associated with a
   X.509 extension, which has the following format:Ni:32 octets+Sec:one
   octet






























Wei, et al.             Expires September 3, 2010               [Page 7]

Internet-Draft                     CTA                        March 2010


4.  security considerations

   Since the issuer name is cryptographically generated from the trust
   anchor's key pair, the issuer name can not be reused, when the trust
   anchor's certificate is revoked.  However, this does not matter, for
   the trust anchor uses long-term certificate, and its certificate will
   not be revoked frequently.

   Since the issuer name is generated from the key pair, and the
   certificate is signed using the key pair, the attacker can not be
   able to declaim that the issuer name belongs to it.








































Wei, et al.             Expires September 3, 2010               [Page 8]

Internet-Draft                     CTA                        March 2010


5.  IANA considerations

   To be completed.
















































Wei, et al.             Expires September 3, 2010               [Page 9]

Internet-Draft                     CTA                        March 2010


6.  References

   [RFC4948]  Andersson, L., "Report from the IAB workshop on Unwanted
              Traffic March 9-10, 2006", August 2007.

   [SIDR-ARCH]
              Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", October 2009.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", April 2003.

   [RFC3971]  Arkko, J. and Et. Al., "SEcure Neighbor Discovery (SEND)",
              March 2005.

   [SIDR-TA]  Michaelson, G. and Et. Al, "A Profile for Trust Anchor
              Material for the Resource Certificate PKI",
              September 2009.

































Wei, et al.             Expires September 3, 2010              [Page 10]

Internet-Draft                     CTA                        March 2010


Authors' Addresses

   Yinxing Wei (editor)
   ZTE Corporation
   No. 68, Zijinghua Road, Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Phone: +86 25 52877993
   Email: wei.yinxing@zte.com.cn


   Shili Duan
   ZTE Corporation
   No. 68, Zijinghua Road, Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Phone: +86 25 52877648
   Email: duan.shili@zte.com.cn


   Hongyan Wang
   ZTE Corporation
   No. 68, Zijinghua Road, Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Phone: +86 25 52877993
   Email: wang.hongyan4@zte.com.cn





















Wei, et al.             Expires September 3, 2010              [Page 11]