From sidr-bounces@ietf.org Mon Jul 03 17:57:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWPb-00061S-7f; Mon, 03 Jul 2006 17:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxWPa-00061L-7q for sidr@ietf.org; Mon, 03 Jul 2006 17:56:58 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxWPY-0001Uq-Ee for sidr@ietf.org; Mon, 03 Jul 2006 17:56:58 -0400 Received: from gihm3.apnic.net (dhcp4.potaroo.net [203.10.60.4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k63Luqp6013637; Tue, 4 Jul 2006 07:56:53 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 04 Jul 2006 07:56:46 +1000 To: sidr@ietf.org From: Geoff Huston Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sandy@tislabs.com Subject: [Sidr] Agenda for SIDR WG meeting at IETF 66 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 Secure Inter-Domain Routing WG (sidr) IETF 66, Montreal Session I - SIDR Meeting Monday, July 10, 2006 1300-1500 (Afternoon Session I) ==================================================== CHAIR(s): Geoff Huston Sandra Murphy AGENDA: 1) Administriva 5 minutes - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html - Scribe? - Blue Sheets - Agenda Bashing 2) Certificate Discussion 60 minutes Certificate Format (Geoff) A Profile for X.509 PKIX Resource Certificates draft-ietf-sidr-res-certs-01.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-01.txt Certificate Repository (George Michaelson) A Profile for Resource Certificate Repository Structure draft-huston-sidr-repos-struct-00.txt http://www.ietf.org/internet-drafts/draft-huston-sidr-repos-struct-00.txt Status Report on a trial implementation of Resource Certificates (George Michaelson) 3) Transport Security Rekeying the TCP MD5 Option (Steve Bellovin) 20 minutes "Key Change Strategies for TCP-MD5" draft-bellovin-keyroll2385-00.txt http://www.ietf.org/internet-drafts/draft-bellovin-keyroll2385-00.txt A New TCP Authentication Option (Ron Bonica) 20 minutes "Authentication for TCP-based Routing and Management Protocols" draft-bonica-tcp-auth-04.txt http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt Key Selection for TCP Authentication (Brian Weiss) 20 minutes "Automated key selection extension for the TCP Authentication Option" draft-weis-tcp-auth-auto-ks-01.txt http://www.ietf.org/internet-drafts/draft-weis-tcp-auth-auto-ks-01.txt Session II - Joint Meeting with PKIX MONDAY, July 10, 2006 1850-1950 (Room 513b) =========================================== 4) Joint PKIX/SIDR Meeting Address Space & As Number PKI (60 min.) Stephen Kent (BBN) This presentation will review the current plans and status for creating a PKI that reflects the allocation of resources through Regional Internet Registries. The motivation for creation this PKI is to enable better security for Internet routing (BGP). _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 04 05:10:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxgvI-0007k4-UB; Tue, 04 Jul 2006 05:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxgvG-0007iw-P7 for sidr@ietf.org; Tue, 04 Jul 2006 05:10:22 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxgtS-0005wX-2n for sidr@ietf.org; Tue, 04 Jul 2006 05:08:30 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6498DVl078428 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 4 Jul 2006 11:08:13 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> References: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A31F26E-0E5F-48C3-9B4F-4CDD9E5E3043@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Tue, 4 Jul 2006 11:08:15 +0200 To: sidr@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [Sidr] Transport security 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 3-jul-2006, at 23:56, Geoff Huston wrote: > 3) Transport Security > Rekeying the TCP MD5 Option (Steve Bellovin) 20 minutes > "Key Change Strategies for TCP-MD5" > draft-bellovin-keyroll2385-00.txt > http://www.ietf.org/internet-drafts/draft-bellovin- > keyroll2385-00.txt > A New TCP Authentication Option (Ron Bonica) 20 minutes > "Authentication for TCP-based Routing and Management Protocols" > draft-bonica-tcp-auth-04.txt > http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt > Key Selection for TCP Authentication (Brian Weiss) 20 minutes > "Automated key selection extension for the TCP Authentication > Option" > draft-weis-tcp-auth-auto-ks-01.txt > http://www.ietf.org/internet-drafts/draft-weis-tcp-auth-auto- > ks-01.txt Three new drafts trying to improve on RFC 2385! There are some good ideas in there, but I see major problems. draft-bonica-tcp-auth-04.txt: However, TCP implementations MAY omit TCP Options from the MAC calculation. When implementation do so, they MUST set the T-bit in the TCP Enhanced Authentication Option. See Section 9 of this document for details. Huh? Why would this be necessary or useful? Seems to me this only adds unnecessary complexity. Using identifiers to identify MAC keys seems like a good idea, but it doesn't preclude two sides from entering different keys, and it only adds more stuff that must be agreed upon. To avoid these problems, I suggest using a hash of the key as the key id. Such a hash would be too long to include in a TCP option, but I don't think this is too much of a problem: rather than include the key id in every segment, implementations can agree on the key that's used in-band. draft-weis-tcp-auth-auto-ks-01.txt: This draft can use some more spelling and grammar checking. I also find the draft hard to follow. I'm not sure whether this is because of my relative unfamiliarity with the matters discussed, the frequent references to things defined elsewhere or because of poor organization. Using an additional four TCP option bytes for a sequence number dedicated to the MAC option is required in order to satisfy the cryptographic requirement of unique nonces. No other value in a TCP packet is guaranteed to be unique. At first glance, the TCP Sequence Number would appear to be suitable. However, the TCP Sequence Number can wrap, after which it increments back through the same sequence number space. Yes, after transmitting 4 GB worth of data... TCP already has a window system that makes sure only part of the sequence space is acceptable at any given time so it would be relatively simple to look at the TCP sequence number as a 64 bit or even longer value and keep the upper bits in sync with the other side when the lower 32 bits wrap with no need to actually transmit the upper bits. Is it worth all this complexity to avoid having to use the same actual MAC key for prolonged periods but rather use different MAC keys based on the same underlying key? In my not cryptographically trained opinion this is only the case when the MAC algorithm is significantly weaker than the encryption algorithm used to exchange new MAC keys. And _that_ should only be necessary when the encryption algorithm can't be used to generate a MAC or uses too much processing time. draft-bellovin-keyroll2385-00.txt: I have a big problem the notion of blindly switching to a new key at a predetermined time. If one side is unable to enter the key before that time, or one side enters the key incorrectly, the session will break at the moment that the switch to the new key happens. Since this happens some time _after_ both sides (are supposed to) have entered the new key, operators aren't actively monitoring the session at that moment, so there will be a delay before the problem can be corrected. I suggedsted this alternative approach on the north american network operators mailinglist: If you want benefits when only one end is upgraded, your mechanism for concurrent keys could be used like this: - the upgraded side installs the new key - the upgraded side keeps using the old key - the non-upgraded side installs the new key - the upgraded side detects that the other side uses the new key and switches over itself - the old key is removed from the upgraded side This way, it all goes down when the non-upgraded side installs the key: they can immediately see the problem if there is some kind of issue with the key (for instance someone entered it incorrectly). It still makes sense to add stuff that allows both ends to manage the key rollover when they're both upgraded (by adding a new BGP message to coordinate all of this in-band), since in that case something like the above won't work. I think something like this would work well: - announce key rollover capability at session connect - when a new key is configured, send a hash of it to the other side - other side doesn't have the key yet so says "reject" - other side is also configured with the new key, sends a hash - first side sees hashes match, starts sending with the new key and says "accept" Finally, as someone who works with BGP with MD5 passwords in practice, I can tell you that operators in general don't even think about changing keys. Yes, coordinating changing a key on both sides at the same time is a pain, but coordinating changing a key PERIOD is almost as big a pain because even ASes that aren't very big can easily have 100 peers or more and only the middle sized ones are easy to work with, the smaller ones barely have a clue and the larger ones have huge bureaucratic NOCs where it's hard to find the right person. And of course everything stretches across timezones and there are often language barriers. Exchanging the key securely is also a big problem. Making key rollover easier isn't going to change all that much here, and there is no perception of immediacy anyway. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 04 08:27:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxk01-0007px-DP; Tue, 04 Jul 2006 08:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxk00-0007pq-Ly for sidr@ietf.org; Tue, 04 Jul 2006 08:27:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxijL-0005Ug-5R for sidr@ietf.org; Tue, 04 Jul 2006 07:06:11 -0400 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FxiZx-0003xH-Ap for sidr@ietf.org; Tue, 04 Jul 2006 06:56:31 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k64AuJfw014267 for ; Tue, 4 Jul 2006 13:56:19 +0300 Date: Tue, 4 Jul 2006 13:56:19 +0300 (EEST) From: Pekka Savola To: sidr@ietf.org Subject: Re: [Sidr] Transport security In-Reply-To: <0A31F26E-0E5F-48C3-9B4F-4CDD9E5E3043@muada.com> Message-ID: References: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> <0A31F26E-0E5F-48C3-9B4F-4CDD9E5E3043@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1582/Tue Jul 4 00:23:18 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: -2.4 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Tue, 4 Jul 2006, Iljitsch van Beijnum wrote: > Finally, as someone who works with BGP with MD5 passwords in practice, I can > tell you that operators in general don't even think about changing keys. Yes, > coordinating changing a key on both sides at the same time is a pain, but > coordinating changing a key PERIOD is almost as big a pain because even ASes > that aren't very big can easily have 100 peers or more and only the middle > sized ones are easy to work with, the smaller ones barely have a clue and the > larger ones have huge bureaucratic NOCs where it's hard to find the right > person. And of course everything stretches across timezones and there are > often language barriers. Exchanging the key securely is also a big problem. > Making key rollover easier isn't going to change all that much here, and > there is no perception of immediacy anyway. I can agree with this statement. There is very little need to change MD5 keys once set. I'd be interested in hearing the reasons why other operators might consider this critical. Personally, I would like to avoid the BGP transport security issues for now. Those are a distraction from the real work this WG is chartered to do. Before we have at least an inkling about the inter-domain routing security framework which we are chartered to produce, all of this seems premature at best. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Jul 05 07:52:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5vG-00069Q-VU; Wed, 05 Jul 2006 07:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5vG-00068e-HG for sidr@ietf.org; Wed, 05 Jul 2006 07:52:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy4kD-0005sl-U7 for sidr@ietf.org; Wed, 05 Jul 2006 06:36:33 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy4XG-0006Wk-QA for sidr@ietf.org; Wed, 05 Jul 2006 06:23:12 -0400 Received: from pc6 (1Cust111.tnt109.lnd4.gbr.da.uu.net [62.188.172.111]) by blaster.systems.pipex.net (Postfix) with SMTP id C6BD6E00029F; Wed, 5 Jul 2006 11:23:02 +0100 (BST) Message-ID: <013001c6a014$078cdce0$0601a8c0@pc6> From: "Tom Petch" To: "Iljitsch van Beijnum" , References: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> <0A31F26E-0E5F-48C3-9B4F-4CDD9E5E3043@muada.com> Subject: Re: [Sidr] Transport security Date: Wed, 5 Jul 2006 10:09:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -2.0 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Iljitsch van Beijnum" To: Sent: Tuesday, July 04, 2006 11:08 AM Subject: [Sidr] Transport security > On 3-jul-2006, at 23:56, Geoff Huston wrote: > > > Finally, as someone who works with BGP with MD5 passwords in > practice, I can tell you that operators in general don't even think > about changing keys. Yes, coordinating changing a key on both sides > at the same time is a pain, but coordinating changing a key PERIOD is > almost as big a pain because even ASes that aren't very big can > easily have 100 peers or more and only the middle sized ones are easy > to work with, the smaller ones barely have a clue and the larger ones > have huge bureaucratic NOCs where it's hard to find the right person. > And of course everything stretches across timezones and there are > often language barriers. Exchanging the key securely is also a big > problem. Making key rollover easier isn't going to change all that > much here, and there is no perception of immediacy anyway. > True, but working with enterprises teaches me that noone takes security seriously until they have felt sufficient pain, millions of euros or dollars. Not long ago, noone used MD5 for BGP, suddenly they were, I understand because of an incident (at a large European IX?). When there is the next incident, we should have the technology ready, and it is not difficult. All we need is the ability to invoke key generation dynamically, with an exchange of pseudo-random numbers etc leading to a new key pair, so that all the operator sees is two knobs, one saying generate key change now, and the other saying accept key change request from peer; the rest is protocol. Tom Petch . > _______________________________________________ > Sidr mailing list > Sidr@ietf.org > https://www1.ietf.org/mailman/listinfo/sidr _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Jul 05 09:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7BH-0000Ip-BE; Wed, 05 Jul 2006 09:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7BF-0000Ih-Mf for sidr@ietf.org; Wed, 05 Jul 2006 09:12:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy7BF-0005rx-Jm for sidr@ietf.org; Wed, 05 Jul 2006 09:12:37 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy7BB-00011f-BL for sidr@ietf.org; Wed, 05 Jul 2006 09:12:37 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k65DCCF0007059 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Jul 2006 15:12:13 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <013001c6a014$078cdce0$0601a8c0@pc6> References: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> <0A31F26E-0E5F-48C3-9B4F-4CDD9E5E3043@muada.com> <013001c6a014$078cdce0$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61A01F10-6C11-4D82-9549-1FB922FDA926@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [Sidr] Transport security Date: Wed, 5 Jul 2006 15:12:10 +0200 To: "Tom Petch" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.4 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sidr@ietf.org 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 5-jul-2006, at 10:09, Tom Petch wrote: >> Making key rollover easier isn't going to change all that >> much here, and there is no perception of immediacy anyway. > True, but working with enterprises teaches me that noone takes > security > seriously until they have felt sufficient pain, millions of euros > or dollars. :-) > Not long ago, noone used MD5 for BGP, suddenly they were, I > understand because > of an incident (at a large European IX?). "Noone" is overstating it a bit, but yes, suddenly very many wanted to do MD5 because some guy claimed he had found a big vulnerability in TCP so he could reset TCP sessions with only a few packets. Turned out that the "vulnerability" in question assumes very large TCP windows: only if someone uses the biggest TCP window allowed by RFC 1323 (nearly a gigabyte) and IP addresses and port numbers are known to the attacker, the attacker can fake an in-window TCP reset within about four tries. Since no other application of TCP is both of internet-wide importance and keeps a single session around for a significant amount of time, this was assumed to be a bad thing for routers running BGP. The fact that no router vendors even use the RFC 1323 window scale option in the first place apparently got lost in the fracas. For more details, see: http://www.bgpexpert.com/article.php?id=89 http://www.bgpexpert.com/article.php?id=90 http://www.bgpexpert.com/article.php?id=93 But it was good advertising for the MD5 option. (-: > When there is the next incident, we > should have the technology ready, and it is not difficult. I agree. I was just trying to deflate expectations of operator deployment to reasonable levels. One important question is whether all of this makes sense in the first place, though, given the existance of IPsec. > All we need is the > ability to invoke key generation dynamically, with an exchange of > pseudo-random > numbers etc leading to a new key pair, so that all the operator > sees is two > knobs, one saying generate key change now, and the other saying > accept key > change request from peer; Wouldn't this perpetuate a key compromise? _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Jul 05 09:44:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7fv-000394-4R; Wed, 05 Jul 2006 09:44:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7ft-00038l-W9 for sidr@ietf.org; Wed, 05 Jul 2006 09:44:17 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy7fr-0000nZ-Mo for sidr@ietf.org; Wed, 05 Jul 2006 09:44:17 -0400 Received: from pc6 (1Cust87.tnt13.lnd4.gbr.da.uu.net [62.188.142.87]) by blaster.systems.pipex.net (Postfix) with SMTP id D00FEE000555; Wed, 5 Jul 2006 14:44:12 +0100 (BST) Message-ID: <02ae01c6a030$2166d6e0$0601a8c0@pc6> From: "Tom Petch" To: "Iljitsch van Beijnum" References: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> <0A31F26E-0E5F-48C3-9B4F-4CDD9E5E3043@muada.com> <013001c6a014$078cdce0$0601a8c0@pc6> <61A01F10-6C11-4D82-9549-1FB922FDA926@muada.com> Subject: Re: [Sidr] Transport security Date: Wed, 5 Jul 2006 14:38:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org ----- Original Message ----- From: "Iljitsch van Beijnum" To: "Tom Petch" Cc: Sent: Wednesday, July 05, 2006 3:12 PM Subject: Re: [Sidr] Transport security > > All we need is the > > ability to invoke key generation dynamically, with an exchange of > > pseudo-random > > numbers etc leading to a new key pair, so that all the operator > > sees is two > > knobs, one saying generate key change now, and the other saying > > accept key > > change request from peer; > > Wouldn't this perpetuate a key compromise? Yes, but then you change the key; the security credential, be it pre-shared key, private/public key pair etc, is what matters and that is what you must keep secret. You only ever use it, along with other material, some predictable, some not, to generate keying material for a session, keying material which you then use as MAC key, encryption key etc At regular intervals, or when you suspect your keying material has been compromised, generate fresh keying material using your security credential and different other material. (PKI does of course insist on refreshing the security credential as well, but I see that as a longer timescale, like years). draft-clancy-emu-eap-shared-secret-01.txt is an example of key derivation in the context of EAP (which lacks, AFAIK, the ability to regenerate keying material later). TLS is another example of key derivation and also has the capacity for current and pending Cipher Specs which can be changed at will. I would regard these building bricks as the current state of security, in no way leading edge. Tom Petch _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Jul 05 15:27:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyD2H-0001Gm-OI; Wed, 05 Jul 2006 15:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyD2H-0001Gh-60 for sidr@ietf.org; Wed, 05 Jul 2006 15:27:45 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyD2G-0002ij-Sj for sidr@ietf.org; Wed, 05 Jul 2006 15:27:45 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k65JRX16016469 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Jul 2006 21:27:34 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <02ae01c6a030$2166d6e0$0601a8c0@pc6> References: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> <0A31F26E-0E5F-48C3-9B4F-4CDD9E5E3043@muada.com> <013001c6a014$078cdce0$0601a8c0@pc6> <61A01F10-6C11-4D82-9549-1FB922FDA926@muada.com> <02ae01c6a030$2166d6e0$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E12DA43-CD12-4780-BAF5-30D9B1FDF6C2@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [Sidr] Transport security Date: Wed, 5 Jul 2006 21:27:36 +0200 To: "Tom Petch" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sidr@ietf.org 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 5-jul-2006, at 14:38, Tom Petch wrote: >> Wouldn't this perpetuate a key compromise? > Yes, but then you change the key; the security credential, be it > pre-shared key, > private/public key pair etc, is what matters and that is what you > must keep > secret. You only ever use it, along with other material, some > predictable, > some not, to generate keying material for a session, keying > material which you > then use as MAC key, encryption key etc At regular intervals, or > when you > suspect your keying material has been compromised, generate fresh > keying > material using your security credential and different other material. I know this is best practice, and RFC 2385 as it is today doesn't support this to any useful degree, but I wonder whether any effort to rectify this situation is worth the effort in practice. The way I see it, the easiest way to compromise such a key is to gain control of the router in question and read it from the configuration. This is MUCH easier than gaining access to the communication channel between two routers, intercept packets and then do a collision attack on MD5 (or, if MD5 is really dead at some point (now?)), a stronger algorithm. Don't forget that in many cases, routers are located at shared sites so physical security isn't always as good as it could be. And when someone has the key, they mostly get to reset BGP sessions. Injecting bad information is MUCH more difficult, unless there are additional attack vectors such as access to a shared LAN. In any event, such attacks will generally be discovered very quickly so in practice this is not a very rewarding exercise for the attacker. Of course there can be situations where a higher level of security is warranted, but why not simply use IPsec in those cases? > I would regard these building bricks as the current state of > security, in no way leading edge. Well, how much security do we need and/or can we stand? To avoid misunderstandings: I think it would be useful to improve upon RFC 2385 for a variety of reasons: - MD5 is a sinking ship - adding MD5 for the first time and rolling over keys is too difficult today - it's too easy to make mistakes and configure non-matching keys at both ends But we need to be careful in drawing the line; reinventing TLS or IPsec or big chunks of those is a waste of time both because it's a duplication of effort and because the way operators work and the (perceived) level of risk make this an exercise in futility. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jul 06 13:00:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXDc-0001nk-0C; Thu, 06 Jul 2006 13:00:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXDa-0001nf-L8 for sidr@ietf.org; Thu, 06 Jul 2006 13:00:46 -0400 Received: from uswgco34.uswest.com ([199.168.32.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXDW-0005Eu-7U for sidr@ietf.org; Thu, 06 Jul 2006 13:00:46 -0400 Received: from egate-ne9.uswc.uswest.com (egate-ne9.uswc.uswest.com [151.117.69.23]) by uswgco34.uswest.com (8/8) with ESMTP id k66H0PKi005506; Thu, 6 Jul 2006 11:00:25 -0600 (MDT) Received: from ITDENE2KSM01.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-ne9.uswc.uswest.com (8/8.13.7) with ESMTP id k66H0OB6009826; Thu, 6 Jul 2006 12:00:24 -0500 (CDT) Received: from qtdene2k3m02.AD.QINTRA.COM ([10.1.4.148]) by ITDENE2KSM01.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 11:00:24 -0600 X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.504 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sidr] Transport security Date: Thu, 6 Jul 2006 11:00:23 -0600 Message-ID: <50E094F67A606244AE045ACB99F9E48E028F2CDB@qtdene2k3m02.AD.QINTRA.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sidr] Transport security thread-index: AcagKXqJC103hemsSWmVPqGrHvCh5QA819ZA Importance: normal Priority: normal From: "Smith, Donald" To: "Tom Petch" , "Iljitsch van Beijnum" , X-OriginalArrivalTime: 06 Jul 2006 17:00:24.0737 (UTC) FILETIME=[AC883910:01C6A11D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: 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 Our IDS reports a false negative rate of 0 (Dr J). Donald.Smith@qwest.com giac =20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Wednesday, July 05, 2006 2:09 AM > To: Iljitsch van Beijnum; sidr@ietf.org > Subject: Re: [Sidr] Transport security >=20 > > Tom Petch >=20 > ----- Original Message ----- > From: "Iljitsch van Beijnum" > To: > Sent: Tuesday, July 04, 2006 11:08 AM > Subject: [Sidr] Transport security >=20 >=20 > > On 3-jul-2006, at 23:56, Geoff Huston wrote: > > > >=20 > > > > Finally, as someone who works with BGP with MD5 passwords in > > practice, I can tell you that operators in general don't even think > > about changing keys. Yes, coordinating changing a key on both sides > > at the same time is a pain, but coordinating changing a key=20 > PERIOD is > > almost as big a pain because even ASes that aren't very big can > > easily have 100 peers or more and only the middle sized=20 > ones are easy > > to work with, the smaller ones barely have a clue and the=20 > larger ones > > have huge bureaucratic NOCs where it's hard to find the=20 > right person. > > And of course everything stretches across timezones and there are > > often language barriers. Exchanging the key securely is also a big > > problem. Making key rollover easier isn't going to change all that > > much here, and there is no perception of immediacy anyway. > > > True, but working with enterprises teaches me that noone=20 > takes security > seriously until they have felt sufficient pain, millions of=20 > euros or dollars. >=20 > Not long ago, noone used MD5 for BGP, suddenly they were, I=20 > understand because > of an incident (at a large European IX?). =20 Network element vendors recommended the use of MD5 to mitigate the tcp reset via sequence number guessing vulnerability=20 http://www.uniras.gov.uk/niscc/docs/al-20040420-00199.html?lang=3Den=20 That was basically the only mitigation available from the network element vendors when this vulnerability was announced. Also the MD5 M and M' collision issue is as far as I know ONLY an issue when M is known so that M' can be generated to hash to the same value. This is not the case when MD5 includes a "secret" password. >When there is the=20 > next incident, we > should have the technology ready, and it is not difficult. =20 > All we need is the > ability to invoke key generation dynamically, with an=20 > exchange of pseudo-random > numbers etc leading to a new key pair, so that all the=20 > operator sees is two > knobs, one saying generate key change now, and the other=20 > saying accept key > change request from peer; the rest is protocol. >=20 > Tom Petch > . >=20 >=20 >=20 >=20 > > _______________________________________________ > > Sidr mailing list > > Sidr@ietf.org > > https://www1.ietf.org/mailman/listinfo/sidr >=20 >=20 > _______________________________________________ > Sidr mailing list > Sidr@ietf.org > https://www1.ietf.org/mailman/listinfo/sidr >=20 This communication is the property of Qwest and may contain confidential = or privileged information. Unauthorized use of this communication is = strictly=20 prohibited and may be unlawful. If you have received this communication = in error, please immediately notify the sender by reply e-mail and = destroy=20 all copies of the communication and any attachments. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 11 05:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0E9I-0008U2-AJ; Tue, 11 Jul 2006 05:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0E9H-0008Tx-I6 for sidr@ietf.org; Tue, 11 Jul 2006 05:03:19 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0E9G-0006N4-9q for sidr@ietf.org; Tue, 11 Jul 2006 05:03:19 -0400 Received: from pc6 (1Cust125.tnt109.lnd4.gbr.da.uu.net [62.188.172.125]) by astro.systems.pipex.net (Postfix) with SMTP id E21E7E000247; Tue, 11 Jul 2006 10:03:15 +0100 (BST) Message-ID: <023401c6a4bf$db348980$0601a8c0@pc6> From: "Tom Petch" To: "Iljitsch van Beijnum" References: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> <0A31F26E-0E5F-48C3-9B4F-4CDD9E5E3043@muada.com> <013001c6a014$078cdce0$0601a8c0@pc6> <61A01F10-6C11-4D82-9549-1FB922FDA926@muada.com> <02ae01c6a030$2166d6e0$0601a8c0@pc6> <5E12DA43-CD12-4780-BAF5-30D9B1FDF6C2@muada.com> Subject: Re: [Sidr] Transport security Date: Tue, 11 Jul 2006 09:43:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org EKR has sent a paper on this to bts and tcpm lists. Joe Touch has suggested that the right place to discuss this is bts. Tom Petch ----- Original Message ----- From: "Iljitsch van Beijnum" To: "Tom Petch" Cc: Sent: Wednesday, July 05, 2006 9:27 PM Subject: Re: [Sidr] Transport security > On 5-jul-2006, at 14:38, Tom Petch wrote: > > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 11 10:45:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JUd-0006Ws-Vl; Tue, 11 Jul 2006 10:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JUd-0006Wb-KC for sidr@ietf.org; Tue, 11 Jul 2006 10:45:43 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0JUc-0005sh-Cm for sidr@ietf.org; Tue, 11 Jul 2006 10:45:43 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6BEigfi021763 for ; Tue, 11 Jul 2006 10:44:42 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWyayvQ; Tue, 11 Jul 06 10:44:00 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6BEgpiD026331; Tue, 11 Jul 2006 10:42:51 -0400 (EDT) Date: Tue, 11 Jul 2006 10:42:51 -0400 (EDT) Message-Id: <200607111442.k6BEgpiD026331@tislabs.com> From: sandy@tislabs.com To: sidr@ietf.org Subject: Re: [Sidr] Transport security X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 >EKR has sent a paper on this to bts and tcpm lists. Joe Touch has suggested >that the right place to discuss this is bts. The last comment at the mike in the meeting (I believe it was Lars), was that the transport area was interested in guidance about this from security and from routing folk, but that it needed to be done in the tcpm working group. I believe deciding where it gets done is the responsibility of the ADs involved. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 11 10:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JZJ-0000NJ-Rr; Tue, 11 Jul 2006 10:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JZJ-0000NE-6M for sidr@ietf.org; Tue, 11 Jul 2006 10:50:33 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0JZI-00063y-OW for sidr@ietf.org; Tue, 11 Jul 2006 10:50:33 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6BEoULB031298; Tue, 11 Jul 2006 17:50:30 +0300 Date: Tue, 11 Jul 2006 17:50:30 +0300 (EEST) From: Pekka Savola To: sandy@tislabs.com Subject: Re: [Sidr] Transport security In-Reply-To: <200607111442.k6BEgpiD026331@tislabs.com> Message-ID: References: <200607111442.k6BEgpiD026331@tislabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1591/Mon Jul 10 22:41:02 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, L_SPAM_COM_URL, NO_RELAYS autolearn=ham version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sidr@ietf.org 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 Tue, 11 Jul 2006, sandy@tislabs.com wrote: >> EKR has sent a paper on this to bts and tcpm lists. Joe Touch has suggested >> that the right place to discuss this is bts. > > The last comment at the mike in the meeting (I believe it was Lars), > was that the transport area was interested in guidance about this > from security and from routing folk, but that it needed to be done > in the tcpm working group. Which qualification, "if the modification involves TCP". There may be solutions (Bellovin's could be one; not sure of others) that don't. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 11 12:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0L5k-0001a9-Ph; Tue, 11 Jul 2006 12:28:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0L5j-0001a4-Qg for sidr@ietf.org; Tue, 11 Jul 2006 12:28:07 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0L5i-000524-KQ for sidr@ietf.org; Tue, 11 Jul 2006 12:28:07 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.104.95]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G0L5h-0002k6-5w; Tue, 11 Jul 2006 12:28:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200607111442.k6BEgpiD026331@tislabs.com> References: <200607111442.k6BEgpiD026331@tislabs.com> Date: Tue, 11 Jul 2006 12:28:03 -0400 To: sandy@tislabs.com From: Stephen Kent Subject: Re: [Sidr] Transport security Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sidr@ietf.org 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 At 10:42 AM -0400 7/11/06, sandy@tislabs.com wrote: > >EKR has sent a paper on this to bts and tcpm lists. Joe Touch has suggested >>that the right place to discuss this is bts. > >The last comment at the mike in the meeting (I believe it was Lars), >was that the transport area was interested in guidance about this >from security and from routing folk, but that it needed to be done >in the tcpm working group. > >I believe deciding where it gets done is the responsibility of the >ADs involved. > >--Sandy Since all of the proposals say that they are solutions specific to the context of routers, I don't think this is an issue that ought to be handed exclusively in the transport area. It is a routing and security issue. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jul 20 17:11:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3fnP-00063e-VU; Thu, 20 Jul 2006 17:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3flV-0003ag-6G for sidr@ietf.org; Thu, 20 Jul 2006 17:09:01 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3fbo-0005g7-N4 for sidr@ietf.org; Thu, 20 Jul 2006 16:59:03 -0400 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k6KKwtsx062741 for ; Fri, 21 Jul 2006 06:58:55 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060721065544.03078618@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 21 Jul 2006 06:58:53 +1000 To: sidr@ietf.org From: Geoff Huston In-Reply-To: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> References: <6.2.0.14.2.20060704073602.02dbf8e8@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Subject: [Sidr] Minutes for SIDR WG meeting at IETF 66 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 The notes from this meeting were taken by Shane Kerr - thanks Shane. I've attached them to this note. [The agenda, collection of presentations and notes from the IETF 66 SIDR WG meeting are at now uploaded at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 (scroll down to the routing area, and SIDR is the last WG in the Routing Area list)] thanks, Geoff ============== Secure Inter-Domain Routing 2006-07-10 13:00 Chairs: Geoff Huston & Sandy Murphy Minutes: Shane Kerr AGENDA: A. SIDR Session 1) Administrivia 5 minutes - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html - Scribe? - Blue Sheets - Agenda Bashing 2) Certificate Discussion 60 minutes - Certificate Format (Geoff) A Profile for X.509 PKIX Resource Certificates draft-ietf-sidr-res-certs-01.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-01.txt - Certificate Repository (George Michaelson) A Profile for Resource Certificate Repository Structure draft-huston-sidr-repos-struct-00.txt http://www.ietf.org/internet-drafts/draft-huston-sidr-repos- struct-00.txt - ROA Specification (Steve Kent) - Status Report on a trial implementation of Resource Certificates (George Michaelson) 3) Transport Security - Re-keying the TCP MD5 Option (Steve Bellovin) 20 minutes "Key Change Strategies for TCP-MD5" draft-bellovin-keyroll2385-00.txt http://www.ietf.org/internet-drafts/draft-bellovin-keyroll2385-00.txt - A New TCP Authentication Option (Ron Bonica) 20 minutes "Authentication for TCP-based Routing and Management Protocols" http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt - Key Selection for TCP Authentication (Brian Weiss) 20 minutes "Automated key selection extension for the TCP Authentication Option" http://www.ietf.org/internet-drafts/draft-weis-tcp-auth-auto-ks-01.txt - The TCP Simple Authentication Option (Joe Touch) 20 minutes http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-simple- auth-01.txt B. Joint PKIX/SIDR Session - Address Space & As Number PKI (60 min.) Stephen Kent (BBN) This presentation will review the current plans and status for creating a PKI that reflects the allocation of resources through Regional Internet Registries. The motivation for creation this PKI is to enable better security for Internet routing (BGP). Notes: 2.1 Resource Certificate Profile (Geoff Huston) [comments on presentation] Steve Kent: (Comment on key size considerations) Originally 2048 keys for top-tier CA, allowing 1024 for bottom-tier CA; do think you should recommend at *least* 2048 keys, or not ? Steve Bellovin: You don't need a really long key for lower level things, because these are not confidentially keys or even really long term keys Geoff: is 1 year near or long term? Steve: 1 year and 1024 bits is about right for today, and you may want to go a bit shorter. This is not an S/MIME certificate and the considerations are somewhat different. Joe Abley: If SHA-1 is not advisable for today, what happens when SHA-256 is no longer advisable? Steve Kent: That's a fair question, PKIX is working on mechanisms to make it easier to do transitions. The security area is looking at migrating to different hash functions over time. Illjitsch van Beijnum: Is uncomfortable that only LIR may do this, because that means hard-coding the IANA / LIR structure into this mechanism and we have to choose between this structure and a complete lack of security. We should not hard-code this structure. Geoff: there is a different between standards activity and its deployment. This draft does not specify the trust structure or the players. It nominates a PKIX certificate profile that could be used in private context just as easily in a public hierarchy context. Illjitsch: So can I construct my own view of security Geoff: You can configure you own trust anchors. This is a profile for certificate contents, not a Certificate Practice Statement. [return to presentation] [comments following the presentation] Sandy Murphy: this is a routing WG, but there are a lot of details about PKIX. Does the draft need an overview section in the beginning? Sam Weiler: I found it a bit hard to get my head around the drafts. Would like to see a much longer overview and introduction section. Sam Weiler: If I understood the draft correctly, this is not useful for P2P certification? Geoff: The profile does not say who trust anchors are, and it may be used in a peer-to-peer context. However the certificate profile encompasses resource sub-delegation. Sam Weiler: Should be clear that this only satisfies the hierarchical use case. Geoff: I don't understand the utility of resource use with no visible form of trust. Steve Kent: This topic issue hinges on the concept of "trust". In PKI trust is not magically imbued only to certification authorities. Indeed trust is never imbued to certification authorities. In PKIs trust is a decision by relying parties, who choose which certification authorities they are willing to trust by making those certification authorities trust anchors. Each relying party gets to choose which CA they are willing to trust, and this has no dependency on the certificate profile. Every ISP can choose which CA it wishes to adopt as trust anchors. This is a common occurrence, and the characterization is clearly evident if one is willing to read the PKIX standards. Sandy: Question not directed at who you could trust, but what information you could trust them to attest to. Would the certificates give the ability to trust people saying "I trust someone to give me this information no matter where he got it from". Steve: yes, I did answer that question. PKIX structures allow precisely that. The 3379 extensions encompass additional information under the control of the relying party. You could configure a trust reliance in any manner of your choosing. George Michaelson: But if you change the trust anchor surely the crypto on the certificate fails? Steve: Yes, but that's only where trust anchors are certificates. Don't forget that trust anchors are not certificates. Jeff Schiller: Disagree. Getting the trust anchors right and getting the business aspects right are more important than people care to think about. We are falling into the "technology trap" without thinking it through. In routing, players in the middle affect traffic, and creating centralized functions is an asymmetric function in a business sense. This does not lead to customer friendly models. The RIRs can't really "revoke" an address right now. Within this model, the RIR will be able to revoke the certificate, and as a consequence you will be disconnected from the network until the dispute is resolved. This is not a good idea. The ISP is a better place to put this trust. There is choice. Stefan Santesson: In practical life, root (CA) configuration is a local matter, undertaken by the relying party. Your need to have different stores for roots for different purposes. You can actually configure information with a root key in your database to tell local applications what to use it for. You cannot assume that PKI and X.509 solve it for you. Steve Kent: Jeff (Schiller) made interesting observations but missed some points. We are trying to capture the existing structure for the management of this resource. The asymmetry is a fact of life. You cannot go to another ISP, if you got your addresses from the ISP who was our provider. Jeff's example is not illustrative of the general situation with addresses and provider-based address distribution structures. Technical standards do allow different people to have different views of who they want to trust. It is the ISPs who decide where the traffic gets routed. When we are looking at trust anchors, we are looking at ISPs. Russ White: We can get deeply into the business models, but we have to be cautious about the specificity of the model, because the Internet is not the only internet in the world. This technology will be rolled out in other realms for other reasons. Jeff Schiller: We have to come up with some way of managing who the trust anchors are. Doing it exclusively for the RIRs as trust anchors is not a good idea. We are changing things, so we need to be careful. The more configurable we make them, the better off we will be. 2.2. Certificate Repository (George Michaelson) [comments on presentation] Stefan Santesson: Do you use SKI and AKI as names? You should note that RFC 3280 does not enforce that these fields match across issuer / subject chains. George: Yes, that's what we do. If there are critical issues then we can look at that, but it is working for us. Stefan Santesson: Does this model depend on SKI and AKI in the root certificate? George: No. This is not a dependency. Stefan Santesson: You need a name in the certificate? George: The name is CN="function of SKI" is one option, but if there is a name in the request it may be used as the Subject name, and there is always the Alt Subject name. Steve Kent: Your presentation combined building along with design, for instance trust anchors are not certificates. Therefore they are not self-signed certificates. George: Yes we should tighten language. Steve: Since trust anchors are locally managed, not being retrieved from repository, I found it confusing when reading. George: There is a set of bottom-up and top-down considerations when constructing validation paths. Steve: Keep a very clear separation between validation procedure and name model. 2.3 ROA Specification (Steve Kent) This agenda item was covered in the joint PKIX / SIDR session 2.4 Status Report on a trial implementation of Resource Certificates (George Michaelson) There was no time for this agenda item. The presentation material is included in the minutes of the Working Group meeting 3.1 Re-keying the TCP MD5 Option (Steve Bellovin) 3.2 A New TCP Authentication Option (Ron Bonica) 3.3 Key Selection for TCP Authentication (Brian Weiss) 3.4 The TCP Simple Authentication Option (Joe Touch) [comments on the TCP MD5 presentations] Steve Kent: We need to start with a requirements document Illjitsch van Beijnum: Not much harder to change BGP than it is to change TCP. BGP negotiates capabilities. Steve: not convinced that this is the way to go, BGP is supposed to be for reachability not key management. Illjitsch: Joe, what about when two ends configure different keys. Joe: Should not be a big issue. Illjitsch: requirements document is a good idea Alex Zinin: convinced we do need something on this line. Alex Zinin: Some of us have been working on this had a look and it would be interesting to compare the arguments. The motivation that you can have a mechanism that does not require and upgrade of software, do not know how relevant it is. Alex Zinin: Wanted to optimize this for hardware implementation as well. Different for real-time code, versus potential N times multiplier. Wonder if there are brute force attacks (for Steve's idea). Alex Zinin: operations and debugging... having keyid goes a long way helping to debug networks when something goes wrong. Steve: do not disagree, this is a way to get from here to there Lars Eggert: if changes to TCP are required to do this, it needs to be in a different area _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Jul 21 18:09:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G43By-0003rR-Ox; Fri, 21 Jul 2006 18:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G43Bx-0003lP-HS for sidr@ietf.org; Fri, 21 Jul 2006 18:09:53 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G43Bv-0001Sd-ET for sidr@ietf.org; Fri, 21 Jul 2006 18:09:53 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6LM8mg0012160 for ; Fri, 21 Jul 2006 18:08:48 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHJaWVx; Fri, 21 Jul 06 18:08:44 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6LM7etd019678; Fri, 21 Jul 2006 18:07:40 -0400 (EDT) Date: Fri, 21 Jul 2006 18:07:40 -0400 (EDT) Message-Id: <200607212207.k6LM7etd019678@tislabs.com> From: sandy@tislabs.com To: sidr@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sandy@tislabs.com Subject: [Sidr] status report on APNIC trial 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 In case you missed the mention in the minutes: The status report about the APNIC trial of the resourece certificates was not presented at last week's meeting as advertised on the agenda. We just ran out of time. But the slides are available on the proceedings web site, currently available at: http://www3.ietf.org/proceedings/06jul/slides/sidr-3.pdf Since we don't have the commentary of the presenter to help explain the slides, post any questions about them to the list. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 24 21:40:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5BuZ-0008ES-1Y; Mon, 24 Jul 2006 21:40:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5BuX-0008E6-QT for sidr@ietf.org; Mon, 24 Jul 2006 21:40:37 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5BuU-0002m0-0k for sidr@ietf.org; Mon, 24 Jul 2006 21:40:37 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2X007PMRQNX3@szxga03-in.huawei.com> for sidr@ietf.org; Tue, 25 Jul 2006 09:49:35 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2X00BZLRQNAB@szxga03-in.huawei.com> for sidr@ietf.org; Tue, 25 Jul 2006 09:49:35 +0800 (CST) Received: from Z48186 ([10.111.12.60]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2X00CLART8H4@szxml04-in.huawei.com> for sidr@ietf.org; Tue, 25 Jul 2006 09:51:12 +0800 (CST) Date: Tue, 25 Jul 2006 09:39:39 +0800 From: Zhao Ye To: sidr@ietf.org Message-id: <007501c6af8b$31af8820$3c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcavizEnWaOlsFr/QVq+2ml3xMFrmg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Sidr] an architecture draft 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 Hi WG I submitted an architecture draft to sidr. It is only a rough one. I hope it is an initial target to discuss and the ideas in it are useful. Abstract This draft describes an architecture for secure inter-domain routing (BGP [RFC4271]). The architecture consists of components (i.e. functional modules) which address the requirements mentioned in [REQUIREMENT]. The draft describes interfaces (i.e. security services) that the architecture provides to routing engine as well. Zhao Ye _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 24 21:44:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5By6-0001mm-T9; Mon, 24 Jul 2006 21:44:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5By5-0001me-Fx for sidr@ietf.org; Mon, 24 Jul 2006 21:44:17 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5By3-0003Rn-K8 for sidr@ietf.org; Mon, 24 Jul 2006 21:44:17 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2X00A6SS8RY6@szxga02-in.huawei.com> for sidr@ietf.org; Tue, 25 Jul 2006 10:00:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2X00E41S8R3P@szxga02-in.huawei.com> for sidr@ietf.org; Tue, 25 Jul 2006 10:00:27 +0800 (CST) Received: from Z48186 ([10.111.12.60]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2X00CAZRZJH4@szxml04-in.huawei.com> for sidr@ietf.org; Tue, 25 Jul 2006 09:54:58 +0800 (CST) Date: Tue, 25 Jul 2006 09:43:25 +0800 From: Zhao Ye In-reply-to: <007501c6af8b$31af8820$3c0c6f0a@china.huawei.com> To: sidr@ietf.org Message-id: <007601c6af8b$b890cc50$3c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcavizEnWaOlsFr/QVq+2ml3xMFrmgAADgng X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sidr] RE: an architecture draft 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 The url of the draft is http://www.ietf.org/internet-drafts/draft-zhao-sidr-architecture-00.txt. > -----Original Message----- > From: Zhao Ye [mailto:yezhao@huawei.com] > Sent: Tuesday, July 25, 2006 9:40 AM > To: sidr@ietf.org > Cc: Miao Fuyou; yezhao@huawei.com > Subject: an architecture draft > > Hi WG > > I submitted an architecture draft to sidr. It is only a rough one. > I hope it is an initial target to discuss and the ideas in it > are useful. > > Abstract > This draft describes an architecture for secure > inter-domain routing > (BGP [RFC4271]). The architecture consists of components (i.e. > functional modules) which address the requirements mentioned in > [REQUIREMENT]. The draft describes interfaces (i.e. > security services) > that the architecture provides to routing engine as well. > > Zhao Ye > > > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Jul 28 17:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6a6R-0003xn-Dc; Fri, 28 Jul 2006 17:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6a6P-0003kp-7M; Fri, 28 Jul 2006 17:42:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6YmQ-0000tJ-NO; Fri, 28 Jul 2006 16:17:54 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G6YLS-00040J-6d; Fri, 28 Jul 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6SJo1p0023413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G6YLR-0003zB-M5; Fri, 28 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 28 Jul 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-res-certs-02.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 Profile for X.509 PKIX Resource Certificates Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-res-certs-02.txt Pages : 29 Date : 2006-7-28 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-to-use" of an Internet Number Resource (IP Addresses and Autonomous System Numbers). This profile is used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of- use" of the IP addresses and AS numbers that are described in the associated Resource Certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-02.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-res-certs-02.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-res-certs-02.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: <2006-7-28110818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-res-certs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-res-certs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-28110818.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--