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]