Subject: [sidr] agenda for IETF 77

From: Sandra Murphy <[email-masked]>
Date: Thu, 11 Mar 2010 08:31:15 -0500 (Eastern Standard Time)

In my flurry of messages last week, there was supposed to be one 
containing a request for agenda topics.  That got missed, which probably 
explains why I have received only private requests for agenda topics.

I created an agenda from the list of updated drafts as well as the private 
requests for agenda time.  It is now uploaded.

We have the two back-to-back meeting slots in the morning of Wed, Mar 24. 
I have made no attempt to distinguish the slots in the agenda, but if 
anyone would find it good to have the two slots separated, please reply to 
the list.

If anyone desires to be assigned a slot on the agenda or to be removed 
from the agenda, please let me know.

There is one new topic on the agenda that I was informed of privately, but 
I do not yet have a draft name to mention.

Expect more updates.  Revised agendas are due by 15 Mar, to give people 
time to make their plans, but agenda changes after that are not forbidden 
by the chair.  And there's always the traditional "agenda bashing" first 
topic.

--Sandy

---

From: [email-masked]
Date: Fri, 12 Mar 2010 09:10:01 +0800

Dear Sandra Murphy, 

I uploaded a new draft in 
http://tools.ietf.org/id/draft-wei-sidr-cta-00.txt.
Could you arrange 10 minutes for me to present it? 

               Title           : A cryptographically generated issuer name 
for trust anchor
                 Author(s)       : Y. Wei, S. Duan, H. Wang
                 Filename        : draft-wei-sidr-cta-00.txt
                 Pages           : 11
                 Date            : 2010-03-01

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.

Best Regards!

Yinxing Wei
--------------------------------------------------------------------------------
Address: System Architecture Department, Central Institute, ZTE 
Corporation
         Room 2C4, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, 
China
Zipcode: 210012
Office Telephone: +86-025-52877993
Mobile Telephone: +86-13611519358
Fax: +86-25-52878008
MSN: [email-masked]
---------------------------------------------------------------------------------

Sandra Murphy <[email-masked]> 
发件人:  [email-masked]
2010-03-11 21:31

收件人
[email-masked]
抄送

主题
[sidr] agenda for IETF 77

the list.

--Sandy
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Mar 2010 14:55:58 -0500

I find this document to be very puzzling.

The introduction includes some allusions to the local TA management 
talks that I have made to the SIDR WG (without attribution), but the 
text contained in this section is inconsistent with the local TA 
management model I have described.

The introduction also talks about attacks on trust anchors, but the 
arguments are incorrect, e.g., they fail to acknowledge that TAs are 
to be distributed out-of-band via secure channels.

The fundamental notion put forth here appears to be a form of 
internal consistency check that can be performed on a self-signed TA 
cert, based on generation of the TA's (issuer) name from an IP 
address (v4 or v6) or an rfc1822 name. The stated goal (see section 
6) is to somehow protect the issuer name of a TA: "Since the issuer 
name is generated from the key pair, and the certificate is signed 
[sic] using the key pair, the attacker can not be able to declaim 
that the issuer name belongs to it." This suggests a fundamental 
misunderstanding of TA concepts.

This makes no sense to me, in several ways:

	- a TA represented by a self-signed cert has the same name 
for the subject and issuer, so references to the issuer name only are 
odd, at best.

	- resource certs are specified to NOT make use of alternative 
names, so there is no place for an rfc1822 name in such a cert

	- resource certs for TAs would contain prefixes, not 
individual addresses, so there would be no individual v4 or v6 
address to use in the algorithm described in section 2.1.

A self-signed cert already has a consistency check, based on the fact 
that the public key contained in the cert must be able to be used to 
verify the signature on the cert.  Because issuer and subject names 
in the RPKI are not intended to be human meaningful, it is not clear 
why there is a need to "secure" in some fashion that issuer name in a 
TA cert.

Section 2.1 presents an algorithm that appears to be derived from the 
CGA algorithm described in RFC 3971. This makes no sense. For 
example, step 6 talks about duplicate address detection, yet this 
document is describing how to generate an issuer name for a cert, not 
an IPv6 address to be used in a network!

Section 3.1 references the SIDR-TA I-D, but fails to indicate which 
form of TA (ETA or RPKI TA) the authors believe would benefit from 
use of this technique.

Section 3.2 has a cryptic description of an extension (not using 
ASN.1), used to contain a 256-bit random number that is employed in 
the name generation algorithm (section 2.1).

None of this makes any sense to me in the SIDR context. Maye the lack 
of references to the resource cert profile 
(draft-ietf-sidr-res-certs-17) is indicative of the serious 
disconnect I see here.

Steve