From sidr-bounces@ietf.org Tue Jan 01 23:40:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9vPA-0005p0-OL; Tue, 01 Jan 2008 23:40:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9vP7-0005og-B4; Tue, 01 Jan 2008 23:40:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9vP6-0001Ww-U3; Tue, 01 Jan 2008 23:40:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8AC39175FC; Wed, 2 Jan 2008 04:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J9vOc-0000sq-2V; Tue, 01 Jan 2008 23:40:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 01 Jan 2008 23:40:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sidr@ietf.org Subject: [Sidr] I-D Action:draft-ietf-sidr-rescerts-provisioning-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Protocol for Provisioning Resource Certificates Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-rescerts-provisioning-00.txt Pages : 21 Date : 2008-01-01 This document defines a framework for certificate management interactions between a resource issuer ("Internet Registry" or "IR") and a resource recipient ("Internet Service Provider" or "ISP") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the ISP, and corresponding responses from the IR encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rescerts-provisioning-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-rescerts-provisioning-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-rescerts-provisioning-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-01233003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-rescerts-provisioning-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-rescerts-provisioning-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-01233003.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Wed Jan 02 01:00:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9we5-0004x9-QP; Wed, 02 Jan 2008 01:00:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9we2-0004wo-NA; Wed, 02 Jan 2008 01:00:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9we2-0004Qd-Au; Wed, 02 Jan 2008 01:00:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3ED6326E6B; Wed, 2 Jan 2008 06:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J9we2-0007Ih-4m; Wed, 02 Jan 2008 01:00:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 02 Jan 2008 01:00:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sidr@ietf.org Subject: [Sidr] I-D Action:draft-ietf-sidr-rpki-manifests-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Manifests for the Resource Public Key Infrastructure Author(s) : R. Austein, et al. Filename : draft-ietf-sidr-rpki-manifests-00.txt Pages : 19 Date : 2008-01-02 This document defines a "manifest" for use in the Resource Public Key Infrastructure. A "manifest" is a signed object that contains a listing of all the signed objects in the repository publication point associated with an authority responsible for publishing in the repository. For each certificate, or other forms of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to expose potential threats to relying parties of the results of a man-in-the middle withholding attack on repository retrieval operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-rpki-manifests-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-rpki-manifests-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-02005322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-rpki-manifests-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-manifests-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-02005322.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Thu Jan 03 13:25:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAUl0-0005rK-KN; Thu, 03 Jan 2008 13:25:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAUky-0005r9-Pf for sidr@ietf.org; Thu, 03 Jan 2008 13:25:28 -0500 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAUky-0004Tz-FV for sidr@ietf.org; Thu, 03 Jan 2008 13:25:28 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m03ILUtR014179 for ; Thu, 3 Jan 2008 13:22:44 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAgIa4OB; Thu, 3 Jan 08 13:21:13 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 6A0143F448; Thu, 3 Jan 2008 13:21:08 -0500 (EST) To: sidr@ietf.org Subject: Re: [Sidr] two new potential work items In-Reply-To: <20071210203239.508DF3F446@pecan.tislabs.com> Message-Id: <20080103182108.6A0143F448@pecan.tislabs.com> Date: Thu, 3 Jan 2008 13:21:08 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sandy@tislabs.com X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On Dec 10 2007, sandy wrote: >Steve Kent and Geoff Huston presented two new topics during the IETF70 >sidr meeting last Monday. The two topics were manifests and a >resource certificate provisioning protocol. > >The question before the working group is whether either or both of >these should be adopted as work items in the working group. There were close to half-a-dozen replies to this question. That's not overwhelming response, but all the replies were for acceptance. Given that the replies were predominantly from non-draft-authors, this is adequate indication of wg approval. So the two drafts have been submitted to the secretariat (yesterday) as wg drafts. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jan 03 13:44:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAV3T-0007ja-C1; Thu, 03 Jan 2008 13:44:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAV3S-0007jV-PH for sidr@ietf.org; Thu, 03 Jan 2008 13:44:34 -0500 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAV3S-0004mU-I8 for sidr@ietf.org; Thu, 03 Jan 2008 13:44:34 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m03If8G7015795 for ; Thu, 3 Jan 2008 13:41:22 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAASqayXE; Thu, 3 Jan 08 13:40:41 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 8353E3F45D; Thu, 3 Jan 2008 13:13:55 -0500 (EST) To: sidr@ietf.org Message-Id: <20080103181355.8353E3F45D@pecan.tislabs.com> Date: Thu, 3 Jan 2008 13:13:55 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: -4.0 (----) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sandy@tislabs.com Subject: [Sidr] meeting minutes deadline tomorrow X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Welcome to the New Year, everyone. The meeting minutes for our meeting at IETF 70 Vancouver were posted on Dec 5. The deadline for any updates is tomorrow. There have been no comments so far, but if anyone was holding off on comments because of being overwhelmed by holiday activities, this is your last chance. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jan 17 09:56:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWA2-0000qv-7O; Thu, 17 Jan 2008 09:56:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWA0-0000lS-Dh for sidr@ietf.org; Thu, 17 Jan 2008 09:56:04 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFW9z-0002y5-Bf for sidr@ietf.org; Thu, 17 Jan 2008 09:56:04 -0500 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JFW9y-0007MF-6L for sidr@ietf.org; Thu, 17 Jan 2008 09:56:03 -0500 Message-ID: <478F6BFA.8090301@bbn.com> Date: Thu, 17 Jan 2008 09:53:46 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sidr@ietf.org Content-Type: multipart/mixed; boundary="------------090809000502080401080403" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [Sidr] Multiple Signatures on a ROA: Proposal X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org This is a multi-part message in MIME format. --------------090809000502080401080403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit At IETF 70, Geoff and I agreed to put together a concrete proposal for how multiple signatures on a ROA would work. The attached file outlines our proposed changes to draft-ietf-sidr-roa-format. Comments, suggestions or clarifying questions would greatly appreciated. - Matt Lepinski --------------090809000502080401080403 Content-Type: text/plain; name="ROA-Many-Sign.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ROA-Many-Sign.txt" Multiple Signatures on a ROA High Level Overview of the Problem and the Proposed Solution: ------------------------------------------------------------- Consider an ISP that wants to authorize an AS to advertise an aggregate prefix, but no single certificate covers the aggregate prefix. (E.g., an ISP has a resource certificate for 10.0/16 and another for 10.1/16, and wants to authorize an AS to advertise 10.0/15.) In the architecture currently described by draft- ietf-sidr-arch and draft-ietf-sidr-roa- format, there is no way to construct a single ROA that authorizes the advertisement of the aggregate prefix. This issue was discussed at the SIDR meeting at IETF 70 in Vancouver. (For more information see: http://www3.ietf.org/proceedings/07dec/slides/sidr-2.pdf and http://www3.ietf.org/proceedings/07dec/minutes/sidr.txt ) The proposed solution is to alter the ROA format to allow for a ROA that includes signatures from multiple signers. In essence, this provides a way for a subject of the certificate containing 10.0/16 to state "I, as the owner of 10.0/16, authorize AS 123 to advertise the aggregate prefix 10.0/15". Note that the envisioned use-case for a multiple-signature ROA is when all the EE certificates used to verify the signatures on a ROA are controlled by the same administrative entity (e.g., a single ISP with multiple certificates corresponding to multiple allocations). Clearly, the proposed solution could also be made to work in a situation when the EE certificates are controlled by distinct entities, but this introduces administrative challenges that are beyond the scope of the current discussion. Proposed Syntax: ---------------- The proposed syntax is straightforward. A ROA is a CMS SignedData object. As specified in RFC 3852, the SignerInfos attribute of a CMS SignedData object can contain a list of SignerInfo objects. Instead of restricting the SignerInfos attribute of a ROA to contain only a single SignerInfo object, the proposed solution is to follow RFC 3852 and allow for a list of SignerInfo objects. Note that in addition to identifying the certificate of the signer, a SignerInfo object also specifies the digest algorithm used to produce the signature. Currently, we specify that the digest algorithm MUST be SHA-256. However, if at some point in the future hash technology improves and we decide to modify the ROA format to migrate to a new hash function, then it would be use to produce a ROA with two SignerInfo objects (both pointing to the same certificate but using different digest algorithms). By now mandating support for multiple SignerInfo objects, we ensure that such a future hash function migration can be performed in a backwards compatible fashion. Proposed Semantics: ------------------- The proposed semantics is that a ROA is a valid authorization for the specified AS to advertise the specified prefix if the valid signatures correspond to address ranges whose union is the specified prefix. If the valid signatures do not correspond to address ranges whose union is the specified prefix, then the ROA is treated as invalid. (That is, all invalid ROAs are treated the same regardless of whether or not they have one or more valid signatures.) Note that while overlapping address ranges is not considered normative for this specification it is not precluded. In the degenerate case where there are multiple signatures that correspond to the same address range, then the authorization is only considered valid if all signatures are valid. The instructions for ROA validation in Section 3 of draft-ietf-sidr-roa- format would then be changed to the following: 1. Verify that the ROA syntax complies with this specification. 2. For each SignerInfo object in the SignerInfos list, do the following: 2.A Obtain an EE certificate that has a Subject Key Identifier (SKI) that matches the sid field of the SignerInfo object. This certificate may be obtained from the certificates field of the SignedData object (if present), the resource PKI repository system, or a local cache. 2.B Use the public key in the EE certificate to verify the signature on the ROA. 2.C Verify that the EE certificate is a valid end-entity certificate in the resource PKI by constructing a valid certificate path to a trust anchor. (See draft-ietf-sidr-res-certs for more details.) 2.D Verify that the EE certificate has an IP Address Delegation extension [RFC3779]. Append the IP address prefix(es) to a list of prefixes corresponding to verified signatures. 3. Compute the union of addresses in the list of prefixes corresponding to verified signatures by aggregating adjacent prefixes to the greatest possible extent. If this union exactly matches the IP address prefix(es) in the ROA, then the ROA is valid. Note on the additional complexity introduced by this proposal: Implementations must already have code that parses a SignerInfo object and uses the EE certificate to verify the signature in the SignerInfo object. This proposal would require looping through that code once for each SignerInfo object, but this seems a small change. Additionally, this proposal requires an implementation to create a list of prefixes and then aggregate the prefixes to the greatest possible extent. --------------090809000502080401080403 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --------------090809000502080401080403--